Despite the claims in the Rust pre-alpha announcement of lanaguage (sic) definition stability, the language changes enough every week or so to break existing programs. This is a classic Mozilla problem; that organization has a track record of deprecating old features in Firefox before the replacement new feature works properly.
I don’t know where John is getting his “claims” from. Rust pre-alpha has no claim of not making breaking changes. The plan for rust 1.0 was laid out in December:
That is, we will reserve the right to make minor breaking changes to both the language and libraries – including #[stable] APIs – throughout the duration of the alpha cycle. But we expect any such changes to be relatively minor tweaks, and changes to #[stable] APIs to be very rare.
The ownership system, which is the big innovation, seems usable.
It is such a relief to see this. Making the system usable was the biggest challenge.
Rust may exceed the pain threshold of some programmers, though.
While the preceding comment confirms Rust does not exceed the pain threshold of all programmers, this is probably still true. It is also my biggest worry about Rust adoption.
This is where I’m at. I was a die-hard C++ programmer for a long time. Yet Rust seems totally unapproachable to me. I’ve moved on to Python and Go; it seems the problems I solve these days aren’t incompatible with garbage collection.
I’d be interested in hearing why you feel it’s unapproachable, if you don’t mind elaborating. You said you’ve were doing C++ for a long time, so I’m guessing it was all pre-C++11?
I have to think about it more, but it starts with the new operators in Rust:
&
&mut
&‘a
!
~
@
ref
ref mut
As a newbie these might as well be on an APL keyboard. With a history of using C, C++ (before C++11), or Java, none are obvious except for & and maybe mut. I realize some of these have changed in newer versions of the language, but this is my impression of it.
Most of the magical memory management and pointer types I’ve used in C++ are variations on templates like shared_ptr<> or unique_ptr<> or linked_ptr<>. Instead of special symbols or syntax it’s just plain old names. These are readable and discoverable to a new reader of the code.
Python and Go are also pretty simple in the operators they use. The worst Python has is probably * and ** for function arguments. Go’s worst is <- for channel operations. I realize that Rust is trying to do something different and needs more ways to express that, so I’m not putting it down here.
If it’s worth anything, another data point is I’m not in favor of Python adopting the @ operator for matrix multiplication (PEP 465). I think it’s too hard for newbies to quickly understand what it means.
While it doesn’t invalidate your reasoning, you are going off slightly out of date information. Actually, I think the Rust community came around to the same opinion you expressed here and decided to change the language. For example, ~ and @ haven’t existed for a while now. Just like C++, instead of special symbols or syntax, Rust decided to go with plain old names.
For the pointer types, as a quick approximation, &T is const T& and &mut T is T&, but they give you stronger guarantees than C++ is able to provide: for example, &T pointers can be relied on by the optimizer to never mutate, unlike const pointers and references in C++.
&'a (lifetime specifiers) and ref/ref mut (used in pattern matching) are admittedly fairly confusing for newcomers. There have been some improvements lately which allow you to omit lifetime specifiers in a lot of cases, which helps.
If you’re still interested in Rust, I would encourage you to check it out after 1.0.0 stable comes out in a few months. You may find it has become a lot more approachable.
I like this post, but it’s got a few things that are off. I’ll reproduce my comment from Reddit here:
There’s a temptation to resort to the “unsafe” feature to bypass the single-use compile time checking system.
That’s not what unsafe does. It does three things:
Call functions marked unsafe
Update or access static mutable variables (hello threads)
dereference raw pointers
unsafe Rust code is still really safe, but doesn’t ‘bypass the type system.’ As /u/smosher mentioned, this is very minor.
I’m concerned that Rust is starting out at the cruft level it took C++ 20 years to achieve.
Rust the language is actually quite small, and its semantics are pretty straightforward, at least if you’re a systems person. This doesn’t qualify as ‘cruft’ for me, which imples build-up of bad stuff over time. This is of course totally subjective.
the language changes enough every week or so to break existing programs.
The language isn’t changing very much at all. Some of the libraries, including three big ones, are still changing. This doesn’t matter much from a usage perspective, as your code is still breaking, but from a “how stable is Rust?” perspective, it’s not like core semantics are still in flux, it’s more cleanup and bringing things in line with conventions.
This is a classic Mozilla problem; that organization has a track record of deprecating old features in Firefox before the replacement new feature works properly.
We renamed io to old_io specifically so that you could upate peacemeal, so this feels quite unfair. It’s true that io isn’t here yet, but that’s why old_io still exists, and it will for a while after io is done to give people time to update thier code.
Again, all of this is pretty minor, and I enjoyed the post overall. You can’t expect everyone to have a handle on every single detail with something like Rust, doing so is my full-time job, and there’s even some bits that I don’t always remember off the top of my head.
While my gripes with Rust are in a completely different area, this is a thing I vehemently agree with.
Whether “a language like this” means Rust 2.0 or something different remains to be seen, though. (My bet is on the latter, because I don’t think they can get the amount of fixes into current Rust to make me reconsider…)
I don’t know where John is getting his “claims” from. Rust pre-alpha has no claim of not making breaking changes. The plan for rust 1.0 was laid out in December:
It is such a relief to see this. Making the system usable was the biggest challenge.
While the preceding comment confirms Rust does not exceed the pain threshold of all programmers, this is probably still true. It is also my biggest worry about Rust adoption.
This is where I’m at. I was a die-hard C++ programmer for a long time. Yet Rust seems totally unapproachable to me. I’ve moved on to Python and Go; it seems the problems I solve these days aren’t incompatible with garbage collection.
I’d be interested in hearing why you feel it’s unapproachable, if you don’t mind elaborating. You said you’ve were doing C++ for a long time, so I’m guessing it was all pre-C++11?
I have to think about it more, but it starts with the new operators in Rust:
As a newbie these might as well be on an APL keyboard. With a history of using C, C++ (before C++11), or Java, none are obvious except for & and maybe mut. I realize some of these have changed in newer versions of the language, but this is my impression of it.
Most of the magical memory management and pointer types I’ve used in C++ are variations on templates like shared_ptr<> or unique_ptr<> or linked_ptr<>. Instead of special symbols or syntax it’s just plain old names. These are readable and discoverable to a new reader of the code.
Python and Go are also pretty simple in the operators they use. The worst Python has is probably
*and**for function arguments. Go’s worst is<-for channel operations. I realize that Rust is trying to do something different and needs more ways to express that, so I’m not putting it down here.If it’s worth anything, another data point is I’m not in favor of Python adopting the @ operator for matrix multiplication (PEP 465). I think it’s too hard for newbies to quickly understand what it means.
While it doesn’t invalidate your reasoning, you are going off slightly out of date information. Actually, I think the Rust community came around to the same opinion you expressed here and decided to change the language. For example,
~and@haven’t existed for a while now. Just like C++, instead of special symbols or syntax, Rust decided to go with plain old names.For the pointer types, as a quick approximation,
&Tisconst T&and&mut TisT&, but they give you stronger guarantees than C++ is able to provide: for example,&Tpointers can be relied on by the optimizer to never mutate, unlikeconstpointers and references in C++.&'a(lifetime specifiers) andref/ref mut(used in pattern matching) are admittedly fairly confusing for newcomers. There have been some improvements lately which allow you to omit lifetime specifiers in a lot of cases, which helps.If you’re still interested in Rust, I would encourage you to check it out after 1.0.0 stable comes out in a few months. You may find it has become a lot more approachable.
Cool will do. I guess first impressions are hard to shake.
Thank you for elaborating. I think /u/tsion said what I was already going to say :)
This is probably my favorite analysis of Rust to date. Most of the article is dedicated to pointing out the flaws, yet it ends with
I’m glad someone took the time to write a realistic view of the language. Hopefully the Rust team can address some of the concerns mentioned.
I like this post, but it’s got a few things that are off. I’ll reproduce my comment from Reddit here:
That’s not what
unsafedoes. It does three things:unsafeunsafeRust code is still really safe, but doesn’t ‘bypass the type system.’ As /u/smosher mentioned, this is very minor.Rust the language is actually quite small, and its semantics are pretty straightforward, at least if you’re a systems person. This doesn’t qualify as ‘cruft’ for me, which imples build-up of bad stuff over time. This is of course totally subjective.
The language isn’t changing very much at all. Some of the libraries, including three big ones, are still changing. This doesn’t matter much from a usage perspective, as your code is still breaking, but from a “how stable is Rust?” perspective, it’s not like core semantics are still in flux, it’s more cleanup and bringing things in line with conventions.
We renamed
iotoold_iospecifically so that you could upate peacemeal, so this feels quite unfair. It’s true thatioisn’t here yet, but that’s whyold_iostill exists, and it will for a while afteriois done to give people time to update thier code.Again, all of this is pretty minor, and I enjoyed the post overall. You can’t expect everyone to have a handle on every single detail with something like Rust, doing so is my full-time job, and there’s even some bits that I don’t always remember off the top of my head.
While my gripes with Rust are in a completely different area, this is a thing I vehemently agree with.
Whether “a language like this” means Rust 2.0 or something different remains to be seen, though. (My bet is on the latter, because I don’t think they can get the amount of fixes into current Rust to make me reconsider…)
What gripes are those, if you don’t mind me asking?