
Go Experience Report: Generics in Kubernetes - Tehnix
https://medium.com/@arschles/go-experience-report-generics-in-kubernetes-25da87430301
======
iscoelho
Not very accurate. Top post explains it well:
[https://medium.com/@Merovius/aiui-runtime-
object-7504a600dd0...](https://medium.com/@Merovius/aiui-runtime-
object-7504a600dd09)

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
> 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
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.

------
gtirloni
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
With either reflection or go:generate.

Just need to search for them on Github.

------
camus2
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.

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

