
Stability as a Deliverable - EduardoBautista
http://blog.rust-lang.org/2014/10/30/Stability.html
======
kibwen
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
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.

~~~
Hemospectrum
Well, the obvious one is your deployment options: You need to either compile
binaries for the target platform, or ask the user to compile from source. As
far as I know, you can't yet compile Rust to Javascript.

Support for GUI toolkits will probably require some glue code. I've heard that
Windows is a particular source of headaches, but I'm not clear as to why. SDL
seems to work everywhere; remember that Rust is designed for seamless C
interop in both directions.

~~~
kyllo
_As far as I know, you can 't yet compile Rust to Javascript._

I don't see why not--Rust uses LLVM as a backend, and LLVM bytecode can
compile to Javascript with emscripten.

Although, I don't really see why you would want to, either.

~~~
vmind
Rust relies on a newer version of LLVM than Emscripten is based on (as
Emscripten-fastcomp is based on the PNaCl fork of LLVM, which is lagging
behind). Once the PNaCl fork is updated and Emscipten rebases, or they rebase
onto LLVM proper, then it should be doable fairly easily.

~~~
kyllo
I see. Thanks for clarifying!

------
steveklabnik
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
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
Just today: [https://github.com/rust-lang/meeting-
minutes/blob/master/wee...](https://github.com/rust-lang/meeting-
minutes/blob/master/weekly-meetings/2014-10-30.md) (aka #236 got merged, #243
is still under discussion)

------
dantiberian
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
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.

~~~
yaantc
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
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.

------
yxhuvud
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
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 :-)

------
jamii
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
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-
langu...](https://github.com/jashkenas/coffeescript/wiki/list-of-languages-
that-compile-to-js)

~~~
jamii
Unfortunately most (all?) of them have performance costs and we are already
eyeing up asm.js for better performance.

~~~
kybernetikos
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.

------
skybrian
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
> 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
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._

------
hoggle
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/)

