6 ms·

It's funny to see how these languages topics always explode. I read it when it had about 20 comments and then it predictably devolved into a mess of hype and co

by blub 11y ago

It's funny to see how these languages topics always explode. I read it when it had about 20 comments and then it predictably devolved into a mess of hype and comparisons. Anyway, I think your strategy is sound. Rust is a young language and I would be pleasantly surprised to see code written today still compile in five years. I got bit by this with Swift v1 in a little app. When 1.x came, it failed to correctly transform the source and the whole thing was a major PITA to update. Completely soured me from using Swift. I can understand why Mozilla wants to use Rust. It solves a problem for them, they largely control how the project evolves and can plan for it. 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. Personally, I root for them, in spite of their recent missteps. I think Rust might be a good choice now for language aficionados and early adopters which can afford to waste time in exchange for other potential benefits. I would absolutely not use it to bring a project to market or for an OSS project which has a long term vision. In 5+ years I expect such a decision could be worth revisiting.

steveklabnik 11y ago
> 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.
smt88 11y ago
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.
- blub 11y ago
  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.
  - smt88 11y ago
    > 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.
  - pcwalton 11y ago
    > * 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.
    - blub 11y ago
      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.
pcwalton 11y ago
> 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.
- blub 11y ago
  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.
- x0x0 11y ago
  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!
  - steveklabnik 11y ago
    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.
    - x0x0 11y ago
      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 https://news.ycombinator.com/item?id=9724849
mcguire 11y ago
"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?
- blub 11y ago
  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.
  - pjmlp 11y ago
    Yep RAII was already a thing in the late 90's for example.
- nickpsecurity 11y ago
  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.
vpkaihla 11y ago
>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?
- dikaiosune 11y ago
  Many, I'm sure. Most Java from 5 years ago will still compile on newer javac versions, for example.
  - kibwen 11y ago
    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-compatibility-guide-2156366.html http://www.oracle.com/technetwork/java/javase/8-compatibilit...
- mariusmg 11y ago
  C#. Yesterday i rebuild a project (with latest compiler version) that i've created 12 years ago.
  - kibwen 11y 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).
    - pjmlp 11y ago
      They also changed the for loop var semantics in C# 5. There a few other little breaking changes as well.

by blub 11y ago

steveklabnik 11y ago

> 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.

smt88 11y ago

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.

blub 11y ago
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.
- smt88 11y ago
  > 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.
- pcwalton 11y ago
  > * 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.
  - blub 11y ago
    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.

pcwalton 11y ago

> 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.

blub 11y ago
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.
x0x0 11y ago
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!
- steveklabnik 11y ago
  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.
  - x0x0 11y ago
    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 https://news.ycombinator.com/item?id=9724849

mcguire 11y ago

"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?

blub 11y ago
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.
- pjmlp 11y ago
  Yep RAII was already a thing in the late 90's for example.
nickpsecurity 11y ago
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.

vpkaihla 11y ago

>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?

dikaiosune 11y ago
Many, I'm sure. Most Java from 5 years ago will still compile on newer javac versions, for example.
- kibwen 11y ago
  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-compatibility-guide-2156366.html http://www.oracle.com/technetwork/java/javase/8-compatibilit...
mariusmg 11y ago
C#. Yesterday i rebuild a project (with latest compiler version) that i've created 12 years ago.
- kibwen 11y 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).
  - pjmlp 11y ago
    They also changed the for loop var semantics in C# 5. There a few other little breaking changes as well.