5 ms·

Actually is pretty good. The world have a lot of bugs in prod because C doesn't zero newly allocated memory (heap or stack). There are APIs with autogenerated

Actually is pretty good. The world have a lot of bugs in prod because C doesn't zero newly allocated memory (heap or stack). There are APIs with autogenerated structs that span a lot of fields (even thousands)... Imagine having to initialize each field when you just want... the default zero value...

steveklabnik 7y ago
There are more options in the design space than those two extremes. Rust does not do either of these two things, for example. It will not let you use something you haven’t initialized, but it also doesn’t force you to declare a default value for each type. If a default value makes sense, you can make one, but you still have to explicitly ask for a default, rather than it implicitly happening. I think each of these three languages have made the correct choice, given their design ideals.
- apta 7y ago
  I appreciate your work on Rust, I find it to be a very interesting language. > I think each of these three languages have made the correct choice, given their design ideals. I feel that's kind of side-stepping the issue though. The approach that golang took could match their design goals, but it doesn't mean that those goals aren't a bad idea in the first place.
  - tptacek 7y ago
    For any set of correctness-improving primitives in a language, you can practically always come up with some disjoint set of additional primitives, and then make the argument that the lack of those additional primitives constitute "bad design". Sometimes you'll even be right (it's not clear to me in this case). But it will almost always be a boring argument.
    - apta 7y ago
      In this case though, it's the addition of a "feature" that causes bugs, so lack of said feature will improve correctness.
      - tptacek 7y ago
        Zeroing out uninitialized memory is a feature, one which significantly improves correctness over C/C++. Meanwhile, the scenario described in this blog post is shared by virtually every mainstream implementation language other than Rust.
        apta 7y ago
        I don't see it in Java or C# for instance. You have to explicitly opt into it by (1) declaring default (parameter-less constructors), and (2) exposing fields you want mutated via setters. On the other hand, golang does not have the ability to prevent "default constructors", and the fact that it has no ability to make types file private further makes this an issue.
        tptacek 7y ago
        Java initializes variables to their zero values. If you want to hide Go struct members from other "files", you can do that trivially by putting them in subdirectories.
        apta 7y ago
        > Java initializes variables to their zero values I know, but that's not what I'm referring to here. I'm referring to someone writing: type A struct { A int B int } a := A {A: 1, B: 2} then modifying `A` by adding another field `C int` The code continues to compile, with `C` being initialized to 0, which can be incorrect. In Java or C#, you'd add a third value to the constructor, resulting in a compile time error for all constructor invocations. As I said, I've seen this issue come up in production resulting in bugs.
        7y ago

steveklabnik 7y ago

There are more options in the design space than those two extremes. Rust does not do either of these two things, for example. It will not let you use something you haven’t initialized, but it also doesn’t force you to declare a default value for each type. If a default value makes sense, you can make one, but you still have to explicitly ask for a default, rather than it implicitly happening. I think each of these three languages have made the correct choice, given their design ideals.

apta 7y ago
I appreciate your work on Rust, I find it to be a very interesting language. > I think each of these three languages have made the correct choice, given their design ideals. I feel that's kind of side-stepping the issue though. The approach that golang took could match their design goals, but it doesn't mean that those goals aren't a bad idea in the first place.
- tptacek 7y ago
  For any set of correctness-improving primitives in a language, you can practically always come up with some disjoint set of additional primitives, and then make the argument that the lack of those additional primitives constitute "bad design". Sometimes you'll even be right (it's not clear to me in this case). But it will almost always be a boring argument.
  - apta 7y ago
    In this case though, it's the addition of a "feature" that causes bugs, so lack of said feature will improve correctness.
    - tptacek 7y ago
      Zeroing out uninitialized memory is a feature, one which significantly improves correctness over C/C++. Meanwhile, the scenario described in this blog post is shared by virtually every mainstream implementation language other than Rust.
      - apta 7y ago
        I don't see it in Java or C# for instance. You have to explicitly opt into it by (1) declaring default (parameter-less constructors), and (2) exposing fields you want mutated via setters. On the other hand, golang does not have the ability to prevent "default constructors", and the fact that it has no ability to make types file private further makes this an issue.
        tptacek 7y ago
        Java initializes variables to their zero values. If you want to hide Go struct members from other "files", you can do that trivially by putting them in subdirectories.
        apta 7y ago
        > Java initializes variables to their zero values I know, but that's not what I'm referring to here. I'm referring to someone writing: type A struct { A int B int } a := A {A: 1, B: 2} then modifying `A` by adding another field `C int` The code continues to compile, with `C` being initialized to 0, which can be incorrect. In Java or C#, you'd add a third value to the constructor, resulting in a compile time error for all constructor invocations. As I said, I've seen this issue come up in production resulting in bugs.
        7y ago