Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Generics aren't ready for Go

drewdevault.com

Post reply on HN
Print view View original

181–190 of 238 posts

Re: Generics aren't ready for Go

#181

Post by latronic_notron »

spion wrote: post #176
latronic_notron wrote: post #168

Earlier quoted context omitted.

They aren't abused in C#, Java, Haskell, OCaml and other languages. Honestly, picking C++ as an example of traditional generic usage is a bit disingenuous.

I would suggest a Go programmer give ReasonML an honest try (as an example language where "generics" are done right), but the getting started / documentation situation is still not at Golang level so thats a bit annoying. Maybe F# would be a better choice. .NET Core and its tooling are pretty well done. C# and NET Core would be another nice alternative.

Agreed. I find C# and F# surprisingly refreshing. ReasonML is a bit unfinished, but it's a sign of great things to come.

Re: Generics aren't ready for Go

#182

Post by llimllib »

bunderbunder wrote: post #95
emersion wrote: post #93

Earlier quoted context omitted.

I'd say either resort to code generation or pick another language that fits better your use-case.

Yeah, sorry if I wasn't being clear. That's pretty much the line I was thinking along. It's perfectly fine for Go's answer to be, "Go doesn't have generics because generics aren't needed to solve the kinds of problems Go is designed for solving, and we are not trying to be a kitchen sink language here. If generics are something you need, please pick a language that's designed to solve the problems that you're trying…

> I think Go should be comfortable not being suitable for writing certain classes of programs. I don’t think programming languages should compete with each other in an attempt to become the perfect solution to every problem. This is impossible, and attempts will just create a messy kitchen sink that solves every problem poorly.

is a quote from the article, and seems to say exactly what you're saying?

Re: Generics aren't ready for Go

#183

Post by latronic_notron »

weberc2 wrote: post #178
latronic_notron wrote: post #170

Earlier quoted context omitted.

> they also remove the rails that keeps Go code pretty consistent But why? There's nothing in generics that would make Go non-consistent. In fact, there's already generics in Go in Array/Map/Slice, and they're not inconsistent with the rest of the language at all. > For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative Why would generics break that? Funcional programming and type-sa…

> It sounds to me that most people advocating generics in Go are having a pragmatic/utilitarian approach, while people against it are opposing it from a purely ideological standpoint not grounded in either theory or pragmatism. And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :) Even if I were making a positive assertion like "generics costs more than it ga…

> And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :)

That's fair! I'm really sorry I typed that, it was completely uncalled for and I wasn't referring to you specifically!

> Because "generics" as a feature suffices to support multi-paradigm programming.

I don't really agree with that. Despite being widely used in functional languages, they aren't really a "functional" thing, as much as static typing is.

In fact, I'd argue that Go already has a feature that is much more important and representative of funcional programming than anything else: higher order functions. [1] With higher order functions (and recursion!) you can implement pretty much anything functional.

Generics don't really allow for much more than something like interface{} can already give. The problem is that interface{} comes with both runtime performance and type-safety penalties. Generics could fix that and help programmers arrive at better/safer practices, IMO.

My point is: with generics the language could be much simpler and we'd have to rely less on (IMO) complicated/unsafe features like Reflection and interface{}.

[1] http://aquaraga.github.io/functional-programming/golang/2016...

Re: Generics aren't ready for Go

#184

Post by pjmlp »

grumpydba wrote: post #135
pjmlp wrote: post #122

Earlier quoted context omitted.

As much as old time mainframes and Novell NetWare based applications could have.

Then it was the proper choice, like go is today. I haven't heard about a lot of distributed databases in assembly.

Most successful distributed databases taking load at scale with powerful OLAP engines are written in C++, not Go.

Re: Generics aren't ready for Go

#185

Post by pjmlp »

jstimpfle wrote: post #140
pjmlp wrote: post #124

Earlier quoted context omitted.

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

> If we reduce Go lack of features to stuff that C doesn't provide, maybe bounds checking, modules and GC aren't required as well. 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…

C++ comes to mind.

Also some would say that Go is actually from 1968.

http://cowlark.com/2009-11-15-go/

Re: Generics aren't ready for Go

#186

Post by grumpydba »

pjmlp wrote: post #184
grumpydba wrote: post #135

Earlier quoted context omitted.

Then it was the proper choice, like go is today. I haven't heard about a lot of distributed databases in assembly.

Most successful distributed databases taking load at scale with powerful OLAP engines are written in C++, not Go.

Indeed. However go does make some inroads there for oltp workloads or simple kv like etcd.

Re: Generics aren't ready for Go

#187

Post by AnimalMuppet »

cannabis_sam wrote: post #103

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…

I read what you linked. No, he is not "openly contemptuous of the academics who do research in his field, while wildly mistepresenting their work" (at least not in the linked article). It would be more fair to say that he doesn't think that, in the real world, types will carry enough weight to deserve the emphasis that they are given.

Re: Generics aren't ready for Go

#188

Post by pjmlp »

grumpydba wrote: post #186
pjmlp wrote: post #184

Earlier quoted context omitted.

Most successful distributed databases taking load at scale with powerful OLAP engines are written in C++, not Go.

Indeed. However go does make some inroads there for oltp workloads or simple kv like etcd.

Not with anything comparable to ScyllaDB, RavenDB, Akka, Akka.NET, Orleans.

Re: Generics aren't ready for Go

#189

Post by pjmlp »

grumpydba wrote: post #137
apta wrote: post #126

Earlier quoted context omitted.

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

> 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. Indeed it's as capable as those languages in this domain. The productivity is higher though, thanks to the stdlib.

Go's stdlib is a tiny portion of what Java and .NET offer.

Re: Generics aren't ready for Go

#190

Post by apta »

spion wrote: post #141
apta wrote: post #127

Earlier quoted context omitted.

> Go biggest advantage isn't the language, its the decent documentation and standard library design Which, ironically, Java is just superior in every way when it comes to documentation of the standard library. Large open source Java projects are well designed and very well documented, unlike golang projects.

Java is not really superior in standard library design. There is too much architecture astronautics going on. Standard interfaces are too complicated. Nominal interfaces kinda suck. Java also lacks green threads. There is baggage in the design of many libraries related to previous lack of lambdas that is now annoying. The Go documentation as well as standard interfaces are tastefully and minimally done (for an impera…

> Java also lacks green threads

Green threads are not the be-all-end-all solution for concurrency. They have their place, but so do event based async io.

That being said, Java is getting green threads in the form of Fibers.

> Compare https://golang.org/pkg/io/#Reader to this mess https://docs.oracle.com/javase/7/docs/api/java/io/Reader.htm....

Obviously Java's Reader interface does more work, and has a `close()` method, which golang lacks. Golang is forced to go with this way to write interfaces due to how they are implemented (sacrificing usability to get nominal typing, which is a very questionable design decision). Languages like Kotlin, Rust, Scala among others have superior solutions.

Post reply on HN