3 ms·

This argument doesn't make sense to me either, but maybe I'm just stupid. For something to die at 3am in production, that means either someone pushed code way

This argument doesn't make sense to me either, but maybe I'm just stupid. For something to die at 3am in production, that means either someone pushed code way too late, or something changed in the stack unpredictability. Your compiler wouldn't have been able to predict either of those cases. But bugs are bugs, if I'm called at 3am to fix a bug, I don't want to spend hours trying to fight my compiler, and then fall back asleep while I'm waiting for it to compile. I want to quickly identify the issue, and then to be able to write the smallest possible patch until morning. In my limited experience, rust is conducive to neither of those options. And you said "if we get liquid types" I assume that means you meant it to say if rust gets? Unless you meant to identify as part of the rust language?

satvikpendem 3y ago
My point is that the more bugs that are caught at compile-time rather than runtime, the better, as it's a much lower likelihood that something randomly breaks in the middle of the night. It has nothing to do with when someone pushed their code out or the stack changing. Someone could have pushed a runtime bug that was not caught (but that could have been caught at compile-time, depending on the type of bug, of course) that then breaks production later on when a specific thing gets triggered. You wouldn't be fighting the compiler at 3 am as well as the code because you likely wouldn't be fixing things at 3 am in the first place, and if it's not something that's caught at compile time, well then you'd be dealing with the language either way. Compile-time checks help you write better code, generally speaking.
- wredue 3y ago
  The idea that “compile time checks help you write better code is unanimous and absolute” is simply false. Rust itself demonstrates that compile time checks sometimes result in worse code, as many people have found especially when they need to do things rust doesn’t like for performance reasons. For sure, some checks are unambiguously good. But there is also definitely a moving target of a line towards whether or not more checks has diminishing returns if not negative returns on your code. That moving line will depend on a lot of things. You also need to be careful because “more checks” doesn’t mean “less work” as you’ve asserted. It means more work in a lot of safe pointer scenarios in rust, and more work actually does often translate to more logic bugs and more complexity when anything changes. As far as I can tell, more checks doesn’t same any time, it often just changes where your time is spent.
  - tored 3y ago
    Not a Rust developer, in what way is Rust forcing you to write less performant code? Any good example?
    - grayhatter 3y ago
      I doubt you'll have anyone take you up on this offer. Goal posts for "good example" get moved every time anyone tries. Anything using Arc is a good place to start though.
    - Measter 3y ago
      The borrow checker is really at its happiest when your ownership and borrow structure is tree-like, so uni-directional references and ownership, because it's much easier to analyse. If the ownership structure that gives the best performance for your problem is not tree-like, you will run into issues with the borrow checker. There are ways to tackle it: you could keep the non-tree-like structure and use reference counting and RefCells to move the borrow checking to runtime, or its possible you could use a less performant but tree-like structure that the borrow checker accepts, but both of these examples would come at a performance cost. It's kinda hard to be more specific because it's heavily dependent on the exact problem.
Philpax 3y ago
> For something to die at 3am in production, that means either someone pushed code way too late, or something changed in the stack unpredictability. I don't think those are the only two scenarios. I think the most likely scenario by far is user input triggering a latent issue in a code path and promptly bringing the application down. A classic example, of course, is a missing bounds check. Modern language design makes this less likely by enforcing invariants, adding checks, and making these kinds of issues impossible by construction. It doesn't mean that there isn't a space for languages without these safe guards, but it does mean you should have a really good reason to use them. > But bugs are bugs, if I'm called at 3am to fix a bug, I don't want to spend hours trying to fight my compiler, and then fall back asleep while I'm waiting for it to compile. I want to quickly identify the issue, and then to be able to write the smallest possible patch until morning. In my limited experience, rust is conducive to neither of those options. In my experience with Rust specifically, I've actually found it easier to make those kinds of fixes as the area of code I have to reason about is much smaller. I don't have to worry that a local change will have global effects, as I can much more clearly see the dataflow. It's not a silver bullet, but I've felt much more comfortable doing emergency fixes on Rust than on C++.

satvikpendem 3y ago

My point is that the more bugs that are caught at compile-time rather than runtime, the better, as it's a much lower likelihood that something randomly breaks in the middle of the night. It has nothing to do with when someone pushed their code out or the stack changing. Someone could have pushed a runtime bug that was not caught (but that could have been caught at compile-time, depending on the type of bug, of course) that then breaks production later on when a specific thing gets triggered. You wouldn't be fighting the compiler at 3 am as well as the code because you likely wouldn't be fixing things at 3 am in the first place, and if it's not something that's caught at compile time, well then you'd be dealing with the language either way. Compile-time checks help you write better code, generally speaking.

wredue 3y ago
The idea that “compile time checks help you write better code is unanimous and absolute” is simply false. Rust itself demonstrates that compile time checks sometimes result in worse code, as many people have found especially when they need to do things rust doesn’t like for performance reasons. For sure, some checks are unambiguously good. But there is also definitely a moving target of a line towards whether or not more checks has diminishing returns if not negative returns on your code. That moving line will depend on a lot of things. You also need to be careful because “more checks” doesn’t mean “less work” as you’ve asserted. It means more work in a lot of safe pointer scenarios in rust, and more work actually does often translate to more logic bugs and more complexity when anything changes. As far as I can tell, more checks doesn’t same any time, it often just changes where your time is spent.
- tored 3y ago
  Not a Rust developer, in what way is Rust forcing you to write less performant code? Any good example?
  - grayhatter 3y ago
    I doubt you'll have anyone take you up on this offer. Goal posts for "good example" get moved every time anyone tries. Anything using Arc is a good place to start though.
  - Measter 3y ago
    The borrow checker is really at its happiest when your ownership and borrow structure is tree-like, so uni-directional references and ownership, because it's much easier to analyse. If the ownership structure that gives the best performance for your problem is not tree-like, you will run into issues with the borrow checker. There are ways to tackle it: you could keep the non-tree-like structure and use reference counting and RefCells to move the borrow checking to runtime, or its possible you could use a less performant but tree-like structure that the borrow checker accepts, but both of these examples would come at a performance cost. It's kinda hard to be more specific because it's heavily dependent on the exact problem.

Philpax 3y ago

> For something to die at 3am in production, that means either someone pushed code way too late, or something changed in the stack unpredictability. I don't think those are the only two scenarios. I think the most likely scenario by far is user input triggering a latent issue in a code path and promptly bringing the application down. A classic example, of course, is a missing bounds check. Modern language design makes this less likely by enforcing invariants, adding checks, and making these kinds of issues impossible by construction. It doesn't mean that there isn't a space for languages without these safe guards, but it does mean you should have a really good reason to use them. > But bugs are bugs, if I'm called at 3am to fix a bug, I don't want to spend hours trying to fight my compiler, and then fall back asleep while I'm waiting for it to compile. I want to quickly identify the issue, and then to be able to write the smallest possible patch until morning. In my limited experience, rust is conducive to neither of those options. In my experience with Rust specifically, I've actually found it easier to make those kinds of fixes as the area of code I have to reason about is much smaller. I don't have to worry that a local change will have global effects, as I can much more clearly see the dataflow. It's not a silver bullet, but I've felt much more comfortable doing emergency fixes on Rust than on C++.