All: So I read Russ Cox post and specifically noted this:
"But once we understand the design space better and can narrow it down to the few key features that must be supported, it will help the Go ecosystem to remove the other features, to reduce expressiveness, to adopt enforced conventions that make Go code bases more uniform and easier to understand and make tooling easier to build." And here's Sam Boyer <https://sdboyer.io/blog/vgo-and-dep/>: "It [vgo] was created largely in isolation from the community’s work on dep, to the point where not only is there no shared code and at best moderate conceptual overlap, but a considerable amount of the insight and experience gleaned from dep as the “official experiment” is just discarded." I don't have an attachment to vgo or dep one way or another. Package management is complicated. I don't believe there's a "right" answer so much as balancing tradeoffs. Someone is going to be upset that you don't support their specific workflow. But there's been very little explanation to the community about why the things dep did at a high level were thrown out. I am curious to know what those are. Thanks, Joe -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
