Re:A Proposal for Package Versioning in Go
by mseepgood on Tuesday March 27, 2018 @04:32AM
(#16686442)
> doesn’t count as proving its value over 40 years
The Go designers used CSP over the course of many decades via Newsqueak, Alef, Limbo and Plan 9 C's libthread.
Re:A Proposal for Package Versioning in Go
by kasey_junk on Tuesday March 27, 2018 @07:01AM
(#16687112)
As only a go user & not a contributer, that describes more the paradigm I’ve observed for how golang chooses the features to add.
Did the principles enjoy a feature while using it on Plan 9? Likely to be included. A feature having broad industry or academic backing, or a long history? Immaterial.
Newsqueak, Alef, Limbo and Plan 9 C's failed spectacularly in the market, nothing to brag about as proven technologies.
In fact, as nice as Go might be, if it had the AT&T Research Labs stamp instead of Google's, it would been just as successful.
Re:A Proposal for Package Versioning in Go
by weberc2 on Tuesday March 27, 2018 @08:48AM
(#16687753)
> Combine those 2 facts & I think it’s fair to say golang is willing to base things (central ones even) on untried ideas, which directly contradicts your stated position
It absolutely doesn't contradict my stated position. I was clear about that in my previous post.
CSP inspired Go's features (in that sense alone it is "the basis for Go's concurrency" as alluded to by the Go FAQ) , but as I mentioned, it's not integral to Go in any way, and very few programs are modeled in CSP fashion.
Combine those 2 facts & I think it’s fair to say golang is willing to base things (central ones even) on untried ideas, which directly contradicts your stated position which was precisely that no dependency management scheme lives up to the precedent of the other accepted features of the language.
This is trivially proven incorrect via looking at other language dependency management schemes that have much more broadly proven their worth.