3 ms·

I'm just hoping to avoid the level of instability that I've experienced in my Ruby projects over the years. It makes it nigh impossible to keep a project mainta

I'm just hoping to avoid the level of instability that I've experienced in my Ruby projects over the years. It makes it nigh impossible to keep a project maintained sanely long-term as its dependencies evolve and even the language or stdlib change in backwards-incompatible ways every couple of years.

bm1362 12y ago
I believe you've picked up some wisdom, congrats!
brson 12y ago
Not to dismiss the importance of language stability, but forward porting in Rust should be significantly easier than Ruby for a few reasons: * Rust's strong type system means the pieces fit together only in specific ways - roughly, if you can get it to compile again it will work; in more dynamic languages you have little confidence that the code works until runtime. * Co-evolving the language with the downstream community is such a critical issue that Rust is developing several tools and processes to help, and this should set it apart from other open source languages that have gone down this path: The Rust process already attempts to tag all breaking changes in the commit log with `[breaking-change]` and we've heard anecdotally that this has made forward-porting Servo much easier. This log isn't published anywhere besides the commit log yet, but it will be. Secondly, Rust has a [stability](http://doc.rust-lang.org/rust.html#stability http://doc.rust-lang.org/rust.html#stability) system that tracks API stability at a fine level. This is influenced by node.js, but in Rust stability is detected and use of unstable API's can be enforced by the tooling. This is still in development but you can see it in the [docs](http://doc.rust-lang.org/std/intrinsics/ http://doc.rust-lang.org/std/intrinsics/).
kbenson 12y ago
It's a fine line to walk. Don't change enough and you hemorrhage developers due to not supporting new and interesting features and concepts, change too much and you you hemorrhage developers who don't want to start a new project to run into the same problems as the last one, where an upgrade caused headaches. FWIW I think Rust's tagging of breaking changes (and eventually making them easy to identify and fix) as stated in a same level comment is wise no matter the strategy.
steveklabnik 12y ago
To give some concrete data about Rust's instability: https://gist.github.com/steveklabnik/616e89860446eb2a6732 https://gist.github.com/steveklabnik/616e89860446eb2a6732

bm1362 12y ago

I believe you've picked up some wisdom, congrats!

brson 12y ago

Not to dismiss the importance of language stability, but forward porting in Rust should be significantly easier than Ruby for a few reasons: * Rust's strong type system means the pieces fit together only in specific ways - roughly, if you can get it to compile again it will work; in more dynamic languages you have little confidence that the code works until runtime. * Co-evolving the language with the downstream community is such a critical issue that Rust is developing several tools and processes to help, and this should set it apart from other open source languages that have gone down this path: The Rust process already attempts to tag all breaking changes in the commit log with `[breaking-change]` and we've heard anecdotally that this has made forward-porting Servo much easier. This log isn't published anywhere besides the commit log yet, but it will be. Secondly, Rust has a [stability](http://doc.rust-lang.org/rust.html#stability http://doc.rust-lang.org/rust.html#stability) system that tracks API stability at a fine level. This is influenced by node.js, but in Rust stability is detected and use of unstable API's can be enforced by the tooling. This is still in development but you can see it in the [docs](http://doc.rust-lang.org/std/intrinsics/ http://doc.rust-lang.org/std/intrinsics/).

kbenson 12y ago

It's a fine line to walk. Don't change enough and you hemorrhage developers due to not supporting new and interesting features and concepts, change too much and you you hemorrhage developers who don't want to start a new project to run into the same problems as the last one, where an upgrade caused headaches. FWIW I think Rust's tagging of breaking changes (and eventually making them easy to identify and fix) as stated in a same level comment is wise no matter the strategy.

steveklabnik 12y ago

To give some concrete data about Rust's instability: https://gist.github.com/steveklabnik/616e89860446eb2a6732 https://gist.github.com/steveklabnik/616e89860446eb2a6732