4 ms·

I find the opposite to be true. If you casually add dependencies without understanding the dependency tree, you have a lot of problems waiting to happen. I pre

by hasenj 9y ago

I find the opposite to be true. If you casually add dependencies without understanding the dependency tree, you have a lot of problems waiting to happen. I prefer to be conservative about adding dependencies, and to always manually include them into the project.

stubish 9y ago
You can be conservative about adding dependencies and still end up with hundreds. Database driver, database utilities, gRPC framework, monitoring & metrics, CLI & configuration tools, /x/ packages such as crypto or net, logging, linters, libraries to talk to other moving parts like Rabbit or Vault, and then all the transitive dependencies like yaml, toml, websockets, and the various 'standard' helpers the authors of your dependencies use... all for a microservice and administrative tool... and one part of the larger project.
- hasenj 9y ago
  That's the definition of not being conservative about adding dependencies.
  - stubish 9y ago
    Oh, that could certainly be a conservative list. It depends on the requirements of the software. Drop any item on that list and you are either losing capabilities or have more software to implement yourself. And it is certainly tempting to reimplement things like Cobra, Viper, sqlx, prometheus end point, and everyone knows we should all implement our own crypto, but overall it ends up costing you time, and probably usability since your time is limited.
    - hasenj 9y ago
      That's definitely not conservative. Maybe you don't know what a conservative attitude about libraries is because you've never seen one. Your original comment: > You can be conservative about adding dependencies and still end up with hundreds No. Just no. If you have hundreds of dependencies, you are by definition not conservative about adding dependencies. > Database driver About the only legit thing on the list. > database utilities Not needed. > gRPC framework Not needed. > monitoring & metrics Not needed. > CLI & configuration tools NOT NEEDED! .. etc. > Drop any item on that list and you are either losing capabilities or have more software to implement yourself What are you losing by not using grpc? You can do a lot of things by just using the builtin rpc package or the encoding/gob with the http package. Being conservative about adding dependencies means resisting the urge to add them and figuring out a way to do without them. Every dependency you add is a potential point of failure and headaches. Just like every layer of abstraction you create. The cost for dependencies is huge, so every dependency has to justify itself by giving such a huge benefits that it's worth the cost. > Cobra Do you need a special library to handle command line arguments? How complex is your CLI interface? How many commands and sub commands do you have? 10? 20? It's trivial to handle that much manually using the builtin libraries. > Viper How hard is it to just read a json file using builtin libraries? How much do you lose by not using "Viper" or whatever? How many times will you have to read config files? One time when the app launches? Does not justify adding a dependency. > it is certainly tempting to reimplement things like Cobra, Viper, sqlx, prometheus end point, and everyone knows we should all implement our own crypto You don't even need to re-implement anything. Just do the simplest thing that works using the standard library. You know the standard library comes with a crypto package, right? The mindset you are presenting is the exact opposite of conservative. You are just grabbing every library that you think can save you 20 lines of code.
      - stubish 9y ago
        Yes, you can certainly be conservative by ignoring the requirements of the project and throwing away features. It will be a complete failure, because it doesn't do what it is supposed to, but it won't have any dependencies. I will stop instrumenting my projects because its not needed, no matter what operations says about our SLAs, and my gRPC endpoint will stop talking gRPC because its not needed, and it will be more reliable because clients can no longer talk to it by the expected protocol, and I'll ignore the usability requirements of the CLI and configuration management because specification documents and usability requirements be damned, and I'll implement by own helpers for the database code because NIH syndrome is fantastic, and I'm sure my employer will be happy for me to reinvent the wheel. Except I probably won't have an employer any more, because I seem to have stopped delivering the software they tasked me to.
        hasenj 9y ago
        No, it will not be a complete failure when you are careful about what you include. It will be a complete failure when things get so hairy with so many layers and failure points that you can't tell what's going on anymore.

by hasenj 9y ago

stubish 9y ago

You can be conservative about adding dependencies and still end up with hundreds. Database driver, database utilities, gRPC framework, monitoring & metrics, CLI & configuration tools, /x/ packages such as crypto or net, logging, linters, libraries to talk to other moving parts like Rabbit or Vault, and then all the transitive dependencies like yaml, toml, websockets, and the various 'standard' helpers the authors of your dependencies use... all for a microservice and administrative tool... and one part of the larger project.

hasenj 9y ago
That's the definition of not being conservative about adding dependencies.
- stubish 9y ago
  Oh, that could certainly be a conservative list. It depends on the requirements of the software. Drop any item on that list and you are either losing capabilities or have more software to implement yourself. And it is certainly tempting to reimplement things like Cobra, Viper, sqlx, prometheus end point, and everyone knows we should all implement our own crypto, but overall it ends up costing you time, and probably usability since your time is limited.
  - hasenj 9y ago
    That's definitely not conservative. Maybe you don't know what a conservative attitude about libraries is because you've never seen one. Your original comment: > You can be conservative about adding dependencies and still end up with hundreds No. Just no. If you have hundreds of dependencies, you are by definition not conservative about adding dependencies. > Database driver About the only legit thing on the list. > database utilities Not needed. > gRPC framework Not needed. > monitoring & metrics Not needed. > CLI & configuration tools NOT NEEDED! .. etc. > Drop any item on that list and you are either losing capabilities or have more software to implement yourself What are you losing by not using grpc? You can do a lot of things by just using the builtin rpc package or the encoding/gob with the http package. Being conservative about adding dependencies means resisting the urge to add them and figuring out a way to do without them. Every dependency you add is a potential point of failure and headaches. Just like every layer of abstraction you create. The cost for dependencies is huge, so every dependency has to justify itself by giving such a huge benefits that it's worth the cost. > Cobra Do you need a special library to handle command line arguments? How complex is your CLI interface? How many commands and sub commands do you have? 10? 20? It's trivial to handle that much manually using the builtin libraries. > Viper How hard is it to just read a json file using builtin libraries? How much do you lose by not using "Viper" or whatever? How many times will you have to read config files? One time when the app launches? Does not justify adding a dependency. > it is certainly tempting to reimplement things like Cobra, Viper, sqlx, prometheus end point, and everyone knows we should all implement our own crypto You don't even need to re-implement anything. Just do the simplest thing that works using the standard library. You know the standard library comes with a crypto package, right? The mindset you are presenting is the exact opposite of conservative. You are just grabbing every library that you think can save you 20 lines of code.
    - stubish 9y ago
      Yes, you can certainly be conservative by ignoring the requirements of the project and throwing away features. It will be a complete failure, because it doesn't do what it is supposed to, but it won't have any dependencies. I will stop instrumenting my projects because its not needed, no matter what operations says about our SLAs, and my gRPC endpoint will stop talking gRPC because its not needed, and it will be more reliable because clients can no longer talk to it by the expected protocol, and I'll ignore the usability requirements of the CLI and configuration management because specification documents and usability requirements be damned, and I'll implement by own helpers for the database code because NIH syndrome is fantastic, and I'm sure my employer will be happy for me to reinvent the wheel. Except I probably won't have an employer any more, because I seem to have stopped delivering the software they tasked me to.
      - hasenj 9y ago
        No, it will not be a complete failure when you are careful about what you include. It will be a complete failure when things get so hairy with so many layers and failure points that you can't tell what's going on anymore.