3 ms·

I'd consider C++ as the worst of the worst when it comes to ease of entry. Compared to, say Javascript, Ruby, or Go, Rust has a secondary set of rules that pro

I'd consider C++ as the worst of the worst when it comes to ease of entry. Compared to, say Javascript, Ruby, or Go, Rust has a secondary set of rules that programmers have to learn before they can even do the most simple things. As an experienced programmer, I look at most Rust code with bewilderment. This is after a week of studying the language. I can look at Python and instantly understand what's happening, without any knowledge of the language. I can look at Go's standard library code and instantly know what it's doing, without any previous knowledge of the language. That seems to me to be the goal of a language. I don't know much about those languages and if they scale or whatever, but they look like they'd be productive. I look at most C++ and it's on the edge of being incomprehensible if anyone does anything remotely abstract. And that's with 10+ years of experience in the language. Rust, to me seems like it chooses to prioritize memory correctness and speed over everything else, including productivity. Maybe I'll hack away at learning it for another few weeks and something will click, but for now it's an uphill battle. That to me is a barrier to entry that will not help it gain traction.

zozbot234 7y ago
> Rust has a secondary set of rules that programmers have to learn The rules are not that hard if you're somewhat familiar with the constraints of functional programming. Rust requires you not to rely on shared, mutable state, unless specifically enabled - thus, by default, you're essentially writing FP code using a 'procedural' paradigm and syntax. It is also possible to do "quick, exploratory" programming in Rust; it just requires somewhat liberal use of language facilities such as .clone() and RefCell<>, to specify things that would mostly be implicit in other memory-safe languages. (And because these somewhat problematic features are so clearly marked in the resulting code, it becomes fairly easy to directly refactor it into better-performing, idiomatic Rust.)
- thekingofh 7y ago
  > thus, by default, you're essentially writing FP code using a 'procedural' paradigm and syntax I've not heard it described this way. It's an idea I can get behind. A lot of the native code I write tends to try and be as functional as possible, or at least avoiding relying on shared mutable state. And don't get me wrong. I think that Rust is a significant upgrade to the status quo. Perhaps it's just time to keep hacking away at it until it clicks.

zozbot234 7y ago

> Rust has a secondary set of rules that programmers have to learn The rules are not that hard if you're somewhat familiar with the constraints of functional programming. Rust requires you not to rely on shared, mutable state, unless specifically enabled - thus, by default, you're essentially writing FP code using a 'procedural' paradigm and syntax. It is also possible to do "quick, exploratory" programming in Rust; it just requires somewhat liberal use of language facilities such as .clone() and RefCell<>, to specify things that would mostly be implicit in other memory-safe languages. (And because these somewhat problematic features are so clearly marked in the resulting code, it becomes fairly easy to directly refactor it into better-performing, idiomatic Rust.)

thekingofh 7y ago
> thus, by default, you're essentially writing FP code using a 'procedural' paradigm and syntax I've not heard it described this way. It's an idea I can get behind. A lot of the native code I write tends to try and be as functional as possible, or at least avoiding relying on shared mutable state. And don't get me wrong. I think that Rust is a significant upgrade to the status quo. Perhaps it's just time to keep hacking away at it until it clicks.