3 ms·

I also recommend avoiding unnecessary libs/frameworks for any code that you expect to run for a long time without change. I do this at work when writing small

by jakevn 9y ago

I also recommend avoiding unnecessary libs/frameworks for any code that you expect to run for a long time without change. I do this at work when writing small services in Go and it works out well. Some have been running for three years now without being touched yet there is no code rot and anyone can easily pick it up.

kstenerud 9y ago
Absolutely this. Even the base dev environment is often an exercise in madness. I loathe every new iOS version because Xcode will break my code in new and interesting ways, requiring me to recheck every single library I've developed to make sure they still compile (often they don't) and run (almost always they don't). And then, once I've got that headache handled, I update the version number, type 'pod lib lint', and watch all the new and interesting ways that cocoapods has broken things since I last used it. Every 3rd party component you rely on is something that WILL break as soon as you need to rebuild your project.
- oblio 9y ago
  Not necessarily. People make fun of Java, but any half decent Java place, especially the ones using Maven, won't have this problem. Maven is quite verbose and it forces you to pin a lot of things down. Where it doesn't outright force you, the general practices are to pin them regardless. All the dependencies are in the same immutable Maven repo (or your own proxy/cache), all the build tool extensions/plugins/etc. are there as well. Java is generally very good at backwards compatibility, as is Maven itself. So you can come back a few years later and do a : mvn clean install and things will work. Of course, humans are fallible and things could still break due to various factors, but in this sense the ecosystem helps you and either offers stability already bundled it or guides you towards achieving it. The downside: Maven is boring. Developers don't like boring :)
  - zamber 9y ago
    In JS world we got a package lockfile fairly recently. Locking your own package.json version wasn't enough because packages have deps too. Beforehand running npm install on newly checked out repos was a gamble, especially given that we have packages for every minute "feature" like leftpad (which is a horror story of its own).
segmondy 9y ago
I absolute agree. The only reason I didn't really mention this is that I don't want to push for the "not invented here" behavior. Once in a while, there are times when some library/frameworks are worth it. More often than not that's not the case.
oblio 9y ago
The thing I don't like on this front for Go is the whole "dependencies on Github" thing. If the dependencies are not vendored or pointing to the correct thing (tags, always tags!), 3 years from now your project might not build. I like the Maven approach of the immutable binary repo. One day a long, long time ago, I found a broken dependency from IBM uploaded on the Maven Central repo, I think. I sent the Maven Central repo maintainers a mail saying that the dependency was broken. They replied saying that they don't ever touch uploaded releases. At the time I was kind of pissed off cause it was a transitive dependency that was breaking stuff. I had to hack around it. But over the years I've come to appreciate that wisdom. Contrast: npm.
- jakevn 9y ago
  > The thing I don't like on this front for Go is the whole "dependencies on Github" thing. Agreed. I really dislike the GOPATH concept that the original tooling is built around, but I strictly make use of vendoring.

by jakevn 9y ago

kstenerud 9y ago

Absolutely this. Even the base dev environment is often an exercise in madness. I loathe every new iOS version because Xcode will break my code in new and interesting ways, requiring me to recheck every single library I've developed to make sure they still compile (often they don't) and run (almost always they don't). And then, once I've got that headache handled, I update the version number, type 'pod lib lint', and watch all the new and interesting ways that cocoapods has broken things since I last used it. Every 3rd party component you rely on is something that WILL break as soon as you need to rebuild your project.

oblio 9y ago
Not necessarily. People make fun of Java, but any half decent Java place, especially the ones using Maven, won't have this problem. Maven is quite verbose and it forces you to pin a lot of things down. Where it doesn't outright force you, the general practices are to pin them regardless. All the dependencies are in the same immutable Maven repo (or your own proxy/cache), all the build tool extensions/plugins/etc. are there as well. Java is generally very good at backwards compatibility, as is Maven itself. So you can come back a few years later and do a : mvn clean install and things will work. Of course, humans are fallible and things could still break due to various factors, but in this sense the ecosystem helps you and either offers stability already bundled it or guides you towards achieving it. The downside: Maven is boring. Developers don't like boring :)
- zamber 9y ago
  In JS world we got a package lockfile fairly recently. Locking your own package.json version wasn't enough because packages have deps too. Beforehand running npm install on newly checked out repos was a gamble, especially given that we have packages for every minute "feature" like leftpad (which is a horror story of its own).

segmondy 9y ago

I absolute agree. The only reason I didn't really mention this is that I don't want to push for the "not invented here" behavior. Once in a while, there are times when some library/frameworks are worth it. More often than not that's not the case.

oblio 9y ago

The thing I don't like on this front for Go is the whole "dependencies on Github" thing. If the dependencies are not vendored or pointing to the correct thing (tags, always tags!), 3 years from now your project might not build. I like the Maven approach of the immutable binary repo. One day a long, long time ago, I found a broken dependency from IBM uploaded on the Maven Central repo, I think. I sent the Maven Central repo maintainers a mail saying that the dependency was broken. They replied saying that they don't ever touch uploaded releases. At the time I was kind of pissed off cause it was a transitive dependency that was breaking stuff. I had to hack around it. But over the years I've come to appreciate that wisdom. Contrast: npm.

jakevn 9y ago
> The thing I don't like on this front for Go is the whole "dependencies on Github" thing. Agreed. I really dislike the GOPATH concept that the original tooling is built around, but I strictly make use of vendoring.