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