Hacker News Reader

Comment by jlouis | Hacker News Reader

I don't think this is so ironic after all.

Featherweight Java is an idealized language, small enough for doing experiments. These experiments often involve the necessity of a formal proof. But being a small language, still capturing the crux of the full language, greatly simplifies the problem space.

Featherweight Go serves the same purpose: find the core. Give the core generics. Then you have a good chance at implementing generics for the full language.

Most languages which end up with type parametrization do so when the language is small and somewhat pliable. Neither Java nor Go did, even though both languages had plenty of prior work in the area. Hence, you have to "reconstruct" a world in which there is such a small language such that your experiments run fast.

View on HN

I think this just highlights how massive a mistake the Go developers made not including generics from Day 1.

It was a mistake in Java that they corrected with a lot of pain. It is a mistake in Go they are going to correct and most likely with a lot of pain. If they cannot do it seamlessly it may end up being a Python 2/3 platform split.

Those who fail to learn from history are doomed to repeat it.

I'd say the popularity of Go stems from the lack of generics.

And why on earth would you say that?

because it's a breeze to read Golang, due in parts to the lack of generics

Why does genetics make things that’s for read?

Functions can be given semantic names (I.e. have meaning); block statements cannot.

If writing a function that can take an array or slice of any type of data requires providing a generic argument (I.e. so you can specify that the function returns a slice of the same type of data as it was given), then you can name it "reverse" if it reverses the array, write it only once, and every timr you use it, you read "reverse" and know what it does.

For loops dont have those names, and so have to be rewritten every time you use them. As such, every time you see a for loop, you have to read and parse every statement to see what it is doing, and if it has any unexpected side effects or bugs introduced via copy-paste or what not.

Sorry I meant to say “why do genetics make things harder to read?”. Tbh I can’t tell if you’re responding to that or not

I did misread your post, but I will also say that generics are a double edged sword when it comes to readability. Needing to declare genetic types in function signatures can add irrelevant detail and heavy syntax. For example, look at the interpreter interface in this typescript file:

https://github.com/gcanti/io-ts/blob/master/src/Schema.ts#L2...

Granted, genetics don't need to be done that way, but it is among the more common and popular approaches. The type information is tangled up in the implementation, making focusing on either more challenging. Perhaps we need modes for syntax highlighting- one for types, one for implementation?

Lack of generics just means you have to copy and paste everything, like any time you want to reverse a slice.

    for i := len(a)/2 - 1; i >= 0; i-- {
        opp := len(a) - 1 - i
        a[i], a[opp] = a[opp], a[i]
    }

Actively hurts reading code as you have to credentialize in a code base to begin to be able to file entire code blocks into copy and pasted "idioms".

Without generics you have to hope the stdlib gets a blessed generic function like reverse() one day since you can't build one without rolling your own monomorphization code-gen or a goofball interface{}+cast hack.

For people who supposedly prefer the lack of generics (which seems more like cargo culting or Stockholm Syndrome), no problem. We can just add a config option to golint that prohibits you from using generics. That way you don't need to hold up the rest of us. win-win.

Weird. While you could copy that from the SliceTricks Go wiki page, you could also just use `sort.Sort(sort.Reverse())` which seems to address all of your complaints.

But it uses an interface, which means dynamic dispatch and an allocation most of the time (because IIRC it tends to break the escape analysis).

That's a recurrent issue with Go: you can either have ergonomic tools (with interface and reflection), or performant code (with no allocation) but you generally can't have both at the same time. Sure it's better than scripting language where you need to use another language when you need performance, but it's still kind of sad.

No, it doesn't. Go is popular because of the names and organization behind it, as well as the fact that it's useful for a lot of people despite the lack of generics.

Certainly, a lot of people are attracted to Rob Pike's rather idiosyncratic preferences, tastes, and nostalgia for the early days of Unix, which are on display in a lot of Go's design decisions, like the lack of generics. But lots of random people have preferences and nostalgia for all sorts of things; we usually only pay attention to such things when it's a person with a famous pedigree who has them.

at least to me, the lack of generics was a benefit. I'm probably not alone :)

The "names and organization behind it" thing is needlessly condescending (not to mention false), and the ability to get things done without generics basically restates David's point.

Was there something in this paper that you felt unfairly treated Rust, the language you represent on these threads? Because otherwise, I can't see what would motivate you to join this thread to snipe.

I'm with David, for what it's worth. Lack of generics has mostly helped me be productive in Go, and the extreme prevalence of generics in every Rust library I deal with has definitely slowed me down a bit. I'm looking forward to generics support in Go, but mostly for what I hope it does to message board threads.

I went out of my way to make the point without condescension. Evidently I didn't succeed, and I'm sorry for that!

Let me put it another way: Virtually all languages that have become popular recently have done so because of the backing of some large organization or another. There was a time when languages like Perl, Python, and PHP could arise out of basically nowhere and become popular. That time is gone, and now languages essentially need organizational backing of some kind to succeed. That was true for TypeScript, it was true for Rust, it was true for Swift, it was true for Kotlin, and it was true for Go. They also benefit from some sort of well-known thought leader, a role that Rob Pike plays well. If you think Go would have gotten popular without having a Google and a Rob Pike behind it, then, well, I don't know what to tell you. I don't think Rust would have been popular either without the Mozilla association.

Or, more succinctly: I see no world in which Go having simple ML-style generics, without typeclasses or functors, would have made it any less popular. Other factors dominate when it comes to success of a programming language. TypeScript, in fact, shows that you can have generics that are more complex than those of Rust and still become wildly popular.

After a week (my first week, to be fair) of hacking on a serious Rust codebase, I'll give you one reason lack of generics might have been a marketing win for Go: I have never appreciated Go's compiler speed more than I do now.

But the bigger problem is just that Rust programmers use generics absolutely everywhere (my early impression is you basically can't avoid it, because of lifetimes), and it simply does make everything harder to understand. I know I'm going to be told that if I buckle down all of this stuff will make sense and I'll be fluent with it, and sure, I managed to grok Alexandrescu C++, too. But adding new layers of indirection everywhere just has to impede comprehension; that's always the tradeoff for parameterizing and indirecting!

The flip side of this is, I've built some fairly serious things in Go --- a compiler, a couple emulators, a disassembler, a symbolic evaluator; not just the server stuff Go is supposed to be good at --- and I have complaints about Go, but almost none of them are its lack of generics.

(There are things I like about Rust! But this isn't the thread for it.)

What are your complaints about Go? I'm curious to know whether they match mine.

- (removed by author; was too aggressive)

Edit: Removed my response. No worries :)

Rereading that comment I do think I was being uncharitable and have removed it.

Reading the esbuild discussion at the time, it definitely read to me as "our language is definitely faster and if you're not getting the same performance you're holding it wrong", but looking at it now I can see how it wouldn't be intended that way.

Regardless, sorry; I think I was projecting some frustrations with the wider RESF on to you.

And for what it’s worth I spend at least as much of my time wishing it had user defined generics as I do enjoying what it does have.

I’ve now resigned myself to wishing it treated its magic generics with proper typing.

A lot of us Go developers would probably say we like Go because "Go is useful" and leave off the rest.

You are right, Go got more initial momentum because it came out of google and had Rob and Ken's names attached to it. But the useful part is why people actually use it.

> Go is popular because of the names and organization behind it

I hear this a lot, but the counterexample is always Dart. Google is behind it, and Lars Bak is definitely not a nobody, yet the language struggled to gain momentum; not until Flutter came on the scene, and it wasn't an official Google project when it started.

Lars gave a talk last year and said the intent was to put dart vm in chrome, then the whole mobile thing happen and there was no room for extra stuff in chrome. https://youtu.be/mPna6D21Eqg?t=480

It's not at all clear that it was a mistake. Go has had eight years of being one of the more successful languages. If they had tried implementing generics right away, it may have taken longer and it's unclear whether Google would have supported the work for so long? Maybe the timing would have been different enough that they didn't succeed, or the lack of experience would have resulted in a design that's worse?

It's also not at all clear that Go will have similar problems as Python did, since the Go team considers backward compatibility important and might approach the problem differently, learning from Python what to avoid.

Counterfactual reasoning is difficult. Learning from history isn't as easy as some make it look.

It was successful due to massive amount of money spent by Google.

Because there were languages that are much better suited for what Go was designed for. To name a few: Erlang (concurrency that is better than Go's, "channels" and types on par with Go with Dialyzer), Haskell (thread concurrency better than Erlang's, channels, transaction memory, etc and types well beyond Go) and many others.

Go was successful despite mistakes.

Except that these kind of experiments contributed to Java generics, being made available 3 years before Go 1.0 was given a green light.

Which is why Go had already a good example to learn from on how not to do language design.

Are you suggesting all new typed languages have generics? What makes you so sure there isn't room in the design space for a typed language without generics?

As much as I like generics, Go's popularity is a success: programmers have spoken, and they value other things more than generics.

Hindsight is 20/20, and even this isn't a commitment to introduce generics in Go.

"programmers have spoken, and they"...'ve done quite a lot of work to get the benefits of generics without language support. You can pretty much look at any large Go project (famously Kubernetes) and see a workaround of some shape or form.

Kubernetes has lots of workarounds - I’m not sure generics are the ones I’ve worried about the most.

If I had to write a list of “tools I would have preferred to have”:

1. Perfect serialization libraries - Serde is the gold standard here, and IIRC the macro system from Rust is as important a part of it as the traits part.

2. Mutability of types in shared caches - to build efficient controller patterns you need fast and efficient caches - an immutable type that protects against mutation would have saved a lot of ugly mutation testing code

3. Client library definitions shared across types - we could have reduced a fair amount of boilerplate with generics, although most bugs are in the serialization part these days as types evolve

But most of these are dwarfed by the need to scale reviewer time across hundreds of people submitting PRs that change fundamentals of the code. The simplicity of Go and ability to review stupid, obvious, absolutely critical code is the reason why I love it.

Having a strong way to reduce cleverness has been a godsend. It doesn’t mean cleverness is bad, or I don’t want more tools in Go. But I appreciate that aspect of Go in a way that others may not.

Edit: I have been watching kube-rs mature, but to get the same level of scale and performance we’d have to reproduce the shared index informers and that’s a lot of drudge work to get right. That’s one place where someone motivated could really help Rust become a first place way to extend Kubernetes, which would be exciting.

Hacker News law: In every thread about Go someone will bring up rust.

Don't mind.

The comment you are replying to was written by one of Red Hat's lead kubernetes developers (https://github.com/kubernetes/kubernetes/graphs/contributors).

While k8s's code is atrocious, I wonder if that isn't due to its legacy translation from Java (iirc, it was written in it initially)

Kubernetes had a non-public prototype in Java. None of the code in the main tree even resembles the code from that prototype (I was one of the first non-googlers to contribute).

It’s just ugly because that’s how it evolved after a community formed and that’s what real evolved software looks like. :)

Go's popularity is due to author's employer.

Both its main influences, Oberon-2 and Limbo had zero traction on the market, and Limbo not only is quite close to Go, it had an whole OS full of the Plan 9 ideas to come along, yet it failed on the market.

Lack of generics has already been publicly acknowldge as problem.

> In three years of Go surveys, lack of generics has always been listed as one of the top three problems to fix in the language.

https://blog.golang.org/why-generics

And yes, there is no place on the 21st century for typed languages without generics, we already have enough of them from the previous century already.

CLU and ML, the first languages to support genericity are from the mid-70's, they are older than C++ and contemporary to C.

> Go's popularity is due to author's employer.

Why isn't Dart seeing the same type of success?

Because it was dropped on the floor by the Chrome team, which lead to the original team leaving Google, if they had shipped Dartium the outcome would be much different.

Is Dart's lack of popularity in spite of its author's employer, then?

Because it was dropped on the floor by the Chrome team, which lead to the original team leaving Google.

Original Go team did not suffer from this.

Dart's lack of popularity is indeed in spite of the Google backing. I basically see two reasons. First, though Lars Bak has an impressive pedigree, Strongtalk and V8 aren't as well-known as Plan 9 and Unix. Moreover, rightly or wrongly, Dart had the appearance of "Google's attempt to kill JS", which neither endeared it to Web developers (who were riding a wave of JavaScript hype at the time) nor to other browser manufacturers (who were growing increasingly distrustful of Google's initiatives).

> Lack of generics has already been publicly acknowldge as problem.

That's from people who complain because they want Golang to be like Java

It is more people that don't want Go be a plain Limbo remake.

I think Go is popular because of its simplicity and fantastic standard library.

It can also feel sometimes like a dynamic language which has attracted people from ruby, python, JS, etc... communities.

You say there's no place for it in the 21st century, yet it already has a place and it doesn't really need generics to continue living.

Thanks to generics and lambdas, Java's standard library includes concurrent mapreduce. Lacking generics, Go's standard library can't even offer https://golang.org/pkg/sync/#Map without sacrificing type safety.

I agree Java streams and concurrent collections are great.

I agree Go cannot offer similar things due to a weaker type system.

I willingly code Go day-to-day. I miss Java streams, and sometimes the codebase is slightly worse due to the lack of Java streams (or equivalent).

I accept a weaker language because I spend less time debating the Right Way to do things (Go is too inexpressive to support a Right Way), and because I can widen my hiring pool from those that know Java, to those that any language, knowing that they can easily pick up Go.

Go is popular because Google enjoys shoving it down our throats not because it is a particularly good language.

Not saying it is a bad language, but it really helps that Go had Google's blessing.

> Go is popular because Google enjoys shoving it down our throats

How exactly is Google "shoving it down our throats"?

Strange. I get the impression that Google's support for Go is rather half hearted.

Or perhaps Google has many hearts and no one knows exactly how many or where they are at any given point in time :-)

I dont think expirements are a way to qualify decades of research that went before.

Second what Sun choose to implement was a smaller subset and not that close to Featherweight Java/pizza compiler. It was only generics, not first class functions at the time, nor algebraic types/pattern matching.

Java had generics in 2004 w 1.5. Go didn't come onto the scene until 2012... so more like close to decade.

Reply on news.ycombinator.com