4 ms·
I disagree on Go. Go is well designed and takes upgrading into consideration. Upgrades very rarely break anything. You should just be able to recompile that
by jweir 9y ago
I disagree on Go.
Go is well designed and takes upgrading into consideration. Upgrades very rarely break anything. You should just be able to recompile that 1.3 code on 1.8, etc.
- deleted 9y ago[deleted]
- bazfoo 9y agoI concur with the sentiment. The risk is still there for dependencies, but it helps that the community for the most part follows "a little copying is better than a little dependency" as an adage.
- kuschku 9y agoOn the other hand, dependency management in go in any sane way is such a byzantine task that it takes ages to get working, and even then it still doesn't. Given an empty set of environment variables, setting up a new go project with dependencies and all in a way that people cloning it later on can also use the dependencies in a single command, without vendoring dependencies, without building custom scripts, is impossible.
- bpicolo 9y agoIt's impossible with first party tools, but I've had a great experience with Glide. That said, go drives me up a wall. Using interface{} to muck with JSON and typecast every step of the way is just my nightmare. It's inelegant in every way
- sethammons 9y agoType cast every step of the way? Methinks you are either doing something wrong or dealing with unstructured json.
- deleted 9y ago[deleted]
- bpicolo 9y agoThe pain of dealing with unstructured json/mapping types is exactly what I'm referring to. :) That said, I don't think the language as a whole lends itself towards elegance - that's pretty much the opposite of their goals. I don't agree that their model for simplicity is the only (or best) model for simplicity is all.