
We plan on not breaking code after Rust 1.0, except for gated features - steveklabnik
https://mail.mozilla.org/pipermail/rust-dev/2013-December/007588.html
======
wycats
We said this in the early days of Ember. Specifically, that while we were
still making a lot of changes to Ember before 1.0, that we were going to go to
strict SemVer compatibility post-1.0.

This made it clear to early adopters that things were rapidly changing, so you
needed to be comfortable with that. It also helped people understand _why_
there was so much breakage leading into 1.0, because it was in service of a
much more stable post-1.0.

Since 1.0, we take Semver pretty seriously, and I think the strategy of being
pretty unstable pre-1.0 in service of a very stable post-1.0 has paid off.

~~~
tikhonj
Actually, this is already built into Semver. 0. _._ is reserved for
development and conveys no stability promises. See point 4 on
[http://semver.org/](http://semver.org/).

------
Pxtl
It still feels too early to say that. Every time I look at Rust, it _still_
feels incredibly different from the last time I looked into it. I'm excited
about this language, and I hope they get it out of the gate and popularized
before Microsoft's counterpart is ready... but it's so far from solidified
right now that I'm worried they might be rushing into 1.0

Of course, nobody wants their language to be forever a toy instead of
something actually _used_ , so I get the the pressure to settle things.

~~~
derefr
> Every time I look at Rust, it still feels incredibly different from the last
> time I looked into it.

I think this is a _good_ sign, as far as stabilization goes. It means they're
frontloading all the experimentation, rather than saying "maybe next version."

~~~
Pacabel
But when does the front-loaded experimentation phase end? When is it "good
enough" to get a stable, usable release out there into the wild? It's easy to
say "Before the end of 2014." but I think we potential users need to start
seeing something more definite. While Rust isn't at a Perl 6 type situation
just yet, it creeps closer ever day. There are a lot of us who want to use
Rust today, and we can settle for some imperfections. What I don't think we
can settle for is a language that remains in an alpha or beta state after 5
years, or even 10 years.

\- Pacabel

~~~
derefr
> but I think we potential users need to start seeing something more definite.

Why? A potential user isn't owed anything; Mozilla hasn't done a marketing
push to capture you, gotten you to sign up for a developer program, or offered
Rust up as the solution to any given problem you have. They haven't promised
you anything. They're just tinkering with Rust like you'd tinker with a custom
car in your garage. Also, unlike Perl 6, there's nothing that's laying fallow
in an increasingly-desperate way while they work on Rust.

On the other hand, a programming language is forever. I'd rather have a
programming language a decade late, that I can use for 40 years, than a
programming language right now that gets outmoded after four.

~~~
chromatic
_there 's nothing that's laying fallow in an increasingly-desperate way while
they work on Rust._

Oh, don't worry. There's plenty of activity in Perl and the CPAN that's not
waiting on Rakudo.

------
mitchellh
Go also has a very strict compatibility promise:
[http://golang.org/doc/go1compat](http://golang.org/doc/go1compat)

This has been fantastic because I know my Go program won't break anytime in
the foreseeable future (Go 2, if I were to guess, is still a decade away).
Additionally, since the compatibility promise is not only in the language but
also in the standard lib (to be expected, perhaps), I know that that isn't
going to break either.

It is pretty neat for a new version of a language runtime/compiler to be
released and to just recompile your app and see dramatic improvements.

This is in stark contrast to a language such as Ruby, where each version
released, even when they say is backwards compatible, has been at least a
minor headache to upgrade to due to behavioral differences.

NOTE: I'm NOT NOT NOT comparing Go to Rust. Let's not open that can of worms.

~~~
millstone
The golang link says "binary compatibility for compiled packages is not
guaranteed between releases." Compare to, say, g++, which takes ABI
compatibility very seriously, even to allowing you to select an ABI at compile
time:
[http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html](http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html)
(maybe Go has that feature too, I don't know).

Anyways, I can see how from a Ruby perspective, Go's policy may appear strict.
But from my C-family perspective, "we reserve the right to break ABI
compatibility with each release" is a liberal policy, not a strict one. What's
even neater is seeing your app get better without a recompile!

~~~
nknighthb
Three main issues:

1) GCC didn't stabilize its C++ ABI until GCC 3.2, released almost 15 years
after C++ support was initially added to GCC, and 4 years after the ISO
standard was finalized.

(This is where I say "You damn kids get off my lawn!".)

2) At this point, ABIs simply don't matter for the Go in the same way. There
is no dynamic linking in the original Go implementation, and you're not
expected to be static-linking modules that you don't have the source for.
That's just a basic assumption of the Go ecosystem: You have the source.

Once the binary is built, it will continue to run so long as the kernel's
userspace ABI remains compatible.

The GCC Go implementation can, of course, implement a stable ABI if it wants,
and that will probably become necessary if and when it supports dynamic
linking (I'm not sure if it does yet, I've only used the original Go suite).

3) Go is designed to compile extremely quickly. Fast enough that you really
shouldn't care if your program has to be recompiled. It should take seconds,
not minutes or hours.

~~~
millstone
1\. Yep. A stable C++ ABI is hard, and limiting, and in a practical sense, C++
has never had one. You simply can't do something like return a `vector<int>`
from a function and have it work reliably across different dylib versions.
Your options here are "distribute the source" (Microsoft with MFC) or "don't
use C++" (Apple with ObjC).

2\. Right, they don't matter _yet_ , because Go has pivoted to target servers
instead of end user software. ABI compatibility is a first world programming
problem: "we are so mature that we care about applications that have already
been distributed to end users running correctly against later versions of
libraries that will also be distributed to end users." Go isn't there yet, but
it can cross that bridge when it reaches it.

3\. Aw hell naw. If my end users have to recompile my software after
reinstalling anything, then I've failed as an engineer.

------
sandGorgon
I'm not an expert in Rust, and things are moving too fast to keep up, but does
anyone know what UI bindings is/will-be available for Rust.

After all, it is intended as a browser development language. I wanted to try
it out versus Vala - but am not sure if GTK is going to be the official
binding.

------
nashashmi
I just studied Rust tutorial and my GOD it is amazing! I love RUST.

------
systems
investing in creating a new language is too much risk, very few languages get
the popularity needed to guanranty their longivity

i really wonder why so many are so willing to take this risk, google with Go
the mozilla foundation and Rust

~~~
coldtea
Seems more languages catch on the last 5-10 years than they did in previous
decades.

Here a few that weren't around (or just starting) 5-6 years ago, but have nice
communities and even industry adoption now: Go, Scala, Clojure, Clojurescript,
Coffeescript.

> _I really wonder why so many are so willing to take this risk, google with
> Go the mozilla foundation and Rust_

What risk? Google spends all of like 10 million dollars per year for Go (if we
are to count the salaries of several developers, which it also uses to make
other stuff), which is spare change for them.

And the reason is that they find that there is a need that isn't properly
covered.

~~~
ma2rten
The risk is that you are using a legacy language in some of your products
which no one else knows how to write in.

~~~
coldtea
Noted how Google didn't wholesale adopt Go? And also how they started using
some of it here and there (a YouTube MySQL balancer, a downloads tool) AFTER
there was decent adoption of it already?

Not to mention that at the scale of Google, they can pay for the continued
development of 5 or 10 languages and/or compilers to suit their needs (and,
well, they do: Dart, Closure, Go, V8, their Unladden Swallow experiment etc
etc), as well as train stuff to use it. And it's not like an half-competent
Google employee can't learn how to "write in" Go in a week or so.

So, it's not a case like some random startup chosing to use an obscure
language -- those indeed would have the problem of not finding enough hires.

------
Yuioup
Offtopic but are there any good examples of projects using Rust?

~~~
steveklabnik
The Rust compiler itself and Servo are the two largest. There are a bunch of
smaller projects on GitHub too, if you search.

------
macspoofing
Still hate the name 'Rust'

