3 ms·

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

by 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.
        tptacek 7y ago
        I don’t doubt it causes bugs. I wish Go had option types, as well. I’m just saying that it’s not unusual behavior, and you’re going to single languages out for the bugs they enable, you’ve a long future of boring arguments ahead of you.
        deleted 7y ago
        [deleted]
    - pcwalton 7y ago
      > Meanwhile, the scenario described in this blog post is shared by virtually every mainstream implementation language other than Rust. I don't believe that TypeScript, which is mainstream, has zero values if strict mode is enabled. (I could be wrong though; plugging all the "undefined" leaks is hard in JS.)

by apta 7y ago

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.
        tptacek 7y ago
        I don’t doubt it causes bugs. I wish Go had option types, as well. I’m just saying that it’s not unusual behavior, and you’re going to single languages out for the bugs they enable, you’ve a long future of boring arguments ahead of you.
        deleted 7y ago
        [deleted]
  - pcwalton 7y ago
    > Meanwhile, the scenario described in this blog post is shared by virtually every mainstream implementation language other than Rust. I don't believe that TypeScript, which is mainstream, has zero values if strict mode is enabled. (I could be wrong though; plugging all the "undefined" leaks is hard in JS.)