Rust is hard to get started with, but once you reach optimal development speed, I can't see how you can go back to any other language.
I have a production application that runs on Rust. It never crashed (yet), it's rock solid and does not require frequent restarts of the container due to memory leaks or whatever, and every time I need to fix something, I can jump into code after weeks of not touching it, and being confident that my changes won't break anything, as long as the code complies (and is free of logical bugs).
I can't say the same about any other language, and I use a few of them in production: NodeJS, Ruby, Python, Java. Each of them has their own quirks, and I'm never 100% confident that changes in one place of the code won't cause harm in another place, or that the code is free of stupid bugs like null-pointer exceptions.
I like writing C and still write C from time to time, but I've migrated to Rust for my hobbyist embedded projects and I just cannot imagine going back. It took me some time to work out how to get Embassy working smoothly, but now I just have a project template that's (for my purposes) absolutely rock solid. Rust and Cargo made embedded fun again for me.
Basically all of my struggling now is entirely based around hardware specifics rather than ironing out kinks in my code and I'm into that.
100% agreed. After writing Rust as my day job and using it in production for the last 2 years, my only criticism is the lack of a good high level standard library (like Go) and the insanity and fragmentation of Future type signatures.
Though at this point, I wish I could write everything in Rust - it's fantastic
Also, I can't wait to (practically) use it as a replacement for JavaScript on the web
It's great for web servers and build tools but has work to do on the client side. It's difficult or impossible to write GUI applications in Rust (despite that being a great use case via macros and fearless concurrency)
re: noarch, emscripten-32, and/or emscripten-wasm32 WASM packages of rust on emscripten-forge a couple days ago. [1][2]
emscripten-forge is a package repo of conda packages for `linux-64 emscripten-32 emscripten-wasm32 osx-arm64 noarch` built with rattler-build and hosted with quetz:
https://repo.mamba.pm/emscripten-forge
Evcxr is a rust kernel for jupyter; but jupyter-xeus is the new (cpp) way to write jupyterlite kernels like xeus-, xeus-sqlite, xeus-lua, xeus-javascript, xeus-javascript
First of all, even if C++ is not 100% safe, that is the go to language when I want to delve into OpenJDK, CLR, V8, GCC and LLVM internals, followed by the language everyone speaks when talking about graphics programing and compute.
Adding something else to the mix, doesn't help, only hinders the reception from other folks, being the strange dude wanting to spoil their party.
Secondly, if I want use a ML type system, I have plenty of options in managed languages.
Naturally as computer nerd, I play with all programming languages, including Rust.
Which doesn't mean I have any business case to push for it.
I do wonder how much of this is "rust" vs "people who pick rust".
Like nothing stops you from littering your codebase with `.expect("TODO: Fix Later")`. This isn't just in your code too; it applies to your dependencies with Hyper returning a Result instead of a RuntimeException.
I have a production application that runs on Rust. It never crashed (yet), it's rock solid and does not require frequent restarts of the container due to memory leaks or whatever, and every time I need to fix something, I can jump into code after weeks of not touching it, and being confident that my changes won't break anything, as long as the code complies (and is free of logical bugs).
I can't say the same about any other language, and I use a few of them in production: NodeJS, Ruby, Python, Java. Each of them has their own quirks, and I'm never 100% confident that changes in one place of the code won't cause harm in another place, or that the code is free of stupid bugs like null-pointer exceptions.