Hacker News new | ask | show | jobs
by _bxg1 2283 days ago
> Is there effort to reduce complexity with the language or does it mostly embrace it?

You're right that it isn't a "simple" language (in the Rich Hickey sense of the word). And I don't think there's any effort to actively simplify it.

However, I do expect the rate of complexity growth to taper off fairly soon. Every feature that gets added to Rust is added carefully and with a clear vision in mind. Up until now they've still been building out the foundations of what most people will need when using Rust in different contexts. Recently a lot of this has been ergonomics (like async/await). But I think the rate of features being added is an S-curve, and I think we're nearing the top. Given that, I have hope that it won't follow the same path as C++ in terms of sprawl; it's certainly not as complicated as C++ yet, and if it doesn't keep growing at this rate, I don't think it will become that way.

Part of why C++ is so complicated is that it's had to tack-on decades of language advancements, after the fact, as they were invented/became prevalent. Heck, C++ itself is already a tack-on of C. There wasn't a clear initial vision for the past couple decades of "stuff".

Rust, on the other hand, a) has those decades of ideas to incorporate from the outset in a cohesive way, and b) was started from scratch, not an extension of an existing language. This has so far meant a much clearer sense of vision and big-picture design. These features were made to work together; the roadmap was fairly clear from the beginning.

1 comments

This. Exactly. Also, there is definitely an ongoing effort to make the language simpler, not in the type system which arguably is getting more complex, but in the way the borrow checker is getting smarter. Might be imperceptible at first but really brings a lot in term of ergonomics and productivity.
Simplifying the borrow checker is a slightly different question than simplifying "the language" (meaning the syntax and/or behavior of the syntax), because the latter can break backwards-compatibility (which is why it likely won't happen).

But the borrow checker is an interesting case because simplifying its rules in such a way that they're more tolerant (without sacrificing safety) might reduce cognitive overhead while still being fully backwards-compatible.

The thing is, in some sense, the borrow checker got more complex. But because it accepts more programs, it makes programming in Rust feel less compex. This is related to the waterbed stuff I was talking about elsewhere in the thread.

There is a fine balance here, for example: https://news.ycombinator.com/item?id=22465409

Yeah ! That's was the point I was trying to make. It was a breath of fresh air when I switched from Rust 2015 to Rust 2018, without obvious change in the language from my point of view.