News for hackers. Stuff that matters.
Re:One year of Rust by jandrese on Monday May 16, 2016 @02:38PM (#11708518)
This is one thing that's a little annoying to me. I know if I develop a Rust app today I can't leave it alone or it will decay horribly.
Re:One year of Rust by pcwalton on Monday May 16, 2016 @02:43PM (#11708556)
> This is one thing that's a little annoying to me. I know if I develop a Rust app today I can't leave it alone or it will decay horribly.

No, it won't. Rust has been stable since 1.0, as the article itself mentions.

Re:One year of Rust by tatterdemalion on Monday May 16, 2016 @02:43PM (#11708565)
Good news for you: this is a complete misconception. Rust has been stable for a year. With a minor caveat for actual bugs in the language, your code will compile on all Rust 1.X compilers from now until the end of time. Upgrading Rust versions has been a breeze.
Re:One year of Rust by kzrdude on Tuesday May 17, 2016 @05:38PM (#11717696)
You're overstating the stability guarantees. The Rust project has formulated it as “hassle-free upgrades” which seems to imply that small, simple edits may be necessary when upgrading to a new Rust version.
Re:One year of Rust by steveklabnik on Tuesday May 17, 2016 @07:42PM (#11718551)
That's only for changes that are important, though: we don't make unnecessary changes.
Re:One year of Rust by kzrdude on Thursday May 19, 2016 @02:07AM (#11728338)
Agree. It's important to underscore what was promised and what was not. Otherwise you might get the impression that a promise was broken (when it was not).
Re:One year of Rust by AsyncAwait on Monday May 16, 2016 @03:01PM (#11708715)
That was true prior to last year's 1.0 being released, but since then code no longer breaks, (in any major ways anyway, there's been some soundness fixes for the good of the language's future). Also, the Rust teams runs any potentially breaking changes against the crates at crates.io and they even sent fixes to existing crates in the past.
Re:One year of Rust by Animats on Monday May 16, 2016 @02:44PM (#11708570)
That's gotten much better since 1.0. Prior to 1.0, you needed to revise your Rust program about once a week so it would compile. Now the language has settled, but the libraries are still churning.

One of the big advantages of Go is that it comes with a coherent set of libraries from a single source (Google) that do most of the things you'd want to do on a server. Rust is more like Python; many people write libraries, many of which overlap and some of which work.

Re:One year of Rust by pcwalton on Monday May 16, 2016 @02:51PM (#11708617)
The advantages of having a distributed ecosystem vs. having a monolithic standard library is an extremely polarized topic, and I don't want to start that debate.

But I do want to emphasize that Rust libraries follow semver, and the lock features of Cargo mean that your builds are always reproducible and you upgrade only when you want to. Your code will never stop compiling one day just because some library "churned".

Re:One year of Rust by jayflux on Monday May 16, 2016 @07:54PM (#11710480)
"Rust is more like Python; many people write libraries, many of which overlap and some of which work."

Odd comparison, Python actually has quite a comprehensive, well used standard library, which usually gives you enough to get going.

Using NodeJS as an example would've made more sense, where most libraries/modules are user written.

Re:One year of Rust by steveklabnik on Monday May 16, 2016 @02:41PM (#11708541)
That should not be true. 1.0 meant that we stopped breaking things on a daily basis, if your code runs on stable today, it should run on stable tomorrow, modulo any soundness fixes (of which we have had two or three this year, which were all trivial to update).

If it is true, please file bugs. We do our best not to break people's stuff, going to pretty extreme lengths compared to many other ecosystems.

Re:One year of Rust by kzrdude on Tuesday May 17, 2016 @05:34PM (#11717661)
and occasional other breaking compiler bug fixes that are not really soundness fixes.