6 ms·

I'm getting seriously concerned about feature-creep in Rust. I understand that there was an initial period of rapid growth as the community figured out what was

by _bxg1 7y ago

I'm getting seriously concerned about feature-creep in Rust. I understand that there was an initial period of rapid growth as the community figured out what was needed, and that some of Rust's syntax sugar makes a very real difference in productivity. But Rust is already not a simple language. It already has long compile times, and some of its syntax sugar already makes it harder to understand what's really going on when you invoke it. I think it's important that the Rust community start reeling in frivolous sugar, otherwise it may just become C++ all over again.

Ar-Curunir 7y ago
Can you name some examples of "frivolous sugar"? Also compile times have been a big focus of the compiler team, and have been going down YoY.
- _bxg1 7y ago
  > Can you name some examples of "frivolous sugar"? The one mentioned in the article seemed fairly frivolous to me. I don't know if I can name one that's already been accepted into the language which I would call frivolous, per se, though they're all varying degrees of necessary. But most of the "sugar" syntaxes have made the language harder to understand for newcomers, even the ones that are arguably necessary. They all come with a cost. The ? syntax for Results, for example, rubs me the wrong way a little bit. In that case it really does eliminate a large amount of code and is probably worth the trade-off. But now instead of Results just being a monad that can be picked apart like any other data structure, they become a Language Feature that gets special, magical treatment not expressible by the type system. You just have to know what the question mark translates to underneath. Worthwhile or not, this makes me sad. Async/await is a similar case. > Also compile times have been a big focus of the compiler team, and have been going down YoY. Yes but adding complexity to the language immutably increases the difficulty of that task. Even if only by a little bit, it adds debt that will have to be reckoned with for the rest of the language's lifetime.
  - hobofan 7y ago
    I don't completely buy the argument for `?`. Yes, you have to know what it compiles down to, but the same goes for any other part of `std::ops` (like Deref, Index, etc.). In that way the addition of `?` as `std::ops::Try` doesn't imply "special, magical treatment not expressible by the type system", but gives it the deserved representation in the type system that was possible anyway, and hooks it up with a syntax that is only achievable with compiler support.
  - dthul 7y ago
    > But now instead of Results just being a monad that can be picked apart like any other data structure, they become a Language Feature that gets special, magical treatment not expressible by the type system. I believe, but please correct me if I'm wrong, that the try operator (`?`) does nothing which lies outside of the type system. It just transforms let v = expr?; into let v = match expr { Ok(v) => v, Err(e) => return Err(e.into()), };
    - dgb23 7y ago
      '?' is an almost completely useless language feature IMO. The second block is much clearer and uniform. When reading the first you implicitly read it as the second, which introduces mental overhead. The only upside of having '?' is to write less code, which is the worst kind of syntactic sugar: It makes the writer type less for a couple of seconds, but the result is harder to read. Now even if one doesn't agree with the above it is still a bad feature. Why? Because the upside of it just doesn't outweigh the cost of having any syntactic language feature like this. And I don't just mean the energy invested in introducing it into Rust, but also the continuous cost of having to deal and respect it in future changes. This is a bad case of hyper-optimization within a very narrow scope combined with bikeshedding.
      - dthul 7y ago
        This is all subjective of course. I for example feel the exact opposite of what you described, and I think the overwhelming majority of Rust coders prefers it to explicit matching (which I find is just code noise).
- lightgreen 7y ago
  Lots of operations on Option and Result for example, and more and more added constantly. They don’t make code readable and it’s hard to remember it and often simple match is easier to write then trying to remember what’s the suitable function exist for the operation. https://doc.rust-lang.org/std/result/enum.Result.html https://doc.rust-lang.org/std/result/enum.Result.html
  - Ar-Curunir 7y ago
    That’s not syntactic sugar, just normal method calls.
  - _bxg1 7y ago
    > Lots of operations on Option and Result for example, and more and more added constantly. You mean methods? I actually don't have any issue with adding more methods and trait implementations, because those can be understood within the existing framework of language-level concepts. Of course the docs also need to highlight the "normal" usage with examples, but those do exist for Result, just not on this page: > See the std::result module documentation for details. std::result has quite a good explanation of "what are Results for and how are they normally used".
- thomasahle 7y ago
  Syntactic sugar has been a big point of confusion in my path to learning Rust. Often I think I have understood something, try to verify by doing the wrong thing, but then because of sy tactic sugar it still works. Two recent things come to mind: - Automatic dereferencing, which can dereference arbitrarily long chains of indirection. This makes it hard to figure out which types I have. - That `match` somehow accepts a reference to an enum, and then magically turns it into an enum over references. Not that I don't think these will be worth it in the long run, but it makes the language harder to learn.
  - _bxg1 7y ago
    Yes. I've used Rust (in a hobby capacity) for a couple years now, I've written a fair amount of C++ and have a clear understanding of how pointers and references work, yet these two cases you mention sometimes remain mysterious to me. I've developed an intuition for "how to use them" but I don't always know exactly what they're going to do, because their meaning shifts under my fingers to try and match up with what's most convenient. I've just learned how to fiddle with them until the compiler accepts them. There's a fog over the code when they come into play.
  - thomasahle 7y ago
    There was also something odd about `Box<T>` automatically dereferencing, as well as `&&T`, but not `&Box<T>`. I can't remember if `Box<&T>` will dereference, which makes it feel like a set of arbitrary rules I just have to memorize.
xyzzy_plugh 7y ago
Yes, this is my concern as well. I used Rust semi-seriously around the time it launched 1.0 (the cake was delicious!) but as an ex-professional C++ dev who loathes C++ very very much, I have a hard time finding Rust any more palatable these days. I'd probably still choose C if I needed to.
- _bxg1 7y ago
  Rust is still much less complicated than C++ IMO. For now. I'm hoping it doesn't catch up in 20 years.
deleted 7y ago
[deleted]

by _bxg1 7y ago

Ar-Curunir 7y ago

Can you name some examples of "frivolous sugar"? Also compile times have been a big focus of the compiler team, and have been going down YoY.

_bxg1 7y ago
> Can you name some examples of "frivolous sugar"? The one mentioned in the article seemed fairly frivolous to me. I don't know if I can name one that's already been accepted into the language which I would call frivolous, per se, though they're all varying degrees of necessary. But most of the "sugar" syntaxes have made the language harder to understand for newcomers, even the ones that are arguably necessary. They all come with a cost. The ? syntax for Results, for example, rubs me the wrong way a little bit. In that case it really does eliminate a large amount of code and is probably worth the trade-off. But now instead of Results just being a monad that can be picked apart like any other data structure, they become a Language Feature that gets special, magical treatment not expressible by the type system. You just have to know what the question mark translates to underneath. Worthwhile or not, this makes me sad. Async/await is a similar case. > Also compile times have been a big focus of the compiler team, and have been going down YoY. Yes but adding complexity to the language immutably increases the difficulty of that task. Even if only by a little bit, it adds debt that will have to be reckoned with for the rest of the language's lifetime.
- hobofan 7y ago
  I don't completely buy the argument for `?`. Yes, you have to know what it compiles down to, but the same goes for any other part of `std::ops` (like Deref, Index, etc.). In that way the addition of `?` as `std::ops::Try` doesn't imply "special, magical treatment not expressible by the type system", but gives it the deserved representation in the type system that was possible anyway, and hooks it up with a syntax that is only achievable with compiler support.
- dthul 7y ago
  > But now instead of Results just being a monad that can be picked apart like any other data structure, they become a Language Feature that gets special, magical treatment not expressible by the type system. I believe, but please correct me if I'm wrong, that the try operator (`?`) does nothing which lies outside of the type system. It just transforms let v = expr?; into let v = match expr { Ok(v) => v, Err(e) => return Err(e.into()), };
  - dgb23 7y ago
    '?' is an almost completely useless language feature IMO. The second block is much clearer and uniform. When reading the first you implicitly read it as the second, which introduces mental overhead. The only upside of having '?' is to write less code, which is the worst kind of syntactic sugar: It makes the writer type less for a couple of seconds, but the result is harder to read. Now even if one doesn't agree with the above it is still a bad feature. Why? Because the upside of it just doesn't outweigh the cost of having any syntactic language feature like this. And I don't just mean the energy invested in introducing it into Rust, but also the continuous cost of having to deal and respect it in future changes. This is a bad case of hyper-optimization within a very narrow scope combined with bikeshedding.
    - dthul 7y ago
      This is all subjective of course. I for example feel the exact opposite of what you described, and I think the overwhelming majority of Rust coders prefers it to explicit matching (which I find is just code noise).
lightgreen 7y ago
Lots of operations on Option and Result for example, and more and more added constantly. They don’t make code readable and it’s hard to remember it and often simple match is easier to write then trying to remember what’s the suitable function exist for the operation. https://doc.rust-lang.org/std/result/enum.Result.html https://doc.rust-lang.org/std/result/enum.Result.html
- Ar-Curunir 7y ago
  That’s not syntactic sugar, just normal method calls.
- _bxg1 7y ago
  > Lots of operations on Option and Result for example, and more and more added constantly. You mean methods? I actually don't have any issue with adding more methods and trait implementations, because those can be understood within the existing framework of language-level concepts. Of course the docs also need to highlight the "normal" usage with examples, but those do exist for Result, just not on this page: > See the std::result module documentation for details. std::result has quite a good explanation of "what are Results for and how are they normally used".
thomasahle 7y ago
Syntactic sugar has been a big point of confusion in my path to learning Rust. Often I think I have understood something, try to verify by doing the wrong thing, but then because of sy tactic sugar it still works. Two recent things come to mind: - Automatic dereferencing, which can dereference arbitrarily long chains of indirection. This makes it hard to figure out which types I have. - That `match` somehow accepts a reference to an enum, and then magically turns it into an enum over references. Not that I don't think these will be worth it in the long run, but it makes the language harder to learn.
- _bxg1 7y ago
  Yes. I've used Rust (in a hobby capacity) for a couple years now, I've written a fair amount of C++ and have a clear understanding of how pointers and references work, yet these two cases you mention sometimes remain mysterious to me. I've developed an intuition for "how to use them" but I don't always know exactly what they're going to do, because their meaning shifts under my fingers to try and match up with what's most convenient. I've just learned how to fiddle with them until the compiler accepts them. There's a fog over the code when they come into play.
- thomasahle 7y ago
  There was also something odd about `Box<T>` automatically dereferencing, as well as `&&T`, but not `&Box<T>`. I can't remember if `Box<&T>` will dereference, which makes it feel like a set of arbitrary rules I just have to memorize.

xyzzy_plugh 7y ago

Yes, this is my concern as well. I used Rust semi-seriously around the time it launched 1.0 (the cake was delicious!) but as an ex-professional C++ dev who loathes C++ very very much, I have a hard time finding Rust any more palatable these days. I'd probably still choose C if I needed to.

_bxg1 7y ago
Rust is still much less complicated than C++ IMO. For now. I'm hoping it doesn't catch up in 20 years.

deleted 7y ago

[deleted]