Live data from Hacker News

Featherweight Go

arxiv.org

111–120 of 169 posts

Re: Featherweight Go

#111

> Whereas most programming languages use nominal subtyping, Go is unique among mainstream typed programming languages in using structural subtyping. I thought typescript also used structural subtyping? i.e. in typescript I can define: interface Stringer { String: () => string } function takesStringer(s: Stringer) {} And now I can call takesStringer with any class that happens to have a String() method. This seems to…

It absolutely does. It doesn't have any nominal typing at all, so even classes are compared structurally.

I assume they're not considering it because typescript compiles to javascript, so it doesn't have the problem Go faces of how to generate code for its generics. The wording is definitely weird though.

Re: Featherweight Go

#112

Suggestion: While your paper is very intellectual and I laud that, perhaps what would work better for mass uptake is to create your own programming language around the concepts you propose, and let people try that language. You could call this language "Featherweight Go" if you wish, but perhaps it would be better to call it something else entirely, and simply state that that this new language was inspired by Go. Thi…

What are you talking about... Two members of the Go team are on the author list.

If I were them, I'd leave Google and start my own programming language company. I can't speak for them of course, but that's what I would do if I were in their position.

Re: Featherweight Go

#113

Suggestion: While your paper is very intellectual and I laud that, perhaps what would work better for mass uptake is to create your own programming language around the concepts you propose, and let people try that language. You could call this language "Featherweight Go" if you wish, but perhaps it would be better to call it something else entirely, and simply state that that this new language was inspired by Go. Thi…

that's one hell of an off-topic comment if I've seen one

Re: Featherweight Go

#114

Earlier quoted context omitted.

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

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

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.

Re: Featherweight Go

#115
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.

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.

Re: Featherweight Go

#116

Thanks for reminding me how the rampant abuse of nearly unreadable mathematical notation for things that can be easily expressed in concise natural language contributed to (voluntarily) shortening my academic career. But more seriously, it's interesting how this produces publications before actual implementations.

If you want to reason about low level compiler optimizations, learn some assembly language. If you want to reason about type systems, learn how to read basic typing rules, it's not complicated.

Sometimes planning before implementing is a good thing, or does even language design need to be agile™?

Re: Featherweight Go

#117

Earlier quoted context omitted.

I haven’t used Rust on any significantly sized project. Could you elaborate? Is it only slow to compile release builds?

It is generally slower to compile than we would like. We have and will continue to spend a lot of engineering time improving it. It is often one of the largest feature requests from the community.

Any compiler that's faster than a human brain is a win. More than that is gravy, and thank you for it.

Re: Featherweight Go

#118
post #96

Earlier quoted context omitted.

What do you mean by "incrementally compile"? an addition of a single line of code results in a 60s build? never experienced anything like that, only the first compile is slow for me.

Incremental compilation results are subjective. If you just changed the file with "main" in it and there was nothing else in there, I'd expect it to be faster than changing a file at the bottom of the dependency tree as you then have to recompile a lot more. Perhaps they're changing some fundamentals of the codebase and (unsurprisingly) the compiler seems slower than you might expect.

Yes, unfortunately, most of my work is on low-level shared libraries and it often wants to rebuild everything.

Re: Featherweight Go

#119
post #87
post #52

Earlier quoted context omitted.

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…

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.

Re: Featherweight Go

#120
post #34

Earlier quoted context omitted.

how come hundred cores is only speedup of ~6?

Amdahl's law.

Not a law. Haskell can be much closer to linear, performance to cores. It starts banging its head on the last core; the little bit of other work the computer does seems to throw off Haskell's gait. (This is subjective first-hand experience.)
Post reply on HN