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

Alan Donovan and Brian Kernighan Answer Questions on Go

features.slashdot.org

Post reply on HN
Print view View original

31–40 of 110 posts

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#31

Post by jerf »

Nexialist wrote: post #29
incepted wrote: post #6

> In general, Go strongly encourages being explicit about errors. That's completely incorrect: it's trivial (and common) to just ignore errors in Go: ok, _ := Foo() Checked exceptions don't let you get away with this kind of sloppy programming.

Although a lot of people are pointing out (correctly) that it's trivially easy to ignore a checked exception, it does at least do two things: 1. Signal to the calling programmer that some error condition can occur. For example having to catch SomethingNotFound tells them that it's possible that Something might not be found. 2. You just put in your coding standards that you must do something sensible inside of a catch…

I've got a blog post on deck that basically says that just as Joel on Software proposed that the vast bulk of the advantage of scripting languages in the 2000s was garbage collection, I propose that the big advancement in error handling lately is simply the idea that it ought to be stuck in the programmer's face, and the exact manner in which it does so isn't really very important.

By that standard, exceptions actually fit in between C-style obliviousness and explicit error returns. They do allow a certain amount of implicitness (does this code have no try/catch exception handlers because the programmer is deliberately invoking the default exception behavior, or is it because they didn't think about errors at all?), but you still can't ignore errors the way you can in C. And then with explicit error returns, you can't ignore them at all without leaving a trail of your decision to do so right there in the source code.

Checked exceptions tried to straddle the boundary, but I think I have to agree with the general consensus that they are a failed experiment. One of my "cut through the noise" metrics for language design decisions is "do any subsequent languages pick up the feature?". If a language as dominant as Java has a feature, but after 10-15 years no new languages are picking up the feature, that Means Something.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#32

Post by d_theorist »

lostcolony wrote: post #4
gamesbrainiac wrote: post #2

I never knew that the decision to not have versioning built into go was because of the diamond dependency problem. This makes a lot of sense now that I think about it. I wonder what alternatives to manually versioning things the go team is considering. Also, at the beginning the Go team wasn't all that enthusiastic about an IDE, but its great to see that Go will get an IntelliJ grade IDE soon, so that works for me :)

I really am not a fan of the lack of versioning, even with that explanation. Of course diamond dependencies are a problem. But they haven't actually fixed that problem; they've just declared a method for picking one of the two dependencies that is ill defined ("whichever one you happen to have pulled in first"). At least with versioning I get told that there's an incompatibility in the expectations between two librar…

I have never really thought about this problem before, but would it not be possible to:

1. Treat each version of a package as a separate package. If there are two versions required, they are both included.

2. At compile time transform package names to include the desired version number.

I may be completely misunderstanding or over-simplifying this problem.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#33

Post by AsyncAwait »

gamesbrainiac wrote: post #2

I never knew that the decision to not have versioning built into go was because of the diamond dependency problem. This makes a lot of sense now that I think about it. I wonder what alternatives to manually versioning things the go team is considering. Also, at the beginning the Go team wasn't all that enthusiastic about an IDE, but its great to see that Go will get an IntelliJ grade IDE soon, so that works for me :)

I'm not sure if the Intellij Go Plugin is going to be made into a separate IDE, but it's already available for their other IDEs as a plugin and they have a team improving it constantly. Notably, it also works with their open-source IDEA Community Edition.

https://github.com/go-lang-plugin-org/go-lang-idea-plugin

So far the best "Go IDE", I've used.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#34

Post by lostcolony »

d_theorist wrote: post #32
lostcolony wrote: post #4

Earlier quoted context omitted.

I really am not a fan of the lack of versioning, even with that explanation. Of course diamond dependencies are a problem. But they haven't actually fixed that problem; they've just declared a method for picking one of the two dependencies that is ill defined ("whichever one you happen to have pulled in first"). At least with versioning I get told that there's an incompatibility in the expectations between two librar…

I have never really thought about this problem before, but would it not be possible to: 1. Treat each version of a package as a separate package. If there are two versions required, they are both included. 2. At compile time transform package names to include the desired version number. I may be completely misunderstanding or over-simplifying this problem.

For some things, yes. But there are a lot of potentially tricksy issues in doing that.

Imagine a queueing library, for instance. You push something onto a queue created with library A, and then you want to read from library B (A and B are different version of the same library). Just about anything could happen (depending on how the library/language are implemented). You might get an error due to library B reading a data structure formatted for library A. Or you might get nothing back, because library B is checking for the queue in its own registry, while it exists in library A's. Etc.

If there is no library-dependent state between calls, or the calls are not being mixed between libraries, you can totally do that, though. A JSON serialization library can totally be supported in that manner, for instance. The queueing library example, if it's only being used to support other libraries or separate functionalities, such that you never have to push onto a queue in library A, and expect to be able to pop it off from a queue in library B, would work, too. But in that latter case, that's not something the library writer can guarantee, it's all about your own usage. So there's a lot of potential issues.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#35

Post by Retra »

ngrilly wrote: post #13
incepted wrote: post #6

> In general, Go strongly encourages being explicit about errors. That's completely incorrect: it's trivial (and common) to just ignore errors in Go: ok, _ := Foo() Checked exceptions don't let you get away with this kind of sloppy programming.

It's also trivial to "just ignore errors" in a language based on checked exceptions: try { ok = foo() } catch (Exception e) { // Do nothing } Checked exceptions don't save you from "this kind of sloppy programming".

And it'll happen frequently, because if you're just trying to test out `ok = foo()` and you're not sure if it'll work, then you've got to write four lines of awful boilerplate and go read an API reference just to get it to compile. Checked exceptions are supposed to encourage correctness, but there's no fudge room for playing around, so they are very not fun.

As an aside, I once tried using a crypto library to do something fairly simple (encrypt a file I'm writing to disk), and I had to handle a whole stack of exceptions that I had no clue how to handle. So what can you do? You should be able to write code that provides sensible default behavior, but checked exceptions make you work to just get that behavior, which is not how default behavior is supposed to work.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#36

Post by elcct »

incepted wrote: post #6

> In general, Go strongly encourages being explicit about errors. That's completely incorrect: it's trivial (and common) to just ignore errors in Go: ok, _ := Foo() Checked exceptions don't let you get away with this kind of sloppy programming.

I don't think it is common, unless you work with pretty bad code base. You simply don't ignore errors like that.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#37

Post by incepted »

howeyc wrote: post #14
incepted wrote: post #6

> In general, Go strongly encourages being explicit about errors. That's completely incorrect: it's trivial (and common) to just ignore errors in Go: ok, _ := Foo() Checked exceptions don't let you get away with this kind of sloppy programming.

> Checked exceptions don't let you get away with this kind of sloppy programming. They sure do. Just write your Java code without a try/catch block anywhere, or just have your catch do absolutely nothing. You can do it, trust me. Exceptions don't stop programmers from doing anything.

> Just write your Java code without a try/catch block anywhere

You can't. I don't think you understand how checked exceptions work.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#38

Post by incepted »

ngrilly wrote: post #13
incepted wrote: post #6

> In general, Go strongly encourages being explicit about errors. That's completely incorrect: it's trivial (and common) to just ignore errors in Go: ok, _ := Foo() Checked exceptions don't let you get away with this kind of sloppy programming.

It's also trivial to "just ignore errors" in a language based on checked exceptions: try { ok = foo() } catch (Exception e) { // Do nothing } Checked exceptions don't save you from "this kind of sloppy programming".

But you have to write the `catch` (or a `throws`). That's the point.

Now if you choose to handle this stupidly, that's entirely your fault, but at least the compiler did its jobs by forcing you to think about the error case.

In Go, the compiler doesn't enforce anything.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#39

Post by pkaye »

voidlogic wrote: post #23
KyleBrandt wrote: post #3

The recently open sourced VSCode also has Go support now. Good first impression. The docs and type inference stuff are more convenient compared to the oracle plugin + GoSublime for sublime it seems.

From trying it out, what does this new support have that LiteIDE does not?

I'm been using LideIDE for a while and it is pretty good. Only thing I've a problem with is configuring build tags. For portions of the code disabled by build tags, it doesn't let me search for variable and function declarations. I wish there was a way to toggle that. Another missing feature is "jump to line".

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#40

Post by ngrilly »

pjmlp wrote: post #17
ngrilly wrote: post #9

Earlier quoted context omitted.

I thought it was just syntax highlighting. Any link documenting VSCode's Go suppport?

There is a video of the presentation: https://channel9.msdn.com/Events/Visual-Studio/Connect-event...

Thanks for the link. Great demo!
Post reply on HN