Nowadays when I see "written in Rust" in the title, it reads like special pleading: "It's maybe not as good as what you use, but we are really proud to have got it working at all."
For the tech savvy crowd, we care about stuff like this because we don't need another electron app hogging memory on our systems. Personally for me "written in rust" translates to "I care about performance" and "I care about my app not hogging your system memory"
And other hilarious jokes you can tell yourself
Free market forces based on individual self-interest have proven to be really bad at doing that, so altruism is needed to fill the gap.
...by that logic, I prefer software written in Rust to software written in C++ or Java Script even if it's worse from a user perspective, as long as it's tolerably worse rather than just unusable.
Ripgrep has completely upended my expectations (in a good way) for what modern machines are capable of. I'm all for OCD perfectionism if it means the performance I dreamed of in the 90's in finally realized.
On the contrary, the rust crate ecosystem and tooling means a lone developer can compose specialised libraries to produce a working artefact that scratches her own itch. Such productivity is the opposite of getting something working at all.
Trying to build an OSS cpp project or even worse, use an OSS Cpp library in your own project is more along the lines of "getting something working at all". Every third-party and some enterprise-internal Cpp libraries require one answers the following questions:
- how do I build the damn thing?
- how do I run the tests?
- how do I use the library? Vendor into the repo? apt install?
- what APIs does the system/library provide?
- where can I find the documentation and examples?
- how do I set up code completion?
- how do I know am using the library interface correctly?
- how do I know I didn't violate any invariants/safety guarantees?
Compare with the list of dependencies across the Cargo workspace members.
https://github.com/lapce/lapce/blob/master/lapce-core/Cargo....
https://github.com/lapce/lapce/blob/master/lapce-ui/Cargo.to...
https://github.com/lapce/lapce/blob/master/lapce-rpc/Cargo.t...
The cost of adding a new rust dependency when measured by the number of questions you need to answer beforehand is nearly constant. This means a layman can be more productive in rust.
More importantly, though: how hard is it to use a library coded in C++ from your Rust program? You have to make and maintain some sort of shim layer. Even a C library needs some such effort. For any given need, you are much less likely to find an existing and suitable Rust library already written, released, and maintained than one in some other, more widely used, language.
This is true.
However the Cargo/Rust ecosystem has one standard answer, read the associated crate docs, e.g.:
Coincidentally, the above linked crate `libloading` also shows how to access functionality in a shared library that exposes a C ABI compatible interface whatever the implementation language.
The only case I know of where I would need a Rust program is to check a blake3 hash. That won't last.
I am not sure what "essential tool" means if pandoc included in it. For me Intellij, Eclipse, Dbeaver are more essential (+ few other Specific tools based on Eclipse).
C# - I am not sure, MS Office?
I've heard good things about Bat and Exa - I personally have never felt a huge need for them, but other people claim that they're pretty essential to them.
alacritty is a Rust program that is promoted as uniquely fast, but is substantially slower than (e.g.) kitty.
Load a rust program into mem, change mem, run rust program. You’ve just lost safety.