I don’t think Rust is perfect, but arguably I do “idolize” it, because I genuinely think it’s notably better both in design and in practice than every other language I’ve used. This includes:
C
C++
Java
C#
Kotlin
Scala
Python
Ruby
JavaScript (…I’ve barely used this, but I doubt my opinion would change on this one)
Perl
Go
Bash (…look, I’ve had to write actual nontrivial scripts with loops and functions, so yes, Bash is a real language; it just sucks)
Tcl/Tk (if you don’t know, don’t ask)
CommonLisp (…again, I’ve barely used this, and I wish I had more experience with this and other Lisps)
In a literal sense, I agree that all (practical) languages “are flawed.” And there are things I appreciate about all of the above languages (…except Tcl/Tk), even if I don’t “like” the language overall. But I sincerely believe that statements like “all languages are flawed” and “use the best tool for the job” tend to imply that all (modern, mainstream) languages are equally flawed, just in different ways, which is absolutely not true. And in particular, it used to be true that all languages made tradeoffs between a fairly static, global set of binary criteria:
safety/correctness versus “power” (i.e. low-level system control)
safety/correctness versus run-time efficiency (both parallelism and high single-thread performance)
ease-of-use/ease-of-learning versus “power” and runtime-efficiency
implementation simplicity versus feature-richness
build-time versus run-time efficiency
type-safety versus runtime flexibility
Looking at these, it’s pretty easy to see where most of the languages in my list above fall on each side of each of these criteria. What’s special about Rust is that the core language design prevents a relatively novel set of tradeoffs, allowing it to choose “both” for the first two criteria (though certainly not the latter three; the “ease-of-use” one is debatable) at the expense of higher implementation complexity and a steeper learning curve.
The great thing about this isn’t that Rust has “solved” the problem of language tradeoffs. It’s that Rust has broadened the space of available tradeoffs. The assumption that safety necessarily comes at a runtime cost was so pervasive prior to Rust that some engineers still believe it. But now, Rust has proven, empirically, that this is not the case! And so my ultimate hope for Rust isn’t that it becomes ubiquitous; it’s that it inspires even better languages, or at least, more languages that use concepts Rust has brought to the mainstream (such as sum-types) as a means to explore new design tradeoff spaces. (The standard example here is a language with a lightweight garbage-collecting runtime that also has traits, sum-types, and correct-by-default parallelism.)
There are other languages that, based on what I know about them, might inspire the same type of enthusiasm if I were to actually use them more:
Erlang
Gleam
OCaml
Swift
…but, with the exception of Swift, these are all effectively “niche” languages. One notable thing about Rust is that its adoption has actually been rather astounding, by systems language standards. (Note that D and Ada never even got close to Rust’s popularity.)
Eh, technical merit is only one of many factors that determine what language is the “best”. Best is inherently a subjective assessment. Rust’s safety and performance is the conceptual bible rustacians use to justify thier faith.
I also know religious people who have written books about their faith too (my uncle is a preacher and my ex-spouse was getting their doctorate in theology). Rust has the same reality-blind, proselytizing zealots.
The needs of the project being planning and the technical abilities of the developers building it are more important that what language is superior.
I like rust. I own a physical copy of the book and donated money to the rust foundation. I have written a few utilities and programs in rust. The runtime performance and safety is paid for in dev time. I would argue that for most software projects, especially small ones, Rust adds too much complexity for maintainability and ease of development.
[warning: “annoying Rust guy” comment incoming]
I don’t think Rust is perfect, but arguably I do “idolize” it, because I genuinely think it’s notably better both in design and in practice than every other language I’ve used. This includes:
In a literal sense, I agree that all (practical) languages “are flawed.” And there are things I appreciate about all of the above languages (…except Tcl/Tk), even if I don’t “like” the language overall. But I sincerely believe that statements like “all languages are flawed” and “use the best tool for the job” tend to imply that all (modern, mainstream) languages are equally flawed, just in different ways, which is absolutely not true. And in particular, it used to be true that all languages made tradeoffs between a fairly static, global set of binary criteria:
Looking at these, it’s pretty easy to see where most of the languages in my list above fall on each side of each of these criteria. What’s special about Rust is that the core language design prevents a relatively novel set of tradeoffs, allowing it to choose “both” for the first two criteria (though certainly not the latter three; the “ease-of-use” one is debatable) at the expense of higher implementation complexity and a steeper learning curve.
The great thing about this isn’t that Rust has “solved” the problem of language tradeoffs. It’s that Rust has broadened the space of available tradeoffs. The assumption that safety necessarily comes at a runtime cost was so pervasive prior to Rust that some engineers still believe it. But now, Rust has proven, empirically, that this is not the case! And so my ultimate hope for Rust isn’t that it becomes ubiquitous; it’s that it inspires even better languages, or at least, more languages that use concepts Rust has brought to the mainstream (such as sum-types) as a means to explore new design tradeoff spaces. (The standard example here is a language with a lightweight garbage-collecting runtime that also has traits, sum-types, and correct-by-default parallelism.)
There are other languages that, based on what I know about them, might inspire the same type of enthusiasm if I were to actually use them more:
…but, with the exception of Swift, these are all effectively “niche” languages. One notable thing about Rust is that its adoption has actually been rather astounding, by systems language standards. (Note that D and Ada never even got close to Rust’s popularity.)
I know religious people who could not explain their faith so specifically.
Because they just have their own brain chemistry as the basis of it whereas the above comment clearly states:
Which is truth. And it’s much easier to base a coherent argument on truth rather than vibes.
Eh, technical merit is only one of many factors that determine what language is the “best”. Best is inherently a subjective assessment. Rust’s safety and performance is the conceptual bible rustacians use to justify thier faith.
I also know religious people who have written books about their faith too (my uncle is a preacher and my ex-spouse was getting their doctorate in theology). Rust has the same reality-blind, proselytizing zealots.
The needs of the project being planning and the technical abilities of the developers building it are more important that what language is superior.
I like rust. I own a physical copy of the book and donated money to the rust foundation. I have written a few utilities and programs in rust. The runtime performance and safety is paid for in dev time. I would argue that for most software projects, especially small ones, Rust adds too much complexity for maintainability and ease of development.