7 ms·

So your problem is the default/zero values of properties? In Go the convention is kind of to have a constructor pattern with a NewStruct(...) *Struct method th

So your problem is the default/zero values of properties? In Go the convention is kind of to have a constructor pattern with a NewStruct(...) *Struct method that initializes all properties. Also can't you build your own validator for that with the reflect package in the Add() method of your UI graph to prevent this sorta thing?

TheDong 1mo ago
The Go std library, as well as practically all go library code, is full of things that don't fully initialize all properties and things that nil-pointer-panic if you hold them wrong, so no, no matter what you do you have to deal with this wart of Go. The go type-system is simply incapable of enforcing nil-safety without being no longer able to compile the go stdlib nor most code in the wild, so it's a quite valid criticism of the go type-system and language, and your comment doesn't hit on a valid solution.
- deleted 1mo ago
  [deleted]
- 0x696C6961 1mo ago
  You're painting a picture where people writing Go are constantly drowning in nil pointer panics. This is not reality. You hit them occasionally and they're trivial to understand and fix.
  - thayne 1mo ago
    nil pointer panics aren't nearly as bad as values getting zero initialized, then used in places that assume they were initialized, and getting subtle bugs because the state is inconsistent.
    - deleted 1mo ago
      [deleted]
    - win311fwg 1mo ago
      I always wonder how those types of mistakes make it through your test suite. You'd need some kind of non-deterministic path to reaching the unintended zero value — but it would need to be a non-deterministic path that you wouldn't make deterministic during testing. I think we'd be curious to see what that code looks like.
    - 0x696C6961 1mo ago
      Again, it happens, but the impact is wildly overstated. I get so confused with people saying "once it compiles, it probably works" (regardless of language). The problems I struggle with need invariants that can't be expressed by any modern language features.
thayne 1mo ago
> the convention is kind of to have a constructor pattern with a NewStruct(...) *Struct method that initializes all properties But that doesn't stop you from declaring a var s Struct, and never initializing it, or making a NewStruct {}. > can't you build your own validator for that with the reflect package in the Add() method of your UI graph Besides the fact that that would almost certainly significantly hurt performance, how would you be able to differentiate between unitialized data and data that was intentionally set to the zero value?
- olmo23 1mo ago
  > But that doesn't stop you from declaring a var s Struct, and never initializing it, or making a NewStruct {}. Static analysis tools can catch this, no?
  - majewsky 1mo ago
    Static analysis does not help if the type comes from a library and is _meant_ to be initialized using a literal. And then upstream adds new fields where the zero value is different from the previous behavior, causing users to silently drift away from the intended behavior. I had this happen to me with a type from std, and had to add a specific test to guard against it with future std upgrades: https://github.com/sapcc/go-bits/pull/309/changes#diff-f5721003d3d035743b2ce1e71dd06f777cd568229ee191e46d5eac5f52532732R35-R52 https://github.com/sapcc/go-bits/pull/309/changes#diff-f5721...
    - duckbrain 1mo ago
      That's a dependency making a breaking change, right?

TheDong 1mo ago

The Go std library, as well as practically all go library code, is full of things that don't fully initialize all properties and things that nil-pointer-panic if you hold them wrong, so no, no matter what you do you have to deal with this wart of Go. The go type-system is simply incapable of enforcing nil-safety without being no longer able to compile the go stdlib nor most code in the wild, so it's a quite valid criticism of the go type-system and language, and your comment doesn't hit on a valid solution.

deleted 1mo ago
[deleted]
0x696C6961 1mo ago
You're painting a picture where people writing Go are constantly drowning in nil pointer panics. This is not reality. You hit them occasionally and they're trivial to understand and fix.
- thayne 1mo ago
  nil pointer panics aren't nearly as bad as values getting zero initialized, then used in places that assume they were initialized, and getting subtle bugs because the state is inconsistent.
  - deleted 1mo ago
    [deleted]
  - win311fwg 1mo ago
    I always wonder how those types of mistakes make it through your test suite. You'd need some kind of non-deterministic path to reaching the unintended zero value — but it would need to be a non-deterministic path that you wouldn't make deterministic during testing. I think we'd be curious to see what that code looks like.
  - 0x696C6961 1mo ago
    Again, it happens, but the impact is wildly overstated. I get so confused with people saying "once it compiles, it probably works" (regardless of language). The problems I struggle with need invariants that can't be expressed by any modern language features.

thayne 1mo ago

> the convention is kind of to have a constructor pattern with a NewStruct(...) *Struct method that initializes all properties But that doesn't stop you from declaring a var s Struct, and never initializing it, or making a NewStruct {}. > can't you build your own validator for that with the reflect package in the Add() method of your UI graph Besides the fact that that would almost certainly significantly hurt performance, how would you be able to differentiate between unitialized data and data that was intentionally set to the zero value?

olmo23 1mo ago
> But that doesn't stop you from declaring a var s Struct, and never initializing it, or making a NewStruct {}. Static analysis tools can catch this, no?
- majewsky 1mo ago
  Static analysis does not help if the type comes from a library and is _meant_ to be initialized using a literal. And then upstream adds new fields where the zero value is different from the previous behavior, causing users to silently drift away from the intended behavior. I had this happen to me with a type from std, and had to add a specific test to guard against it with future std upgrades: https://github.com/sapcc/go-bits/pull/309/changes#diff-f5721003d3d035743b2ce1e71dd06f777cd568229ee191e46d5eac5f52532732R35-R52 https://github.com/sapcc/go-bits/pull/309/changes#diff-f5721...
  - duckbrain 1mo ago
    That's a dependency making a breaking change, right?