6 ms·

This sounds insane at this point. The language already has too many features. Would be cool if all these people with amazing visions could move it elsewhere. R

This sounds insane at this point. The language already has too many features. Would be cool if all these people with amazing visions could move it elsewhere. Rust is fast tracking being as bad as c++ in terms of just garbage in it. IMO the worst thing about c++ isn't that it is unsafe but it is extemely difficult to learn to a satisfying degree. This is already kind of feels true for Rust and it will be surely true if people just keep shoving their amazing ideas into it. IMO even async/tokio/error-handling aren't that well though out in rust. So much for keeping things out of the language. Maybe Rust just wasn't what I wanted and I am salty about it but it feels a bit annoying when I see posts like this and considering where Rust is now after many years of shoving stuff into it

fabiensanglard 8mo ago
I agree that the complexity is getting scary. They keep on adding more and more stuff and it is hard to follow.
- tcfhgj 8mo ago
  Could you expand a bit more?
xiphias2 8mo ago
The main problem I see is adding things slowly instead of automatic rewrites. I remember adding lifetimes in some structs and then wanted to use generics and self pointing with lifetimes because that made sense, and then it didn't work because the composition of some features was not yet part of Rust. Another thing: there are annotations for lifetimes in function signatures, but not inside the functions where there is a lot of magic happening that makes understanding them and working with them really hard: after finally the borrow checking gave me errors, that's when I just started to getting lots of lifetime errors, which were not shown before. Rust should add these features but take out the old ones with guaranteed automatic update path.
- satvikpendem 8mo ago
  The edition mechanism covers your last paragraph.
zozbot234 8mo ago
> The language already has too many features. That's actually the point. Many of these additions can be phrased as unifying existing features and allowing them to be used in previously unusable ways and contexts. There's basically no real increase in user-perceived complexity. The Rust editions system is a key enabler of this, and C++ has nothing comparable.
- pjmlp 8mo ago
  It has clang tidy, -std=lang-version, and preprocessor that is version aware. Rust editions don't cover all use cases that one can think of regarding language evolution, and requires full access to source code.
  - SkiFire13 8mo ago
    > requires full access to source code What do you mean? Editions don't require full access to source code. Rust in general relies heavily on having access to source code, but that has nothing to do with how editions work
    - zozbot234 8mo ago
      You can write a binary library that exposes a C ABI using Rust (which is indistinguishable from an ordinary C/C++ library) and then provide source for a Rust wrapper crate that provides a "safe" interface to it, much like a C header file.
    - pjmlp 8mo ago
      Yes they do, when mixing crates from various editions and how changes interact together.
      - aw1621107 8mo ago
        > when mixing crates from various editions and how changes interact together. Could you elaborate more on this? It's not obvious to me right now why (for example) Crate A using the 2024 edition and Crate B using the 2015 edition would require both full access to both crates' source beyond the standard lack of a stable ABI.
satvikpendem 8mo ago
It doesn't have too many features, it arguably does not have enough. The issue is that the current features don't play nicely with each other, so much of the work has been in making sure they do, such as with async traits as an example: there is no reason why you can make a function async but not inside a trait, and this was the case until very recently. Beyond that, what the article shows is exactly what I want, I want as much type safety as possible especially for critical systems code which is increasingly what Rust is being used for.
- LiamPowell 8mo ago
  This inevitably happens when the approach to language design is "try it and see". I know people here hate design-by-committee, but historically it's led to some very cohesive languages.
  - satvikpendem 8mo ago
    Yes, however how many of them are used in production to some level of scale (not even to the scale of Rust)? Stroustrup's quote and all that. Rust's development process is also design by committee, interestingly enough.
    - LiamPowell 8mo ago
      > Rust's development process is also design by committee, interestingly enough. Sure, but it's still quite informal and they just add things as they go instead of writing a complete standard and figuring out how everything interacts before anything is added to the language. Design-by-committee was probably not the best term to use.
  - metaltyphoon 8mo ago
    > I know people here hate design-by-committee, but historically it's led to some very cohesive languages. C++ is not cohesive at all
    - 8mo ago
jcranmer 8mo ago
You're not wrong here. Not that I'm entirely up-to-speed on all of the deep Rust discussions, but the sense I have of the language evolution is that while there is definitely a loud contingent of people pushing for a lot of the complexity of full effect systems or linear types, these sorts of proposals aren't actually all that likely to actually move forward in the language. (I should note that of all of the features mentioned in this blog post, the only one I actually expect to see in Rust someday is pattern types, and that's largely because it partially exists already in unstable form to use for things like NonZeroU32.)
- satvikpendem 8mo ago
  Yoshua works directly on developing the language, and mentions he is working on these features specifically (he is part of the effects initiative), I'm not sure you won't see these features in Rust.
  - Rusky 8mo ago
    Yoshua is part of the "loud contingent" being described. He's not on the lang team, and he's been "working on" things like keyword generics for years without any indication that they are going to make it into the language.
    - satvikpendem 8mo ago
      > We (Oli, Niko, and Yosh) are excited to announce the start of the Keyword Generics Initiative, a new initiative 1 under the purview of the language team https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-generics/#fn-initiative https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge... Maybe he's not on the language team (I haven't read enough into Rust governance structures to know definitively) but it's not like he's on some random person working on this. And yes, work takes time, I actually disagreed with his initial approach where his syntax was to have a bunch of effects before the function name, and everyone rightly mentioned how messy it was. So they should be taking it slow anyway.
selfmodruntime 8mo ago
After working with Rust for half a decade I‘m afraid I have to agree. A lot of the newer features have weird edge cases with promises for fixes stuck in bikeshedding hell for years (looking at you const generics). Alternatively feature authors wait on dependecies that will never ship.
russdill 8mo ago
I think part of the idea is you and to make it impossible to misuse an underlying API. This can make development much less complex.

fabiensanglard 8mo ago

I agree that the complexity is getting scary. They keep on adding more and more stuff and it is hard to follow.

tcfhgj 8mo ago
Could you expand a bit more?

xiphias2 8mo ago

The main problem I see is adding things slowly instead of automatic rewrites. I remember adding lifetimes in some structs and then wanted to use generics and self pointing with lifetimes because that made sense, and then it didn't work because the composition of some features was not yet part of Rust. Another thing: there are annotations for lifetimes in function signatures, but not inside the functions where there is a lot of magic happening that makes understanding them and working with them really hard: after finally the borrow checking gave me errors, that's when I just started to getting lots of lifetime errors, which were not shown before. Rust should add these features but take out the old ones with guaranteed automatic update path.

satvikpendem 8mo ago
The edition mechanism covers your last paragraph.

zozbot234 8mo ago

> The language already has too many features. That's actually the point. Many of these additions can be phrased as unifying existing features and allowing them to be used in previously unusable ways and contexts. There's basically no real increase in user-perceived complexity. The Rust editions system is a key enabler of this, and C++ has nothing comparable.

pjmlp 8mo ago
It has clang tidy, -std=lang-version, and preprocessor that is version aware. Rust editions don't cover all use cases that one can think of regarding language evolution, and requires full access to source code.
- SkiFire13 8mo ago
  > requires full access to source code What do you mean? Editions don't require full access to source code. Rust in general relies heavily on having access to source code, but that has nothing to do with how editions work
  - zozbot234 8mo ago
    You can write a binary library that exposes a C ABI using Rust (which is indistinguishable from an ordinary C/C++ library) and then provide source for a Rust wrapper crate that provides a "safe" interface to it, much like a C header file.
  - pjmlp 8mo ago
    Yes they do, when mixing crates from various editions and how changes interact together.
    - aw1621107 8mo ago
      > when mixing crates from various editions and how changes interact together. Could you elaborate more on this? It's not obvious to me right now why (for example) Crate A using the 2024 edition and Crate B using the 2015 edition would require both full access to both crates' source beyond the standard lack of a stable ABI.

satvikpendem 8mo ago

It doesn't have too many features, it arguably does not have enough. The issue is that the current features don't play nicely with each other, so much of the work has been in making sure they do, such as with async traits as an example: there is no reason why you can make a function async but not inside a trait, and this was the case until very recently. Beyond that, what the article shows is exactly what I want, I want as much type safety as possible especially for critical systems code which is increasingly what Rust is being used for.

LiamPowell 8mo ago
This inevitably happens when the approach to language design is "try it and see". I know people here hate design-by-committee, but historically it's led to some very cohesive languages.
- satvikpendem 8mo ago
  Yes, however how many of them are used in production to some level of scale (not even to the scale of Rust)? Stroustrup's quote and all that. Rust's development process is also design by committee, interestingly enough.
  - LiamPowell 8mo ago
    > Rust's development process is also design by committee, interestingly enough. Sure, but it's still quite informal and they just add things as they go instead of writing a complete standard and figuring out how everything interacts before anything is added to the language. Design-by-committee was probably not the best term to use.
- metaltyphoon 8mo ago
  > I know people here hate design-by-committee, but historically it's led to some very cohesive languages. C++ is not cohesive at all
  - 8mo ago

jcranmer 8mo ago

You're not wrong here. Not that I'm entirely up-to-speed on all of the deep Rust discussions, but the sense I have of the language evolution is that while there is definitely a loud contingent of people pushing for a lot of the complexity of full effect systems or linear types, these sorts of proposals aren't actually all that likely to actually move forward in the language. (I should note that of all of the features mentioned in this blog post, the only one I actually expect to see in Rust someday is pattern types, and that's largely because it partially exists already in unstable form to use for things like NonZeroU32.)

satvikpendem 8mo ago
Yoshua works directly on developing the language, and mentions he is working on these features specifically (he is part of the effects initiative), I'm not sure you won't see these features in Rust.
- Rusky 8mo ago
  Yoshua is part of the "loud contingent" being described. He's not on the lang team, and he's been "working on" things like keyword generics for years without any indication that they are going to make it into the language.
  - satvikpendem 8mo ago
    > We (Oli, Niko, and Yosh) are excited to announce the start of the Keyword Generics Initiative, a new initiative 1 under the purview of the language team https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-generics/#fn-initiative https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge... Maybe he's not on the language team (I haven't read enough into Rust governance structures to know definitively) but it's not like he's on some random person working on this. And yes, work takes time, I actually disagreed with his initial approach where his syntax was to have a bunch of effects before the function name, and everyone rightly mentioned how messy it was. So they should be taking it slow anyway.

selfmodruntime 8mo ago

After working with Rust for half a decade I‘m afraid I have to agree. A lot of the newer features have weird edge cases with promises for fixes stuck in bikeshedding hell for years (looking at you const generics). Alternatively feature authors wait on dependecies that will never ship.

russdill 8mo ago

I think part of the idea is you and to make it impossible to misuse an underlying API. This can make development much less complex.