8 ms·
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
by jlouis 6y ago
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.
- pjmlp 6y agoExcept 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.
- eeh 6y agoAre 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.
- jdub 6y ago"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.
- smarterclayton 6y agoKubernetes 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.
- entha_saava 6y agoHacker News law: In every thread about Go someone will bring up rust. Don't mind.
- uluyol 6y agoThe comment you are replying to was written by one of Red Hat's lead kubernetes developers (https://github.com/kubernetes/kubernetes/graphs/contributors https://github.com/kubernetes/kubernetes/graphs/contributors).
- saturn_vk 6y agoWhile 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)
- pjmlp 6y agoGo'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 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.
- icholy 6y ago> Go's popularity is due to author's employer. Why isn't Dart seeing the same type of success?
- pjmlp 6y agoBecause 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.
- jstarks 6y agoIs Dart's lack of popularity in spite of its author's employer, then?
- pjmlp 6y agoBecause 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.
- pcwalton 6y agoDart'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).
- meddlepal 6y agoGo 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.
- icholy 6y ago> Go is popular because Google enjoys shoving it down our throats How exactly is Google "shoving it down our throats"?
- fauigerzigerk 6y agoStrange. 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 :-)
- frej 6y agoI 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.
- meddlepal 6y agoJava had generics in 2004 w 1.5. Go didn't come onto the scene until 2012... so more like close to decade.
- meddlepal 6y agoI 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.
- baby 6y agoI'd say the popularity of Go stems from the lack of generics.
- xkapastel 6y agoAnd why on earth would you say that?
- baby 6y agobecause it's a breeze to read Golang, due in parts to the lack of generics
- therealdrag0 6y agoWhy does genetics make things that’s for read?
- zdragnar 6y agoFunctions 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.