5 ms·

It's not guaranteed at all, that's where go's zero-values come in. E.g. nested structs, un/marshaljson magic methods etc. How do you deal with that?

stouset 3y ago
Every struct requiring its zero value to be meaningful is probably one of the worst design flaws in the language.
- randomdata 3y ago
  There is no such requirement. Common wisdom suggests that you should ensure zero values are useful, but that isn't about every random struct field – only the values you actually give others. Initialize your struct fields and you won't have to consider their zero state. They will never be zero. It's funny seeing this beside the DRY thread. Seems programmers taking things a bit too literally is a common theme.
  - stouset 3y ago
    > Initialize your struct fields and you won't have to consider their zero state. “Just do the right thing everywhere and you don’t have to worry!” You can’t stop consumers of your libraries from creating zero-valued instances.
    - randomdata 3y ago
      Then the zero value is their problem, not yours. You have no reason to be worried about that any more than you are worried about them not getting enough sleep, or eating unhealthy food. What are you doing to stop them from doing that? Nothing, of course. Not your problem. Coq exists if you really feel you need a complete type system. But there is probably good reason why almost nobody uses it.
      - stouset 3y ago
        > Then the zero value is their problem, not yours. Except for all those times you're the consumer of someone else's library and there's no way for them to indicate that creating a zero-valued struct is a bug. Again, it's the philosophy of "Just do the right thing everywhere and you don’t have to worry!" Sometimes it's nice to work with a type system where designers of libraries can actually prevent you from writing bugs.
        randomdata 3y ago
        > Except for all those times you're the consumer of someone else's library and there's no way for them to indicate that creating a zero-valued struct is a bug. Nonsense. Go has a built-in facility for documentation to communicate these things to other developers. Idiomatic Go strongly encourages you to use it. Consumers of the libraries expect it. > Sometimes it's nice to work with a type system where designers of libraries can actually prevent you from writing bugs. Well, sure. But, like I said, almost nobody uses Coq. The vast, vast, vast majority of projects – and I expect 100% of web projects – use languages with incomplete type systems, making what you seek impossible. And there's probably a good reason for that. While complete type systems sound nice in theory, practice isn't so kind. There are tradeoffs abound. There is no free lunch in life. Sorry.
        owl57 3y ago
        > The vast, vast, vast majority of projects – and I expect 100% of web projects – use languages with incomplete type systems, making what you seek impossible. …where, "what GP seeks" is… > way for [library authors] to indicate that creating a zero-valued struct is a bug I'd say that's a really low and practical bar, you really don't need Coq for that. Good old Python is enough, even without linters and type hints. Of course it's very easy to create an equivalent of zero struct (object without __init__ called), but do you think it's possible to do it while not noticing that you are doing something unusual?
        randomdata 3y ago
- ttymck 3y ago
  This is where we arrive at my conclusion that go is not well-suited to implementing business logic!
  - deleted 3y ago
    [deleted]
- angra_mainyu 3y ago
  On the contrary, I've found striving to make zero values meaningful makes designs far more succinct and clearer.
bsdpufferfish 3y ago
C++ constructors actually make the guarantee, but it comes with other pains
- masklinn 3y ago
  Lots of languages handle it just fine and don’t need the mess of C++ ctors. GP is pointing out that go specifically makes it an issue.
  - bsdpufferfish 3y ago
    What language do you have in mind?
    - masklinn 3y ago
      Any language which supports private state: smalltalk, haskell, ada, rust, …

stouset 3y ago

Every struct requiring its zero value to be meaningful is probably one of the worst design flaws in the language.

randomdata 3y ago
There is no such requirement. Common wisdom suggests that you should ensure zero values are useful, but that isn't about every random struct field – only the values you actually give others. Initialize your struct fields and you won't have to consider their zero state. They will never be zero. It's funny seeing this beside the DRY thread. Seems programmers taking things a bit too literally is a common theme.
- stouset 3y ago
  > Initialize your struct fields and you won't have to consider their zero state. “Just do the right thing everywhere and you don’t have to worry!” You can’t stop consumers of your libraries from creating zero-valued instances.
  - randomdata 3y ago
    Then the zero value is their problem, not yours. You have no reason to be worried about that any more than you are worried about them not getting enough sleep, or eating unhealthy food. What are you doing to stop them from doing that? Nothing, of course. Not your problem. Coq exists if you really feel you need a complete type system. But there is probably good reason why almost nobody uses it.
    - stouset 3y ago
      > Then the zero value is their problem, not yours. Except for all those times you're the consumer of someone else's library and there's no way for them to indicate that creating a zero-valued struct is a bug. Again, it's the philosophy of "Just do the right thing everywhere and you don’t have to worry!" Sometimes it's nice to work with a type system where designers of libraries can actually prevent you from writing bugs.
      - randomdata 3y ago
        > Except for all those times you're the consumer of someone else's library and there's no way for them to indicate that creating a zero-valued struct is a bug. Nonsense. Go has a built-in facility for documentation to communicate these things to other developers. Idiomatic Go strongly encourages you to use it. Consumers of the libraries expect it. > Sometimes it's nice to work with a type system where designers of libraries can actually prevent you from writing bugs. Well, sure. But, like I said, almost nobody uses Coq. The vast, vast, vast majority of projects – and I expect 100% of web projects – use languages with incomplete type systems, making what you seek impossible. And there's probably a good reason for that. While complete type systems sound nice in theory, practice isn't so kind. There are tradeoffs abound. There is no free lunch in life. Sorry.
        owl57 3y ago
        > The vast, vast, vast majority of projects – and I expect 100% of web projects – use languages with incomplete type systems, making what you seek impossible. …where, "what GP seeks" is… > way for [library authors] to indicate that creating a zero-valued struct is a bug I'd say that's a really low and practical bar, you really don't need Coq for that. Good old Python is enough, even without linters and type hints. Of course it's very easy to create an equivalent of zero struct (object without __init__ called), but do you think it's possible to do it while not noticing that you are doing something unusual?
        randomdata 3y ago
ttymck 3y ago
This is where we arrive at my conclusion that go is not well-suited to implementing business logic!
- deleted 3y ago
  [deleted]
angra_mainyu 3y ago
On the contrary, I've found striving to make zero values meaningful makes designs far more succinct and clearer.

bsdpufferfish 3y ago

C++ constructors actually make the guarantee, but it comes with other pains

masklinn 3y ago
Lots of languages handle it just fine and don’t need the mess of C++ ctors. GP is pointing out that go specifically makes it an issue.
- bsdpufferfish 3y ago
  What language do you have in mind?
  - masklinn 3y ago
    Any language which supports private state: smalltalk, haskell, ada, rust, …