5 ms·

Look, it's easy to beat up on an article like this and feel good and smug about it. ...but, let's not beat around the bush. Rust has some sharp edges (1). Why

Look, it's easy to beat up on an article like this and feel good and smug about it. ...but, let's not beat around the bush. Rust has some sharp edges (1). Why can't you clone a boxed function? I get it, Box<dyn Foo> isn't sized, so you can't clone it. Ok! ...but you can clone a closure because a raw closure is clone if the contents is clone. Not when it's boxed though. Why cant you express that a struct can contain an object and a reference to the object and have a 'static lifetime? Yes, you can collect::<Result<...>>, but why can't you just use the `?` sugar for it? There's only one possible reason to end a collect() with ? surely? Yup. I get it. Lot of reasons, writing languages is hard. ...but, I dunno. I read this: > the teams working on language design need to SLOW DOWN and focus on ergonomics and composability. ...and I think about `trait ?async` and I read the roadmap (2), and I have to say, I'm sympathetic. More sympathetic then I should be, perhaps, given how ragey the article is... but still. I feel that pain too. I use rust because it's nicer than C++. If it turns into a trash can of features (like C++), why bother? [1] - https://stackoverflow.com/questions/tagged/rust?tab=Frequent https://stackoverflow.com/questions/tagged/rust?tab=Frequent [2] - https://rust-lang.github.io/async-fundamentals-initiative/roadmap.html https://rust-lang.github.io/async-fundamentals-initiative/ro...

anon291 4y ago
We have plenty of languages which have slowed down. I recommend the author use one of them. I will never understand the idea that 'thing X doesn't work for me, thus those behind X need to stop their work to accommodate me, despite the desires of thousands of others'. If you don't like Rust, don't use it. No one is forcing anyone. In particular, languages such as C are incredibly slow moving and well understood.
- wokwokwok 4y ago
  I think the point being made is that rust has lots of users now, and, perhaps, the “thousands of users” who want new features now now now are not the majority of users any more. Those are the demands of passionate early adopters. There are *a lot* of people who don’t like things that move that quickly. Are the rust teams sure they’re serving their user base? Or are they actually pandering to a vocal minority? Are they actually addressing real pain points? Or just working on cool stuff? Have they even asked?
  - sophacles 4y ago
    Did you know you don't have to use every feature? You can write perfectly valid and useful rust code without async or const fn or GATs or ? or whatnot. Rust is really good at additive features - the new features tend to be a strict superset of what was already there, rather than a "you must do it this different way now" set of changes. You might not get to use the latest and greatest versions of libraries that way, but that's the explicit goal of not changing things anyway.
    - t8sr 4y ago
      But that's not true, extra features in the language have a complexity cost. They slow down the compiler, they make certain things ambiguous, add bugs, etc. It's not the case that if I don't use GATs they have zero negative impact on me.
      - sophacles 4y ago
        What things do gats make ambiguous? What bugs did they expose to you that affected non gat use? The compiler hasn't slowed down for them, in fact it was sped up recently. So I'm curious if you can point to instances of your hypotheticals, sure that's all possible, but did it actually happen or are you arguing in the sense of "if you just write perfect code..." and similar grasping at strawmen styles.
        t8sr 4y ago
        If you're claiming that adding complexity to any software project comes without trade-offs then I don't know what to tell you. I will not spend time researching and writing up specific instances where existing complexity made something harder, slower or more bug-prone. If you think that's not a fact, then you're either not arguing in good faith or don't have much experience with real software.
        sophacles 4y ago
        Im not claiming that adding complexity doesn't come with tradeoffs. I never said anything of the sort. > I will not spend time researching and writing up specific instances where existing complexity made something harder, slower or more bug-prone. Im asking very specifically if this is true of rustc for GATs which you called out. I'm literally just asking you to back your claims. I apologize if I made a bad assumption that you were talking about a topic you were actually familiar with. > If you think that's not a fact, then you're either not arguing in good faith You listed some types of negative consequences that may arise from those complexity trade offs then you said: "It's not the case that if I don't use GATs they have zero negative impact on me." I asked if you using GATs caused any of the listed issues for you (or if you knew of cases where adding GATs to rust caused those issues), particularly when not using GATs. Yes there are trade offs, and there are many ways those trade offs might be made. It doesn't mean the specific trade offs you call out were made. The trade offs could be "rustc is harder to develop in the future", "the binary of rustc is bigger", "if and only if developers use GATs, things get slower and they may have bugs", and a myriad of others. None of those impact you the end user of the rust compiler (if you aren't choosing to use GATs anyway). So again: do you have any actual knowledge that the trade offs you listed actually apply in the case you highlighted or are you hypothesizing and strawmanning due to ignorance of the specific case?
- netbioserror 4y ago
  >If you don't like Rust, don't use it. No one is forcing anyone. To be immediately followed by >Marginal systems language (D/Nim/V/Go/Odin/Vale) is useless bikeshedding and has no corporate backer, why would anyone waste their time with this, they should use an established well-known language. PL debates are whiplash.
  - deleted 4y ago
    [deleted]
- lenkite 4y ago
  > If you don't like Rust, don't use it. No one is forcing anyone. Actually, there is a lot of "force" and "forcing" behind Rust.
  - anon291 4y ago
    Last I checked, clang, gcc, g++, gccgo, go, etc are all freely available for download. Do you disagree?
- t8sr 4y ago
  > If you don't like Rust, don't use it. No one is forcing anyone. In particular, languages such as C are incredibly slow moving and well understood. Rust's goal seems to be replacing C++, which kind of means people will have to deal with it. If it's going to be in all these domains, people have to be willing to take criticism constructively. Saying "you don't have to use all these features" doesn't work either - just look at C++. It's the mess that it is precisely because the language designers never learned to say no to the next cool thing someone wanted to add in. At the moment, Rust is opinionated and polarizing. Some people who really like it try to push it everywhere. If and as that happens, people who disagree with a lot of the design choices Rust is making are going to have to have a voice in the community.
  - MichaelZuo 4y ago
    Wasn't the point of C++ to allow for tacking on everything that couldn't get out of committee in C?
bsder 4y ago
> Why can't you clone a boxed function? I get it, Box<dyn Foo> isn't sized, so you can't clone it. Ok! ...but you can clone a closure because a raw closure is clone if the contents is clone. Not when it's boxed though. And closures in Rust can do things that "fully named functions" cannot. Let that one sink in.
- DangitBobby 4y ago
  The only thing I know of is that they can enclose variables from the outer scope where named functions can't. What else?

anon291 4y ago

We have plenty of languages which have slowed down. I recommend the author use one of them. I will never understand the idea that 'thing X doesn't work for me, thus those behind X need to stop their work to accommodate me, despite the desires of thousands of others'. If you don't like Rust, don't use it. No one is forcing anyone. In particular, languages such as C are incredibly slow moving and well understood.

wokwokwok 4y ago
I think the point being made is that rust has lots of users now, and, perhaps, the “thousands of users” who want new features now now now are not the majority of users any more. Those are the demands of passionate early adopters. There are *a lot* of people who don’t like things that move that quickly. Are the rust teams sure they’re serving their user base? Or are they actually pandering to a vocal minority? Are they actually addressing real pain points? Or just working on cool stuff? Have they even asked?
- sophacles 4y ago
  Did you know you don't have to use every feature? You can write perfectly valid and useful rust code without async or const fn or GATs or ? or whatnot. Rust is really good at additive features - the new features tend to be a strict superset of what was already there, rather than a "you must do it this different way now" set of changes. You might not get to use the latest and greatest versions of libraries that way, but that's the explicit goal of not changing things anyway.
  - t8sr 4y ago
    But that's not true, extra features in the language have a complexity cost. They slow down the compiler, they make certain things ambiguous, add bugs, etc. It's not the case that if I don't use GATs they have zero negative impact on me.
    - sophacles 4y ago
      What things do gats make ambiguous? What bugs did they expose to you that affected non gat use? The compiler hasn't slowed down for them, in fact it was sped up recently. So I'm curious if you can point to instances of your hypotheticals, sure that's all possible, but did it actually happen or are you arguing in the sense of "if you just write perfect code..." and similar grasping at strawmen styles.
      - t8sr 4y ago
        If you're claiming that adding complexity to any software project comes without trade-offs then I don't know what to tell you. I will not spend time researching and writing up specific instances where existing complexity made something harder, slower or more bug-prone. If you think that's not a fact, then you're either not arguing in good faith or don't have much experience with real software.
        sophacles 4y ago
        Im not claiming that adding complexity doesn't come with tradeoffs. I never said anything of the sort. > I will not spend time researching and writing up specific instances where existing complexity made something harder, slower or more bug-prone. Im asking very specifically if this is true of rustc for GATs which you called out. I'm literally just asking you to back your claims. I apologize if I made a bad assumption that you were talking about a topic you were actually familiar with. > If you think that's not a fact, then you're either not arguing in good faith You listed some types of negative consequences that may arise from those complexity trade offs then you said: "It's not the case that if I don't use GATs they have zero negative impact on me." I asked if you using GATs caused any of the listed issues for you (or if you knew of cases where adding GATs to rust caused those issues), particularly when not using GATs. Yes there are trade offs, and there are many ways those trade offs might be made. It doesn't mean the specific trade offs you call out were made. The trade offs could be "rustc is harder to develop in the future", "the binary of rustc is bigger", "if and only if developers use GATs, things get slower and they may have bugs", and a myriad of others. None of those impact you the end user of the rust compiler (if you aren't choosing to use GATs anyway). So again: do you have any actual knowledge that the trade offs you listed actually apply in the case you highlighted or are you hypothesizing and strawmanning due to ignorance of the specific case?
netbioserror 4y ago
>If you don't like Rust, don't use it. No one is forcing anyone. To be immediately followed by >Marginal systems language (D/Nim/V/Go/Odin/Vale) is useless bikeshedding and has no corporate backer, why would anyone waste their time with this, they should use an established well-known language. PL debates are whiplash.
- deleted 4y ago
  [deleted]
lenkite 4y ago
> If you don't like Rust, don't use it. No one is forcing anyone. Actually, there is a lot of "force" and "forcing" behind Rust.
- anon291 4y ago
  Last I checked, clang, gcc, g++, gccgo, go, etc are all freely available for download. Do you disagree?
t8sr 4y ago
> If you don't like Rust, don't use it. No one is forcing anyone. In particular, languages such as C are incredibly slow moving and well understood. Rust's goal seems to be replacing C++, which kind of means people will have to deal with it. If it's going to be in all these domains, people have to be willing to take criticism constructively. Saying "you don't have to use all these features" doesn't work either - just look at C++. It's the mess that it is precisely because the language designers never learned to say no to the next cool thing someone wanted to add in. At the moment, Rust is opinionated and polarizing. Some people who really like it try to push it everywhere. If and as that happens, people who disagree with a lot of the design choices Rust is making are going to have to have a voice in the community.
- MichaelZuo 4y ago
  Wasn't the point of C++ to allow for tacking on everything that couldn't get out of committee in C?

bsder 4y ago

> Why can't you clone a boxed function? I get it, Box<dyn Foo> isn't sized, so you can't clone it. Ok! ...but you can clone a closure because a raw closure is clone if the contents is clone. Not when it's boxed though. And closures in Rust can do things that "fully named functions" cannot. Let that one sink in.

DangitBobby 4y ago
The only thing I know of is that they can enclose variables from the outer scope where named functions can't. What else?