Go doesn’t “do” that.
Using GitHub HEAD is one of many ways it can be used. It’s not a very popular approach. People with important projects that often use other ways, such as vendoring via a tool like dep.
3,365 karma · joined November 8, 2012
https://dmitri.shuralyov.com/about
Using GitHub HEAD is one of many ways it can be used. It’s not a very popular approach. People with important projects that often use other ways, such as vendoring via a tool like dep.
If the latter, how can you still implement the equalizer?
For a moment, I thought the 404 was intentional and this was supposed to be some sort of satire.
[1] http://www.antigrain.com/research/font_rasterization/index.h...
That said, I think it’s nice to be able to reflect the same attack vector upon the attackers to make the attack less efficient and hopefully less attractive.
[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...
I'm really fond of how Google does versioning in their internal codebase (from the public information about it that I know). They have a monorepo containing a single version of every library. When updating something, you're supposed to take into account all the places it's being used, and avoid breakages. Tests and tooling play an important role in making it possible.
I really want something like that for the open-source world, instead of having to deal with maintaining multiple versions, and dealing with the complexity of interactions between the all the permutations of different versions.
[/naive wish mode]
I’m aware, thanks. I tested in both anyway just to have more data.
This is how you can sort slices of arbitrary types in Go:
https://play.golang.org/p/VHJW9lVY9b
I’m not sure about you, but it feels very reasonable to me. It’s not anywhere near the top of my list of pains that I feel when working with Go everyday.
You can also link to #readme, which is a generic tag at the very top of the README and is guaranteed to exist in every github repo. E.g.:
E.g., look at https://github.com/camlistore/go4. Unless your monitor height is 1600 px and you're using 90% browser zoom, you might not even see the README until you scroll down.
You talk about giving the developer tools, but those tools can be augmentations on top of the basic building block that is the language. That way, anyone can build tools for their needs, without complicating the lives of others. No need to build all the tools into the language, that's very constraining.
Basically, I feel that completely removing the physical map is okay until you've picked a target. Then, having to click on it to be able to see what the route looks like (which streets to take, etc.) is higher friction than I'd like. Instead, imagine if hovering would give you a route overlay, and as you hover your mouse over multiple places you're considering, you're already aware of the physical directions as well.
Having to click back and forth feels quite constraining.
This is simply feedback on a way I think it could be improved further, not to take away from how good it already is.
The app will continue to work as long as it's supported by its developer and Apple doesn't forcibly remove it. If the developer no longer supports it, it's just a matter of time before it'll stop working.
It tells you exactly what it does in one sentence, and that sentence is the only one on the page. Despite that, it's probably not as popular as the vague sites being complained about here.