3 ms·

Go Experience Report: Generics in Kubernetes

18 points by Tehnix 9y ago

moocowtruck 9y ago
I'm told generics don't help anything and it's better to just write it all out...on paper first
gtirloni 9y ago
Are there other examples of this type registry solution outside Kubernetes? I wonder how other Go projects are solving this situation and/or if it's too k8s-specific.
- pjmlp 9y ago
  With either reflection or go:generate. Just need to search for them on Github.
iscoelho 9y ago
Not very accurate. Top post explains it well: https://medium.com/@Merovius/aiui-runtime-object-7504a600dd09 https://medium.com/@Merovius/aiui-runtime-object-7504a600dd0... tl;dr: runtime.Object is a type used for serializing messages in RPC calls. Deserializing the type requires a type lookup through a registry. Generics would not solve this issue, so the OP's entire point really doesn't make sense.
- camus2 9y ago
  > tl;dr: runtime.Object is a type used for serializing messages in RPC calls. Deserializing the type requires a type lookup through a registry. Generics would not solve this issue, so the OP's entire point really doesn't make sense. And generics would allow compile-time safe checks for serialization. Easy rebutal to merovius post. I don't see how more type safety is a bad thing.
  - iscoelho 9y ago
    It wouldn't though. If you've designed something like this before, you'd know a type assertion is required no matter what just because of how serialization works. If you have some example code that can convince it would be useful though, I'll happily agree, but the only place I see where it can be useful (perhaps a callback?) can already be solved by "reflect". So I don't see any benefit whatsoever.
camus2 9y ago
So it's Russ Cox I believe who asked people to submit "experience reports" to understand the use case of generics, because apparently he doesn't. The use case for generics is known already, there is more than 30 years of literature about the issue they solve. One can always tell developers :"well you don't need generics for that" and that would be true just like no problem cannot be solved without the use of functions. Yet functions are useful nobody can deny it. It's the same with generics they are useful when you need them. So why ask people to submit "experience reports" when one can easily say "You don't need generics for that"? I doesn't sound that useful to ask people to waste their time writing "experience reports". Either a language designer understands the value of generics, or they don't. I like the way ada deals with generics: they are just incomplete types one need to complete before use. with Ada.Containers.Vectors; procedure jdoodle is -- declare a typed package from a package with generic types package int_vectors is new Ada.Containers.Vectors (Index_Type => Natural, Element_Type => Integer); package char_vectors is new Ada.Containers.Vectors (Index_Type => Natural, Element_Type => Character); int_vector_1 : int_vectors.Vector; char_vector_1 : char_vectors.Vector; begin int_vector_1.Append (20); int_vector_1.Append (34); int_vector_1.Append (94); char_vector_1.Append ('a'); char_vector_1.Append ('b'); char_vector_1.Append ('c'); end jdoodle; https://www.jdoodle.com/a/i6z https://www.jdoodle.com/a/i6z No use of templates, no code generation with all its bureaucracy, no type erasure, it's completely type safe both at compile tima and runtime, no use of <<>> everywhere that hurts readability and it solves 99% of the use cases where generics would be a fit. Now go might not be able to implement something like that while keeping backward compatibility , my point is, if the question is "how", then don't make people write experience reports when the use cases have been known for decades, the how exists in many languages that are neither C++ or Java. In fact, a lot of issues with Go were solved decades ago in Ada, especially when it comes to concurrency. Ada had goroutines because goroutines were a thing including the "select" statement.

18 points by Tehnix 9y ago

I'm told generics don't help anything and it's better to just write it all out...on paper first

Are there other examples of this type registry solution outside Kubernetes? I wonder how other Go projects are solving this situation and/or if it's too k8s-specific.

pjmlp 9y ago
With either reflection or go:generate. Just need to search for them on Github.

iscoelho 9y ago

Not very accurate. Top post explains it well: https://medium.com/@Merovius/aiui-runtime-object-7504a600dd09 https://medium.com/@Merovius/aiui-runtime-object-7504a600dd0... tl;dr: runtime.Object is a type used for serializing messages in RPC calls. Deserializing the type requires a type lookup through a registry. Generics would not solve this issue, so the OP's entire point really doesn't make sense.

camus2 9y ago
> tl;dr: runtime.Object is a type used for serializing messages in RPC calls. Deserializing the type requires a type lookup through a registry. Generics would not solve this issue, so the OP's entire point really doesn't make sense. And generics would allow compile-time safe checks for serialization. Easy rebutal to merovius post. I don't see how more type safety is a bad thing.
- iscoelho 9y ago
  It wouldn't though. If you've designed something like this before, you'd know a type assertion is required no matter what just because of how serialization works. If you have some example code that can convince it would be useful though, I'll happily agree, but the only place I see where it can be useful (perhaps a callback?) can already be solved by "reflect". So I don't see any benefit whatsoever.

camus2 9y ago

So it's Russ Cox I believe who asked people to submit "experience reports" to understand the use case of generics, because apparently he doesn't. The use case for generics is known already, there is more than 30 years of literature about the issue they solve. One can always tell developers :"well you don't need generics for that" and that would be true just like no problem cannot be solved without the use of functions. Yet functions are useful nobody can deny it. It's the same with generics they are useful when you need them. So why ask people to submit "experience reports" when one can easily say "You don't need generics for that"? I doesn't sound that useful to ask people to waste their time writing "experience reports". Either a language designer understands the value of generics, or they don't. I like the way ada deals with generics: they are just incomplete types one need to complete before use. with Ada.Containers.Vectors; procedure jdoodle is -- declare a typed package from a package with generic types package int_vectors is new Ada.Containers.Vectors (Index_Type => Natural, Element_Type => Integer); package char_vectors is new Ada.Containers.Vectors (Index_Type => Natural, Element_Type => Character); int_vector_1 : int_vectors.Vector; char_vector_1 : char_vectors.Vector; begin int_vector_1.Append (20); int_vector_1.Append (34); int_vector_1.Append (94); char_vector_1.Append ('a'); char_vector_1.Append ('b'); char_vector_1.Append ('c'); end jdoodle; https://www.jdoodle.com/a/i6z https://www.jdoodle.com/a/i6z No use of templates, no code generation with all its bureaucracy, no type erasure, it's completely type safe both at compile tima and runtime, no use of <<>> everywhere that hurts readability and it solves 99% of the use cases where generics would be a fit. Now go might not be able to implement something like that while keeping backward compatibility , my point is, if the question is "how", then don't make people write experience reports when the use cases have been known for decades, the how exists in many languages that are neither C++ or Java. In fact, a lot of issues with Go were solved decades ago in Ada, especially when it comes to concurrency. Ada had goroutines because goroutines were a thing including the "select" statement.