Admittedly, the first time I encountered the posts I skimmed them and only absorbed a third or so of the technical points. If anyone is interested and willing to invest the time, Russ Cox’s blog posts on the design are very well-written and explain motivation and design in (gory) detail. It avoids a lot of the pain points in traditional package ecosystems, it adds its own new pain thank you for the succinct summary of Go’s design. Having worked in large Go projects, I don’t think it’s better. Other projects work around it, for instance kubernetes, at least at one time, I don’t know if they still do, pretends their X.Y version is 0.X.Y in the package manager to trick it into behaving more like a traditional package manager does. Of course, there’s no tooling to actually enforce this, so projects semi regularly break it, and when they do it creates awful problems that the Go tooling has no real ability to fix. It boils down to attempting to force that you never break compatibility, and two major versions of the same library can be imported and used independently, so you never have to do any real dependency solving. This narrows the dependency solver problem domain down significantly. If you want to break backwards compatibility the official Go approved way, is you rename yourself. Go has very minimal version constraints, it basically only supports >= and !=. Ĭan you provide details of Go’s design? Or at least a link to something that someone with no Go experience could read to understand what you’re referring to? Also, I don’t know what you mean by “linear version selection”, and I’m not at all sure what you believe to be “critical” as regards expressivity. It would make for a much more pleasant ecosystem - and much simpler packaging tools too. I’d love for Python to follow Go’s lead and start shedding much of the baggage of its current dependency management.
0 Comments
Leave a Reply. |