After trying rust only for a few hours i really wonder how come this language remain the most loved one on surveys. From the outside it looks like a niche language you'd only use for super constrained or critical environments.
Take backend dev for example: unless you're trying to squeeze the last drop of performance from your CPU, most concurrency issues are usually dealt with at the middleware level (DB, Queue, Nginx, etc), and most performance issues are usually I/O related.
I'm currently evaluating developing a cross-platform mobile native library using Rust, but i really don't see myself inflicting the pain of that language to the rest of my team.
Or maybe it's just a reflection on how active the community is ?
edit: i realize a lot of people are probably still coding in C because they have no other choice, and for them it's probably a good idea to switch. However, for all the rest i really don't see the point.
>After trying rust only for a few hours i really wonder how come this language remain the most loved one on surveys
Arguably, it's because you tried it "only for a few hours". Rust has a relatively steep learning curve and it usually takes several months to become comfortable with it. But once you get over it, it often becomes quite hard to return to your previous languages, be it Python or C/C++.
Yes, there are tasks which are ill-fit for Rust and your IO-bound backend example is a good one. Not only Rust ecosystem is somewhat underdeveloped in this area (and don't get me started on Rust async and the heap of troubles it causes...), but also you have business requirements which change unpredictably and Rust's strictness introduces a certain friction in such environment.
But I think your mobile library can be a good project to properly learn Rust. If it's properly encapsulated, I don't think it will cause much trouble to your team outside of build system changes and risks associated with you being its sole developer.
> Arguably, it's because you tried it "only for a few hours". Rust has a relatively steep learning curve and it usually takes several months to become comfortable with it. But once you get over it, it often becomes quite hard to return to your previous languages, be it Python or C/C++.
You failed to address OP's point.
OP wondered why would he, or anyone, subject anyone else to a steep learning curve if there are no meaningful advantages to be gained.
As OP mentioned:
> Take backend dev for example: unless you're trying to squeeze the last drop of performance from your CPU, most concurrency issues are usually dealt with at the middleware level (DB, Queue, Nginx, etc), and most performance issues are usually I/O related.
Why do you believe that doubling down on a whole new programming language and tech stack would help address the fact that you do not benefit from any of it's sales pitches?
Honestly, your comment reads like a boilerplate reply to any criticism of Rust that presumes Rust's only problem is it's developer experience caused by it's learning curve but once that's behind anyone it's somehow the ideal solution for any imaginable scenario.
It's competing with C/C++/Go/Nim/Zig, not Python and JS.
I don't use it because I don't have a need for low level coding on platforms with mature Rust support, but if I did I am pretty sure it would be my language of choice without hesitation.
Rust has a unique experience. Initially you hate it, right up to the point where you grok it, then you love it because you realize it save you from so many boneheaded errors that C/C++ allow you to do easily. You can still do them in Rust, but you can't do them unintentionally (generally). The borrow checker, the forced composition over inheritance, and the trait mechanisms are major wins.
I tried Rust once and found it pretty interesting. The moment I left was when I wanted to write a simple web scraper, so I found a library, installed it… and found out that it had downloaded a gigabyte of dependencies.
I find it incredible that when I try out a project, it easily pulls in a GB of files. It's a space and bandwidth junkie. I long for a lo-fi version, fully UNoptimized but fast.
My doubt is if it'll work over a basic mobile phone connection, and that lots of folks in developing countries, as I also will be soon, will be left out because of this behavior.
Yes, it has a bit of the same problem Node does with NPM.
There are ways to minimize the final resulting binary though, such as link time optimization, stripping symbols, building in release mode, and more. The following does a good job going over the options:
It’s not just about performance. It’s the maintainability and correctness that its amazing type system gives you. Refactoring and maintaining code is so much easier when the compiler tells you when you missed something.
Take backend dev for example: unless you're trying to squeeze the last drop of performance from your CPU, most concurrency issues are usually dealt with at the middleware level (DB, Queue, Nginx, etc), and most performance issues are usually I/O related.
I'm currently evaluating developing a cross-platform mobile native library using Rust, but i really don't see myself inflicting the pain of that language to the rest of my team.
Or maybe it's just a reflection on how active the community is ?
edit: i realize a lot of people are probably still coding in C because they have no other choice, and for them it's probably a good idea to switch. However, for all the rest i really don't see the point.