For bare metal definitely get a microcontroller and do some fun electronics project.

Easiest to get into is Arduino, but don't stick with that because its only redeeming feature is that it's easy to get into. The IDE sucks, the build system sucks, the APIs really suck, and the code quality is very low (probably because it's easy to get into so you get a lot of inexperienced people doing stuff).

After Arduino I would recommend either going to the Nordic nRF5x series - you can do some cool Bluetooth stuff, or even make you your own radio protocol since the radio peripheral is fully documented... Or ESP32 with Rust and Embassy is probably the most modern and slick way to do microcontrollers.

It does require learning Rust but Rust is really really good so you should do that anyway.

There are some extremely good videos on YouTube about that: https://youtube.com/@therustybits

I would probably still start with Arduino though since you know C. Just don't stay there for too long.

That is not actually a "data race". It is a race condition for sure, but a data race is a very specific thing - where two threads access the same location at the same time and at least one is a write.

That could be unsafe in Rust because it might lead to reading "impossible values" like an enum that isn't equal to any of its variants. Therefore safe Rust must prevent it or there's a soundness hole.

If you find yourself needing this, the correct thing to do is to stop writing that shell scripts and switch to a proper language.

That's nitpicking. It is statically typed. Is Dart not statically typed because it has dynamic.

You could call it "gradually typed" if you want to be pedantic.

can be circumvented pretty easily

That means it isn't sound.

It's not because people are sensitive, it's because Rust gets a lot of dumb criticism and people are tired of it.

I would say:

1. Avoid async if you can. It's way more difficult and error prone than non-async Rust. Unfortunately a lot of web stuff insists on async.
2. Don't be afraid to .clone() stuff to fix lifetime errors. It's not optimal but consider that in C++ everything is pretty much cloned by default, and nobody ever said C++ was slow.
3. Use anyhow::Result for error handling. It's the easiest option.

Yeah I mean it's definitely a reference volume of last resort, rather than a tutorial you would read cover to cover. Clearly a genius but he explains things as if you already understand them, and can also read his mind.

That said, for a lot of the content the only alternative is research papers and they are even less accessible. I definitely would only use it if I couldn't find answers anywhere else though.

Is that even desirable? There are other runtimes for specific things, e.g. for embedded, WASM, Fuchsia, etc. Doesn't seem like there's a one-size-fits-all runtime.

I guess the proper answer is some kind of minimum standard async interface, but presumably there's a reason they haven't done that.

I dunno really, I've avoided async Rust as much as possible due to the number of footguns it has.

Ah yeah that works. Very silly. Phones can zoom!

I agree, too little regard for backwards compatibility. They also removed distutils which meant I had to fix a load of code that used it. It was bad code that shouldn't have used it even when written, but still... seems like they didn't learn their lesson from Python 2.

It's not like it would be difficult to avoid these issues either. Everyone else just makes you declare your "target version" and then the runtime keeps things compatible with that version - Android via SDK target version, Rust with its editions, hell even CMake got this right. CMake!!

It's not a browser issue. There's some weird "responsive" thing that entirely hides the graphs. You probably just have a bigger screen.

I agree. OCaml too. I think there are several factors that lead to it being very difficult to read other people's code:

• Currying and lack of syntax in general means you have to be a human parser for basic things like "which part of the text is a function name? which bits are arguments?". Often it's impossible to tell without looking up the function definitions.
• The functional style - while generally great - also makes it very tempting for people to write enormous heavily nested functions where the control flow is hard to follow. You sometimes get assignment expressions that are hundreds of lines long.
• Haskel & OCaml feature global type inference. Programmers often omit explicit type annotations which very often means that function types are inferred as generic. This means you lose several huge benefits from static types. For example you can no longer look up the types that will actually be passed into the function, and inferring the authors intent is much harder. It also makes error messages way more confusing.
• I don't know why but Haskel and OCaml programmers love stupidly short identifiers.
• They also abhor comments.