>> ..., 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.
Alan Donovan and Brian Kernighan Answer Questions on Go
11–20 of 110 posts
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#12>> ..., 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.
Yet still, Kernighan said what he said.
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#13> 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.
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> 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.
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> 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.
try {
foo();
} catch (Exception e) {
;
}
?Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#16> 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.
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#17The 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?
https://channel9.msdn.com/Events/Visual-Studio/Connect-event...
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#18> 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.
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#19Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#20I 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 :)