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

Featherweight Go

arxiv.org

Post reply on HN
Print view View original

71–80 of 169 posts

Re: Featherweight Go

#71

Post by meddlepal »

eeh wrote: post #29
pjmlp wrote: post #25

Earlier quoted context omitted.

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.

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.

Re: Featherweight Go

#72

Post by voidfunc »

pjmlp wrote: post #25
jlouis wrote: post #8

Earlier quoted context omitted.

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

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.

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

Re: Featherweight Go

#73

Post by icholy »

meddlepal wrote: post #71
eeh wrote: post #29

Earlier quoted context omitted.

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.

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"?

Re: Featherweight Go

#74

Post by mshockwave »

entha_saava wrote: post #60
parhamn wrote: post #6

There’s also a generics implementation on a branch of the go repo. I’m most curious how they perform on compilation speed assuming a big project makes decent use of generics. I doubt golang would merge anything that causes significant slowdown. And I don’t blame them, the only reason I don’t dread TypeScript dev given its slow compile times is you can typecheck async and strip the typing information for the hot reloa…

I guess it need not be the case that generics will slow down compilation that much. Problem with C++ template generics is that they are reinstantiated per type __per compilation unit__. I think they can * Use dynamic dispatch liberally - such that one instantiation per object size in order to avoid boxing. That said, I don't know how the experimental generics work. And this will obviously prevent some optimizations,…

Interesting ideas! some comments from a C++ compiler perspective:

> Use dynamic dispatch liberally - such that one instantiation per object size in order to avoid boxing. That said, I don't know how the experimental generics work. And this will obviously prevent some optimizations, notably escape analysis.

I think you're right about optimization: dynamic dispatch is what most of the template users want to avoid

> defer compilation of generic code to the end i.e "just before linking" phase instead of eliminating duplicates at link time.

Pretty cool. Never thought about that, though I believe LTO in gcc/clang might cover this part in some near future, or already had some partial supports.

> Some kind of caching mechanism for generic code such that you `sed` the machine code / plan9 intermediate to replace it with type specialization wherever required

Not sure about this though...not sure if the benefit outperforms the overhead cuz it sounds pretty expensive. But as a similar approach, JIT compilation might be a way.

Re: Featherweight Go

#75

Post by uluyol »

entha_saava wrote: post #63
smarterclayton wrote: post #48

Earlier quoted context omitted.

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

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).

Re: Featherweight Go

#76

Post by etse »

pjmlp wrote: post #54
enitihas wrote: post #49

Earlier quoted context omitted.

They could have gone to 2001 technology way back. The Go FAQs say -> > " We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it." I mean if you are going to use 2001 technology, you could have found it long back.

Yet, they acknowledged it was a mistake not to consider them. > 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 By the way, they could have gone to 1974 (CLU), 1973 (ML), 1983 (Ada), 1986 (Eiffel), 1988 (Modula-3), 1990 (Sather & BETA), 1998 (C++), 2007 (D), 2009 (Java & Delphi). These are just the most…

They weren't convinced at the time. Now they feel compelled to act. How is this political?

Re: Featherweight Go

#77

Post by baby »

voidfunc wrote: post #69
jlouis wrote: post #8

Earlier quoted context omitted.

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

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.

Re: Featherweight Go

#78

Post by baby »

pjmlp wrote: post #52
eeh wrote: post #29

Earlier quoted context omitted.

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.

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

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

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

Re: Featherweight Go

#79

Post by solarkraft »

ainar-g wrote: post #26

From the conclusion: Featherweight Go is restricted to a tiny subset of Go. We plan a model of other important features such as assignments, arrays, slices, and packages, which we will dub Bantamweight Go; and a model of Go’s innovative concurrency mechanism based on “goroutines” and message passing, which we will dub Cruiserweight Go. Love the naming!

Thanks for posting, but next time please cite with >.

This code block is a scrolling nightmare on mobile.

Re: Featherweight Go

#80

Post by Ericson2314 »

lazyjones wrote: post #40
jlouis wrote: post #35

Earlier quoted context omitted.

Closer to logic. There is a straightforward rewrite into prolog if you want a program. Or one of the proof assistants. The notation is abused though. Try looking up some of the work by Guy L. Steele in the recent years.

> Closer to logic. There is a straightforward rewrite into prolog if you want a program. Journal papers usually don't get rewritten into Prolog or fed into proof assistants. They're read by human beings. I've long suspected (and colleagues used to "joke" about it) that excessive use of mathematical notation is just employed to impress and/or confuse peer reviewers into just accepting the paper instead of trying to co…

Stop trying to justify your own ignorance.

The sequent calculus is great—I am far from an expert and for many papers I can skip the text at first, read the sequents, and then just go back to the prose only if I have specific questions. No prolog conversion needed.

As programers, we should be able to read, not just write, formal languages, and appreciate the value of the precision they provide.

Post reply on HN