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

Twelve Years of Go

go.dev

Post reply on HN
Print view View original

151–160 of 244 posts

Re: Twelve Years of Go

#151

Post by merb »

Zababa wrote: post #129
closeparen wrote: post #125

Earlier quoted context omitted.

The community strongly discourages panic.

I think a panic is still better than a chain of if err != nil { return err } that bubbles up and does nothing. Of course the best solution would be proper error handling but not everyone does that (and it's not always obvious what to do).

and most of the time you can't handle it anyway. I mean consider you are having a database query and it fails because the connection error'd (network split). what to do know? restart the network switches and wait? of course not in http you will just print a 5xx err and hope it comes back. in go you need to bubble up these errors to your middleware and handle it there.

Re: Twelve Years of Go

#152

Post by kaba0 »

grey-area wrote: post #86
kbd wrote: post #74

Earlier quoted context omitted.

> No 'oops I forgot to put in a try/catch and now my code died with no explanation'. This is so backwards. First, I want my program to immediately crash if I have a bug. Go is like shell in that it keeps going even if there's an error. Second, I'm used to getting stack traces, Go is the language that will give "no explanation" by comparison if there's a failure.

Your users typically don't want the program to crash, spare a thought for them. Re stack traces, they're fine I guess, but I prefer a well-crafted error message to 200 lines of irrelevant file locations/functions.

That’s the point of exceptions. They bubble up! I can manage them at a place where it is appropriate.

Something had happened during the processing of this web request? Catch the exception and convert it to an appropriate status code.

You should only ever let exceptions fall through ”main” when the problem is really not something you can manage to handle.

Re: Twelve Years of Go

#153

Post by kaba0 »

grey-area wrote: post #117
JoeyJoJoJr wrote: post #113

Earlier quoted context omitted.

I want my program to crash obviously during development so that I know of the existence of bugs, which can be ironed out before getting to production.

That's the theory. In practice it's impossible to exercise all the inputs your programs may get, and then they crash in production when users do things you don't expect.

Which is better than having a bug silently be in production for years to come due to a silent error.

Re: Twelve Years of Go

#154

Post by kaba0 »

nineplay wrote: post #97
kbd wrote: post #74

Earlier quoted context omitted.

> No 'oops I forgot to put in a try/catch and now my code died with no explanation'. This is so backwards. First, I want my program to immediately crash if I have a bug. Go is like shell in that it keeps going even if there's an error. Second, I'm used to getting stack traces, Go is the language that will give "no explanation" by comparison if there's a failure.

I don't know what scale of projects you've worked on. When you're dealing 100K requests/second you very much do not want to immediately crash. It is absolutely the worst think your code can do.

What framework, language crashes due to an exception, regardless of scale? That exception gets mapped to a http status code and that gets returned.

Re: Twelve Years of Go

#155

Post by stouset »

_0w8t wrote: post #68
new_stranger wrote: post #42

Earlier quoted context omitted.

> I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible Which is also the hardest part of convincing people to use Go for me: "Why can't I just .map()/.filter()/.find()?" followed closely by "Why do I always have to check for errors?" What is odd to me is that while yes, my Go code is more verbose than my node services - I always end up writing less Go for the sam…

Most perceived verboseness of Go comes not from the language or libraries but from the formater that does not allow to compress 3 lines of the error check down to single if err != nil { return err }

Worse,

    if res, err := actually_important_bits(...); err != nil {
        return nil, err
    }
The actually important bits are hidden in the middle of line noise. In the "common case" where `actually_important_bits` is just a simple function call it's not necessarily as bad, but the problem is when you have ten successive instances of this and one is slightly different. It's impossible to notice the important difference at a glance.

For an industry that is just starting to understand that code is read hundreds of times more often than it's written, golang fails at the few things we actually know for certain about what makes it easier to understand code at a glance.

Re: Twelve Years of Go

#156

Post by throwaway894345 »

_0w8t wrote: post #147
throwaway894345 wrote: post #72

Earlier quoted context omitted.

If this is the case, I think the fault here lies with flawed perception and not the formatter.

The formater in many cases essentially doubles the number of lines. That requires to scroll much more frequently than with more compact formatting.

I understand, but I take issue with the implication that compression makes code more readable.

Re: Twelve Years of Go

#157

Post by leodriesch »

jpavel2 wrote: post #92
ryandvm wrote: post #76

Earlier quoted context omitted.

C#/Java are almost as fast, but not for immediate execution environments. If you have one off invocations of the code, Go executables will beat the pants off Java as you wait for the JVM to fire up and for HotSpot to kick in.

I write a variety of CLI tools for my own use in Java. On this low-end Chromebook (Samsung Chromebook 3 with a Celeron N3060 @1.60GHz) I can start the JVM, load the classes for my CLI program, and print a help message, jpavel@penguin:~$ time rcr -h Usage: RCloner get|put [args] RCloner list real 0m0.316s user 0m0.208s sys 0m0.126s in less than 1/3 of a second. And this is with stock openjdk version 1.8.0_302, which d…

I think he was talking more about serverless functions, where 300ms longer for answering an HTTP-request would be pretty long.

Re: Twelve Years of Go

#158

Post by latchkey »

nineplay wrote: post #25
AtNightWeCode wrote: post #10

12 years and still no proper error handling. World stars. ;) Seriously, the error handling is a big problem with Go. Not the way it works, the way it effects how people do control flow in general.

Error handling is easily one of my favorite things about Go. No 'oops I forgot to put in a try/catch and now my code died with no explanation'. No 'I forgot a finally ( or didn't realize I needed one ) and now I'm leaking resources'. No 'should I return Null or false or an error code?'. No '20 log messages for the same error because every function is reporting it'. The Go model - Return err, always as the last parame…

There is no catch for array (or slice) index out of bounds. You either code it in yourself or the best you can do is watch for `recover()` and log it.

I wish that one use case was handled better. It is just too easy to mess up.

Re: Twelve Years of Go

#159

Post by kaba0 »

handrous wrote: post #30
ohCh6zos wrote: post #19

Earlier quoted context omitted.

Programming is always going to be complicated as long as the domain is complex. Go as is has traded having no learning curve for having nothing to offer.

What it offers is that code you didn't write is significantly easier to read & understand than in most languages.

But code you didn’t write yourself but still have to wade through is still harder to read and understand than code that was not required to be written due to a better abstraction.

Re: Twelve Years of Go

#160

Post by Andys »

kaba0 wrote: post #141
Andys wrote: post #118

Earlier quoted context omitted.

It is lighter and faster and requires no runtime.

Than Java 1.14? Yes. Lighter is true of current Javas as well, but faster is dependent on the program. Go can often prevent garbage from being generated in the first place, but when creating garbage is a must, Java will happily handle heaps up to a terabyte in size, and its GCs are simply the state of the art. Also, Go most definitely has a runtime, what runs the GC otherwise?

But its also faster to compile and use as a developer. And by runtime I mean there's no JVM. If you're used to Java you should probably just stick with it, but using Go is a huge relief to me.
Post reply on HN