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.
The core language hasn't changed very much at all in the last few months, it's mostly been libraries that have changed. I've been writing "Rust for Rubyists" for the past year, and I started with 0.5. I need smaller and smaller changes each time, and most of them are regex-able.
> 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."
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.
> 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.
Mozilla owe it to themselves to get as many users of Rust as possible, especially if they intend to use it seriously at some point for their own software. Only languages with strong adoption truly survive and provide an ecosystem rich with effective libraries and development tools necessary for them to flourish.
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.
> "popularized before Microsoft's counterpart is ready"
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.
Hmm interesting. The first thing they mention is GC. IMO that's very solvable with manual intervention, and probably not too hard to solve with tooling. A call a simple as String.Split can require allocating multiple objects on the heap just to make the call. (An array to string objects.) There's no reason this couldn't be stack-allocated. Similarly, there's probably lots of code that'd benefit from a pool allocation, like say, processing an HTTP request, where GC can be done just by freeing the pool.
Agreed. The people on Rust's IRC channel are very helpful but are flabbergasted if you are using anything other than HEAD (even the most recent official release is considered ancient history). I'm glad they're willing to make big changes to get everything right, but it seems like things still need a little time to settle before freezing things.
When is the target for 1.0? That wasn't mentioned in the linked message.
> Every time I look at Rust, it still feels incredibly different from the last time I looked into it.
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.
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.
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.
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 (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!
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.
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.
Because current languages aren't good enough for the various domains the two companies are creating them for (Go for server middleware, aiui; Rust for concurrent and safe web browsers), and so by biting the bullet and creating new languages, they can get something curated for exactly what's necessary.
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.
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.
>Seems more languages catch on the last 5-10 years than they did in previous decades.
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.
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.
40 comments
[ 3.8 ms ] story [ 79.5 ms ] threadEDIT: deleted parent said "Better than Python."
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 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.
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.
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.
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.