Rust Language Maintenance

General Prog (Archived)
,
1

Found an article posted recently that nicely summarizes the Rust Language Maintenance process

https://increment.com/programming-languages/maintaining-rust

A few things of note:

  • Rust has a language spec, as all languages should have and almost all ‘big’ languages have. (Elixir really really badly needs a language spec).
  • Rust since 1.0 does not break backwards compatibility (however there is a list of things to change at 2.0 ‘eventually’) and is split into 3 ‘levels’. There is ‘stable’, ‘beta’, and 'nightly.
    • Nightly includes the new features, these may or may not proceed to ‘beta’ depending on whether it is determined that they should be or not (in general most are except for compiler plugin support as it is generally considered that it needs a better overall design). Every 6 weeks features that are considered ‘complete’ and useful are moved to ‘beta’.
    • Beta includes features that are slated for release, they will only not be released if an egregious bug or design fault is encountered. Every 6 weeks the features that are considered “Well Tested” (popular ones may only need a single 6-week testing period, less popular ones may need more) are moved to ‘stable’.
    • Stable is the full release, only including things that are in general considered well designed, well tested, and well useful. Tends to have a new release every 6 weeks I think.
  • There is a rust-standard manager called ‘rustup’ that is the scaffolding for the rust system. By default it will install and use ‘stable’, but you can switch to stable/beta/nightly as well as any target-triple it can compile to (great for cross-compilation). It has about 90% overall community usage since Rust included it as it’s Official distribution manager (the rest tend to either manually manage their rust install or still use the old multirust manager).
  • New features are added to rust via RFC’s, living documents posted via standard markup to a rust-rfc specific repo. The purpose of this is to encourage discussion. If it gets no or negative discussion then it will eventually be closed by a bot. If it gets only positive discussion then it gets looked at by the main core programmers to vet and if it passes their worth/soundness/usefulness checks then it gets accepted. If it gets mixed discussion then it will be looked at by the core programmers to work out the overall worth, soundness, and usefullness of the feature to be vetted or not.
  • Once an RFC is accepted then it is open to the community to create a PR for or a core programmers will eventually get to it (generally depending on the idea popularity). Once a PR is made and is feature complete to the RFC with an appropriate test suite then it gets tested by a few bots and other core programmers, if all accept it then it gets merged into nightly.

Now admittedly Elixir is not big enough (yet) to need this whole process, but it might be worth absorbing some of the ideas. :slight_smile:

11 Likes
2

Related links from Elxir

1 Like
3

In a certain sense, I bet Elixir will never bee as “big” as rust. Rist is a big languagec with lots of syntactic structures and lots of concepts. It also breaks AST compatibility all the time (or so I’ve read). This means that macros are an unstable feature.

Elixir is vey different. It’s a much smaller language, with little syntax, and is commited to keeping AST compatibility. You can evolve the language via macros (which is risky in rust because compatibility is nor guaranteed).

It’s also married to the BEAM, so it can’t grow very innovative features comparative to what it has now (unless you achoeve them with macros or something like that)