Live data from Hacker News

Alan Donovan and Brian Kernighan Answer Questions on Go

features.slashdot.org

11–20 of 110 posts

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#11
post #8

>> ..., and extreme abstraction capabilities in high level languages like Common Lisp, ... > Go has everything you mention in both of your lists of desirable attributes (depending perhaps on what you mean by "extreme abstraction") "perhaps"? By whose definition would it ever even come close to "extreme abstraction"? All of us assembly programmers, maybe? Don't get me wrong, I use Go where it makes sense. It has pros…

You missed what Donovan said, which answered the question. Obviously PL-enthusiasts (give me all the shiny! all the time!) wont like the answer though.

[deleted]

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#12
post #8

>> ..., and extreme abstraction capabilities in high level languages like Common Lisp, ... > Go has everything you mention in both of your lists of desirable attributes (depending perhaps on what you mean by "extreme abstraction") "perhaps"? By whose definition would it ever even come close to "extreme abstraction"? All of us assembly programmers, maybe? Don't get me wrong, I use Go where it makes sense. It has pros…

You missed what Donovan said, which answered the question. Obviously PL-enthusiasts (give me all the shiny! all the time!) wont like the answer though.

Absolutely agree with what he said, and I agree it answers the question. And I agree with what you said, it's not a great answer for everybody, but it's an answer.

Yet still, Kernighan said what he said.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#13
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".

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#14
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.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#15
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.

You've never seen the Java "pattern" of

  try {
    foo();
  } catch (Exception e) {
    ;
  }

?

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#17
post #9

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.

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...

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#18
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.

This is not idiomatic Go code and in my experience not many people will do this. New Go programmers who ask for help with a piece of code that ignores the error are told immediately to check the error. And experienced Go programmers simply do not ignore the error.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#19
post #17
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...

Jump to 2:15, great to see!

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#20

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 :)

Everyone seems to overlook this, but Go has had LiteIDE for a very long time and it keeps getting better.
Post reply on HN