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

211–217 of 217 posts

Re: Thirteen Years of Go

#211

Post by origin_path »

tgv wrote: post #136
origin_path wrote: post #123

Earlier quoted context omitted.

The reason the Tomcat filled memory is that for the longest time Java would only run GCs if you were actually running out of memory. The assumption was, if there's RAM there doing nothing then why would you waste CPU and electricity on cleaning up the heap. If you needed that RAM for something else, OK, tell the JVM there's a cap on how much it can use. It'll then do enough GC work to use that much (ish). The problem…

I think Go shows that that's a false dichotomy. Go can GC very quickly, almost without pauses, and the pauses are sub millisecond. That should be fast enough for almost all backends. Capping isn't great, although doable if you've got a steady workload.

The argument for the Java behavior doesn't depend on how long pauses are. It's purely about efficiency. If your runtime is collecting then it's not spending that CPU time on your apps workload. If you're GCing to reduce your heap from 300M to 100M when you have 16GB free, your server is running slower than it needs to because GC work is more efficient when clearing a lot of garbage from the heap.

Fundamentally with GC there's a throughput vs memory usage tradeoff. Go faces the same issue which is why GOGC exists:

https://tip.golang.org/doc/gc-guide#GOGC

Re: Thirteen Years of Go

#212

Post by benibela »

playingalong wrote: post #160

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.

As someone writing all my code in Pascal, I feel offended

Pascal had exceptions for error handling and got generics before Go

Re: Thirteen Years of Go

#213

Post by Xeoncross »

kaba0 wrote: post #186
Xeoncross wrote: post #179

Earlier quoted context omitted.

I've written a lot of try/catch but no one in those languages do that for every branch, it's usually just everything wrapped in a big try/catch. Go makes you deal with the error every single time something could go wrong, so you have a chance to do the right thing and append context at every single failure path.

Go makes you believe you dealt with the error, but instead you just forget about it. Also, checked exceptions are very much not like that, and being able to handle errors of a logical unit is also beneficiary (e.g. transactions). You are free to use the scope-size that makes sense for the given use case.

> Go makes you believe you dealt with the error, but instead you just forget about it.

Can you explain that? Touching every context of an error propagation seems opposite of forgetting about it.

Re: Thirteen Years of Go

#214

Post by jrockway »

rahen wrote: post #152
throwaway894345 wrote: post #143

Earlier quoted context omitted.

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.

Tinygo lets you build your program with the option -gc=none that results in a link error at every point in your program that would allocate memory on the heap. So that's a very easy way to find them. Tinygo is a completely separate implementation of Go, so not every program is going to be portable 1 to 1, and I suppose that where Tinygo might allocate memory is different than where normal Go would allocate memory, so you'll have to take the results with a grain of salt.

It is of course possible to use Tinygo-compiled programs for your production use case as well. It has a focus on WebAssembly and microcontrollers, but produces perfectly-serviceable amd64 binaries as well.

Re: Thirteen Years of Go

#215

Post by smasher164 »

kaba0 wrote: post #199
smasher164 wrote: post #187

Earlier quoted context omitted.

I don’t think the original commenter said anything about “automatic”. That’s more of a subjective decision—whether or not you manually bubble up an error, or it just floats up because of the exception handler. Empirically, java code has had terrible error handling, because people just stick one catch statement at the root of their program. Go atleast confronts you with the error at every step.

And that is exactly the wrong approach. You really can’t do anything with the error case at most places. If I write a web server, which parts could knowingly handle a db connection error? Either the db driver internally, or going 10 deep higher and the request handler returning an 500 error. In go you would just verbosely (and error pronely!!) have to manually bubble it up, while this is automatically happening in Ja…

I agree that a stack trace is useful, but I disagree that automatic bubbling is universally good. If you look at well-written Go, context is added to every site where you bubble up an error.

Re: Thirteen Years of Go

#216

Post by Xeoncross »

CoolCold wrote: post #196
ilyt wrote: post #146

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. It could've definitely be better (just Rust-like Result type would make it so much clearer to handle) but Go's insistence…

> Go's insistence of dealing with it here and now means you have to think about what is exactly happening when it errors out I read it as "let's stop pretending we are wizardy wizards and can do things right way in 100% cases and let the language to enforce us to handle errors, producing better result for average Joe SR SWE". Am I right with my readings (i'm not a dev guy at all)?

Yes, every process a person/language/company/country/etc.. adopts has a cost. It's not free. The question is if being forced to always deal with errors is worth the cost of always dealing with errors.

I think it is. I will gladly trade a couple of hours of extra error handling code every week in exchange for no pager duty alarms on the weekend.

Re: Thirteen Years of Go

#217

Post by konart »

masklinn wrote: post #106
konart wrote: post #99

Earlier quoted context omitted.

>More like applications you suffer. >How about examples? Sorry, I'm not here to tease or please you. I'm pretty sure you can use google or github search to look for popular Go based projects and try them out.

> Sorry, I'm not here to tease or please you. So you replied to a comment asking for examples, without examples, because... your life passion is to be an ass?

No, I replied with examples that you personally find invalid for your personal reason.

And I'm not eager to bruteforce the "right answer".

Post reply on HN