Hacker News Reader

> Rust is a young language and I would be pleasantly surprised to see code written today still compile in five years.

We have had a code stability promise for months now in 1.0. So what you are saying here is that you do not believe that Rust will adhere to what it very publicly planned to do. Do you have specific reasons for this?

> To me, the big questions are what will happen to Rust if Mozilla changes strategies (Persona, Thunderbird, FirefoxOS) and whether Mozilla will continue to be a successful organisation.

Rust has a core team and community that overlaps a lot with, but is very much not identical to, Mozilla. Probably most Rust users aren't even Firefox users.

Rust is not "Mozilla's language". It's the Rust community's language.

My only reason is that experience and surprising developments have made me into a skeptic when discussing technology. I was not aware of any promises.

Are there any large deployments of Rust outside Mozilla? (I'm not being sarcastic, just wondering who with resources besides Mozilla is incentivized to put money into Rust development.) Thanks!

The largest is currently Dropbox, who re-wrote the way they store the bytes on disk in Rust. It was deployed in late December, they have promised a report after it's been in production longer than a few weeks.

thank you; I'll put a note on my calendar to check in a couple weeks

edit: Once you google for dropbox rust, you find some really interesting stuff; here's an overview

https://news.ycombinator.com/item?id=9724849

Author of that comment here, let me update it with some new links for you. :)

Putting Rust into production at Dropbox: https://www.reddit.com/r/rust/comments/3wrgl0/what_are_you_f...

Some preliminary feedback on using Rust at Dropbox: https://www.reddit.com/r/programming/comments/3w8dgn/announc...

> We have had a code stability promise for months now in 1.0. So what you are saying here is that you do not believe that Rust will adhere to what it very publicly planned to do. Do you have specific reasons for this?

Since 1.0, Rust has in fact had multiple significant stable-breaking compiler changes, not to mention that, among other things, adding any new method to a trait or type in the standard library has the potential to cause breakage. The official code stability promise has not been violated by these changes only because it's riddled with exceptions.

I don't think this phrasing is particularly charitable, yet we don't need to argue about semantics, because we have numbers.

  > Approximately 96% of published crate revisions that build with the 1.0 compiler 
  > build with the 1.5 compiler.

https://internals.rust-lang.org/t/rust-regressions-2015-year...

I've seen it, and if that rate of 4% of code breaking in half a year were to continue, in the above stipulated 5 years it would look pretty bad. Hopefully it will not, given that some of those regressions involved soundness issues and other things (integer fallback) that were "clearly wrong", which ought to be mostly weeded out before long. That said, the rate of new features in the language and especially libraries seems likely to increase a bit in the nearish features, given the size of the feature request backlog (or not - you'd know better than I).

But even at a rate of significantly less than 4%, there's still trouble. That figure is based on the number of root regressions, right? (If I'm wrong, disregard the rest of this paragraph, but I don't think so...) That is, the number of crates that break on their own accord, rather than those that won't compile because one of their dependencies is broken. If one application depends on dozens of crates (or is just really large), the chances of it breaking somewhere are much higher.

This can be partially mitigated by the crates themselves releasing upgrades, but look at Python 3 - there will eventually be a lot of code out there that's completely unmaintained, especially within the "dark matter" of internal or closed source applications. Also, a fix in the latest version of a crate will probably not be backported to long deprecated major versions of it - which means that if I dust off a crate that hasn't been touched in years and uses such a version, I'd have to either upgrade the dependency or do the backport manually.

And the ancestor post did say five years: last I checked on the lists, there was no real consensus as to when Rust 2.0 should be released, on a scale from "in a year" to "never". Maybe there is more consensus internally, but I'd be surprised if it didn't happen in that long...

edit: It's not an entirely fair comparison, but for what my ideal stability promise for a programming language would look like, one need not look very far - only as far as Mozilla's other programming language.

You're correct about impacts of popular crates, this is why crater is so important. A nice benefit is that popular crates should also have more attention on them, since they're popular, so if they are hit by a soundness issue, it should be addressed quickly.

The core team feelings on a 2.0 is much closer to the "never" end of the spectrum than the "in a year" side.

I'm convinced that the breakage in new C++ compilers is worse than Rust's breakage. New C++ compilers and language revisions break more than 4% of code. Likewise with many other languages, such as Ruby. We're just very up front about regressions when they do occur.

> edit: It's not an entirely fair comparison, but for what my ideal stability promise for a programming language would look like, one need not look very far - only as far as Mozilla's other programming language.

As a matter of fact, JS's stability promise is very similar. See my other post for an example in which JS was broken due to, essentially, one of the reasons you cited, and we lived with it. The JS stability promise is not "we will never break any JavaScript in theory with new browser versions", because that would prevent anyone from, as an extreme example, changing the sorting algorithm for Array.sort. It's "we will not break you in practice, except in a carefully delineated set of circumstances." (Actually, JS's stability promise is much weaker than that: its stability in practice is decided by browser consensus and market forces rather than a clear set of rules.)

> Since 1.0, Rust has in fact had multiple significant stable-breaking compiler changes, not to mention that, among other things, adding any new method to a trait or type in the standard library has the potential to cause breakage. The official code stability promise has not been violated by these changes only because it's riddled with exceptions.

This is essentially the same as any other language. Adding a new method to traits or types can also break JavaScript, the other example you gave.

In fact, I know of one such example where code was broken in the wild because of new methods being added, and we did not revert the change. Marijn Haverbeke's winning js1k entry relied on the 4th and 7th letters (or something along those lines) of every CanvasRenderingContext2D method being unique, because it compressed code by renaming the canvas methods with what was then a perfect hash function. A new Firefox version was released months later that added new methods and broke the code. That was deemed an acceptable piece of breakage, and Rust's policies are very similar.

Anyway, the vast majority of breakage that we've seen so far was due to the libcpocalypse. This was an issue with people not specifying specific versions of libraries they depended on, not the language.

Here's another example with less trivial breakage, which was reverted:

https://www.fxsitecompat.com/en-US/docs/2015/string-prototyp...

Unless you mean to refute the idea that JS doesn't break anything ever - which it clearly does, occasionally, but proof-of-concept golf code that intentionally takes fragile shortcuts isn't the best example.

...But JS has moved away from monkey patching builtin objects for good reason, whereas Rust tends to be relatively promiscuous in adding methods to other people's types via trait impls. This isn't bad per se, but I do think it creates bigger compatibility risks.

"Rust is a young language and I would be pleasantly surprised to see code written today still compile in five years."

I'm myself willing to accept the promise of code stability, so I think you're looking at slightly the wrong problem. While I'd expect current code to continue to compile, I also expect what is regarded as good Rust now won't be in five years. That's not a bad thing, but it also means that hopping on the Rust bandwagon might be premature.

The worst case? How about Haskell, where new language features make old code look worse even as it still works? Or C++, with it's accelerating rate of style changes?

That's an interesting point regarding changing idioms/culture.

Can't speak about Haskell, however I believe that C++ changes can be incrementally adopted: we had C++98, then boost established itself, some parts of boost were included in TR1 and then were part of C++11. A similar process is taking place with other libraries such as asio and filesystem. I don't have the feeling that modern C++ style is in flux, its pillars continue to be RAII, generic programming and the STL.

I think Bjarne & co have explicitly stated that they want to grow the language while maintaining backwards compatibility as much as possible and from my experience, the code I write today builds on patterns and idioms that started to crystalize a long time ago.

Yep RAII was already a thing in the late 90's for example.

That is an interesting point. I'd like to see pcwalton respond to it. That people are having problems with current Rust idioms means they might [rightly] change them. So, starting with Rust now could reinforce bad practices that come with a retraining or software re-engineering cost later. So, this is a real risk that I overlooked in prior discussions.

Good catch.

According to TIOBE, Rust is now more popular than Go. Both have corporate backing. Go is definitely used in production, and I wouldn't be surprised if people are dipping their toes in the water with Rust in production as well.

Even if it remains a small niche, I think we've seen that Rust is popular enough that using it long-term is fairly safe. Maybe you'll be one of only a few thousand shops who use it -- that's enough. The benefits of writing secure code vastly outweigh to drawbacks of using something unpopular.

TIOBE's good for trivia, but probably not for picking a specialisation path or choosing which tech to build a project on.

When choosing a language to learn, I consider:

* what a particular industry or project of significance is using

* job availability

* compatibility with my existing toolbox

* the power/fun factor

But that's far from the whole story, because programming languages are relatively fungible and investing in domain knowledge, people skills, architecture and many other things will bring bigger benefits than learning that brand new programming language!

And yet here we are, discussing how Rust will deliver us.

> programming languages are relatively fungible

I agree with that regarding learning them, but I disagree strongly when it comes to the end result.

I make a lot of my money fixing/replacing PHP projects. As has been pointed out many times before, there are issues with PHP that are guaranteed to cause bugs. The same is true of many languages.

But there is a spectrum! Some compilers/interpreters scream at you and terminate if you contradict yourself. Some of them even recognize security vulnerabilities.

I agree that people skills, domain knowledge, and architecture are hugely important, but great teams are still less effective when they use slow or confusing tools.

You might be the greatest contractor in the world, but if someone asks you to build a skyscraper with plywood and super glue, you're going to end up with something dangerous, fragile, and guaranteed to fall apart as soon as someone tries to use it.

> * what a particular industry or project of significance is using

> * job availability

That just boils down to popularity once again. I prefer to pick languages based on suitability for the problem domain. For me, Rust is suitable in a way that C++ is not, due to memory safety among many other reasons.

I think we are mostly in agreement. If an industry is standardizing on a language, it's probably a good match for the kind of problems that they solve, i.e. for their problem domain.

Job availability is not just about number of jobs, but also about project quality, companies and personal preference. E.g: I don't have an interest in containers, and most Go jobs involve containers, so this is a minus for Go.

This works in the other direction too. Let's say I want to work for Mozilla, I notice they use mostly C++ & Js, so I decide to invest time brushing up my skills in those areas.

>>many other things will bring bigger benefits than learning that brand new programming language!

The other narrative is also true. Using newer technologies is the best way to be a part of new projects and avoid working legacy maintenance kind of projects.

It's interesting that a synonym for "legacy maintenance kind of projects" is "successful".

"And yet here we are, discussing how Rust will deliver us."

So why are you here, debating about Rust, if you already know your time would be better spent investing in domain knowledge, people skills, or architecture?

Spending let's say 1h on HN is not at the same level of time investment as learning a programming language. ;)

I am not really discussing Rust per se, as I am not familiar enough with it, however, when I see biased or misleading statements I do sometimes feel obliged to offer a counterpoint.

IIRC, doesn't TIOBE have a problem with indexing Go because they only search for "Google Go" (or something restrictive like that)?

According to a post from a few years ago, they were using "Go programming", "Google Go", and "golang"[1].

You'd have a similar problem with Rust, Ruby, Python, Java, Ada, Julia, and probably tons of other languages. It must also be really difficult to differentiate between C, C#, and C++, considering most search algorithms will ignore the # and + characters.

1. https://groups.google.com/d/msg/golang-nuts/TtPzOvhG6bM/-XCr...

  >  I would be pleasantly surprised to see code written today still compile
  > in five years.

That's the goal, modulo soundness fixes. We don't currently have any plans for a 2.0.

  > what will happen to Rust if Mozilla changes strategies

Well, we're just starting the process of integrating Rust code into Firefox. Yes, Mozilla has killed off a lot of things, but I don't think Firefox is going away any time soon.

>Rust is a young language and I would be pleasantly surprised to see code written today still compile in five years.

Without changes to the code? Has there even been a language where that has been true?

Many, I'm sure. Most Java from 5 years ago will still compile on newer javac versions, for example.

Not just most, I'm betting the overwhelming majority of Java code will compile. But all popular languages break small things with every release (and this is probably a good thing in the long run), so look hard enough and you're guaranteed to find code that won't work.

For instance, here's the compatibility guide to Java 8: http://www.oracle.com/technetwork/java/javase/8-compatibilit...

C#. Yesterday i rebuild a project (with latest compiler version) that i've created 12 years ago.

Note that C# famously broke backwards compatibility when it added generics. I say "famously" because it opted not to follow Java's type-erasure approach (which was chosen so as to explicitly maintain backwards compatibility), and history seems to agree that the minor amount of pain back then was well worth the improvements that it brought to the language (especially relative to Java).

They also changed the for loop var semantics in C# 5.

There a few other little breaking changes as well.

BASIC. Fortran. Pascal. Oberon. Any language designed to be simple and map well to pseudo-code. Even the source-to-source converters tend to have few problems with those. One of reasons I recommended them for certain projects in the past where longevity and talent were concerns.