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

Declined Proposal: A built-in Go error check function, “try”

github.com

Post reply on HN
Print view View original

421–425 of 425 posts

Re: Declined Proposal: A built-in Go error check function, “try”

#421

Post by mikeschinkel »

repolfx wrote: post #300
eikenberry wrote: post #290

Earlier quoted context omitted.

I would say the niche is basically clouds systems programming and general server side apps. JVM based language can't compare due to the JVM. The last thing you want for that type of programming is a huge, complex virtual machine to worry about. That plus memory issues, slow compiles, complex deployments makes it not really in the running. The .net based languages are a bit more interesting, but they have a _lot_ of g…

The last think you want for general server side programming and cloud systems programming is Java? Because of the JVM? You should probably tell Google and Amazon that. Both very heavy users of Java on the server, despite Go. In fact the server space is where Java is most dominant! The JVM is not actually complicated to use, especially not in the latest versions. It has the same number of 'default knobs' (that you sho…

> "The last think you want for general server side programming and cloud systems programming is Java? Because of the JVM?"

Yes, for the smaller companies that do not have the effectively unlimited resources of Google and Amazon. Go is just so much easier to work with and deploy for my tiny company.

Re: Declined Proposal: A built-in Go error check function, “try”

#422

Post by mikeschinkel »

apta wrote: post #343
eikenberry wrote: post #290

Earlier quoted context omitted.

I would say the niche is basically clouds systems programming and general server side apps. JVM based language can't compare due to the JVM. The last thing you want for that type of programming is a huge, complex virtual machine to worry about. That plus memory issues, slow compiles, complex deployments makes it not really in the running. The .net based languages are a bit more interesting, but they have a _lot_ of g…

> The last thing you want for that type of programming is a huge, complex virtual machine to worry about. That plus memory issues, slow compiles, complex deployments makes it not really in the running. Sorry, but I don't buy this at all. golang also ships with a runtime, that's why binaries are dozens of MBs. The JVM is very configurable, which is what I assume you mean when you say "complex". This configurability is…

> "Running them is as simple as `java -jar program.jar`."

That is several steps too complicated:

1. Do you have Java installed? 2. Is it in the path? 3. Do you have the Required Version of Java installed?

None of those need be issues with a self-contained compiled Go program. And that is one of the key reasons we chose Go over any other language.

(And for the other languages that can do the same, Go was the easiest to learn and potentially master.)

Re: Declined Proposal: A built-in Go error check function, “try”

#423

Post by philwelch »

mikeschinkel wrote: post #420
philwelch wrote: post #369

Earlier quoted context omitted.

While true, HTTP services in particular are a very, very common context.

Then use panic() and recover() for that special type of use-case. Just as easy as exception handling.

That's just exception handling with extra steps! ;)

Re: Declined Proposal: A built-in Go error check function, “try”

#424

Post by philwelch »

mikeschinkel wrote: post #419
philwelch wrote: post #334

Earlier quoted context omitted.

In some contexts, exceptions are just cleaner and easier. If I’m writing a web backend, my error handling is going to almost always be, “stop trying to do things and generate a 4xx/5xx response”. Throwing an exception from anywhere and then handling it at the top of the request handling does that without having to tediously carry errors all the way up the call stack.

But then you have to spend lots of extra time trying to discern between the errors that were okay, and the errors that actually indicate flaws in your code. As they say, an ounce of prevention...

It never really seemed like that to me, to be honest.

Any error that I have forgotten to handle is a bug, in the sense that it was a bug to have forgotten to handle the error in the first place. So the standard behavior of "treat every unhandled exception as a 500 response" is technically correct there. Upon consideration, some errors are actually so rare and/or catastrophic that I don't even have to worry about handling them because I wouldn't do anything different anyway. For example, suppose I have a database-backed service that has no meaningful failover if the database is down, and it throws an exception whenever the database is down. There is no reason for me to have to handle that error.

There are other error cases where I have to stop handling the request but it isn't my fault. So if my service has an endpoint that expects a JSON POST body and the body doesn't even parse as JSON, maybe I need to handle that so it throws a 400 instead of a 500. But I could just wrap that exception with a custom class that my error handler generates a 400 response for, and then the rest of my code could just go on assuming that the JSON did parse and that it was valid.

Probably the closest equivalent would be if you had a forking web server where each request had its own thread, and you could effectively kill the thread with a response object at any time. It's not really a case of "using exceptions for flow control" or whatever; it's more a case of "this entire unit of execution is finished and can kill itself just as soon as it's done leaving a note".

Re: Declined Proposal: A built-in Go error check function, “try”

#425

Post by qtplatypus »

wybiral wrote: post #130
nkozyra wrote: post #73

Earlier quoted context omitted.

> and you can see it in stark contrast to something like the JS community with its require('left-pad') NPM ecosystem. Is it fair to compare external packages to core language features? There is nothing preventing a go mod/dep left-pad

Language choices like lacking generics make the over-reliance on dependencies less.

Isn't that a nice way of saying "lacking generics makes people reimplement the same code?". If they are not using some sort of dependency then the code is being duplicated.
Post reply on HN