Stability as a Deliverable | Hacker News Reader

Stability as a Deliverable

blog.rust-lang.org

I still recall my somewhat naive prediction at the time of Rust 0.3 that a stable release would be out by Q1 2013. All things considered, I guess two years isn't that far off. :)

So thrilled to see the progress Rust has made in the past three years! It's gone from a kinda-interesting-theoretically language to an ohmigosh-this-is-actually-rad language. I'm giddy for the 1.0 release, so that other people can at last start using it in earnest!

What are some of the big reasons to avoid using Rust (including after the 1.0 release)?

Every language has flaws, so I'd like to try to learn from other people's experiences before I stumble across them on my own.

Well depending on who you ask, one flaw might be that there's no garbage collector. Others might say that's a bonus.

The mechanisms that Rust uses to provide memory safety require more forethought than the various forms of garbage collection that other memory-safe programming languages use. If you can happily live with a garbage collector, then Rust may not appeal to you. If you're not doing anything that benefits from concurrency, then Rust's ability to statically prevent data races won't matter to you.

From a personal standpoint, the things that I dislike about Rust are the module system (too complex IMO, though it's been getting better recently) and a few places where the syntax is ugly (some of the ugly syntax has good reasoning behind it, but that doesn't mean it's not still ugly).

Furthermore, the typical downsides to working with a very young technology will apply. Tooling is minimal. Googling for answers to questions will often be futile. Precedents for how to most effectively solve problems with the language are few. The wider ecosystem has comparatively very few useful libs, and even where libs exist they will often be only partially implemented. In other words, it's going to be a wild west for a while yet.

Well, the obvious one is your deployment options: You need to either compile binaries for the target platform, or ask the user to compile from source. As far as I know, you can't yet compile Rust to Javascript.

Support for GUI toolkits will probably require some glue code. I've heard that Windows is a particular source of headaches, but I'm not clear as to why. SDL seems to work everywhere; remember that Rust is designed for seamless C interop in both directions.

Your first point perplexes me, Rust is a systems programming language like C, Pascal, FORTRAN, C++ and the like. Building ahead-of-time platform specific binaries is business as usual and not anything really notable about Rust itself.

It's also actually a feature if you want to do things like bare-metal runtimeless code.

As far as I know, you can't yet compile Rust to Javascript.

I don't see why not--Rust uses LLVM as a backend, and LLVM bytecode can compile to Javascript with emscripten.

Although, I don't really see why you would want to, either.

Rust relies on a newer version of LLVM than Emscripten is based on (as Emscripten-fastcomp is based on the PNaCl fork of LLVM, which is lagging behind). Once the PNaCl fork is updated and Emscipten rebases, or they rebase onto LLVM proper, then it should be doable fairly easily.

I see. Thanks for clarifying!

Before I start, I will say that I love Rust, and more often than not find it a pleasure to work with. Pretty much all my GitHub repositories[0] are in Rust, and have contributed a reasonable amount to the Rust repository itself[1]. Despite this, I think it is important to be honest. How much these are a deal breakers depends on your perspective and the domain that you are targeting. If you are working in a space where you really need performance, control over memory layout and allocation, and value strong abstractive power and excellent maintainability properties, then I doubt you will find a better choice of language than Rust once 1.0 is released.

With that in mind, here are some of the shortcomings that you may run into, along with their counterpoints:

The short version:

- It can sometimes be hard to get it to type check, but the payoff is worth it in terms of refactorability and maintainability.

- Some type system and language features are lacking, but those will most likely be added post-1.0.

- I miss some semantics from pure FP, but these have been given up for good reasons.

- The syntax is clunky, but it's not a deal breaker, and it will be more familiar to our target audience.

The long version:

You have to do more work to get your program past the borrow checker. The error messages are pretty good and you quickly develop an intuition for it, but sometimes it's not always clear why you are running into an issue. Most often though you are actually doing something subtly wrong that needs to be re-thought. The upshot is that you end up with a rock solid program at that you can refactor freely with the confidence that the compiler will help you along if and when you mess something up. This is in contrast to C and C++ where you constantly feel like you are walking on eggshells.

We don't have as much type system goodness as Haskell, especially with regard to higher order polymorphism. CTFE is also limited. Macro importing/exporting/namespacing as pretty ugly. These will all be addressed post 1.0 though.

Functions are tupled, and currying is not natural. This can make function composition harder than in languages like Haskell and ML. There is no support for guaranteed tail call optimization. There are technical reasons why implementing these are hard though without compromising the core emphasis on systems programming[2][3]. I am thankful that the core devs have chosen to be conservative on these fronts.

The syntax is curly braced, with <> for type parameter lists. Types are declared inline in function signatures (unlike in Haskell, where they are above) which can make them long and hard to read, especially when type parameters come into play - where clauses have helped alleviate this though.

[0]: https://github.com/bjz?tab=repositories

[1]: https://github.com/rust-lang/rust/graphs/contributors

[2]: http://www.reddit.com/r/rust/comments/2ejxk6/minutes_from_la...

[3]: https://mail.mozilla.org/pipermail/rust-dev/2013-April/00355...

- The syntax is clunky, but it's not a deal breaker, and it will be more familiar to our target audience.

If there are any areas in which this is still true, I urge you to value "familiarity" less. As I get older and older, I realize how long software timescales can be. In 40 years, people will still be programming in Rust, and nobody will remember why the syntax started out clunky. :-)

I'm super excited too. It's been great to see how much the language has been simplified, and how much more powerful it has become. And how despite a very democratic approach to development the language still seems very considered in its design, thanks to strong leadership by the core team.

I am _incredibly_ excited about working with a language where we ship every six weeks. And furthermore, that these are compatible releases. It changes a lot of things in a really positive way.

Where does error handling stand (there was a trait-based error handling RFC)? I guess that can be done in a backward compatible way post 1.0.

Just today: https://github.com/rust-lang/meeting-minutes/blob/master/wee... (aka #236 got merged, #243 is still under discussion)

From looking at Cargo, it seems like Rust will compile everything from source so it won't have the same issues with binary compatibility that you get with different versions of Scala. Is that correct?

There is not a plan to have Cargo serve binary blobs, that's correct. However, I'm not familiar enough with the situation in Scala to comment on that part.

The short version is that any dependency (compiled) you pull in has to have been built with the same version of Scala you are using. Scala's build tool sbt alleviates this somewhat, though you can still have headaches using Scala libraries from other JVM languages.

Hi Steve,

First thanks a lot for Rust. I have a background in embedded development and the perspective to have a modern, safe by default language available in the future (it's a conservative domain ;) is very exciting!

Cargo aside, the question of ABI stability is an interesting one: if an implementation stick to stable features, will it be possible to link code compiled with a newer compiler with a library compiled with an older version? Or is the stability only at the language level for now?

I don't think ABI stability is required at this stage. There's been some experience with ABI changes with C++ and it's always possible to deal with it by having interfaces defined using a C ABI (stable) to shield oneself, if needed (if recompiling everything is not practical). But clarifying the status and plan would be nice.

Thanks again.

ABI stability is definitely not guaranteed at this time, as this would require standardizing a huge swath of behavior that is currently internal to the compiler. As mentioned in the OP, this is the same reason why syntax extensions cannot be stabilized as they are.

So the answer is sadly no, different versions of the Rust compiler will not be guaranteed to produce binaries that can link to each other, short of using a C ABI.

You will still need to be able to compile it though.

Aiming at perl level stability seems like a bad idea at version 1.0. There will be mistakes - some of them really horribad.

Wouldn't it be a better idea to aim at some kind of Rails level stability, with actually expecting 1->2 to be a total rewrite, 2->3 be a massive undertaking and 3->4 be a quite simple undertaking and then accumulate stability as the good ideas pile up over time?

Different approaches to stability attract different people. I wouldn't touch a 1.0 that promised 1->2 to be a total rewrite. With a 1.0 that promises backward compatibility, I'll be sure to look into it. More importantly, it's true for whole organizations employing hundreds or thousands of programmers.

On the other hand, some people like to work on things that "will always improve", and where compatibility will never be a reason to tolerate a suboptimal design decision in the long run. Which works especially well if their taste matches the taste of whoever is charged with evolving the thing. One could argue that Rails 4.0 or 20.0 beats any 1.9999 version a backward-compatibility-centered system could ever deliver... and one could argue against it.

I'm obviously happy that Rust takes the approach that suits me :-)

They did that work already. They just had the good sense to keep the version number below 1.0 until it got stable.

I almost want to liken this attitude to Lua's approach to stability: The general look of the language will remain the same, but some base-line things may change between releases. That's the impression I got from the OP. (Granted, Lua gets used in a far different environment than Rust, so people holding onto an older version for their own projects is not a big deal in Lua. I don't think Rust wants to engender that attitude for its use. I'm not sure, though; I haven't really used Rust nor spent any time in the community.)

I really wish I could use rust for my current work, but it has to be runnable in the browser and it looks like it would take a lot of work to get emscripten on to the same version of llvm as rust.

I just spent two hours debugging what turned out to be a "0" where there should be a 0. Turns out that 1 + "0" > 9.

1 + "0" > 9 in JavaScript, right? There are plenty of languages compile to JavaScript [1], maybe you can try some of them.

[1] https://github.com/jashkenas/coffeescript/wiki/list-of-langu...

Unfortunately most (all?) of them have performance costs and we are already eyeing up asm.js for better performance.

There are iteration costs in that you're adding a compile step, but in terms of runtime performance, many of the languages are close enough to js that there shouldn't be any cost over hand written js (e.g. typescript, coffeescript,etc). In production you're probably running the whole thing through a minifier anyway, and the most popular of those can actually do performance enhancing transformations too. Google claim that compiled-to-js dart performs better than hand written js, although that is probably a mixture of exaggeration and the effect of the closure compiler which you can run on javascript code anyway.

Technically he could have been referring to C, where it's also true that 1 + "0" > 9, albeit with a warning. ;)

Yes, but to be fair, that is mostly emscripten's fault, not rust's. Once emscripten rebases onto something more recent (currently it's somewhere around 3.3-3.4), building a single-threaded program using rust shouldn't be that hard.

I saw a related issue on emscripten-fastcomp saying they are based off the pnacl fork of llvm, which is why they are lagging behind.

I'm hoping we can use rust eventually but it doesnt look like the kind of problem we can just throw money at - its a pretty big change to emscripten.

That's correct, yes. But pnacl is close to a big update to llvm 3.5, and hopefully emscripten will follow that not long after.

That's good to know, thanks.

This seems rather confusing compared to Go's commitment to stability with their 1.0 release. I can't really tell whether they're freezing the language or not, but it mostly sounds like they aren't.

> I can't really tell whether they're freezing the language or not

The TL;DR is,

> To put it simply, our responsibility is to ensure that you never dread upgrading Rust. If your code compiles on Rust stable 1.0, it should compile with Rust stable 1.x with a minimum of hassle.

The language is not being 'frozen' in the sense of never changing. But it will change in an additive way, so the code you write today will compile tomorrow just fine.

To add to this:

> It’s important to be clear about what we mean by stable. We don’t mean that Rust will stop evolving.

Rust's 1.0 promise is analogous to Go's. Code that works will keep working and new features will come with each new release without breaking old code.

The only real difference is Rust's time-based "release train" schedule, compared to Go's milestone-based release schedule.

So future releases will only accumulate new features?

Because that approach worked so well in ... C++? PHP? JavaScript? Java? C#?

Future releases will accumulate new features as they are deemed useful to the goal of a memory-safe zero-overhead systems programming language. Rust is not interested in feature maximalism, so dread not the kitchen sink. For the features that we do add, we value orthogonality and clean integration with the rest of the language.

Not quite related but if you found yourself wondering why Rust has semicolon based statement termination - there is a thought provoking article on that topic:

"Such a Little Thing: The Semicolon in Rust" http://lucumr.pocoo.org/2012/10/18/such-a-little-thing/

Reply on news.ycombinator.com