6 ms·

6 months in an enterprise setting means that we will never touch Rust.

paavohtl 6y ago
There are generally speaking no breaking changes. Upgrading the toolchain practically never requires any changes to code.
- DyslexicAtheist 6y ago
  > Upgrading the toolchain practically never requires any changes to code. if you work on safety/security critical systems upgrading the toolchain is considered like changing the tires on a moving vehicle. We have introduced and many weeks later discovered critical (and hard to trace) bugs simply by changing -O2 to -O3 in gcc that ended in sporadic crashes when cross-compiling for 1 specific platform. (which is a change much less severe than upgrading gcc itself) And I'd be surprised if upgrading the toolchain wouldn't potentially introduce similar hard to trace issues in rust. My point is that just because the first 2 months after upgrade look like there were no required changes in code doesn't mean there are none. I see rust being used in very large companies for internal projects, test harnesses, and other glue/plumbing. And the places I know are really reluctant to go all the way in and substitute their ~30 years of experience with C/C++ with something that remains a constantly moving target. To be fair there are other reasons such as culture, and distribution of skills across the team that drive these decisions but my main point still holds (i think).
  - nicoburns 6y ago
    If you don't upgrade the compiler at all, then why does it matter how fast it updates? You're not going to be using the new version anyway.
    - pjmlp 6y ago
      Depends on the libraries I guess, when that CVE fix is only available on a version that requires a compiler upgrade.
    - bluGill 6y ago
      Eventually they will stop making the CPU we use and then the new CPU only works with a new compiler.
  - bsder 6y ago
    1) Sorry, but if you're talking safety critical, then you're talking Sealed Rust/Ferrocene which is talked about here: https://ferrous-systems.com/blog/sealed-rust-the-plan/ https://ferrous-systems.com/blog/sealed-rust-the-plan/ I mean, even with C, there is a very circumscribed subset that you use for "safety critical" applications. 2) People are banging on about Rust not being stable but the Rust Embedded guys DO lag for stability--so you can have stability if you choose. And Rust is by far the best language I have seen about being able to stay on old compiler versions and still use newer libraries. 3) I find crappy libraries to be the biggest threat to Rust's sustainability. There was a big "Gold Rush" mentality and a whole lot of unqualified people built a whole lot of crap libraries with no good way for someone to come along later and to flag "That's a crap library, please remove it from crates.io permanently".
  - roca 6y ago
    > changing -O2 to -O3 in gcc that ended in sporadic crashes when cross-compiling for 1 specific platform. Sure, this happens regularly in C and C++ because large programs inevitably depend on undefined behaviour, and changing compiler versions, optimization levels and target platforms is allowed to change that behaviour. For the last five years I've been writing 99% safe Rust code, which is designed to have no undefined behavior, and I think it's not a coincidence that I can't remember ever having a compiler update break code at runtime. Once in a long while a compiler update will fail to compile some existing code, but that's not a safety issue. The idea that C and C++ compilers are somehow more stable across releases is a mirage. https://lwn.net/Articles/845691/ https://lwn.net/Articles/845691/ https://lwn.net/Articles/845775/ https://lwn.net/Articles/845775/
    - bluGill 6y ago
      No, this happens because bugs in compilers happen. Nothing to do with undefined behavior. (Which is a separate problem)
      - steveklabnik 6y ago
        It can be both.
  - dfhjgkljhf44 6y ago
    >-O2 to -O3 in gcc This sounds more like undefined behavior in your codebase than a compiler error. I don't know Rust but I'm pretty sure the whole selling point is that you won't run into problems like this.
    - tsimionescu 6y ago
      There are active open bugs today in GCC and clang for x86 where optimizations can break standards-correct code [0] (writing to a union through a pointer to a currently inactive member, which std::variant does internally). For more obscure platforms and older releases, there are bound to be numerous bugs. In particular, volatile handling is notoriously shoddy on many platforms. As an aside, the clang bug would also affect Rust if they used that type of optimization (assuming strict aliasing rules). [0] https://lists.isocpp.org/std-discussion/2020/10/0882.php https://lists.isocpp.org/std-discussion/2020/10/0882.php
      - ordu 6y ago
        > As an aside, the clang bug would also affect Rust if they used that type of optimization (assuming strict aliasing rules). No, this bug cannot affect rust, because rust wouldn't allow to pass into a function three mutable references pointing to the same object. It wouldn't even allow two, nor one mutable and one immutable. Either it pass one mutable reference, or any number of immutable.
        steveklabnik 6y ago
        This one (probably) wouldn’t, but there have been codegen bugs in Rust, some that have blocked people from upgrading before they can be fixed. It doesn’t happen often, but it does happen.
        tsimionescu 6y ago
        Not sure if that bug explicitly, but the fact that clang in noalias mode assumes that two pointers to different variants of the same union are not aliased (if it can't see from the immediate context that they are pointers to the same union variable) can very much affect Rust - if you call one function with a &mut to one field, than another function with a &mut to another field, and the optimizer inlines both functions in a broader context and loses the union information, you may well see reordering issues even in pure safe Rust. Anyway, Rust has found plenty of noalias bugs in clang, which is why it still doesn't compile with noalias optimizations turned on.
  - dralley 6y ago
    >And I'd be surprised if upgrading the toolchain wouldn't potentially introduce similar hard to trace issues in rust. It absolutely happens, but less often than you would think. Rust has a tool named "crater" which compiles and executing tests for every package uploaded to crates.io (and some which are just on github). It's not perfect but supposedly it catches quite a lot of bugs.
signal11 6y ago
That somehow rapid-release is antithetical to the enterprise is a very archaic view of enterprise computing. Enterprises use cloud HR software, Office suites (MS365 and Google Workspace), Salesforce, etc all the time and those update on a fairly frequent basis. Also, given the need to patch promptly, most forward-looking enterprises have much more responsive systems in place -- including investments in good CI/CD systems to deliver even internal software faster. So they're quite comfortable with the "new normal" of the software industry. The most used enterprise OS, Windows, is rapid release too -- every 6 months, coincidentally! But there's a LTSB branch you can use. Java releases every 6 months too, and that hasn't halted enterprise adoption. Similarly with C#, not every team jumps to the latest language level just because it was released. Teams should pick language updates at a speed that suits them -- but hopefully not so slowly that moving to newer releases becomes difficult. Similarly with Go. Why should it be any different with Rust? To the extent that enterprises are using the latter two in massive numbers. The key thing is, as others have noted, is stability and a lack of breaking changes.
- nobleach 6y ago
  >with C#, not every team jumps to the latest language level just because it was released. Exactly when it comes to Java, even though there is now a 6 month release cadence, take a survey of which version most are using. Certainly every time I bring this up, someone pops up and says, "I'm using 11" or "10". But the vast majority of "enterprises" are at max, Java 8. And they'll remain on 8 until something forces them off of it. Enterprises by nature move at a glacial pace. So their reason for adopting Java is not because it's "moving fast".
  - signal11 6y ago
    > So their reason for adopting Java is not because it's "moving fast". I was replying to the parent poster, who said that moving fast is a roadblock to enterprise adoption. Whether enterprises adopt Java because it's moving fast is another question altogether. Certainly no one is deserting Java because of the decision to boost its release cadence. > Enterprises by nature move at a glacial pace I think it depends on the enterprise.[1] Cyber-Security has changed the game for many enterprises very fundamentally. Well-run enterprises now patch more promptly than many consumers -- at least, certainly the consumers who don't auto-update. Well, unless they want a Maersk-like incident[2], or be infected by ransomware. Maersk's incident cost it $200M if you believe Forbes. About slow JVM upgrades, a lot of that is a cost/benefit calculation or poor technical leadership. CIOs and COOs (or audit, for that matter) have no interest in which Java version you use. The only questions are: Is it secure? Does it make commercial sense? For actively developed software, staying on a recent-ish Java isn't a problem (many good enterprises have adopted Devops in some shape and form -- just add a task to your CI server to test on the latest JRE) once your engineering team has crossed the Java 8-to-11 hump. If you do that, you get to not pay Oracle $$$ per desktop/server every year (or you could use Corretto etc, but most enterprises will choose to pay Oracle). Or you could simply upgrade for the productivity & JVM improvements. Legacy products not in active development are another matter, but even there -- the cost of not getting security updates is too high nowadays, so you have to spend money to secure it -- and legacy software has other costs too[3]. So unless you're a developer working on a legacy app, or an app who's design is so poor that it's locked into Java 8, there's no reason you couldn't be on Java 11 soon and get on the rapid cadence train yourself thereafter. It's really about how nimble your team is. Of course, you could be unfortunate enough to work in an enterprise that doesn't take cyber-security seriously, in which case YOLO. [1] https://news.ycombinator.com/item?id=25873325 https://news.ycombinator.com/item?id=25873325 [2] https://www.forbes.com/sites/leemathews/2017/08/16/notpetya-ransomware-attack-cost-shipping-giant-maersk-over-200-million/ https://www.forbes.com/sites/leemathews/2017/08/16/notpetya-... [3] https://arstechnica.com/tech-policy/2021/02/citibank-just-got-a-500-million-lesson-in-the-importance-of-ui-design/ https://arstechnica.com/tech-policy/2021/02/citibank-just-go...

There are generally speaking no breaking changes. Upgrading the toolchain practically never requires any changes to code.

DyslexicAtheist 6y ago
> Upgrading the toolchain practically never requires any changes to code. if you work on safety/security critical systems upgrading the toolchain is considered like changing the tires on a moving vehicle. We have introduced and many weeks later discovered critical (and hard to trace) bugs simply by changing -O2 to -O3 in gcc that ended in sporadic crashes when cross-compiling for 1 specific platform. (which is a change much less severe than upgrading gcc itself) And I'd be surprised if upgrading the toolchain wouldn't potentially introduce similar hard to trace issues in rust. My point is that just because the first 2 months after upgrade look like there were no required changes in code doesn't mean there are none. I see rust being used in very large companies for internal projects, test harnesses, and other glue/plumbing. And the places I know are really reluctant to go all the way in and substitute their ~30 years of experience with C/C++ with something that remains a constantly moving target. To be fair there are other reasons such as culture, and distribution of skills across the team that drive these decisions but my main point still holds (i think).
- nicoburns 6y ago
  If you don't upgrade the compiler at all, then why does it matter how fast it updates? You're not going to be using the new version anyway.
  - pjmlp 6y ago
    Depends on the libraries I guess, when that CVE fix is only available on a version that requires a compiler upgrade.
  - bluGill 6y ago
    Eventually they will stop making the CPU we use and then the new CPU only works with a new compiler.
- bsder 6y ago
  1) Sorry, but if you're talking safety critical, then you're talking Sealed Rust/Ferrocene which is talked about here: https://ferrous-systems.com/blog/sealed-rust-the-plan/ https://ferrous-systems.com/blog/sealed-rust-the-plan/ I mean, even with C, there is a very circumscribed subset that you use for "safety critical" applications. 2) People are banging on about Rust not being stable but the Rust Embedded guys DO lag for stability--so you can have stability if you choose. And Rust is by far the best language I have seen about being able to stay on old compiler versions and still use newer libraries. 3) I find crappy libraries to be the biggest threat to Rust's sustainability. There was a big "Gold Rush" mentality and a whole lot of unqualified people built a whole lot of crap libraries with no good way for someone to come along later and to flag "That's a crap library, please remove it from crates.io permanently".
- roca 6y ago
  > changing -O2 to -O3 in gcc that ended in sporadic crashes when cross-compiling for 1 specific platform. Sure, this happens regularly in C and C++ because large programs inevitably depend on undefined behaviour, and changing compiler versions, optimization levels and target platforms is allowed to change that behaviour. For the last five years I've been writing 99% safe Rust code, which is designed to have no undefined behavior, and I think it's not a coincidence that I can't remember ever having a compiler update break code at runtime. Once in a long while a compiler update will fail to compile some existing code, but that's not a safety issue. The idea that C and C++ compilers are somehow more stable across releases is a mirage. https://lwn.net/Articles/845691/ https://lwn.net/Articles/845691/ https://lwn.net/Articles/845775/ https://lwn.net/Articles/845775/
  - bluGill 6y ago
    No, this happens because bugs in compilers happen. Nothing to do with undefined behavior. (Which is a separate problem)
    - steveklabnik 6y ago
      It can be both.
- dfhjgkljhf44 6y ago
  >-O2 to -O3 in gcc This sounds more like undefined behavior in your codebase than a compiler error. I don't know Rust but I'm pretty sure the whole selling point is that you won't run into problems like this.
  - tsimionescu 6y ago
    There are active open bugs today in GCC and clang for x86 where optimizations can break standards-correct code [0] (writing to a union through a pointer to a currently inactive member, which std::variant does internally). For more obscure platforms and older releases, there are bound to be numerous bugs. In particular, volatile handling is notoriously shoddy on many platforms. As an aside, the clang bug would also affect Rust if they used that type of optimization (assuming strict aliasing rules). [0] https://lists.isocpp.org/std-discussion/2020/10/0882.php https://lists.isocpp.org/std-discussion/2020/10/0882.php
    - ordu 6y ago
      > As an aside, the clang bug would also affect Rust if they used that type of optimization (assuming strict aliasing rules). No, this bug cannot affect rust, because rust wouldn't allow to pass into a function three mutable references pointing to the same object. It wouldn't even allow two, nor one mutable and one immutable. Either it pass one mutable reference, or any number of immutable.
      - steveklabnik 6y ago
        This one (probably) wouldn’t, but there have been codegen bugs in Rust, some that have blocked people from upgrading before they can be fixed. It doesn’t happen often, but it does happen.
      - tsimionescu 6y ago
        Not sure if that bug explicitly, but the fact that clang in noalias mode assumes that two pointers to different variants of the same union are not aliased (if it can't see from the immediate context that they are pointers to the same union variable) can very much affect Rust - if you call one function with a &mut to one field, than another function with a &mut to another field, and the optimizer inlines both functions in a broader context and loses the union information, you may well see reordering issues even in pure safe Rust. Anyway, Rust has found plenty of noalias bugs in clang, which is why it still doesn't compile with noalias optimizations turned on.
- dralley 6y ago
  >And I'd be surprised if upgrading the toolchain wouldn't potentially introduce similar hard to trace issues in rust. It absolutely happens, but less often than you would think. Rust has a tool named "crater" which compiles and executing tests for every package uploaded to crates.io (and some which are just on github). It's not perfect but supposedly it catches quite a lot of bugs.

signal11 6y ago

That somehow rapid-release is antithetical to the enterprise is a very archaic view of enterprise computing. Enterprises use cloud HR software, Office suites (MS365 and Google Workspace), Salesforce, etc all the time and those update on a fairly frequent basis. Also, given the need to patch promptly, most forward-looking enterprises have much more responsive systems in place -- including investments in good CI/CD systems to deliver even internal software faster. So they're quite comfortable with the "new normal" of the software industry. The most used enterprise OS, Windows, is rapid release too -- every 6 months, coincidentally! But there's a LTSB branch you can use. Java releases every 6 months too, and that hasn't halted enterprise adoption. Similarly with C#, not every team jumps to the latest language level just because it was released. Teams should pick language updates at a speed that suits them -- but hopefully not so slowly that moving to newer releases becomes difficult. Similarly with Go. Why should it be any different with Rust? To the extent that enterprises are using the latter two in massive numbers. The key thing is, as others have noted, is stability and a lack of breaking changes.

nobleach 6y ago
>with C#, not every team jumps to the latest language level just because it was released. Exactly when it comes to Java, even though there is now a 6 month release cadence, take a survey of which version most are using. Certainly every time I bring this up, someone pops up and says, "I'm using 11" or "10". But the vast majority of "enterprises" are at max, Java 8. And they'll remain on 8 until something forces them off of it. Enterprises by nature move at a glacial pace. So their reason for adopting Java is not because it's "moving fast".
- signal11 6y ago
  > So their reason for adopting Java is not because it's "moving fast". I was replying to the parent poster, who said that moving fast is a roadblock to enterprise adoption. Whether enterprises adopt Java because it's moving fast is another question altogether. Certainly no one is deserting Java because of the decision to boost its release cadence. > Enterprises by nature move at a glacial pace I think it depends on the enterprise.[1] Cyber-Security has changed the game for many enterprises very fundamentally. Well-run enterprises now patch more promptly than many consumers -- at least, certainly the consumers who don't auto-update. Well, unless they want a Maersk-like incident[2], or be infected by ransomware. Maersk's incident cost it $200M if you believe Forbes. About slow JVM upgrades, a lot of that is a cost/benefit calculation or poor technical leadership. CIOs and COOs (or audit, for that matter) have no interest in which Java version you use. The only questions are: Is it secure? Does it make commercial sense? For actively developed software, staying on a recent-ish Java isn't a problem (many good enterprises have adopted Devops in some shape and form -- just add a task to your CI server to test on the latest JRE) once your engineering team has crossed the Java 8-to-11 hump. If you do that, you get to not pay Oracle $$$ per desktop/server every year (or you could use Corretto etc, but most enterprises will choose to pay Oracle). Or you could simply upgrade for the productivity & JVM improvements. Legacy products not in active development are another matter, but even there -- the cost of not getting security updates is too high nowadays, so you have to spend money to secure it -- and legacy software has other costs too[3]. So unless you're a developer working on a legacy app, or an app who's design is so poor that it's locked into Java 8, there's no reason you couldn't be on Java 11 soon and get on the rapid cadence train yourself thereafter. It's really about how nimble your team is. Of course, you could be unfortunate enough to work in an enterprise that doesn't take cyber-security seriously, in which case YOLO. [1] https://news.ycombinator.com/item?id=25873325 https://news.ycombinator.com/item?id=25873325 [2] https://www.forbes.com/sites/leemathews/2017/08/16/notpetya-ransomware-attack-cost-shipping-giant-maersk-over-200-million/ https://www.forbes.com/sites/leemathews/2017/08/16/notpetya-... [3] https://arstechnica.com/tech-policy/2021/02/citibank-just-got-a-500-million-lesson-in-the-importance-of-ui-design/ https://arstechnica.com/tech-policy/2021/02/citibank-just-go...