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

61–70 of 88 posts

Re: Problems with Go's design

#61

Post by AnimalMuppet »

fixermark wrote: post #24
bobbyrullo wrote: post #8

Earlier quoted context omitted.

For every "quirk" mentioned in this article there are very good reasons for it, which the author lacks the imagination or patience to try and reason through. Point 4 is perhaps the best example. So given an interface Foo and a struct FooImpl which implements Foo, why can't we pass a slice of []FooImpls to []Foo? It's because the creators of Go are lazy and arrogant and incompetent and don't care right? No. Consider t…

I wouldn't put it quite so strongly, but yes; go makes design decisions that are addressing non-obvious problems that the designers encountered over several years of software development in other languages. Consider the block against unused imports. Now consider an application made of hundreds of .go files, that relies on hundreds of libraries, each of which could itself be made of hundreds of .go files---all of whic…

> I wouldn't put it quite so strongly, but yes; go makes design decisions that are addressing non-obvious problems that the designers encountered over several years of software development in other languages.

s/years/decades/

(Which strengthens your point...)

Re: Problems with Go's design

#62

Post by rtz12 »

Yes, Go sucks. But currently, at least for me, I think it sucks a lot less than alternatives. No language is perfect, neither is Go.

The most annoying thing is compiler instructions with special formatted comments. And Rob Pike calls that "elegant design".

Re: Problems with Go's design

#63

Post by spion »

Jemaclus wrote: post #58
spion wrote: post #52

Earlier quoted context omitted.

I've never understood this, every Go user swears on gofmt for some reason that I just dont get. Can you elaborate how gofmt changed your life? Its a really simple tool and lots of languages have those...

You're right. There are other tools out there. But what I really appreciate about gofmt are a few things: * It's highly opinionated. It's not cluttered with customization options. This means your Go program and my Go program are formatted exactly the same. Period. I don't have to choose between spaces or tabs or get annoyed that you chose spaces when tabs are clearly superior. * By being highly opinionated, Gofmt jus…

The reason I don't get it, I think is that I've never cared about stylistic decisions, ever. Why would anyone care, I have no idea.

I can configure my editor for either spaces or tabs. I run npm install when starting with the project anyway, and it will also fetch any devDependencies for me (which means a script such as npm run stylecheck can be made available). The project lead decides the rules. Or there can be no style rules, it doesn't matter - most of those are very superficial and have little to no effect on anything.

Re: Problems with Go's design

#64

Post by shawnps »

yokohummer7 wrote: post #53
shawnps wrote: post #20

I'm surprised to see the author mention not being able to compile when there are unused imports. Editor plugins that call goimports have solved this problem for a long time now. For example, I use vim-go ( https://github.com/fatih/vim-go ), and if I remove the only line of code that references the "fmt" package, the "fmt" import line at the top of the file will automatically be removed. Edit: Here is the reasoning on…

This is a typical instance of solving language issues with excessive tooling. I find it uneasy that we will be reproducing all the baggage Java required us in a different language. And even Java didn't have mandatory imports.

I personally wouldn't call it excessive. It's more like set it once and forget about it. And it's something that basically all professional Go developers do, along the same lines of how everyone runs gofmt.

Re: Problems with Go's design

#65

Post by spion »

cs702 wrote: post #56
RodericDay wrote: post #28

Earlier quoted context omitted.

> don't call Go or any other popular language "poorly designed" with a short blog post. Instead, say "it doesn't fit my current needs." that's not what the author wanted to say though. very, very often someone says "this is bad" when they actually mean "this doesn't fit me". in this scenario, I think the author made a very good case for "it's poorly designed".

RodericDay: Language design decisions by superstars like Robert Griesemer, Rob Pike, and Ken Thompson (the creators of Go) that may seem inconvenient or annoying when working on small to mid-size projects could very well make life much easier when working on giant projects which take years and do not fit on any single person's head. I'm reminded of this insight by Lawrence Kesteloot of Dreamworks: "What’s particularl…

I keep seeing this argument all the time. Lets put a counter-argument-by-authority: Fran Allen [1] thinks that the C was a huge step backwards in language design [2], and there is no reason to think that Go didn't repeat the same pattern.

Interestingly, the article you quoted mentions functional programming and immutable data as the step to go from 200K to 2M lines. Go is fundamentally incapable of functional programming* and its builtins allow pervasive mutable state.

[1]: https://en.wikipedia.org/wiki/Frances_E._Allen

[2]: http://www.amazon.com/Coders-Work-Reflections-Craft-Programm...

* Its impossible to support FP without generics. Even the most basic higher order functions require type variables.

Re: Problems with Go's design

#66

Post by dang »

boulos wrote: post #22
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

On a related note, unfortunately the system encourages attention grabbing headlines to make it to the first page. I think it's great that you then replace them, but without a penalty I don't think this will stop. Would it be hard to deduct say min(5, upvotes)

That's indeed a weakness of the system, but it's complicated by the articles sometimes being good despite the clickbait. This is especially so with the publications large enough to employ specialist headline writers who put bait on everything.

Re: Problems with Go's design

#67

Post by sgeop »

pcwalton wrote: post #57
Jabbles wrote: post #55

Earlier quoted context omitted.

I don't see how it's not type covariance. Go's slices are generic to the extent needed, and the subtyping of Go's interfaces fits the requirements for ordering of types well enough.

In Go, if T implements interface I, T is not a subtype of the interface type I. T can be converted to the interface type I, but it's not a subtype.

What's the difference though? Is this true of interfaces in Java for instance, or does it have to do with the specific implementation of go?

Re: Problems with Go's design

#68

Post by bufordsharkley »

infogulch wrote: post #44
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,…

This sums up my opinion on this pretty well. On 1 I'll just say it'd be nice if append (and other varargs functions) could take multiple of individually listed and slice-expanded args at the same time. As in: `append(a[:2], 3, a[2:]...)`. I already expect append to be O(n), and this would be some very nice sugar.

Yes, the syntax here just looks so unnecessarily ugly. For all the talk of Pythonistas moving to go, I can't see myself switching over to a language with so many ugly, hard-to-remember warts.

Re: Problems with Go's design

#69

Post by sgeop »

yokohummer7 wrote: post #13
bobbyrullo wrote: post #8

Earlier quoted context omitted.

For every "quirk" mentioned in this article there are very good reasons for it, which the author lacks the imagination or patience to try and reason through. Point 4 is perhaps the best example. So given an interface Foo and a struct FooImpl which implements Foo, why can't we pass a slice of []FooImpls to []Foo? It's because the creators of Go are lazy and arrogant and incompetent and don't care right? No. Consider t…

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…

You can already define functions that work on every type that implements Foo, no? I've never coded in go, but I thought that was the whole point of interfaces.

And I don't see how adding generics would solve the problem of being able to add a FooImpl2 to a slice of FooImpls. Java has generics and they don't allow covariant generic collections for this same reason.

Re: Problems with Go's design

#70

Post by kyrra »

spion wrote: post #63
Jemaclus wrote: post #58

Earlier quoted context omitted.

You're right. There are other tools out there. But what I really appreciate about gofmt are a few things: * It's highly opinionated. It's not cluttered with customization options. This means your Go program and my Go program are formatted exactly the same. Period. I don't have to choose between spaces or tabs or get annoyed that you chose spaces when tabs are clearly superior. * By being highly opinionated, Gofmt jus…

The reason I don't get it, I think is that I've never cared about stylistic decisions, ever. Why would anyone care, I have no idea. I can configure my editor for either spaces or tabs. I run npm install when starting with the project anyway, and it will also fetch any devDependencies for me (which means a script such as npm run stylecheck can be made available). The project lead decides the rules. Or there can be no…

Almost all Go code you find on the web will be formatted the same. It removed some pain points when looking at someone else's code. It also complete removes the discussion about formatting during code reviews with team members. While you may not be opinionated on the matter, many people will learn a certain formatting style and stick with it. They then bring it to their new company and it can cause some minor conflict.

Gofmt helps remove that.

Post reply on HN