Live data from Hacker News

Generics aren't ready for Go

drewdevault.com

221–230 of 238 posts

Re: Generics aren't ready for Go

#221
post #211

Earlier quoted context omitted.

On the contrary, they are feature rich with capabilities that Go still hasn't found a proper way to support, like something comparable to Swing. Naturally turning into name calling is easier when running out of arguments.

You say this as if swing is a plus for java. It looks alien everywhere. Is it used by eclipse by the way?

It is used by JetBrains products, a fairly small company selling developer tools, you might have heard you them.

They happen to sell an IDE for Go.

Re: Generics aren't ready for Go

#222
post #212

Earlier quoted context omitted.

Everyone here would like some numbers, after all you must have a solid source to make such statement.

Care to provide the name of VC backed companies built around them? I do not know of any. Akka has some java shops using them. But I wouldn't call it a database. Ravendb...

You got me lost there, first you say nobody uses them, then you mention some.

Better get those numbers straight.

Re: Generics aren't ready for Go

#223

Earlier quoted context omitted.

On a phone, so sorry in advance for terse response. Agreed that the language would be simpler in some sense with generics; I don’t think it would be more readable due to aforementioned increase in expressivity. Interesting point about first class functions, and while I largely agree, the variation in Go code is still small and constrained which is my point. :)

You don't find the existing Go code using the built-in generics (arrays, dictionaries, channels) readable? You find that its expressiveness makes it too complex?

Sorry if I haven’t articulated my position very well: the property I care about is consistency of code throughout the ecosystem which exist due to the constraints such as the absense of user-defined generics. Hopefully that’s a little clearer, and makes it obvious why “a few built in genetics” is fundamentally different than user-defines generics.

Re: Generics aren't ready for Go

#224

Earlier quoted context omitted.

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?

>about the software that runs the world Software that runs the world utilizes parametric polymorphysm in C++, Java, Ada, D, Swift, OCaml, Haskell etc, hell, even C [1]. I also tend to consider some mission critical Ada/C++ software a real engineering, not some webshit. [1] https://github.com/jiixyj/libebur128/blob/master/ebur128/ebu...

And [1] actually makes a point that we don't need language support for every imaginable use case (maybe not even Generics). It's not a problem to work around a "missing" feature, sometimes.

Re: Generics aren't ready for Go

#225

Earlier quoted context omitted.

He is one of the Unix figures at Bell Labs (although a late-joiner, being younger), he designed UTF-8 with Ken Thompson, and worked on the Plan 9 project, before joining Google. That's probably more than most of us will ever achieve.

>He is one of the Unix figures at Bell Labs (although a late-joiner, being younger), he designed UTF-8 with Ken Thompson, and worked on the Plan 9 project So his only "serious engineering project" is a toyish academic operating system? No mission-critical software, no application software with millions of installations (except Go compilers).

You're being disrespectful.

> No mission-critical software, no application software with millions of installations (except Go compilers).

Yes. NOOO software with millions of installations. Except Go compilers. Which doesn't count? (And I don't even know, there might be more).

He is an accomplished engineer. UTF-8 is one of the best designs I know. Unix is still around, despite its shortcomings. He's written books and been around some of the gods of software and OS engineering. Regarding Plan 9, I'm not positive that it is a toy operating system. I've never used it. It tried to improve on Unix and might (or might not) have achieved that in many ways. It's named as an inspiration by Linus Torvalds.

What do you have to show?

Re: Generics aren't ready for Go

#226
post #191

Earlier quoted context omitted.

golang authors seem to only have experience with C++ as they keep talking about C++'s deficiencies, as if it's the only other language that exists when it comes to generics.

Sure. Seems like they have the same experience than me then.

The point is that they are not familiar with the solutions other languages have. So it's either the C++ way or don't look elsewhere.

Re: Generics aren't ready for Go

#227

Earlier quoted context omitted.

>He is one of the Unix figures at Bell Labs (although a late-joiner, being younger), he designed UTF-8 with Ken Thompson, and worked on the Plan 9 project So his only "serious engineering project" is a toyish academic operating system? No mission-critical software, no application software with millions of installations (except Go compilers).

You're being disrespectful. > No mission-critical software, no application software with millions of installations (except Go compilers). Yes. NOOO software with millions of installations. Except Go compilers. Which doesn't count? (And I don't even know, there might be more). He is an accomplished engineer. UTF-8 is one of the best designs I know. Unix is still around, despite its shortcomings. He's written books and…

>Yes. NOOO software with millions of installations. Except Go compilers.

So the grand experience of Rob being the justification of Go's design is the Go compiler itself? Besides, Go compiler is ridiculous if you compare it to things like llvm, gcc, ghc, CompCert.

>UTF-8 is one of the best designs I know.

Not a software.

>Unix is still around, despite its shortcomings

1) he didn't create Unix and 2) modern unix has pretty nothing in common with the bell labs unix.

>I've never used it.

So let's draw the conclusion: the enormous engineering background of Pike -- which tends to be a justification of Go's "suitable for real world apps not academic masturbation" design -- consists of writing a simplistic academic operating system nobody used (you included) and UTF-8 which is not even a software?

That's big, but I'll stick to Ada or C++, languages with real industrial background.

Re: Generics aren't ready for Go

#228

Earlier quoted context omitted.

No the two conflicting statements are. 1. Go doesn't have generics because the authors didn't have strong grasp of type theory. 2. Go doesn't have generics, not from a lack of knowledge, but because the authors' real world software engineering experience had shown to them it wasn't important.

>Go doesn't have generics, not from a lack of knowledge, but because the authors' real world software engineering experience had shown to them it wasn't important. What do you mean by "real world software engineering experience", Acme or Plan9? These are silly academic projects with tens of installations at best.

If your only metric is installations I'd say go is doing quite well at least.

Re: Generics aren't ready for Go

#229
post #214
post #205

Earlier quoted context omitted.

Can Quasar fibers be efficiently used with other (popular) Java libraries that build on top of the standard libraries? If not, I don't consider that to be good developer experience. That is more of a mistake that cannot be rectified. Async IO is also fine. The question is, what is your current ecosystem built on top of. AFAIK the answer with Java is definitely not async IO or fibers. Yes, structural interfaces in Go…

From Loom talks it appears that fibers will also be able to consume Runnable and Completable.

Loom is still WIP. Remains to be seen how easy / performant it is going to be adopt in practice with the existing ecosystem.

Re: Generics aren't ready for Go

#230

Earlier quoted context omitted.

No the two conflicting statements are. 1. Go doesn't have generics because the authors didn't have strong grasp of type theory. 2. Go doesn't have generics, not from a lack of knowledge, but because the authors' real world software engineering experience had shown to them it wasn't important.

>Go doesn't have generics, not from a lack of knowledge, but because the authors' real world software engineering experience had shown to them it wasn't important. What do you mean by "real world software engineering experience", Acme or Plan9? These are silly academic projects with tens of installations at best.

Ken Thompson was one of the original authors of Unix
Post reply on HN