Hacker News Reader

Comment by mihaic | Hacker News Reader

I'm not a big fan of all the complexity of Rust (often just to be different), but this is pure flame-bait.

I'm also not a fan of all the design decisions in Carbon/Cpp2, but progress is being made since paradigms keep evolving.

Memory safety and unique ownership being built into the language seems to be inevitably required in anything that will be used in the future, and honestly I don't think we've reached a stable point yet with anything we have.

If your language only supports adding more complexity and never simplifies syntax, it's inevitably going to be replaced. The same thing will happen with Rust in 20 years, it's just how things go.

View on HN

The complexity ratchet is an interesting problem. I wonder if (or how much) Rust's "edition" system will help. Or if some other mechanisms are needed, and what ideas there are for that.

I suppose eventually you need a bridge to escape to another language. C to Rust bridge is easy. C++ to Rust is a bit harder. I wonder what the Rust to Next Big Language bridge will be like.

> If your language only supports adding more complexity and never simplifies syntax, it's inevitably going to be replaced. The same thing will happen with Rust in 20 years, it's just how things go.

I feel like this won't necessarily happen with Rust, because Rust isn't locked down by any standard, breaking changes can happen and there are also Rust editions which help with the whole process of updating the language. The "better Rust" might just be another revised edition of Rust

While this is true now, I expect this to be the case since it's a reasonably fresh language, and most maintainers of Rust projects are enthusiasts that are fine with breaking changes.

Once you get those 10 year old legacy Rust projects that's when you'll be in a different situation.

There's also a potential paradigm changes (like OOP -> functional pattern) that require a complete redesign of the language, since incremental changes can only get you so far.

Python barely managed to pull of v2 to 3, so I guess the future is open to all options.

Nope, editions cover that use case nicely: Rust breaks things every three years -- without breaking existing code.

Basically you have to opt in your project to the new normal. All your projects dependencies can opt in, too, whenever they want to make the jump. Nobody has to opt in though.

Maybe C++ can do something similar eventually once modules are used everywhere. Those have a much cleaner separation of code between individual project parts than you can have with headers.

Rust is already at a done/stable stage, and won’t make major changes even if it theoretically could.

Change proposals that cause churn are regularly shot down.

Reply on news.ycombinator.com