7 ms·

Stability as a Deliverable

steveklabnik 12y ago
I am _incredibly_ excited about working with a language where we ship every six weeks. And furthermore, that these are compatible releases. It changes a lot of things in a really positive way.
- apta 12y ago
  Where does error handling stand (there was a trait-based error handling RFC)? I guess that can be done in a backward compatible way post 1.0.
  - steveklabnik 12y ago
    Just today: https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-10-30.md https://github.com/rust-lang/meeting-minutes/blob/master/wee... (aka #236 got merged, #243 is still under discussion)
jamii 12y ago
I really wish I could use rust for my current work, but it has to be runnable in the browser and it looks like it would take a lot of work to get emscripten on to the same version of llvm as rust. I just spent two hours debugging what turned out to be a "0" where there should be a 0. Turns out that 1 + "0" > 9.
- lifthrasiir 12y ago
  1 + "0" > 9 in JavaScript, right? There are plenty of languages compile to JavaScript [1], maybe you can try some of them. [1] https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
  - jamii 12y ago
    Unfortunately most (all?) of them have performance costs and we are already eyeing up asm.js for better performance.
    - kybernetikos 12y ago
      There are iteration costs in that you're adding a compile step, but in terms of runtime performance, many of the languages are close enough to js that there shouldn't be any cost over hand written js (e.g. typescript, coffeescript,etc). In production you're probably running the whole thing through a minifier anyway, and the most popular of those can actually do performance enhancing transformations too. Google claim that compiled-to-js dart performs better than hand written js, although that is probably a mixture of exaggeration and the effect of the closure compiler which you can run on javascript code anyway.
  - comex 12y ago
    Technically he could have been referring to C, where it's also true that 1 + "0" > 9, albeit with a warning. ;)
- azakai 12y ago
  Yes, but to be fair, that is mostly emscripten's fault, not rust's. Once emscripten rebases onto something more recent (currently it's somewhere around 3.3-3.4), building a single-threaded program using rust shouldn't be that hard.
  - jamii 12y ago
    I saw a related issue on emscripten-fastcomp saying they are based off the pnacl fork of llvm, which is why they are lagging behind. I'm hoping we can use rust eventually but it doesnt look like the kind of problem we can just throw money at - its a pretty big change to emscripten.
    - azakai 12y ago
      That's correct, yes. But pnacl is close to a big update to llvm 3.5, and hopefully emscripten will follow that not long after.
      - jamii 12y ago
        That's good to know, thanks.
dantiberian 12y ago
From looking at Cargo, it seems like Rust will compile everything from source so it won't have the same issues with binary compatibility that you get with different versions of Scala. Is that correct?
- steveklabnik 12y ago
  There is not a plan to have Cargo serve binary blobs, that's correct. However, I'm not familiar enough with the situation in Scala to comment on that part.
  - dantiberian 12y ago
    The short version is that any dependency (compiled) you pull in has to have been built with the same version of Scala you are using. Scala's build tool sbt alleviates this somewhat, though you can still have headaches using Scala libraries from other JVM languages.
  - yaantc 12y ago
    Hi Steve, First thanks a lot for Rust. I have a background in embedded development and the perspective to have a modern, safe by default language available in the future (it's a conservative domain ;) is very exciting! Cargo aside, the question of ABI stability is an interesting one: if an implementation stick to stable features, will it be possible to link code compiled with a newer compiler with a library compiled with an older version? Or is the stability only at the language level for now? I don't think ABI stability is required at this stage. There's been some experience with ABI changes with C++ and it's always possible to deal with it by having interfaces defined using a C ABI (stable) to shield oneself, if needed (if recompiling everything is not practical). But clarifying the status and plan would be nice. Thanks again.
    - kibwen 12y ago
      ABI stability is definitely not guaranteed at this time, as this would require standardizing a huge swath of behavior that is currently internal to the compiler. As mentioned in the OP, this is the same reason why syntax extensions cannot be stabilized as they are. So the answer is sadly no, different versions of the Rust compiler will not be guaranteed to produce binaries that can link to each other, short of using a C ABI.
skybrian 12y ago
This seems rather confusing compared to Go's commitment to stability with their 1.0 release. I can't really tell whether they're freezing the language or not, but it mostly sounds like they aren't.
- steveklabnik 12y ago
  > I can't really tell whether they're freezing the language or not The TL;DR is, > To put it simply, our responsibility is to ensure that you never dread upgrading Rust. If your code compiles on Rust stable 1.0, it should compile with Rust stable 1.x with a minimum of hassle. The language is not being 'frozen' in the sense of never changing. But it will change in an additive way, so the code you write today will compile tomorrow just fine.
  - dbaupp 12y ago
    To add to this: > It’s important to be clear about what we mean by stable. We don’t mean that Rust will stop evolving.
- kibwen 12y ago
  Rust's 1.0 promise is analogous to Go's. Code that works will keep working and new features will come with each new release without breaking old code. The only real difference is Rust's time-based "release train" schedule, compared to Go's milestone-based release schedule.
  - frowaway001 12y ago
    So future releases will only accumulate new features? Because that approach worked so well in ... C++? PHP? JavaScript? Java? C#?
    - kibwen 12y ago
      Future releases will accumulate new features as they are deemed useful to the goal of a memory-safe zero-overhead systems programming language. Rust is not interested in feature maximalism, so dread not the kitchen sink. For the features that we do add, we value orthogonality and clean integration with the rest of the language.
kibwen 12y ago
I still recall my somewhat naive prediction at the time of Rust 0.3 that a stable release would be out by Q1 2013. All things considered, I guess two years isn't that far off. :) So thrilled to see the progress Rust has made in the past three years! It's gone from a kinda-interesting-theoretically language to an ohmigosh-this-is-actually-rad language. I'm giddy for the 1.0 release, so that other people can at last start using it in earnest!
- sillysaurus3 12y ago
  What are some of the big reasons to avoid using Rust (including after the 1.0 release)? Every language has flaws, so I'd like to try to learn from other people's experiences before I stumble across them on my own.
  - na85 12y ago
    Well depending on who you ask, one flaw might be that there's no garbage collector. Others might say that's a bonus.
  - kibwen 12y ago
    The mechanisms that Rust uses to provide memory safety require more forethought than the various forms of garbage collection that other memory-safe programming languages use. If you can happily live with a garbage collector, then Rust may not appeal to you. If you're not doing anything that benefits from concurrency, then Rust's ability to statically prevent data races won't matter to you. From a personal standpoint, the things that I dislike about Rust are the module system (too complex IMO, though it's been getting better recently) and a few places where the syntax is ugly (some of the ugly syntax has good reasoning behind it, but that doesn't mean it's not still ugly). Furthermore, the typical downsides to working with a very young technology will apply. Tooling is minimal. Googling for answers to questions will often be futile. Precedents for how to most effectively solve problems with the language are few. The wider ecosystem has comparatively very few useful libs, and even where libs exist they will often be only partially implemented. In other words, it's going to be a wild west for a while yet.
  - Hemospectrum 12y ago
yxhuvud 12y ago
Aiming at perl level stability seems like a bad idea at version 1.0. There will be mistakes - some of them really horribad. Wouldn't it be a better idea to aim at some kind of Rails level stability, with actually expecting 1->2 to be a total rewrite, 2->3 be a massive undertaking and 3->4 be a quite simple undertaking and then accumulate stability as the good ideas pile up over time?
- _yosefk 12y ago
  Different approaches to stability attract different people. I wouldn't touch a 1.0 that promised 1->2 to be a total rewrite. With a 1.0 that promises backward compatibility, I'll be sure to look into it. More importantly, it's true for whole organizations employing hundreds or thousands of programmers. On the other hand, some people like to work on things that "will always improve", and where compatibility will never be a reason to tolerate a suboptimal design decision in the long run. Which works especially well if their taste matches the taste of whoever is charged with evolving the thing. One could argue that Rails 4.0 or 20.0 beats any 1.9999 version a backward-compatibility-centered system could ever deliver... and one could argue against it. I'm obviously happy that Rust takes the approach that suits me :-)
- sp332 12y ago
  They did that work already. They just had the good sense to keep the version number below 1.0 until it got stable.
- icesoldier 12y ago
  I almost want to liken this attitude to Lua's approach to stability: The general look of the language will remain the same, but some base-line things may change between releases. That's the impression I got from the OP. (Granted, Lua gets used in a far different environment than Rust, so people holding onto an older version for their own projects is not a big deal in Lua. I don't think Rust wants to engender that attitude for its use. I'm not sure, though; I haven't really used Rust nor spent any time in the community.)
hoggle 12y ago
Not quite related but if you found yourself wondering why Rust has semicolon based statement termination - there is a thought provoking article on that topic: "Such a Little Thing: The Semicolon in Rust" http://lucumr.pocoo.org/2012/10/18/such-a-little-thing/ http://lucumr.pocoo.org/2012/10/18/such-a-little-thing/

I am _incredibly_ excited about working with a language where we ship every six weeks. And furthermore, that these are compatible releases. It changes a lot of things in a really positive way.

apta 12y ago
Where does error handling stand (there was a trait-based error handling RFC)? I guess that can be done in a backward compatible way post 1.0.
- steveklabnik 12y ago
  Just today: https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-10-30.md https://github.com/rust-lang/meeting-minutes/blob/master/wee... (aka #236 got merged, #243 is still under discussion)

jamii 12y ago

I really wish I could use rust for my current work, but it has to be runnable in the browser and it looks like it would take a lot of work to get emscripten on to the same version of llvm as rust. I just spent two hours debugging what turned out to be a "0" where there should be a 0. Turns out that 1 + "0" > 9.

lifthrasiir 12y ago
1 + "0" > 9 in JavaScript, right? There are plenty of languages compile to JavaScript [1], maybe you can try some of them. [1] https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
- jamii 12y ago
  Unfortunately most (all?) of them have performance costs and we are already eyeing up asm.js for better performance.
  - kybernetikos 12y ago
    There are iteration costs in that you're adding a compile step, but in terms of runtime performance, many of the languages are close enough to js that there shouldn't be any cost over hand written js (e.g. typescript, coffeescript,etc). In production you're probably running the whole thing through a minifier anyway, and the most popular of those can actually do performance enhancing transformations too. Google claim that compiled-to-js dart performs better than hand written js, although that is probably a mixture of exaggeration and the effect of the closure compiler which you can run on javascript code anyway.
- comex 12y ago
  Technically he could have been referring to C, where it's also true that 1 + "0" > 9, albeit with a warning. ;)
azakai 12y ago
Yes, but to be fair, that is mostly emscripten's fault, not rust's. Once emscripten rebases onto something more recent (currently it's somewhere around 3.3-3.4), building a single-threaded program using rust shouldn't be that hard.
- jamii 12y ago
  I saw a related issue on emscripten-fastcomp saying they are based off the pnacl fork of llvm, which is why they are lagging behind. I'm hoping we can use rust eventually but it doesnt look like the kind of problem we can just throw money at - its a pretty big change to emscripten.
  - azakai 12y ago
    That's correct, yes. But pnacl is close to a big update to llvm 3.5, and hopefully emscripten will follow that not long after.
    - jamii 12y ago
      That's good to know, thanks.

dantiberian 12y ago

From looking at Cargo, it seems like Rust will compile everything from source so it won't have the same issues with binary compatibility that you get with different versions of Scala. Is that correct?

steveklabnik 12y ago
There is not a plan to have Cargo serve binary blobs, that's correct. However, I'm not familiar enough with the situation in Scala to comment on that part.
- dantiberian 12y ago
  The short version is that any dependency (compiled) you pull in has to have been built with the same version of Scala you are using. Scala's build tool sbt alleviates this somewhat, though you can still have headaches using Scala libraries from other JVM languages.
- yaantc 12y ago
  Hi Steve, First thanks a lot for Rust. I have a background in embedded development and the perspective to have a modern, safe by default language available in the future (it's a conservative domain ;) is very exciting! Cargo aside, the question of ABI stability is an interesting one: if an implementation stick to stable features, will it be possible to link code compiled with a newer compiler with a library compiled with an older version? Or is the stability only at the language level for now? I don't think ABI stability is required at this stage. There's been some experience with ABI changes with C++ and it's always possible to deal with it by having interfaces defined using a C ABI (stable) to shield oneself, if needed (if recompiling everything is not practical). But clarifying the status and plan would be nice. Thanks again.
  - kibwen 12y ago
    ABI stability is definitely not guaranteed at this time, as this would require standardizing a huge swath of behavior that is currently internal to the compiler. As mentioned in the OP, this is the same reason why syntax extensions cannot be stabilized as they are. So the answer is sadly no, different versions of the Rust compiler will not be guaranteed to produce binaries that can link to each other, short of using a C ABI.

skybrian 12y ago

This seems rather confusing compared to Go's commitment to stability with their 1.0 release. I can't really tell whether they're freezing the language or not, but it mostly sounds like they aren't.

steveklabnik 12y ago
> I can't really tell whether they're freezing the language or not The TL;DR is, > To put it simply, our responsibility is to ensure that you never dread upgrading Rust. If your code compiles on Rust stable 1.0, it should compile with Rust stable 1.x with a minimum of hassle. The language is not being 'frozen' in the sense of never changing. But it will change in an additive way, so the code you write today will compile tomorrow just fine.
- dbaupp 12y ago
  To add to this: > It’s important to be clear about what we mean by stable. We don’t mean that Rust will stop evolving.
kibwen 12y ago
Rust's 1.0 promise is analogous to Go's. Code that works will keep working and new features will come with each new release without breaking old code. The only real difference is Rust's time-based "release train" schedule, compared to Go's milestone-based release schedule.
- frowaway001 12y ago
  So future releases will only accumulate new features? Because that approach worked so well in ... C++? PHP? JavaScript? Java? C#?
  - kibwen 12y ago
    Future releases will accumulate new features as they are deemed useful to the goal of a memory-safe zero-overhead systems programming language. Rust is not interested in feature maximalism, so dread not the kitchen sink. For the features that we do add, we value orthogonality and clean integration with the rest of the language.

kibwen 12y ago

I still recall my somewhat naive prediction at the time of Rust 0.3 that a stable release would be out by Q1 2013. All things considered, I guess two years isn't that far off. :) So thrilled to see the progress Rust has made in the past three years! It's gone from a kinda-interesting-theoretically language to an ohmigosh-this-is-actually-rad language. I'm giddy for the 1.0 release, so that other people can at last start using it in earnest!

sillysaurus3 12y ago
What are some of the big reasons to avoid using Rust (including after the 1.0 release)? Every language has flaws, so I'd like to try to learn from other people's experiences before I stumble across them on my own.
- na85 12y ago
  Well depending on who you ask, one flaw might be that there's no garbage collector. Others might say that's a bonus.
- kibwen 12y ago
  The mechanisms that Rust uses to provide memory safety require more forethought than the various forms of garbage collection that other memory-safe programming languages use. If you can happily live with a garbage collector, then Rust may not appeal to you. If you're not doing anything that benefits from concurrency, then Rust's ability to statically prevent data races won't matter to you. From a personal standpoint, the things that I dislike about Rust are the module system (too complex IMO, though it's been getting better recently) and a few places where the syntax is ugly (some of the ugly syntax has good reasoning behind it, but that doesn't mean it's not still ugly). Furthermore, the typical downsides to working with a very young technology will apply. Tooling is minimal. Googling for answers to questions will often be futile. Precedents for how to most effectively solve problems with the language are few. The wider ecosystem has comparatively very few useful libs, and even where libs exist they will often be only partially implemented. In other words, it's going to be a wild west for a while yet.
- Hemospectrum 12y ago

yxhuvud 12y ago

Aiming at perl level stability seems like a bad idea at version 1.0. There will be mistakes - some of them really horribad. Wouldn't it be a better idea to aim at some kind of Rails level stability, with actually expecting 1->2 to be a total rewrite, 2->3 be a massive undertaking and 3->4 be a quite simple undertaking and then accumulate stability as the good ideas pile up over time?

_yosefk 12y ago
Different approaches to stability attract different people. I wouldn't touch a 1.0 that promised 1->2 to be a total rewrite. With a 1.0 that promises backward compatibility, I'll be sure to look into it. More importantly, it's true for whole organizations employing hundreds or thousands of programmers. On the other hand, some people like to work on things that "will always improve", and where compatibility will never be a reason to tolerate a suboptimal design decision in the long run. Which works especially well if their taste matches the taste of whoever is charged with evolving the thing. One could argue that Rails 4.0 or 20.0 beats any 1.9999 version a backward-compatibility-centered system could ever deliver... and one could argue against it. I'm obviously happy that Rust takes the approach that suits me :-)
sp332 12y ago
They did that work already. They just had the good sense to keep the version number below 1.0 until it got stable.
icesoldier 12y ago
I almost want to liken this attitude to Lua's approach to stability: The general look of the language will remain the same, but some base-line things may change between releases. That's the impression I got from the OP. (Granted, Lua gets used in a far different environment than Rust, so people holding onto an older version for their own projects is not a big deal in Lua. I don't think Rust wants to engender that attitude for its use. I'm not sure, though; I haven't really used Rust nor spent any time in the community.)

hoggle 12y ago

Not quite related but if you found yourself wondering why Rust has semicolon based statement termination - there is a thought provoking article on that topic: "Such a Little Thing: The Semicolon in Rust" http://lucumr.pocoo.org/2012/10/18/such-a-little-thing/ http://lucumr.pocoo.org/2012/10/18/such-a-little-thing/