-
I hope the prototype gets a better, more searchable name. So far, Go has done a great job of being terrible for Googling. Name of the most popular web toolkit? Gorilla. For that reason, any time I refer to Go, I instead make a point to call it Golang.
-
FWIW: this isn’t a troll, but a legitimate concern from someone uses Go a lot.
go depmakes sense as a name, but I hope that the package itself on Github does not end up being nameddep. As one of the early adopters of Golang in production, it was a real problem in the early day to help get the other programmers I worked with to find the right repo when talking about them.-
We went back and forth over naming a fair bit internally, with the poor searchability of “dep” being a major driver. Ultimately, we couldn’t settle on an alternative name to the rather generic “dep,” so it’s sufficing for now.
On the plus side, assuming all goes well and the proposal is accepted, the planned trajectory for the tool is to integrate it seamlessly into the go toolchain - the name will go away. So, the name we use for now hopefully won’t matter too much.
-
-
-
I’m generally a bit suspicious of both humans and machines modifying the same files, although comment preserving parser writers is something I have seen become more popular lately.
For myself, I think it just adds complexity that is unnecessary and probably supporting a less-good decision made earlier.
-
-
Gofmt is a trivial example, go fix, and the various go refactoring tools like the ones from x/tools/refactor and grind are more complex examples. Go programmers are used to tools that modify user-writable code.
-
-
I agree on the whole – though upon seeing the headline, I was thinking it was probably because they were up to something goofier, like retroactively redefining what a comment is to include things with actual semantic significance (as they’ve done before). At least it isn’t more of that.
-
-
-
the-kenny
1 year ago
|
link
| on:
Go dep team laments lack of comment-preserving configuration parsers
The wort part for me here is the people who simply ignore all points made by the author, simply saying “Let’s just stick with JSON” or “I don’t think comments are necessary”. It feels like they just saw the headline and commented without reading the text.
-
I’m very glad to see Lockfiles in the design docs, but please consider alternatives to SemVer!
See Rich Hickey’s Spec-ulation talk for problems and my alternative scheme proposal for potential solutions.
In short, SemVer provides clients (limited) warning of breaking changes. Alternatively, consider a scheme that provides guidance for upgrading without breakage. Concretely, this would mean replacing
name@major.minor.revwithname@major-timestampand integrating deprecation warnings in togo vet.More verbosely, “breaking changes” should never happen in stable libraries without at least one major version’s worth of deprecation warnings for smooth migration. Adding new functionality should never cause breakage (Go has some unique problems here). SemVer formalizes bad library behavior as adds the unnecessary burden of fiddling with minor and revision numbers for every little change.
(one of the dep team members, here)
It’s very unlikely that we use something other than semver. I’ve spent plenty of time worshipping at the Altar of Hickey, but this is one case where I’d say his arguments don’t add a lot new to the discussion that we didn’t already know.
I’ve been hoping to find some time to write this up in greater detail, but it’s been a busy couple months. Simplest, shortest version I can conjure: Hickey, like most folks, seems to be expecting more out of fundamentally meaningless numbers than is really wise.
That’s a strange conclusion. He literally uses the words “not meaningful” when talking about version numbers. Half of his argument against SemVer is that it codifies non-useful information in to two thirds of its values.
The bulk of my proposal is that you simply replace minor and revision numbers with a timestamp. People who want to annoy their users with breaking changes can still bump the major version to do that. They just no longer have to fiddle with minor version numbers every time they make non-breaking changes.
Indeed, but acknowledging that doesn’t preclude expecting unhelpful things from them. But like I said - shortest possible explanation. Not necessarily one that makes prima facie sense :) Maybe I’ll have time for a fuller writeup, sometime.
It might be better. Certainly, that’s encoding less subjective information. The crucial question is whether the benefit is large enough to merit the social disruption that would come from displacing a widely used standard. That’s where I’m dubious.
To me, this is the only point worth discussing. I’m firmly in the camp that SemVer is actively harmful and trivially eliminated in any community that does not yet have a standardized package manager. What risks to you perceive?