We plan on not breaking code after Rust 1.0, except for gated features
mail.mozilla.org
mail.mozilla.org
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.
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.
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
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.
Oh, don't worry. There's plenty of activity in Perl and the CPAN that's not waiting on Rakudo.
While programming languages may "last forever", their viability for real software development is very impacted by their adoption. Languages with limited or minimal adoption will not be usable for anything beyond trivial software systems. Just look at the Modulas, Lisp, and even Haskell.
- Pacabel
This is precisely what the current push towards 1.0 is. You can look at the priority tags on the issue tracker.
> 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.
Rust is currently making all efforts not to be that.
Do you have any information on this or is it just conjecture that MS would attempt such a noble task?
I've only skimmed Rust, but it looks exactly like what I'd want, from trying to do some "systems" type coding in F#. I'm still unconvinced the CLR isn't up to the job - with some annotations for allocation handling, a lot of the performance gap could be closed.
All will fight out.... C++ will thrive under the patronage of its father, C
When is the target for 1.0? That wasn't mentioned in the linked message.
It feels that way to me, too, although in fairness, the amount of changes (i.e. the number of different kinds of edits, as opposed to the number of any one change) has actually been fairly small as I've been updating code to go with the "official" releases.
On the other hand, I would like to see some reasonable period of time with a "feature freeze" before 1.0.
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.
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!
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.
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.
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.
i really wonder why so many are so willing to take this risk, google with Go the mozilla foundation and Rust
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.
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.
I think that's partly due to the increasing acceptance of "polyglot programmers", the realization that many programming concepts are shared across languages and that good programmers work with those concepts rather than just syntax or implementations, the resulting push-back against "X years of experience in Y language" type recruiting, and the "use the right tool for the job" while interfacing across different platforms via defined API/messaging system only.
It's good see all that come together and enable and incentivize a Cambrian explosion of programming language experimentation. Good time to be in the field.