Alan Donovan and Brian Kernighan Answer Questions on Go
features.slashdot.org
Alan Donovan and Brian Kernighan Answer Questions on Go
1–10 of 110 posts
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#2I 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 :)
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#3The 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.
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#4I 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 libraries.
With Go's removal of version numbers, they haven't removed any of the complexity of resolving incompatibilities, they've just hidden the fact that there is one. I would have much preferred a strategy of maintaining version numbers, and resolving them via "either you specify what version you want pulled in, or we'll build with the most recent and throw a warning".
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#5I 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 :)
No, it doesn't really make much sense.
The diamond dependency problem only happens when two indirect dependencies are identical but on different versions and that these two versions are incompatible. That's two big if's. 99% of the time, it's not a problem.
Notice first that this is a pretty rare problem since libraries tend to be backward compatible these days. And if you happen to come across a bad behaved one, you simply exclude the one you don't want from the graph, problem solved.
This problem has been fixed in Maven for almost ten years now, the only reason why you would not implement this crucial feature in a version manager is laziness.
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#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()
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#7>> ..., 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 and cons. I'm literally programming Go right now. But "extreme abstraction"... you need more than "perhaps" to qualify that.
Or was that his point and did I just completely miss the joke? Actually, that's probably it.
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#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.
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#9The 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?
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#10I 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…
There are fixes for the diamond dependency problem out there, it's not like this is how to build a warp drive. For instance UNIXes have had symbol versioning since forever, they have RTLD_DEEPBIND in glibc, etc. Java is currently noodling around this problem with Jigsaw (though there's already a solution in OSGi) and it looks like for now they'll punt on solving it themselves, but provide the APIs needed for a simple container to solve it instead.
It's fine to not ship a solution in version one. But to use it as a reason to not have version numbers at all seems like heading in the wrong direction (backwards).