5 ms·

In this case, the memory pointer for Vec3 would not be null? It will be a defined memory address which points to 3 zeros. I think it's a difference of objects a

In this case, the memory pointer for Vec3 would not be null? It will be a defined memory address which points to 3 zeros. I think it's a difference of objects and primitive data types.

simiones 5y ago
The discussion was that in Go, given the current lack of generics, you have two options to have an optional parameter: 1. Take a *Vec3, using nil as the "optional is missing" value. 2. Take a Vec3, but consider some value as "invalid", often the 0-value as possible. 1 invokes exactly the issues in Hoare's essay. 2 doesn't work for all types, as some types don't have any bit pattern that are not useful, this is what I was trying to point out.
- SQueeeeeL 5y ago
  I can't think of any situations where (1) would be insufficient, but I'm probably wrong. But I agree that setting an isValid bit for every object is overkill.
  - saghm 5y ago
    I think the point is that it would be nice to be able to express the idea of a value not being present without having to risk accidentally trying to dereference a nil pointer. That's what Option brings to the table, although arguably Go could just provide an implementation of that like they do for slices and maps without actually having to introduce full generics to the language.
  - chakkepolja 5y ago
    apart from what sibling comment mentions, declaring as pointer will often result in a heap allocation in Go.
  - simiones 5y ago
    Well, in the link that you shared, Tony Hoare explains in quite some detail why having support for null pointers is not great. Additionally, a *Vec3 is more than `Vec3` or `null`. For example, the following code will behave very differently based on whether optionalVec is Vec3 or *Vec3. optionalVec := Vec3{0, 0, 0} foo(optionalVec) fmt.Printf("theVec: %+v", optionalVec) // would print {0, 0, 0} with an Optional[Vec3] type // will actually print {2, 0, 0} with *Vec3 ... func foo(optionalVec *Vec3) { if optionalVec != nil { optionalVec.x += 2 //we use a different origin } [...] }
- BenFrantzDale 5y ago
  Why in almost 2022 do people put up with a language lacking generics?
  - simiones 5y ago
    I don't know about others, but we chose to use Go despite the problems with the language itself because we liked several properties of the Go runtime. Particularly, the fact that Go is garbage collected (so it's memory safe), but has much lower memory and start time overhead than even the latest versions of Java or .NET or even Haskell; and the ecosystem is much greater than something like OCaml. This low overhead is very useful for a microservices-based application. For my team, we would have loved to have something like C# (or even Java), with generics, exceptions, lambdas, LINQ/Streams etc., but with Go's low overhead and large ecosystem. Go the language was a major negative point, just not bad enough to outweigh the advantages of the runtime.

In this case, the memory pointer for Vec3 would not be null? It will be a defined memory address which points to 3 zeros. I think it's a difference of objects and primitive data types.

simiones 5y ago

The discussion was that in Go, given the current lack of generics, you have two options to have an optional parameter: 1. Take a *Vec3, using nil as the "optional is missing" value. 2. Take a Vec3, but consider some value as "invalid", often the 0-value as possible. 1 invokes exactly the issues in Hoare's essay. 2 doesn't work for all types, as some types don't have any bit pattern that are not useful, this is what I was trying to point out.

SQueeeeeL 5y ago
I can't think of any situations where (1) would be insufficient, but I'm probably wrong. But I agree that setting an isValid bit for every object is overkill.
- saghm 5y ago
  I think the point is that it would be nice to be able to express the idea of a value not being present without having to risk accidentally trying to dereference a nil pointer. That's what Option brings to the table, although arguably Go could just provide an implementation of that like they do for slices and maps without actually having to introduce full generics to the language.
- chakkepolja 5y ago
  apart from what sibling comment mentions, declaring as pointer will often result in a heap allocation in Go.
- simiones 5y ago
  Well, in the link that you shared, Tony Hoare explains in quite some detail why having support for null pointers is not great. Additionally, a *Vec3 is more than `Vec3` or `null`. For example, the following code will behave very differently based on whether optionalVec is Vec3 or *Vec3. optionalVec := Vec3{0, 0, 0} foo(optionalVec) fmt.Printf("theVec: %+v", optionalVec) // would print {0, 0, 0} with an Optional[Vec3] type // will actually print {2, 0, 0} with *Vec3 ... func foo(optionalVec *Vec3) { if optionalVec != nil { optionalVec.x += 2 //we use a different origin } [...] }
BenFrantzDale 5y ago
Why in almost 2022 do people put up with a language lacking generics?
- simiones 5y ago
  I don't know about others, but we chose to use Go despite the problems with the language itself because we liked several properties of the Go runtime. Particularly, the fact that Go is garbage collected (so it's memory safe), but has much lower memory and start time overhead than even the latest versions of Java or .NET or even Haskell; and the ecosystem is much greater than something like OCaml. This low overhead is very useful for a microservices-based application. For my team, we would have loved to have something like C# (or even Java), with generics, exceptions, lambdas, LINQ/Streams etc., but with Go's low overhead and large ecosystem. Go the language was a major negative point, just not bad enough to outweigh the advantages of the runtime.