3 ms·
Every time there's a new post about 'big new features' in current or future Rust releases there's someone shouting in fear of how Rust is getting more and more
by infogulch 4y ago
Every time there's a new post about 'big new features' in current or future Rust releases there's someone shouting in fear of how Rust is getting more and more complex. Rust may be complex, but 99% of newly added features have not made it more complex than the initial release.
Consider a different language with three orthogonal features. You could think of its 'design space' as a cube, where each feature corresponds to a dimension, and where code that uses some features are a point in the space. If the implementors of this hypothetical language didn't know exactly how all three features should interact together but they could figure out how pairs of features would work, you could imagine their initial implementation as the same cube with a chunk missing out of the corner. Later, after users and implementors gather experience about how the language feels, they make a big proposal: The next release will be a full cube instead of a cube with a corner missing! Wow! Now the big question: did this release make the language "more complex"? Well, it is more capable. But it doesn't add any new orthogonal concepts, it just filled out the full space that was implied by the original three. And arguably "cube" is simpler than "cube with a corner missing".
The design of Rust is the cartesian product of about five primary orthogonal features on top of some basic concepts that might be familiar to C programmers. Maybe they are: lifetimes, generics, traits, enums, unsafe. (Argue away if you choose a different five.) When these features were chosen all the way back in 2015 the designers did their best to consider what might happen if you tried to use various combinations of them at once; but crucially, large portions of the corners of this 'space' were left unimplemented simply because it was too hard to do all at once [1]. 65 releases later, Rust has added very few new features -- as in orthogonal concepts -- [2] but has made a lot of progress filling in bits of the design space that was unimplemented but implied by the original five.
And that's literally what this whole article is about: Niko's vision for filling in Rust's implied design space that was left unimplemented for practical reasons, "Making Rust feel simpler by making it more uniform".
[1]: At some point after you've laid the foundation for a big idea it's better to let your idea tell you how it wants to work instead of forcing it, and that requires time and experience with it.
[2]: async, and that's it?
- gouda-gouda 4y agoThis is the right take. Nikos vision is about polishing what’s already refinement, polishing what’s already there.
- rob74 4y agoMaybe this will be an unpopular opinion here, but I guess that's one of the reasons why Go is easier to use than Rust. Ok, the main reason is of course that you don't have to think about memory management complexities. And Go also has fewer of these "orthogonal features" than Rust. But for those features that are there, they made sure that, as far as possible, every feature was working together with every other feature from the start, and not "we'll start by allowing this only for A, B and C, and then let's see where it goes from there"...
- tasuki 4y agoYes of course Go has fewer orthogonal features than Rust. It has fewer features period. Go is a very simple and not a very expressive language.