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

I’m joining the Go team at Google

spf13.com

Post reply on HN
Print view View original

101–110 of 211 posts

Re: I’m joining the Go team at Google

#101

Post by Conlectus »

pmarreck wrote: post #89
thwd wrote: post #80

Earlier quoted context omitted.

True, you can discard errors on purpose by assigning them to "_", which is an explicit way of saying "I do not care about this error happening". If you do that and get a panic down the line, you already know where to start debugging. That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it?

> That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it? I don't see how that follows. A stack trace (as initially cryptic as it seems) is a record of all the code that would have affected the current buggy state you find yourself in. If anything, a stack trace isn't comprehensive enough, ideally it would include all known/named…

Any error return values in go must be assigned to a variable at call time, otherwise it's a compile error. Unused variables are also a compile error, so you are forced to do something with it.

Assigning to _ effectively ignores the error, but is considered a very bad practice.

Unavoidable runtime errors (eg divide by 0) will generate a panic, which is similar to an exception, but is uncatchable within the Go routine it originates in.

Re: I’m joining the Go team at Google

#102

Post by Hello71 »

pmarreck wrote: post #89
thwd wrote: post #80

Earlier quoted context omitted.

True, you can discard errors on purpose by assigning them to "_", which is an explicit way of saying "I do not care about this error happening". If you do that and get a panic down the line, you already know where to start debugging. That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it?

> That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it? I don't see how that follows. A stack trace (as initially cryptic as it seems) is a record of all the code that would have affected the current buggy state you find yourself in. If anything, a stack trace isn't comprehensive enough, ideally it would include all known/named…

    (gdb) bt full

Re: I’m joining the Go team at Google

#103

Post by microtonal »

Conlectus wrote: post #101
pmarreck wrote: post #89

Earlier quoted context omitted.

> That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it? I don't see how that follows. A stack trace (as initially cryptic as it seems) is a record of all the code that would have affected the current buggy state you find yourself in. If anything, a stack trace isn't comprehensive enough, ideally it would include all known/named…

Any error return values in go must be assigned to a variable at call time, otherwise it's a compile error. Unused variables are also a compile error, so you are forced to do something with it. Assigning to _ effectively ignores the error, but is considered a very bad practice. Unavoidable runtime errors (eg divide by 0) will generate a panic, which is similar to an exception, but is uncatchable within the Go routine…

Any error return values in go must be assigned to a variable at call time, otherwise it's a compile error.

Nonsense.

   fmt.Println("Hello world!")
I just ignored an error and it compiles fine. Go check the return type of Println:

https://golang.org/pkg/fmt/#Println

tl;dr, it's very easy to accidentally ignore errors in functions that are side-effecting or modify parameters. Been there, done that.

Re: I’m joining the Go team at Google

#104

Post by thwd »

pmarreck wrote: post #89
thwd wrote: post #80

Earlier quoted context omitted.

True, you can discard errors on purpose by assigning them to "_", which is an explicit way of saying "I do not care about this error happening". If you do that and get a panic down the line, you already know where to start debugging. That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it?

> That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it? I don't see how that follows. A stack trace (as initially cryptic as it seems) is a record of all the code that would have affected the current buggy state you find yourself in. If anything, a stack trace isn't comprehensive enough, ideally it would include all known/named…

To illustrate my point: If I implemented some network program which converses with a remote server in multiple steps in an language with exceptions and something fails I might get a stack trace and the message:

"Syntax error, expected token HTTP_METHOD but got 'B'"

In Go, with proper error handling I'd get a message like:

"Couldn't do flubber transfer: Unable to negotiate protocol: Sent supported protocols but remote responded with HTTP 400 "Bad Request": Missing required field 'version' in protocol definition"

As "error" is an interface, this message is only the tip of the iceberg: the error object itself may contain the address of the remote server, the protocol definitions that were sent, the response body that we got and any other relevant contextual payload.

This is all due to the error being treated in-context as opposed to just bubbling up.

Re: I’m joining the Go team at Google

#106

Post by javajavaj »

sdegutis wrote: post #57
gravypod wrote: post #43

Earlier quoted context omitted.

In general make good tooling and others will come. Look at Java/Eclipse

Can confirm. At work we're moving from Clojure 8 to Java 8 partially because IntelliJ is amazing and partially because Java 8 plus the right libraries is close enough to Clojure anyway, except much faster.

I'm not a Java developer, so I'm interested to know what the amazing parts of IntelliJ are. When I look at it it just looks like they ripped off the skin from Sublime Text and it has some debugging features that are readily available in other editors. I get pretty much everything on https://www.jetbrains.com/idea/whatsnew/ in my vim setup.

Re: I’m joining the Go team at Google

#107

Post by javajavaj »

gravypod wrote: post #77
sdegutis wrote: post #57

Earlier quoted context omitted.

Can confirm. At work we're moving from Clojure 8 to Java 8 partially because IntelliJ is amazing and partially because Java 8 plus the right libraries is close enough to Clojure anyway, except much faster.

I think as developers we are so used to pain that we forget how "easy" development can be if we allow people the right tools. If any language had the tooling and development Java did it would hold the market share. It's my opinion that if Rust makes a similar IDE experience (even just using Eclipse's platform) with every feature like code completion, formatting, debugging, the hole 9 yards and integrate Cargo into it…

That you need an IDE to make a language bearable speaks volumes to the design of the language.

Go is doing well because it realizes we can strip so much away, stay with the standard lib, and get real work done quickly.

That's not to say that Java, in particular the JVM, isn't an impressive piece of engineering, but more that we should be careful when we choose our tools so as to not overly complicate things.

Re: I’m joining the Go team at Google

#108

Post by aninhumer »

thwd wrote: post #104
pmarreck wrote: post #89

Earlier quoted context omitted.

> That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it? I don't see how that follows. A stack trace (as initially cryptic as it seems) is a record of all the code that would have affected the current buggy state you find yourself in. If anything, a stack trace isn't comprehensive enough, ideally it would include all known/named…

To illustrate my point: If I implemented some network program which converses with a remote server in multiple steps in an language with exceptions and something fails I might get a stack trace and the message: "Syntax error, expected token HTTP_METHOD but got 'B'" In Go, with proper error handling I'd get a message like: "Couldn't do flubber transfer: Unable to negotiate protocol: Sent supported protocols but remote…

>In Go, with proper error handling

Well yeah, if you handle errors properly, you get better results than if you don't.

The point is that with exceptions, it fails loudly and you get the cryptic message even if you forget, whereas with Go, if you forget to handle an error, you just get weird behaviour and corrupt data.

And if you want more helpful error messages, you can catch the exceptions and report the context just as easily as you can in Go.

Re: I’m joining the Go team at Google

#109

Post by the_duke »

wyattjoh wrote: post #92
the_duke wrote: post #37

Earlier quoted context omitted.

My main iusses: -) A proper package manager. (no, go get is not enough. They have realized this and have a team coming up with a draft for an official one) -) Well written, well maintained libraries that do proper releases. There are very few of those out there. Might get better with an offical package manager and ideally package repository a la npm/crates.io -) Generics. This will help the previous point also. Often…

> Generics I was concerned by this at first as well, but after using Go full time for the past two years, I've never found a need/use for them. Go doesn't lean towards strict OO principles, where I feel that most of the Generics uses are applied (Arrays, sorting, etc.). Not everyone's opinion, just my two cents.

You only have "generic" functionality for built in types though. Arrays. (In a certain way maps and channels).

That's fine if you only use those, but it makes it impossible to write generic functions for much else. See my comment about lack of libraries. I did miss them a lot.

Not when writing your one off app or program, but for libraries.

And you end up having to implement a lot yourself that's for free in other languages.

Re: I’m joining the Go team at Google

#110

Post by javajavaj »

pmarreck wrote: post #63
thwd wrote: post #53

Earlier quoted context omitted.

How does Go completely ignore run-time errors? For all I know it forces you to deal with them by treating them as values instead of exceptions.

How does treating them as values force you to deal with them (except on principle)? Does the language force you to check the return value of every line of code? And the checking would only encompass expected errors, not unexpected ones, no? The unexpected ones (read: bugs) would simply be swallowed up and the actual problem would finally turn up far away in some other stack scope, no?

Dave Cheney gave a talk about error handling in Go that sheds some light on how the Go community thinks about errors:

https://www.youtube.com/watch?v=lsBF58Q-DnY

Post reply on HN