|
|
|
|
|
by mnd999
1897 days ago
|
|
I skimmed it, but I think what the author is getting at is that rust demands rigour. The kind of rigour required when failure is a problem and this tends to be the kind of code people get paid to write. I guess the reverse is also true, if you’re writing the kind of code where failure doesn’t matter (e.g. spikes, experimentation, just messing about) perhaps rust isn’t the best choice. |
|
1. provides some unique benefits in terms of safety, and
2. is hard to program and requires rigor
that all that rigor is "worth it", and that it makes you a better programmer to put up with it.
Don't get me wrong, Rust's tradeoffs are valuable for some use-cases, but there are many, many use-cases where a GC'd language will work just fine, and it doesn't make you less professional for choosing a higher level tool which you can be more productive in if you don't have performance or memory constraints.
I also think, as the author alludes to, that many programmers get their first exposure to algebraic types and the elimination of NPE's through Rust, and get the false impression that the benefits of these features are somehow related to the additional complexity required by Rust. But these features are not related. Languages like Swift have shown us that you can get many of the benefits of Rust in terms of providing an "if it compiles it works" experience without many of the challenges Rust imposes on the programmer.