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

Eight years of Go

blog.golang.org

Post reply on HN
Print view View original

121–130 of 291 posts

Re: Eight years of Go

#121

Post by cannam »

brian-armstrong wrote: post #110

Go is woefully missing some really key features, which you encounter when tuning it for high performance. My list of grievances: - Dep handling was never considered. Makes sense given Google's monorepo but thats not how the world works. - Stdlib just loosely wraps posix features with many C flags copied verbatim. These APIs are old and could use a refresh but Go never bothered. - No easy way to construct arenas/pools…

> - No supervision tree. Erlang existed far before Go but they didn't learn from this key feature. But it would greatly enhance Go to have it

This is the one thing in your list that I don't recognise. What is a supervision tree? Can you (or another Erlang programmer) point to your favourite reference?

Re: Eight years of Go

#122

Post by cube2222 »

terminalcommand wrote: post #90
tetraodonpuffer wrote: post #78

Earlier quoted context omitted.

> my intuition what I think a given piece of code should mean is nearly always in line with the language specification. for some things yes, but for others I think that it's more familiarity than intuition, take for example interface slices, you start by learning that you can assign any type to interface{}, so intuitively you'd think that you could assign any type slice to []interface{} but you find out soon enough t…

IMO interfaces are the Achilles' heel of Golang. Another thing that has been bugging me about them is that you cannot specify which interface you're implementing in the code (beside from comments). I think that is so because Go hates circular imports. If you had to import a file to be able to use an interface, you'd soon run into compile errors due to circular dependencies. And as there is no way to immediately see w…

I actually experienced the opposite. Interfaces in go work so well, partly because you can create an interface which automatically gets satisfied by existing structures. For example I often use a requestDoer interface which only has the http clients "Do" method.

I'm using Goland so I have jump to interface from any structure implementing it. So that's another one that gets solved by tooling.

The structurally typed interfaces are actually my favorite part about Go probably.

Re: Eight years of Go

#123

Post by brian-armstrong »

Karrot_Kream wrote: post #119
brian-armstrong wrote: post #110

Go is woefully missing some really key features, which you encounter when tuning it for high performance. My list of grievances: - Dep handling was never considered. Makes sense given Google's monorepo but thats not how the world works. - Stdlib just loosely wraps posix features with many C flags copied verbatim. These APIs are old and could use a refresh but Go never bothered. - No easy way to construct arenas/pools…

I'm not disagreeing with you (I've previously criticized Go here) but I think it's helpful to think of Go as a more "modern" C. A lot of the warts you see here (Cludgey POSIX interfaces, no smart scheduling around channel error handling, bad reflection semantics, etc.) are the same as you'd find in C.

Except, it's not a compelling replacement of C. The type system doesn't give me good assurances about program behavior at compile time. Go inserts itself as a heavy unwanted additional layer for cases where I want C. Especially considering that now my program will have GC pauses.

Re: Eight years of Go

#124

Post by krylon »

johndubchak wrote: post #111
krylon wrote: post #30

Earlier quoted context omitted.

You are not wrong. But I think there is more to it. I have used Go (almost) exclusively for private toy programs I write in my free time to relax (sounds weird, I know), so my perspective may be warped. But something about is very compatible with the way my mind works. With some other languages, say C or C#, I find myself constantly browsing through documentation to figure out what a given construct means in that lan…

> I write in my free time to relax (sounds weird, I know) Not weird at all. I do that myself. I believe the relaxation is in pure creativity, the wonder of exploring something novel and the absence of any pressure or stress due to timelines or deadlines. You're also exercising both right and left sides of the brain. I suspect there are many many more who do the same.

Huh. That are exactly the reasons I would give if I had to explain that hobby to somebody. ;-)

Feels kind of good to know that I am not the only one doing this.

When it goes really well, programming is akin to what I think meditation must be like. But explaining that to people who have never programmed themselves is hard.

Re: Eight years of Go

#125

Post by terminalcommand »

majewsky wrote: post #106
terminalcommand wrote: post #105

Earlier quoted context omitted.

Yes you could, but then you'd have to have both the declaration and the implementation of the interface in the same package. That would mean that if either of them is in a separate file, you'd have to import it. That in return, could easily call hellish compiler errors due to circular dependencies. In Go any circular dependency is an immediate compile error. Looking at the link, the second advice is that you could re…

A possible solution is to have a separate (otherwise unused) package in your codebase with just a test in it: //compile_test.go func TestThatThisModuleCompiles(t* testing.T) {} //list of "type implements interface" tests var _ mymodule.MyInterface = myothermodule.MyStruct{} ... Then you just ensure that `go test` is run, e.g. by the CI.

That's a clever way to solve the issue. I think most Go codebases could benefit from such explicit checks where the language does not provide an unambiguous solution.

The interface issue has been on my mind for quite sometime. I had thought maybe declaring all interfaces in seperate files might help with the structure (like having the definitions in a header file in C), but the Go standard library does not use this approach. Interfaces and implementations are scattered across files and modules. Maybe I'm being too clever and we all know that Rob Pike always says that programmers should not be too clever. Maybe I should loosen up a bit, and treat Golang more like a pragmatic language. They did the best they could and produced a wonderful language. Any additional feature such as generics and explicit implements statements would have made the language much more complex.

Re: Eight years of Go

#126

Post by brian-armstrong »

cannam wrote: post #121
brian-armstrong wrote: post #110

Go is woefully missing some really key features, which you encounter when tuning it for high performance. My list of grievances: - Dep handling was never considered. Makes sense given Google's monorepo but thats not how the world works. - Stdlib just loosely wraps posix features with many C flags copied verbatim. These APIs are old and could use a refresh but Go never bothered. - No easy way to construct arenas/pools…

> - No supervision tree. Erlang existed far before Go but they didn't learn from this key feature. But it would greatly enhance Go to have it This is the one thing in your list that I don't recognise. What is a supervision tree? Can you (or another Erlang programmer) point to your favourite reference?

Here's the relevant chapter from Learn You Some Erlang

http://learnyousomeerlang.com/supervisors

Re: Eight years of Go

#127

Post by erik_seaberg »

theshrike79 wrote: post #80
dekhn wrote: post #38

Earlier quoted context omitted.

Complaints about generics aren't coming from a minority group. It's a majority now.

People want generics because they think every language should have generics. What they don't know is the exact cases where the lack of generics causes a real-world problem for them. This is what the developers are requesting at the moment, in order to possibly bring generics to Go 2.

Every statically-typed language needs generics to allow a function to be used with more than one type. Otherwise you throw away most of the type info and end up with the same problems dynamically-typed languages have.

Re: Eight years of Go

#128

Post by cube2222 »

solox3 wrote: post #4
noncoml wrote: post #2

Things I love about go: 1. Probably the best ecosystem out there. 2. Go routines 3. (Enabled by (2) actually) `defer` 4. That I can add interfaces implementations to structs I don’t own 5. No exceptions. Actually (5) is one of the few things I don’t like about Haskell. If Go had ADTs and generics it would easily be my favorite language. Edit: and of course the channels. Edit2: yeah, i have no idea why i connected (2)…

Novice here. Why is having no exceptions a good thing, in your opinion?

Because it makes you handle errors by value, which makes you handle them one by one, and not group everything into one try statement.

This usually makes the error handling much better and better thought through.

You can see the same thing happening in all the functional languages using the Either monad instead of exceptions.

Re: Eight years of Go

#129

Post by insulanian »

krylon wrote: post #30
nine_k wrote: post #7

Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).

You are not wrong. But I think there is more to it. I have used Go (almost) exclusively for private toy programs I write in my free time to relax (sounds weird, I know), so my perspective may be warped. But something about is very compatible with the way my mind works. With some other languages, say C or C#, I find myself constantly browsing through documentation to figure out what a given construct means in that lan…

> sounds weird, I know

No, it doesn't.

Re: Eight years of Go

#130

Post by simon_o »

atmosx wrote: post #32
nine_k wrote: post #14

Earlier quoted context omitted.

For exceptional, unforeseen situations you do have exceptions, aka "panic". For signaling error conditions that the caller has to expect and handle, you have the `result, err = func(...)` idiom, and a compiler that would warn you if you forget to use the value of `err`. If Rob Pike's opinion on this is not enough, here's Martin Fowler saying essentially the same thing: https://martinfowler.com/articles/replaceThrowWi…

I’ve read the first article. It was eye opening, cause I am writing a bot right now and using exceptions to control input flow. Made me think about my design. That said, it does not argue against exceptions. So, I am not sure what your argument is.

Exceptions are bad outside the "your computer just started burning" cases, but Go has replaced them with something even worse, "multiple return values".

So instead of some imagined return of "int or throw Exception" you now have "(int, error)", which basically means that the result of a function call can be any of these four options:

  - (   value, no error)
  - (no value,    error)
  - (   value,    error)
  - (no value, no error)
And due to the lack of Generics you can't abstract over your error handling.

And due to the lack of proper ADTs you can't even properly model "value OR error" manually.

Post reply on HN