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

Problems with Go's design

medium.com

Post reply on HN
Print view View original

31–40 of 88 posts

Re: Problems with Go's design

#31

Post by pcwalton »

thorn wrote: post #9

I think author of this article is strangely biased towards dynamic languages. Go is not about shortest programs in the worlds, yes sometimes code is longer than in python. But in Go I can manage code execution and predict memory easier better than in Python or other dynamic languages. Many things in Go were done on purpose. Learn to use Go and it's awesome tools, like gofmt, goimports and others.

Many of the issues here--for example, the set of built-in slice primitives being inadequate--have ready solutions in other statically typed languages (in this case, generics). These are not problems fundamental to static typing.

(For the record, I disagree with some of the criticisms here, for example the slice-of-interfaces type coercion criticism.)

Re: Problems with Go's design

#32

Post by pcwalton »

Jabbles wrote: post #29

Meh. 1. How often do you insert into a slice? You know that's a O(n) operation, right? 2. nil is typed, I'll grant that it's not the most obvious part of Go's type system. 3. Meh. 4. This is type covariance. It's complicated and hard to get right. The Java Generics FAQ looks like this: http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.ht... 5. I like by-value loops. Everything else in Go is by-value. 6. Yeah,…

That's not type covariance. Variance only comes up when you have generics, which Go doesn't, and subtyping, which Go doesn't really have. It's the lack of a coercion/conversion between slice-of-T to slice-of-interface.

The correct language-level solution to #4 is to introduce generics and to allow generic type parameters to have interface bounds. That would solve the problem without having to introduce variance.

Re: Problems with Go's design

#33

Post by xemdetia »

thorn wrote: post #9

I think author of this article is strangely biased towards dynamic languages. Go is not about shortest programs in the worlds, yes sometimes code is longer than in python. But in Go I can manage code execution and predict memory easier better than in Python or other dynamic languages. Many things in Go were done on purpose. Learn to use Go and it's awesome tools, like gofmt, goimports and others.

I agree strongly with this, it seems like the author has some expectations from his known language pool. Reason #3 about lexical scoping is the big one to me, as you can (and might want to) arbitrarily block variable scopes in many languages.

The other components seem to be mostly that Go is still in flux as a language so things that are silly today may be fixed tomorrow, but that's kind of a built in expectation with the ability to transform source files to current. This feels like a lot of the early Java issues that were resolved some time later.

Re: Problems with Go's design

#35

Post by pbnjay »

While Go could probably be better at not letting you shoot yourself in the foot, 1-4 seem to be code smells - you should fix your code and not the language. 5-6 seem to be personal preference, I have no problem with either as they are and they certainly don't trip me up. #7 as the author says himself:

> noone actually cares, it’s just fine

Re: Problems with Go's design

#36

Post by kzhahou »

dang wrote: post #14

We replaced the baity title with something more neutral, in keeping with the HN guidelines: https://news.ycombinator.com/newsguidelines.html

Dang, I think you're too aggressive with article renames. The author claims that Go is poorly designed. And that's the title of the article. Yes, it's a provocative opinion (and the article text is loud), but the title itself was not outrageous hyperbole. I disagree with other commenters here: just because a controversial opinion will (naturally) gather more clicks, doesn't mean it's linkbait.

The articles here on HN also surface on reddit and other forums. I frequently click links on HN just to discover I'd read them already.

The title often contains a clue as to what I'll find in the article. The author presumably gave it some thought. When HN editorializes titles, I lose that context before I decide to click.

Re: Problems with Go's design

#37

Post by mpu »

pcwalton wrote: post #32
Jabbles wrote: post #29

Meh. 1. How often do you insert into a slice? You know that's a O(n) operation, right? 2. nil is typed, I'll grant that it's not the most obvious part of Go's type system. 3. Meh. 4. This is type covariance. It's complicated and hard to get right. The Java Generics FAQ looks like this: http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.ht... 5. I like by-value loops. Everything else in Go is by-value. 6. Yeah,…

That's not type covariance. Variance only comes up when you have generics, which Go doesn't, and subtyping, which Go doesn't really have. It's the lack of a coercion/conversion between slice-of-T to slice-of-interface. The correct language-level solution to #4 is to introduce generics and to allow generic type parameters to have interface bounds. That would solve the problem without having to introduce variance.

Isn't it possible to talk about variance as soon as you have a type constructor (function from types to types)? In this case [].

Edit: I don't know go, but if slices give write access, I think the automatic conversion the author wants would be unsound.

Re: Problems with Go's design

#38

Post by pcwalton »

bobbyrullo wrote: post #15
yokohummer7 wrote: post #13

Earlier quoted context omitted.

Sorry to bring up this yet-another-generics-ranty-thing, but actually point 4 is a typical issue that can be nicely solved with generics, by defining a function that works on every type that implements Foo. In this way you can directly pass a slice of Foo to the function and achieve type safety at the same time. As stated by the author, there's a demand for manually constructing an interface-slice in Go, and this sho…

That's a different criticism. That's the "Go Needs Generics" issue. I don't disagree with it, but I also agree that there hasn't been any good solutions proposed for generics that meet the requirements that are at the core of Go: namely, performance of the compiled program, performance of the compiler, and performance of the developer.

Just monomorphize the code. It really isn't a problem for compilation performance. (I predict 10%-20% overhead based on measurements in other languages, though note that I think the entire concept of measuring the compilation speed overhead of generics is pretty much hopelessly flawed to begin with.)

Re: Problems with Go's design

#39

Post by dang »

kzhahou wrote: post #36
dang wrote: post #14

We replaced the baity title with something more neutral, in keeping with the HN guidelines: https://news.ycombinator.com/newsguidelines.html

Dang, I think you're too aggressive with article renames. The author claims that Go is poorly designed. And that's the title of the article. Yes, it's a provocative opinion (and the article text is loud), but the title itself was not outrageous hyperbole. I disagree with other commenters here: just because a controversial opinion will (naturally) gather more clicks, doesn't mean it's linkbait. The articles here on HN…

You may not think this was linkbait, but I guarantee you that if this article were on HN's front page with that title, the thread would become about the title. All you need to do is look at the comments that were posted before we changed it.

Your objection is really to HN's title policy. In my view that policy is a critical aspect of this site—indeed the longer I work on HN the more critical it seems. So I have to disappoint you here; it's not going to change. Huge numbers of HN readers would be up in arms if it did, even though no reader agrees with every particular edit moderators do.

Re: Problems with Go's design

#40

Post by bobbyrullo »

yokohummer7 wrote: post #21
bobbyrullo wrote: post #15

Earlier quoted context omitted.

That's a different criticism. That's the "Go Needs Generics" issue. I don't disagree with it, but I also agree that there hasn't been any good solutions proposed for generics that meet the requirements that are at the core of Go: namely, performance of the compiled program, performance of the compiler, and performance of the developer.

The reason why I think generics are relevant to point 4 is that generics can be thought as "first-class interfaces" which seem to be wanted by the author. Yes, the author suggests a method that is not acceptable to my taste (implicitly converting []struct to []interface), but if Go had generics he might have not complained about the lack of "first-class interfaces", because generics are in some ways "interfaces on st…

Sure, there's lots of trade-offs - you can't build anything significant without trade-offs. Also, you can still say performance is a value and trade it away for other things, eg GC. It's a bit silly to say that if something isn't as fast as C++/C right away then it doesn't take performance seriously. I don't think anyone's being dishonest in making such trade-offs - if you have multiple competing values then you need them.

The big difference with stuff like GC and re-writing stuff in go slowing the compiler time is that they are not inherent to the language. That stuff can and will improve. With generics if done incorrectly, it's more or less permanent. So I appreciate the conservatism there, and don't think it's fair (or accurate) to say that it's dishonest.

Post reply on HN