
Reject C, return to assembly. Structured programming is the true oppression our generation never talks about.

Reject C, return to assembly. Structured programming is the true oppression our generation never talks about.

That’s silly. Luckily, I don’t think this was the same situation. This was at a university and they had classes with other languages. The beginner classes were split into two variants, where some students (mostly CS students) learned C, and other students (economy, etc.) learned Python. I suppose they figured it was more useful to them or something.

I was a teacher’s assistant in beginner’s programming at university for a bit. I expected them to learn C, which I knew enough of, but I got assigned to a group that learned Python instead. I had never used Python at the time. I ended up having to speed learn it while trying to teach it, to not be completely useless.

That’s definitely part of “the deal” with MIT and Apache. The other end of it is that they shouldn’t really expect to get anything more than what the authors are willing to give.

Simple features are often complex to make, and complex features are often way too simple to make.
It may be possible to use the Any trait to “launder” the value by first casting it to &Any and then downcasting it to the generic type.
let any_value = match tmp_value {
serde_json::Value::Number(x) => x as &Any,
// ...
};
let maybe_value = any_value.downcast_ref::< T >();
I haven’t tested it, so I may have missed something.
Edit: to be clear, this will not actually let you return multiple types, but let the caller decide which type to expect. I assumed this was your goal.

Absolutely, I didn’t mean to suggest otherwise. :) I’m just giving a bit of context and perspective from someone who has used it for a while.

Static types aside, the file system has a lot of failure cases, which every language is affected by, and Rust makes them very visible. This can indeed feel like a lot, but it’s an intentional feature and makes more sense in larger projects. I guess the feeling may get amplified by the author’s style of long form posts with a lot of details.
Error handling in practice contains a lot of “let the caller deal with it”, using the ? operator to pass errors up the call stack. The more verbose options are for when you need to actually handle it.
To make things worse, that teapot doesn’t have a bottom surface.
I liked this talk on the subject: https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase
It’s a nice explanation of how it’s less about code that looks the same or currently performs the same operations, and more about what it means.
Maybe they are trying to manifest its death by arranging its funeral over and over. Programming as an art form isn’t more dead than painting as an art form, as long as people want to do it. However, as the blog post hints at, what you produce for work wasn’t perhaps ever meant to be a work of art. You aren’t necessarily going to be able to write code in your favorite style for work anyway, unless you can influence it and decide the conventions. That has been true since forever in larger organisations.
Props to the blog author for seeking out new experiences in their free time but what they are mourning is either still there (just write your art code) or they have just had to adjust to their new trade-off. Don’t be surprised when it doesn’t feel artistic if you don’t spend any effort on the process.