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

Thirteen Years of Go

go.dev

Post reply on HN
Print view View original

151–160 of 217 posts

Re: Thirteen Years of Go

#151

Post by Gwypaas »

ilyt wrote: post #146
kaba0 wrote: post #128

Earlier quoted context omitted.

Error handling is strictly worse than pretty much any other language out there — you are only making you believe that you are handling your error cases. A pragmatic “handle it here or bubble it up” is a much better approach, as more often than not you can’t actually handle the error at call site. Goroutines in themselves won’t give you actually correct concurrency. I really hope that Go doesn’t replace Java.

>Error handling is strictly worse than pretty much any other language out there — you are only making you believe that you are handling your error cases. A pragmatic “handle it here or bubble it up” is a much better approach, as more often than not you can’t actually handle the error at call site. It could've definitely be better (just Rust-like Result type would make it so much clearer to handle) but Go's insistence…

> The concurrency primitives are built into language and stdlibs which means when you do need synchronization, everyone does it same way.

As long as you after refactor N still are staying in the happy path avoiding the numerous footguns and implicit behavior Go supplies you with.

I would say if you stray outside a single thread or shared nothing fire up a Goroutine per response architecture deeply reconsider the choice of using Go.

https://eng.uber.com/data-race-patterns-in-go/

Re: Thirteen Years of Go

#152

Post by rahen »

throwaway894345 wrote: post #143
rahen wrote: post #82

Earlier quoted context omitted.

> I only wish it was a bit more C-like and you had the ability to run it without a garbage collector "import C, import unsafe". You absolutely can, at least for performance critical sections where you cannot afford garbage collection. https://dgraph.io/blog/post/manual-memory-management-golang-...

You don't even need CGo or unsafe to deal without a GC. Go's GC is written in Go and it obviously doesn't depend on a GC! You just need to know which features imply a GC/allocation and you need to take care to avoid those features. Conceivably, you could devise a linter that statically verifies your no-GC requirement.

> You just need to know which features imply a GC/allocation and you need to take care to avoid those features.

This is very insightful. Would you mind sharing more resources regarding that? I'd be interested in a list of such features.

The GC can also be used manually by setting GOGC=off, then be triggered manually at the most convenient time.

Re: Thirteen Years of Go

#153

Post by HillRat »

throwaway894345 wrote: post #139
Xeoncross wrote: post #43

I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a default. It's hard to explain, but the language is one you can throw into a team of random developers and come out with benchmarks, tests, CI/CD pipelines, unified code formatting, and good parallel work models (via goroutines) almost every time. Builds are in…

Not only that, but all of the features Go doesn't have means that you don't have to navigate the "which subset of the language does this project use?" problem. Every project uses pretty much the same language features. Similarly, the code formatter is universal and minimally configurable, so the code formatting looks the same across the ecosystem. Virtually everyone uses the same test runner too. Also, you get docume…

One of my mantras is "what you say no to is more important than what you say yes to," and the Go team says no to a lot. It can be frustrating and Go can be incredibly inexpressive (and, frankly, boring) compared to other languages, but it's hard to find another stack in which any random developer can be as productive as quickly on any random codebase. There are other languages where my personal velocity is a lot higher, but at a team level I haven't found anything that beats Go.

Re: Thirteen Years of Go

#154

Post by erik_seaberg »

doorman2 wrote: post #141
kaba0 wrote: post #137

Earlier quoted context omitted.

What exactly is fantastic about it, objectively? I really can’t come up with anything besides goroutines. It’s quite inexpressive and is pretty much like the litany of other managed languages (I am honestly baffled how it gets compared to Rust — wouldn’t you be surprised if someone was going on about C vs JS? That’s the same thing)

Personally, I hate writing Go. It's a very dull and boring language, but it's an amazing language (objectively speaking) for software development. 1) It's performant. The language itself is very fast, the GC is very fast and go routines make concurrency fast. 2) The tooling is great. Once you have the Go CLI installed, everything else "just works." Cross-compilation is super easy. Install dependencies is easy. Genera…

The GC is low latency, but its throughput isn’t great. The key is avoiding the heap by mostly brute forcing trivial data structures on the stack (which is why you see so many repetitive O(n) loops).

Re: Thirteen Years of Go

#155

Post by masklinn »

tptacek wrote: post #51
Laiho wrote: post #37

I really want to love this language, a fast and simple garbage collected lang, but feel like they missed the spot a little. I just wish they did something different with error handling / nil, doesn't feel right for the language. Also whats up with stuff like unused imports being such a big deal?

I keep count in my own code of the number of bugs Go's "damnable use requirement" has caught for me, and I'm now up to 5. It's not a big number, but they were real bugs that would have annoyed the shit out of me if they'd made it into shipping code. I think this is one of the polarizing decisions Go made that is going to turn out to be universal orthodoxy 10 years from now. I think error handling is the thing about G…

> I keep count in my own code of the number of bugs Go's "damnable use requirement" has caught for me, and I'm now up to 5.

Are you saying that you’ve had 5 bugs caused by unnecessary imports?

Re: Thirteen Years of Go

#156

Post by eweise »

doorman2 wrote: post #141
kaba0 wrote: post #137

Earlier quoted context omitted.

What exactly is fantastic about it, objectively? I really can’t come up with anything besides goroutines. It’s quite inexpressive and is pretty much like the litany of other managed languages (I am honestly baffled how it gets compared to Rust — wouldn’t you be surprised if someone was going on about C vs JS? That’s the same thing)

Personally, I hate writing Go. It's a very dull and boring language, but it's an amazing language (objectively speaking) for software development. 1) It's performant. The language itself is very fast, the GC is very fast and go routines make concurrency fast. 2) The tooling is great. Once you have the Go CLI installed, everything else "just works." Cross-compilation is super easy. Install dependencies is easy. Genera…

Not sure generics are amazing. I wish I could do something like

addresses := persons.map(func(p Person) Address {p.address})

Actually what I really want is

addresses := persons.map(p => p.address)

But I understand Go doesn't allow that level of readability.

Re: Thirteen Years of Go

#157

Post by throwawaygal7 »

origin_path wrote: post #122
Xeoncross wrote: post #43

I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a default. It's hard to explain, but the language is one you can throw into a team of random developers and come out with benchmarks, tests, CI/CD pipelines, unified code formatting, and good parallel work models (via goroutines) almost every time. Builds are in…

"Errors always get handled because the linter points them out and the devs don't cheat by setting up multi-function try/catch blocks" My experience with Go has been that errors get "handled" by propagating them up the stack manually and then logging them, without keeping proper track of how the error got there. So there is error handling but only in theory, in practice what you get is a sort of hand-written stack unw…

In go, you either handle the error where it happens or close to it, or log it. No need to pass things up just to log. I like the simplicity, and the zero cost at runtime. If you could handle the error in another lang you could handle it in go, or youd just supress or log it anyway.

Re: Thirteen Years of Go

#158

Post by galangalalgol »

throwaway894345 wrote: post #144
galangalalgol wrote: post #81

Earlier quoted context omitted.

Just got told about tinygo on another thread where I was saying rust is the obvious only choice. But tinygo looks nice. I've written very little go professionally, and rust only for a few months more. Go does seem super easy. But rust doesn't really seem hard either. And the fearless concurrency is really attractivento not have to think much about data races too much. Either one is nicer than c++ which I have a quart…

TinyGo still has a GC, right?

It does. https://aykevl.nl/2020/09/gc-tinygo

Edit: but that said with sich constrained resources do people really use gc or even dynamic memory allocation often in embedded? I work embedded and it is usually standard practice to preallocate everything to avoid fragmentation. Unless it is a more performant device in which case I'll add the quotes to "embedded". But for those you could just use normal go, or python for that matter.

Re: Thirteen Years of Go

#159

Post by throwawaygal7 »

eweise wrote: post #156
doorman2 wrote: post #141

Earlier quoted context omitted.

Personally, I hate writing Go. It's a very dull and boring language, but it's an amazing language (objectively speaking) for software development. 1) It's performant. The language itself is very fast, the GC is very fast and go routines make concurrency fast. 2) The tooling is great. Once you have the Go CLI installed, everything else "just works." Cross-compilation is super easy. Install dependencies is easy. Genera…

Not sure generics are amazing. I wish I could do something like addresses := persons.map(func(p Person) Address {p.address}) Actually what I really want is addresses := persons.map(p => p.address) But I understand Go doesn't allow that level of readability.

So you just want implicit returns?

Re: Thirteen Years of Go

#160

Post by playingalong »

Anyone else feeling put off by golang? The syntax, the crazy error handling, etc. To me it's like taking a step back in programming, or actually 20 years back. Not better than Java (which is annoyingly verbose), maybe better than Pascal.
Post reply on HN