If I see something built for massive concurrency and I see Erlang or Elixir, I'm immediately much more confident in the tooling.
If I see something written in Rust, I'm confident in it's memory safety at a minimum but it usually bodes well for quality code in general.
Built in Rust does not assess of good code quality at all, it just tells you that you will most likely not have a class of bugs or issues, but the code itself can be very ugly.
As a matter of fact given that Rust is "young" most people don't have a lot of knowledge and will most likely copy paterns from other languages, especially when fighting with the borrow checker.
Just open some random Rust code, open the lib.rs and see how things are organized in there, you will be very surprised.
I'm mostly basing that on what I've read about Rust both here and in various other communities about the guarantees provided by the compiler/runtime itself. I haven't even dabbled in it yet myself, but I plan to at some point.
Besides the first-order effects of choice of language on program behavior (e.g. presence of type errors, memory errors, etc.) it also has a second-order filtering effect on the type of people writing programs and their mindset. There are certain languages without a strong first-order effect that nonetheless have a very strong second-order effect.
Now there are other issues other than popularity (like you can expect anything written in JavaScript/Python/Java to have a higher probability of a bloated mess, not only because they're popular...).
"X but in Rust" IME almost always implies something with at best feature parity, but also debloated code
- Rust is a complicated language, so novice developers probably use something else.
- Its ownership/borrowing system makes sure that architecture is not an afterthought (unless you pollute your code with countless smart pointers).
- You get memory safety in safe Rust code and don't need a garbage collector.
- Non-optimal solutions usually are visible/more cumbersome to write.
In the end it's up to the individual developer, but Rust really helps to produce high-quality code.
How's that? The difference between a suboptimal and an optimal solution can be perfectly valid normal code for lots of procedures. It's not something that's knowable without semantic meaning of what the code's trying to do.
- Rust forces you to deal with errors and "null" values (Option). If you just unwrap them, it's visible.
- Rust requires systems with clear ownership. You can opt out with various smart pointers, it's visible.
- Rust requires you to use Box for heap allocations, it's visible.
Note: I'm not talking about optimal solutions in the sense of "best algorithm", more in the sense of "well thought out and without lazy shortcuts".
While I get that languages can eliminate a type of problem, they don't eliminate badly written software. Most of the time, the software development process itself, is more important, if you really want to examine what it means to build secure/safe software.
Having a team dedicated to developing software safely and using a language with stronger type safety guarantees vs. having a person just build something with the same language, does not magically imbue the end product with good qualities.
Take your example, if you don't have a good foundation in distributed systems, and try to build a distributed system in Erlang, you will only get so far, before you hit your head against the wall so hard, you start studying distributed systems instead.
If you ask people explicitly about whether Rust just makes better products, they might say that they have doubts, or give a vague answer. But asking like this is just a leading question, and therefore the process itself of asking the question, will probably cast doubt over some automatic assumptions about what the type safetly of Rust really does for the end product.
But the reality is, "Made with Rust" is starting to look like a certificate/claim of validity, and its definitely not, just like any other language isn't either.
Language adoption isn't just about technical merits (although those have to be there). The ecosystem, tooling, core team, learning resources, and overall community have to be there, too.
To your point - if I want to get started in another language that is 1) statically compiled, 2) non-garbage collected, and 3) memory-safe by design, as far as I can tell my only other mainstream options are Swift / Objective-C, Ada / SPARK, and Nim. I don't see nearly as much activity in those language's open source ecosystems, and "basic" libraries might not even exist due to the small communities.
Care should be taken to not be in so much of a bubble, to not realize that other languages have viable solutions too or are developing alternatives to what's presently available. If our choice for one or the other, is more a matter of personal preference, it would arguably be better to acknowledge such.
This is the second time I've seen someone say this in the last week or so, but I've never seen this claim in the wild, and certainly not by Rust's core team or organization. It's also not a secret that Rust's memory management is heavily influenced by Cyclone. Can you show an example of someone making this claim?