131–140 of 238 posts
This article highlights very well why designing a programming language without generics is a mistake. Adding it after the fact is not trivial, especially if you have high standards wrt simplicity and non-redundancy.
You're implying that there is a better design that has generics and caters to the same programmer folks. But you don't show what that design is. The OP didn't imply there was one.
Earlier quoted context omitted.
Yeah, you have to either give up type safety (Go's "void pointers" retain runtime type information, so it's closer to a Python object than a void pointer) or you have to write each implementation. In the case of linked list, that's not a big deal: `type List struct { Next *List; Value int}` and Go comes with a handful of useful generic types (slices, arrays, maps, channels, etc). It also has interfaces and closures,…
> "You can't ship software in a language without generics!" Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety. interface{} does feel like a temporary and clunky solution for people used…
As a C programmer (which doesn't have generics either) I can't recall the last time where that additional safety was being missed. Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvious. Plus, Go even has runtime type checking to catch this sort of problem with 100% probability at runtime (I think - I'm not a Go programmer).
So I don't think there's a valid problem here.
Maybe the more serious problem is that people want to be able to quickly say "I want a Fibonacci-Tree for types K and V"?
Earlier quoted context omitted.
Yeah, you have to either give up type safety (Go's "void pointers" retain runtime type information, so it's closer to a Python object than a void pointer) or you have to write each implementation. In the case of linked list, that's not a big deal: `type List struct { Next *List; Value int}` and Go comes with a handful of useful generic types (slices, arrays, maps, channels, etc). It also has interfaces and closures,…
> "You can't ship software in a language without generics!" Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety. interface{} does feel like a temporary and clunky solution for people used…
For the rest... Yes, it is very ugly. But the standard generic does not fit very well with go type system, so....
Luckily, go is very simple. Even ugly bit are not hard to understand.
It’s weird seeing all this post-hoc rationalising when there is a perfect explanation for why go doesn’t have generics: Rob Pike didn’t bother to look into any of the research into type theory and programming language technology. Hence his understanding of types were restricted to Java and C++ and similar (whose type systems are an abomination), and he could not separate subclass polymorhism with inhertance from para…
Or maybe the academics and type theorists are philistines about the software that runs the world and their arguments have mostly been about hand-picked toy examples? Maybe Mr. Pike actually has some well-deserved reputation when it comes to real-world software and engineering projects that are about handling large scale data in real time?
1. Rob Pike doesn't have a strong grasp of type theory.
2. Rob Pike is an accomplished programmer.
1. That shape over there is a square.
2. That shape over there is blue.
Earlier quoted context omitted.
With thousands of institutional users? Implementing distributed databases?
As much as old time mainframes and Novell NetWare based applications could have.
Earlier quoted context omitted.
> "You can't ship software in a language without generics!" Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety. interface{} does feel like a temporary and clunky solution for people used…
> Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... As a C programmer (which doesn't have generics either) I can't recall the last time where that additional safety was being missed. Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvi…
Except when it isn't. Except when it crashes in production. I believe this is the kind of situation people are trying to avoid with type safety...
> Maybe the more serious problem is that people want to be able to quickly say "I want a Fibonacci-Tree for types K and V"?
That's uncalled for, isn't it? There's a lot of non-toy problems solved elegantly and pragmatically using generics. I personally enjoy how Entity Framework uses it.
Earlier quoted context omitted.
The parent should have said, "Go is regularly used to ship..." instead of "Go can be used...". The fact that Go backs all sorts of complex, interesting software testifies that it has solved the basics extrememly well, and if you're going to argue for a definition of "the basics" which doesn't respect shipping software then your argument is self-defeating. "Generics" isn't an end unto itself, after all.
> The parent should have said, "Go is regularly used to ship..." So does C, C++, Java, etc. That statement is meaningless. It just means that with enough contortion, you can write some code in golang that works. But that doesn't mean mean there aren't better, safer ways to write code. As others said, you can write large systems in C, but we still see the fallouts of using a very limited and unsafe language. And the f…
Indeed it's as capable as those languages in this domain. The productivity is higher though, thanks to the stdlib.
Earlier quoted context omitted.
> "You can't ship software in a language without generics!" Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety. interface{} does feel like a temporary and clunky solution for people used…
Go use a duck typing system, many of the generic use case can be solved using interface elegantly.. For the rest... Yes, it is very ugly. But the standard generic does not fit very well with go type system, so.... Luckily, go is very simple. Even ugly bit are not hard to understand.
Why not? Generics in Arrays/Maps/Slices fit perfectly in the language, and don't feel weird at all in Go.
Earlier quoted context omitted.
Macros are another can of worms. Even if they're AST-aware like in Rust, you can do very complicated stuff with them and they are very hard to read/write/debug. This would kill the advantage that it's very hard to write obscure Go code.
>> his would kill the advantage that it's very hard to write obscure Go code. But it's very easy to spread that Go code into tens of Kloc. The amount of error handling and if constructs make me feel as if I am readying assembly: predictable AF, but it doesn't help because the volume of the code is huge.
Design choice. You can't have both.
Earlier quoted context omitted.
> I am applying that term to Go developers against generics no matter what. They are actively looking for something that doesn't suck. Aren't they? > C does provide minimal support for generics since C11, with improvments planned for later standard revisions, as anyone that works predominantly in C should be aware. Not sure what was your intention behind that statement. But of course I'm aware of C11 Generics. And th…
> They are actively looking for something that doesn't suck. Aren't they? It looks more of "we are working on it excuse" to keep people at bay. Rob Pike has done a presentation last year where he stated that he doesn't have anything to do with it and is very sceptical of it being ever added. So WIP is kind of euphemism. > Not sure what was your intention behind that statement. That even languages born before generics…
Well that was the initial basic design frame: A systems programming language that removes some of the headaches of writing distributed systems software with the use of a GC and Channels/CSP.
It was intended from the start to have more features and tradeoffs than C has, and it even backed up pretty quickly from trying to be a competitor in the (not-distributed) systems programming space, didn't it?
> That even languages born before generics are willing to move forward.
C11 Generics are a pretty limited feature, basically a central switch on types instead of values. They are not a big deal. And maybe Go decided against them because Go has RTTI. In any case, C11 Generics are decidedly different from what many people expect from a Generics in Go.
> As for complaining, projects like Docker and K8s ensure that those of us that rather not use Go, have to deal with it in some form anyway.
Dude... 1) They are not Go. 2) If you don't like them don't deal with them. 3) Don't make an elephant from a mosquito. 4) Show us some of your beautiful systems software written in perfect OOP style in languages from 1975 already! We need real world proof that there is a supreme super-typesafe OOP way with functional bells that solves all of our problems!