3 ms·

There seems to be a happy point in languages where it's easy enough to get up and running, but complex enough to come back through and tighten things up. Like h

There seems to be a happy point in languages where it's easy enough to get up and running, but complex enough to come back through and tighten things up. Like how Python allows a secondary file for parameter types in the function signatures. Also how tools like Flow for javascript has the bolt on type checking. To me, the perfect language seems to be one that does the annoying things like that for you and lets the programmer focus on the actual logic. Languages like Rust seem to be a reaction against the problems caused by dynamic typing, but I'm not sure that forcing all that burden onto the programmer is the right answer yet. The languages that ease newcomers into the language tend to do well. Rust is like a brick to the face. Does that mean Rust won't take over the world? Who knows. I do know that what they're doing with it does seem to be the future, but the language is difficult, even for experienced programmers to learn.

zozbot234 7y ago
Rust eases newcomers into the language a lot more than C++ does. As there are plenty of novices learning C++ as their first(!) programming language, I'm not sure why newcomers would be expected to have more of an issue with Rust
- thekingofh 7y ago
  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.
- pjmlp 7y ago
  Try to write a GUI application, or game, in both C++ and Rust and see which one ends up being more newcomer friendly.
  - majewsky 7y ago
    Is it fair to compare GUI frameworks with over 20 years of maturity (Qt, GTK+) with others that are less than a few years old and still mostly in their exploratory stages?
    - pjmlp 7y ago
      It is, because the issue is the language semantics to deal with typical UI workflows. You are forced to use Rc<RefCell<>> and clone everywhere, or copy objects around, reactive style, to kind of work around borrow checker ergonomics.
      - majewsky 7y ago
        Only if you use a binding to a traditional UI framework. There is an opportunity here to research wholly new classes of UI frameworks. Data binding like in React lends itself nicely to ownership/borrowing semantics, for example. The React-like Relm may only be a first glimpse of what's to come.
        pjmlp 7y ago
        Reactive UIs produce too many allocations, most developers aren't comfortable using them and most importantly lack of UI designers.

zozbot234 7y ago

Rust eases newcomers into the language a lot more than C++ does. As there are plenty of novices learning C++ as their first(!) programming language, I'm not sure why newcomers would be expected to have more of an issue with Rust

thekingofh 7y ago
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.
pjmlp 7y ago
Try to write a GUI application, or game, in both C++ and Rust and see which one ends up being more newcomer friendly.
- majewsky 7y ago
  Is it fair to compare GUI frameworks with over 20 years of maturity (Qt, GTK+) with others that are less than a few years old and still mostly in their exploratory stages?
  - pjmlp 7y ago
    It is, because the issue is the language semantics to deal with typical UI workflows. You are forced to use Rc<RefCell<>> and clone everywhere, or copy objects around, reactive style, to kind of work around borrow checker ergonomics.
    - majewsky 7y ago
      Only if you use a binding to a traditional UI framework. There is an opportunity here to research wholly new classes of UI frameworks. Data binding like in React lends itself nicely to ownership/borrowing semantics, for example. The React-like Relm may only be a first glimpse of what's to come.
      - pjmlp 7y ago
        Reactive UIs produce too many allocations, most developers aren't comfortable using them and most importantly lack of UI designers.