Hacker News Reader

Comment by ozgrakkurt | Hacker News Reader

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

View on HN

> 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.

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.

> 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

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.

Yes they do, when mixing crates from various editions and how changes interact together.

> 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.

Because in order to have standard library breaking changes across editions, if those types are exposed in the crate public types, or change their semantics across editions, the compiler has to be able to translate between them when generating code.

See the Rust documentation on what editions are allowed to change, and the advanced migration guide on examples regarding manual code migration.

Not so much what has happened thus far, rather the limitations imposed in what is possible to actually break across editions.

Or put another way, a hypothetical feature that you made up in your head is the thing that requires source access. Editions do not let you change the semantics of types.

To be fair, Rust tooling does tend toward build-from-source. But this is for completely different reasons than the edition system: if you had a way to build a crate and then feed the binary into builds by future compilers, it would require zero additional work to link it into a crate using a different edition.

Exactly, hence why people should stop talking about editions as if they sort out all Rust evolution problems, in your own words it doesn't allow changing type semantics

I think you're too stuck on the current implementation. Work is going into investigating how to evolve the standard library over editions. The "easiest" win would be to have a way to do edition-dependent re-exports of types.

What I am stuck is Rust folks advocating editions as the solution for everything in language evolution, when it clearly isn't.

What you're describing sounds more like a potential issue with editions if/when they allow breaking stdlib changes more than a problem with editions as they exist today, which is more what I took the original comment to be talking about.

Exactly because they don't allow it, they don't cover all scenarios regarding language evolution

OK, sure, but again what breaking changes editions do/don't currently allow is independent from what SkiFire13/I was responding to, which was the "requires full access to source code" bit.

How do you expect a compiler to be able to mix and match changes across editions between crates, if those happen to be changes in semantic behaviour?

Depends on the change. Obviously the compiler doesn't need to care about cross-edition compatibility between crates if the changes in question don't impact the public API. Otherwise, I'd expect the compiler to canonicalize the changes, and from what I understand that is precisely how edition changes are chosen/designed/implemented.

https://xkcd.com/927/

Can you explain how this is relevant here?

Adding a new feature to unify existing features is perfectly isomorphic to defining a new standard to unify existing standards.

It's not though, unless the new feature and existing features continue to exist as disjoint things. If the new feature subsumes the old ones, then you've reduced the number of features in the language.

The same is true of standards.

This comparison is useless until rust commits to a stable ABI.

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.

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.

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.

> 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.

> I know people here hate design-by-committee, but historically it's led to some very cohesive languages.

C++ is not cohesive at all

I didn't say this applies to every committee, but I do think the opposite applies to almost every "try it and see" language.

Examples of cohesive languages designed by committees would be Ada and Haskell.

Haskell is anything but cohesive, depending on which feature flags are enabled on GHC, or any other compiler.

Well ok ... experiment but maybe unlike c++ we could have added N keywords removed M keywords for arguably net-simpler language.

Geez I'd hate to be in rust dev shoes if I can't remove something later when I have a better better min/max. I guess this could be done off main, stable.

Rust is also design-by-committee.

> design-by-committee

I don't think it is about having committee, but rather having a spec. And I mean spec, not necessarily ISO standard. There should be a description of how specific features work, what is expected behavior, what is unexpected and should be treated as bug, and what is rationale behind specific decision.

Coincidentally people here hate specs as well, and that explains some things.

I know there is some work on Rust spec, but it doesn't seem to progress much.

AIUI, that is what the MIR formalization work is about, and it seems to be moving along fine. My impression is that covers essentially all the interesting parts of Rust worth specifying formally.

Re: async in traits, the feature was delayed because it relied on the "Generic Associated Types" and "Impl Trait in Traits" features. If Rust delayed the whole `async` feature for working on those pretty type-theoretic features what would you have thought?

Well in practice the async_trait crate worked just fine. If Rust delayed the whole async feature I'd have thought they'd have better been able to handle the function coloring problem via something like OCaml's algebraic effects rather than following the trend of JS and C# back then, as OCaml's came along much later after more research into the model.

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.

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.)

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.

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.

> 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-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.

The thing is that anyone can show up and spend time discussing ideas in Rust project spaces. From the outside it is easy to confuse that with actual movement toward landing changes in the language.

(The communication aspect of this is something that has bothered me many times in the past- even people who are lang team members often phrase things in a way that makes it sound like something is on its way in, when it's still just in the stage of "we're kinda noodling with ideas.")

What complexity?

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

Could you expand a bit more?

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.

The edition mechanism covers your last paragraph.

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.

Reply on news.ycombinator.com