3 ms·

Most of these is confirmation of easily observable reality, but the 4x difference in rollback rates, jesus christ.

by masklinn 1y ago

anttiharju 1y ago
I found it interesting that the rollback rate remained more or less constant despite size differences.
deleted 1y ago
[deleted]
bla3 1y ago
If they use Rust for new code and C++ changes are all in old code, this could be explained just by older code being more risky to change.
- nixpulvis 1y ago
  Funny, another commenter on this post was saying the opposite, that Rust was likely being used to just port existing features and that was easier because there were probably good tests for it already. If you've actually written considerable amounts of Rust and C++, these statistics don't require justification. In my opinion it's completely expected that Rust code is easier to write correctly.
  - kridsdale1 1y ago
    I’d say the same applies for Swift vs ObjC. Let’s end the C era.
    - girvo 1y ago
      While the C calling convention continues to rule operating systems and FFIs, I think it’ll continue to limp along. Hopefully one day that can be fixed, it’s annoying that C is what I have to reach for to call SomeLib no matter what language I’m using
    - manmal 1y ago
      Apple should have modernized ObjC instead of making Swift the lingua franca. Both speed of iteration and flexibility (on which web-stack-rivaling productivity features would have been possible) are gone forever. Swift Concurrency is a tire fire that not even their async-algorithms team can use completely correctly, and useful feature like typed throws are left half finished. The enormous effort the constant further bastardization of Swift takes, is at least in part the reason for the sorry state dev tooling is in. Not even a 4T dollar company can make a reliable SwiftUI preview work, in their own IDE. Variadic generics (a seemingly pure compiler feature) crash at runtime if you look at them the wrong way. Actors, the big light tower of their structured concurrency, are unusable because calls to them are unordered. They enforce strict concurrency checking now, but the compiler is too dumb to infer common valid send patterns; and their solution to make this abomination work in real codebases? Intro a default that lets _everything_ in a module run on the main thread per default! </rant>
      - ModernMech 1y ago
        Swift has so many issues they would honestly be better off just moving to Rust rather than fix Swift. Seriously. The fact that it's so easy to get the compiler to spend exponential time resolving types that it very often just shits the bed and begs you to rewrite your code for it to stand a chance is shameful coming from, as you say, a $4T company. Points to deep problems with Swift.
        manmal 1y ago
        I fully, totally agree with this. The recent fixes for concurrency makes Swift look like a poor man’s Rust anyway.
      - kridsdale1 1y ago
        I don’t disagree with anything you said.
  - danudey 1y ago
    As a relatively novice programmer who's worked in tech for decades but not as a software developer: I take issue with the idea that you need to write considerable amounts of Rust and C++ for these statistics to be expected. In fact, despite Rust's initial vertical learning curve I'd say that any junior developer trying to implement anything with any degree of complexity at all in Rust and C++ would see the benefits. At the very least, the fact that IDE integration can tell you all kinds of stuff about what you're doing/doing wrong and why accelerates things greatly when you're starting out.
    - nixpulvis 1y ago
      Oh I totally agree with you. The logic in my comment wasn't that you need to have written considerably amounts of code to be expecting this, just that to not be expecting this would make me think you hadn't. If that makes sense. On your second point, I think IDE integration for C++ is similar as it is for Rust. Just Rust errors and tooling are a million times better regardless of IDE.
    - marcosdumay 1y ago
      Oh, the more junior the developers, the quicker they will get any benefit. That's common for any language that enforces correctness, but the C++ vs. Rust comparison isn't even fair; C++ is an incredibly hard language to use. Now, if they actually "see" it is another matter.
    - baq 1y ago
      The problem with junior developers is that Rust will be incredibly frustrating to learn by perturbation, because the compiler will reject most random changes to the code. Which is the point of course, but C++ will compile programs which then crash, giving you a very misguided feeling that you’re making progress, but this is very important in the process of gaining new skills. I don’t see a way around it, programming without garbage collection is hard, Rust makes it very clear very quickly, which is also the point, but this is at odds with making the learning curve accessible.
      - danudey 1y ago
- nicoburns 1y ago
  I think they're comparing new code in Rust vs new code in C++.
MBCook 1y ago
We all knew rust was safer. It was the 1000x number that surprised me. Which is more that rust isn’t that safe in my mind, it’s that bugs are that prevalent. I never would have guessed that. That 4x rate is very impressive too. Great seeing all this data from a large big complicated codebase.
ActorNightly 1y ago
The issue with most codebases is nobody thinks about starting out with acceptance testing system. The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests or a subset based on what you are working on. This is essentially your contract for software. And on a modular level, it means that it scopes down the contracts to the individual sub systems. And things like memory and cpu runtime constraints are a part of this. If you have this, you basically replace what the Rust compiler is doing for you with tests. Memory leaks are caught. However, as a benefit, you also can verify changes in the dev cycle with things like performance degradation, all in the same system.
- ikety 1y ago
  I'm not sure that nobody thinks of this. We just have a finite amount of time. Usually with a solid approach, you get solid performance. Fixing a performance related bug rarely when it comes up, is still a time savings over designing this kind of rigorous process from scratch, and getting everyone on board with it. Getting rid of a whole host of bugs due to the compiler is a big deal because you won't have to design this extra acceptance system or deal with keeping an entire organization disciplined by it. If you can solve this seamlessly I think that's an interesting product that others would be very interested in.
  - ActorNightly 1y ago
    > because you won't have to design this extra acceptance system or deal with keeping an entire organization disciplined by it. This is just a matter of tooling. (On that note, here is a free business idea, prompt engineer an LLM agent that sets this up for you) While the compiler does do a lot of things for you, you still end up with things that you should check because compiler doesn't understand your program logic. If Rust was a absolutely strict typed language, where basically everything had a type that defined what data it could hold, then it would be a different story. For example, when parsing a json into an object, instead of strings/numbers/bools, every single field has a finite set of values that it can hold. Then the compiler can figure out a lot of things. For example, if you try to convert a string to int, if the string field type doesn't have a defined regex expression it must match, then the compiler can catch this. Anything less then that, you are better of writing the validation system once and reusing it for all your code bases now and in the future.

Most of these is confirmation of easily observable reality, but the 4x difference in rollback rates, jesus christ.

anttiharju 1y ago

I found it interesting that the rollback rate remained more or less constant despite size differences.

deleted 1y ago

[deleted]

bla3 1y ago

If they use Rust for new code and C++ changes are all in old code, this could be explained just by older code being more risky to change.

nixpulvis 1y ago
Funny, another commenter on this post was saying the opposite, that Rust was likely being used to just port existing features and that was easier because there were probably good tests for it already. If you've actually written considerable amounts of Rust and C++, these statistics don't require justification. In my opinion it's completely expected that Rust code is easier to write correctly.
- kridsdale1 1y ago
  I’d say the same applies for Swift vs ObjC. Let’s end the C era.
  - girvo 1y ago
    While the C calling convention continues to rule operating systems and FFIs, I think it’ll continue to limp along. Hopefully one day that can be fixed, it’s annoying that C is what I have to reach for to call SomeLib no matter what language I’m using
  - manmal 1y ago
    Apple should have modernized ObjC instead of making Swift the lingua franca. Both speed of iteration and flexibility (on which web-stack-rivaling productivity features would have been possible) are gone forever. Swift Concurrency is a tire fire that not even their async-algorithms team can use completely correctly, and useful feature like typed throws are left half finished. The enormous effort the constant further bastardization of Swift takes, is at least in part the reason for the sorry state dev tooling is in. Not even a 4T dollar company can make a reliable SwiftUI preview work, in their own IDE. Variadic generics (a seemingly pure compiler feature) crash at runtime if you look at them the wrong way. Actors, the big light tower of their structured concurrency, are unusable because calls to them are unordered. They enforce strict concurrency checking now, but the compiler is too dumb to infer common valid send patterns; and their solution to make this abomination work in real codebases? Intro a default that lets _everything_ in a module run on the main thread per default! </rant>
    - ModernMech 1y ago
      Swift has so many issues they would honestly be better off just moving to Rust rather than fix Swift. Seriously. The fact that it's so easy to get the compiler to spend exponential time resolving types that it very often just shits the bed and begs you to rewrite your code for it to stand a chance is shameful coming from, as you say, a $4T company. Points to deep problems with Swift.
      - manmal 1y ago
        I fully, totally agree with this. The recent fixes for concurrency makes Swift look like a poor man’s Rust anyway.
    - kridsdale1 1y ago
      I don’t disagree with anything you said.
- danudey 1y ago
  As a relatively novice programmer who's worked in tech for decades but not as a software developer: I take issue with the idea that you need to write considerable amounts of Rust and C++ for these statistics to be expected. In fact, despite Rust's initial vertical learning curve I'd say that any junior developer trying to implement anything with any degree of complexity at all in Rust and C++ would see the benefits. At the very least, the fact that IDE integration can tell you all kinds of stuff about what you're doing/doing wrong and why accelerates things greatly when you're starting out.
  - nixpulvis 1y ago
    Oh I totally agree with you. The logic in my comment wasn't that you need to have written considerably amounts of code to be expecting this, just that to not be expecting this would make me think you hadn't. If that makes sense. On your second point, I think IDE integration for C++ is similar as it is for Rust. Just Rust errors and tooling are a million times better regardless of IDE.
  - marcosdumay 1y ago
    Oh, the more junior the developers, the quicker they will get any benefit. That's common for any language that enforces correctness, but the C++ vs. Rust comparison isn't even fair; C++ is an incredibly hard language to use. Now, if they actually "see" it is another matter.
  - baq 1y ago
    The problem with junior developers is that Rust will be incredibly frustrating to learn by perturbation, because the compiler will reject most random changes to the code. Which is the point of course, but C++ will compile programs which then crash, giving you a very misguided feeling that you’re making progress, but this is very important in the process of gaining new skills. I don’t see a way around it, programming without garbage collection is hard, Rust makes it very clear very quickly, which is also the point, but this is at odds with making the learning curve accessible.
    - danudey 1y ago
nicoburns 1y ago
I think they're comparing new code in Rust vs new code in C++.

MBCook 1y ago

We all knew rust was safer. It was the 1000x number that surprised me. Which is more that rust isn’t that safe in my mind, it’s that bugs are that prevalent. I never would have guessed that. That 4x rate is very impressive too. Great seeing all this data from a large big complicated codebase.

ActorNightly 1y ago

The issue with most codebases is nobody thinks about starting out with acceptance testing system. The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests or a subset based on what you are working on. This is essentially your contract for software. And on a modular level, it means that it scopes down the contracts to the individual sub systems. And things like memory and cpu runtime constraints are a part of this. If you have this, you basically replace what the Rust compiler is doing for you with tests. Memory leaks are caught. However, as a benefit, you also can verify changes in the dev cycle with things like performance degradation, all in the same system.

ikety 1y ago
I'm not sure that nobody thinks of this. We just have a finite amount of time. Usually with a solid approach, you get solid performance. Fixing a performance related bug rarely when it comes up, is still a time savings over designing this kind of rigorous process from scratch, and getting everyone on board with it. Getting rid of a whole host of bugs due to the compiler is a big deal because you won't have to design this extra acceptance system or deal with keeping an entire organization disciplined by it. If you can solve this seamlessly I think that's an interesting product that others would be very interested in.
- ActorNightly 1y ago
  > because you won't have to design this extra acceptance system or deal with keeping an entire organization disciplined by it. This is just a matter of tooling. (On that note, here is a free business idea, prompt engineer an LLM agent that sets this up for you) While the compiler does do a lot of things for you, you still end up with things that you should check because compiler doesn't understand your program logic. If Rust was a absolutely strict typed language, where basically everything had a type that defined what data it could hold, then it would be a different story. For example, when parsing a json into an object, instead of strings/numbers/bools, every single field has a finite set of values that it can hold. Then the compiler can figure out a lot of things. For example, if you try to convert a string to int, if the string field type doesn't have a defined regex expression it must match, then the compiler can catch this. Anything less then that, you are better of writing the validation system once and reusing it for all your code bases now and in the future.