4 ms·

I don't think this comment really contributes to the discussion. It comes across as Rust advocacy without having any tangible points to make. First paragraph:

• ncruces 3y ago
  There's one thing in there worth discussing IMO: the focus on zero values (incl. nil). That's the Go mistake, the one that causes most of the issues for the intended audience, the one that can't really be fixed. It's a shame Pike doesn't really discuss this, even if it's hopeless now. The rest is just people projecting and self-selecting outside of the intended audience. Don't like it, don't use it, we don't all need to agree with you.
  • campbel 3y ago
    Zero values are fine, some benefits, some drawbacks. Workarounds exist for when you need to identify the difference between unset and zero.
    • FridgeSeal 3y ago
      No they’re not, they’re a horrible decision, and some of the “solutions” I’ve seen for working around them are band-aid-code at best. The design decisions around zero values infect protobufs too, and they suck to work around. The fact that an empty message can successfully deserialise into any valid protobuf is an insane decision and should have been thrown out long ago.
      • znkr 3y ago
        > The fact that an empty message can successfully deserialise into any valid protobuf is an insane decision and should have been thrown out long ago The reason for this is that the protobuf wire format is designed for very high entropy: It contains only a minimal amount of metadata and consists mostly of data. This means you can deserialize most wire messages as a different message. This is a tradeoff: smaller message size for loss of schema information. This just means that schemas need to be handled at a higher level. This tradeoff makes some sense if you process millions of protos per second. BTW: Dismissing a tradeoff like this as insane is derogatory. You can do better
      • campbel 3y ago
        This is the main drawback I also experience with zero values, knowing whether something was set or its the zero value. Like I said, there are some work arounds, buts its a tradeoff. Perhaps its a tradeoff you don't like.
    • euroderf 3y ago
      > when you need to identify the difference between unset and zero. Use pointer variables ? Works 4 me.
      • campbel 3y ago
        Also what I do. You could theoretically also create your own type that manages deserialization and includes an "is_set" field.
        • euroderf 3y ago
          FWIW: calling Error() on a nil error is an obnoxious NPE fail, so I made this: https://pkg.go.dev/github.com/fbaube/miscutils#Errer https://pkg.go.dev/github.com/fbaube/miscutils#Errer
    • orangeboats 3y ago
      I don't see how they are fine, when NULL is widely known (even though it might not be agreed by some) as the billion-dollar mistake. One could have easily added an Optional type that forces programmers to check for nil every time the optional variable is accessed.
      • campbel 3y ago
        Couldn't we do an optional type with the type system as is rather than embedding in the language? type Optional[V any] struct { IsSet bool Value V }
        • kaba0 3y ago
          The type system would store it at compile time, while your type would only have it at runtime.
        • ncruces 3y ago
          How does that prevent an unset Value from being used?
    • ncruces 3y ago
      Sorry, but no. Interfaces and how they ended up limiting generics (parametric polymorphism) are a tradeoff. Structural interfaces (duck-typed in an otherwise static-typed, with composition-over-inheritance, language) are innovative, interesting, and offer many benefits, enough to compensate any drawbacks. This is mentioned in the talk. But the fact that anyone can just conjure a zero value out of thin air, and this fine because it's zero initialized (a decade after Java had proved this was really not good enough) it's pretty inexcusable. And this is not just a "default," it's actually impossible by design to enforce initialization in any way. Then they did this in a language with pointers, which by necessity are zero initialized to nil, and simply added some timid steps to make nils more useable/useful (like nil receivers being valid). Which unfortunately, in the end, only further complicates static analysis and tooling that might ameliorate the issue. Finally, if this wasn't enough of a problem, nil panics (any panics, in fact) are a hard crash if a goroutine doesn't handle them, and: it's impossible to add a global handler, it's impossible to prevent goroutines from being created that don't handle panics. So any code that you call can crash your program, and this is considered good form. If you really feel that zero values are useful enough to justify all this, please explain. Because I just don't see it. This isn't a widely innovative feature that shapes idiomatic programming in an amazing way. The standard library is full of awkward hacks to make zero values useful (esp. in the face of backwards compatibility), where simple enforced construction would be much better. I love Go. It's my favourite programming tool. I wish I could use it more professionally. But not acknowledging this error, or being dismissive, and doing nothing about it, helps no one.
      • campbel 3y ago
        I like zero values because when I create a struct I can know for certain accessing a non pointer won't crash the program. That's a pretty good value add. My type system also knows this, so I don't have to worry about asserting non nil values or adding needless if value == nil checks.
        • Gadiguibou 3y ago
          I understand that you like zero values as an alternative to initialization of objects as nil like Java does it. I think the parent comment explains pretty well what the issues with this approach are. Taking Rust as an example (because that's what I'm most familiar with), it's possible to simply enforce that variables are initialized explicitly or that safe constructors are provided, avoiding all the nil safety issues.
• cangeroo 3y ago
  I was trying to say that: by paragraph: 1) The article should have acknowledged the issues that a wide part of the community are experiencing. 2) I accept that I'm the problem. But then I must leave. 3) The consequence of their attitude is that I cannot recommend the language anymore. I used to be excited about it, and that disappointment makes me angry. 4) If only Go was trying to be better. Rust is just an example of the visionary leadership that I expect from Go. I want go to be visionary! Because they have some things right, like fast compiliation, cross compilation, simple syntax, and a focus on simple concurrency. But it's like those ideas never developed. 5) Rust is a counterexample, that a language can be visionary, without giving up on its fundamentals. 6) Acknowledgment that Go was the best solution at a time. But also that the time seems to have passed.