4 ms·

I'm not sure if I'd consider Rust to be a perfect example of this style of design. Most language-level decisions seemed to be mostly dictated by what anyone was

by Tobba_ 9y ago

I'm not sure if I'd consider Rust to be a perfect example of this style of design. Most language-level decisions seemed to be mostly dictated by what anyone was actually able to implement in the compiler, a lot of which was a nigh-incomprehensible mess that only a few people ever touched.

ekidd 9y ago
> Most language-level decisions seemed to be mostly dictated by what anyone was actually able to implement in the compiler This is getting off topic, but that hasn't really been my experience as a user of Rust. Yes, the compiler is full of weird ancient code, but that doesn't seem to constrain the design of RFCs. As far as I can tell: 1. The ancient code in the compiler means that some highly desirable features have taken a couple of years to implement. Granted, some of this is being fixed by the MIR work. But things like stable async/await are probably going to take a while. 2. Some desirable features are constrained by backwards compatibility with existing Rust source. This has affected the module system work, for example. 3. Rust has moved into a particular ecological niche: Precise control over memory allocation and copying, generic types that are monomorphized at compile-time, etc. The best-known language in this space is C++. And so Rust needs to wrestle with many of the same issues that C++ has, such as whether to allow partial specialization. It's certainly not a perfect process, and not everybody will be interested in the particular tradeoffs Rust chose. But it's still one of the best "bazaar"-style projects I've ever seen.
kibwen 9y ago
As a longtime follower of Rust development, I can say for certain that language-level features have never been rejected for being "too tough too implement". Quite the opposite, in fact: major compiler refactorings in order to improve the language happen regularly (e.g. MIR, a new intermediate layer which was needed to support an improved borrow checker (and close about a dozen soundness bugs)). Rust is happy to make the compiler implementor's life difficult in order to make the language user's life easier. Rust also doesn't require anyone proposing RFCs to be at all familiar with the compiler internals; all that RFCs require is a loose approximation of how a given feature will change the documentation and the theoretical language reference. And while the Rust compiler was certainly a mess before 1.0 (due to being written in an ever-changing version of itself), nowadays the compiler is much cleaner. It would also be mistaken to suggest that only a few people ever touched the compiler, as the Rust repo has, AFAICT, one of the highest contributor counts on all of Github (apparently higher than Ruby, Node, Swift, Go, Clang... so far the only ones that I've found that exceed it are rails/rails and torvalds/linux (listed, cheekily, as having "∞ contributors")).
- Tobba_ 9y ago
  Pre-MIR, I'm fairly sure the people who would touch the type/lifetime checker could be counted on one hand, and it was borderline obfuscated due to all the pointless type theory thrown around. RFCs would still get rejected as "postponed" if it wasn't possible to implement them (i.e dependent on MIR). Implementability was the deciding factor from what I could see, though compiler improvements would usually render them un-postponed/rejected later. Overall I think the lack of an actual specification hamstrung it real bad, since everything past one step ahead only existed in peoples heads. And, at least me for me, it can't replace C++ (in every situation) as much as I'd prefer not to have to use that abomination of a language.
  - kibwen 9y ago
    > RFCs would still get rejected as "postponed" if it wasn't possible to implement them (i.e dependent on MIR) Indeed, but postponed emphatically does not mean "rejected". :) It means "we think we still might want this, but we don't yet have enough information to ensure that it will work nicely with the rest of the language". Sometimes this is because of prerequisite implementation work, indeed, but other times it's simply because designing a feature takes time and energy (gated on the language/library teams, in which sense Rust isn't really a pure bazaar at all) and not all features are equally prioritized. > Pre-MIR, I'm fairly sure the people who would touch the type/lifetime checker could be counted on one hand, and it was borderline obfuscated due to all the pointless type theory thrown around. Firstly, one of the places where type theory definitely isn't pointless is when implementing a type checker* (of which borrowck counts as well). :P Secondly, the difficulty of contributing to type checkers in general has little to do with implementation and lots to do with the aforementioned type theory. Thirdly, even pre-MIR, the librustc_typeck directory had 105 contributors, and the librustc_borrowck dir had 60 (and that's only counting back to Nov 2014).

by Tobba_ 9y ago

ekidd 9y ago

> Most language-level decisions seemed to be mostly dictated by what anyone was actually able to implement in the compiler This is getting off topic, but that hasn't really been my experience as a user of Rust. Yes, the compiler is full of weird ancient code, but that doesn't seem to constrain the design of RFCs. As far as I can tell: 1. The ancient code in the compiler means that some highly desirable features have taken a couple of years to implement. Granted, some of this is being fixed by the MIR work. But things like stable async/await are probably going to take a while. 2. Some desirable features are constrained by backwards compatibility with existing Rust source. This has affected the module system work, for example. 3. Rust has moved into a particular ecological niche: Precise control over memory allocation and copying, generic types that are monomorphized at compile-time, etc. The best-known language in this space is C++. And so Rust needs to wrestle with many of the same issues that C++ has, such as whether to allow partial specialization. It's certainly not a perfect process, and not everybody will be interested in the particular tradeoffs Rust chose. But it's still one of the best "bazaar"-style projects I've ever seen.

kibwen 9y ago

As a longtime follower of Rust development, I can say for certain that language-level features have never been rejected for being "too tough too implement". Quite the opposite, in fact: major compiler refactorings in order to improve the language happen regularly (e.g. MIR, a new intermediate layer which was needed to support an improved borrow checker (and close about a dozen soundness bugs)). Rust is happy to make the compiler implementor's life difficult in order to make the language user's life easier. Rust also doesn't require anyone proposing RFCs to be at all familiar with the compiler internals; all that RFCs require is a loose approximation of how a given feature will change the documentation and the theoretical language reference. And while the Rust compiler was certainly a mess before 1.0 (due to being written in an ever-changing version of itself), nowadays the compiler is much cleaner. It would also be mistaken to suggest that only a few people ever touched the compiler, as the Rust repo has, AFAICT, one of the highest contributor counts on all of Github (apparently higher than Ruby, Node, Swift, Go, Clang... so far the only ones that I've found that exceed it are rails/rails and torvalds/linux (listed, cheekily, as having "∞ contributors")).

Tobba_ 9y ago
Pre-MIR, I'm fairly sure the people who would touch the type/lifetime checker could be counted on one hand, and it was borderline obfuscated due to all the pointless type theory thrown around. RFCs would still get rejected as "postponed" if it wasn't possible to implement them (i.e dependent on MIR). Implementability was the deciding factor from what I could see, though compiler improvements would usually render them un-postponed/rejected later. Overall I think the lack of an actual specification hamstrung it real bad, since everything past one step ahead only existed in peoples heads. And, at least me for me, it can't replace C++ (in every situation) as much as I'd prefer not to have to use that abomination of a language.
- kibwen 9y ago
  > RFCs would still get rejected as "postponed" if it wasn't possible to implement them (i.e dependent on MIR) Indeed, but postponed emphatically does not mean "rejected". :) It means "we think we still might want this, but we don't yet have enough information to ensure that it will work nicely with the rest of the language". Sometimes this is because of prerequisite implementation work, indeed, but other times it's simply because designing a feature takes time and energy (gated on the language/library teams, in which sense Rust isn't really a pure bazaar at all) and not all features are equally prioritized. > Pre-MIR, I'm fairly sure the people who would touch the type/lifetime checker could be counted on one hand, and it was borderline obfuscated due to all the pointless type theory thrown around. Firstly, one of the places where type theory definitely isn't pointless is when implementing a type checker* (of which borrowck counts as well). :P Secondly, the difficulty of contributing to type checkers in general has little to do with implementation and lots to do with the aforementioned type theory. Thirdly, even pre-MIR, the librustc_typeck directory had 105 contributors, and the librustc_borrowck dir had 60 (and that's only counting back to Nov 2014).