Announcing Rust 1.0-alpha2
blog.rust-lang.org
blog.rust-lang.org
Currently, I'm on the verge of choosing the language I will choose for an important project I'm about to start, I have a good knowledge of Rust and I think it's a great language, but despite all of this I think I will pass on Rust for this project because I'm not sure I'm ready / be able to keep-up with this level of changes.
Can you comment on that -- possibly entirely incorrect -- concern I have about Rust's development? Are we going to see Rust 2.x popping up in six months?
Furthermore, and this is speculation, since again, we haven't talked about it as a group, but I wouldn't imagine a Rust 2.0 where it's like breaking changes are today. I would imagine a very long period of deprecations, a nice upgrade path, and all that jazz. Nobody likes when the entire world changes out from under them all at once, and sudden, massive changes are something we're trying to avoid with the release train model.
The important thing is to provide a migration path (e.g., begin by marking something as deprecated). Then provide refactoring tools to help migrate or interface with legacy code.
I think C++ would have been much better off had it been willing to do this. Paraphrasing Stroustrup: C++11 has within it a smaller more elegant language that's trying to break free.
At the fast pace things develop for Rust I hope that the language will have a good way to handle Rust 2.0 code together with Rust 1.x code. IMHO providing practical tools for an upgrade path is something that should be thought of before releasing 1.0.
Code written in ObjC a couple of years ago will likely not run today without modifications. But overall this has been a net positive for the language. It's actually become really pleasant to use. And is in part why Apple's platform has thrived.
I think optimizing for the past is the wrong thing to do. If your language is successful, then most of the code is yet to be written. So if your choice is between making future code easy to write, or not breaking legacy code, then you should err on breaking legacy code and provide deprecation/migration tools.
Just to nit pick, but there were actually breaking changes introduced in the latest C++ standards. See http://stackoverflow.com/a/6402166/101999 for a decent list.
Regardless, great work. Rust seems rather promising.
https://mail.mozilla.org/pipermail/rust-dev/2013-January/002...
Care to make a PR so you get a commit credit, or should I just fix it? rust-lang/blog.rust-lang.org is the repo.
And you're very welcome. I couldn't do it without Mozilla paying my bills, though I hope to strike out on my own later in the year.
let x = ys.filter(|y| self.p(y));
self.z = x;This let me compare these two interesting languages in a quite detailed way.
While Rust seems to be more safe in terms of trying to prevent as much as it can that you shoot yourself in the foot, it can be understood that the way to achieve this is maybe too extreme. I've read that programmers new to this language invariable struggle with lifetime issues that the compiler keeps arising.
I'm sure this is a good thing. But I'm not sure the ways to fix those issues, at least in a number of examples I've seen, are pretty. Most of them involved abusing the "*" and "&" symbols, which put you in a territory in which you seem to be dealing with pointer arithmetic again like in low-level C, something which I thought Rust was trying to escape from.
One thing I really liked about D is the string mixins, which could allow for what has become common these days in F#: type generation at compile time (which at the end of the day allow you to, for example, parse XML or JSON with static APIs, hence allowing intellisense/codeCompletion/youNameIt).
I'm really excited about what these kind of high&low (hybrid) level languages will allow. I hope they get into mainstream soon, and surpass other less interesting (but trendy) ones like Go.
First off, Rust doesn't have pointer arithmetic.
Moreover, though, Rust is not trying to "escape from" pointers in C and C++; it's a manually memory-managed language, not a garbage-collected one. For Rust's domain (systems programming without automated memory management), learning about pointers is a necessity. What Rust saves you from is making dangerous mistakes with memory management.
> One thing I really liked about D is the string mixins, which could allow for what has become common these days in F#: type generation at compile time (which at the end of the day allow you to, for example, parse XML or JSON with static APIs, hence allowing intellisense/codeCompletion/youNameIt).
Rust has macros and compiler plugins, which allow you to do the same thing.
It should have avoided the "*" and "&" symbols then, IMNSHO.
C# does this partially by using the "ref" keyword.
Those operators aren't for pointer arithmetic…
> C# does this partially by using the "ref" keyword.
But C#'s reference parameters have no corresponding dereference operator, because they aren't first class and are limited to function parameters. As a result, most programs cannot be written without using the garbage collector in C#. In Rust, however, references can appear as first-class values, which makes them much more flexible—enough to supplant a garbage collector when combined with smart pointers—but requires that you annotate where they are created. `&` and `*` are well-known operators for this.
That's the point of my suggestion! One looking at them will think they are pointer arithmetic, which is not pretty for newcomers.