10 ms·

Dependency graphs of Go web frameworks

114 points by markkit 10y ago

epse 10y ago
What's up with Revel? That's crazy!
- breakingcups 10y ago
  Syscall package for fsnotify. It's not that weird.
  - sethammons 10y ago
    Thinking of fsnotify, know that it is configured to only be able to handle a given amount of notifications at a time. I ran into an issue where the number of monitored files exceeded that, and it silently ignored new files that were being created. Learned the hard way: check your OS for how to configure it and make sure you operate within its bounds. Or, said a different way, know your tools before you rely on them.
weitzj 10y ago
That's really great! I went to 'ThoughtWorks On The Beach' in Cologne, Germany, and there was this really nice idea to just print a dependency graph of your project to see if you can still grasp it or if it is getting out of hand.
- karma_vaccum123 10y ago
  Why is this even a concern? We have tools to walk that graph for us, they're called compilers and linkers. A small codebase can be buggy too. If you have success with a toolkit and it has good testing and community support, don't walk away because the graph looks weird. Take all those frameworks and inline them directly into your main package...now your graph collapses....are you better off?
  - reitanqild 10y ago
    Agree. As long as your dependencies are good so you don't need to open the hood then don't worry about it. I just accept it: I'm not an artist or an F1 driver, elegance and unparalleled performance in the code shouldn't be my concern as long as it is solid and works. I'm in the business of solving business problems, not at scale, not in realtime but on a shoestring budget.
    - eikenberry 10y ago
      Elegance is the quality in code that makes it easy to understand, easy to extend and easy to maintain. It is what makes code solid. Code is art.
  - quacker 10y ago
    > A small codebase can be buggy too. True, but in general, the more code, the more bugs. Now there are a number of qualifications to that statement: - More dependencies doesn't necessarily mean more code. Each dependency could be small (and well tested). - "More code" doesn't necessarily imply a higher percentage of bugs per amount of code. - Having more dependencies doesn't necessarily mean I'm calling more functions or hitting more code paths. However, a larger codebase will tend to have more "pieces" of code that can interact, which will tend toward combinatorial growth in the number of ways to (mis)use those bits of code. If I have more dependencies, there are more pieces of code interacting and exponentially higher potential for bugs. So, while I listed out those qualifications, I don't believe they are the norm. On the other hand, if I need some functionality, then either I use a dependency the provides the functionality, or I implement whatever it is myself. In that case, I'm taking a bet that my code will be better tested and more correct than the library author's code. In most cases, I think I would lose that bet.
ajacksified 10y ago
Checks dependency graph in his isomorphic React web framework This is gonna take a while. Maybe I'll learn Go while my cluster processes the tree...
- merb 10y ago
  Guess that's impossible without Spark or Hadoop.
  - edem 10y ago
    Then try to analyze the dependencies of Hadoop.
EthanV2 10y ago
It would be interesting to see this kind of graph created for other languages like Python, Node.js, etc. to see how they all compare. It would be neat to visualise which language/framework has the worst case of dependency hell Edit: Spelling
- steveklabnik 10y ago
  Two months ago, someone made one for Servo, in Rust: https://dirkjan.ochtman.nl/files/servo-graph.svg https://dirkjan.ochtman.nl/files/servo-graph.svg https://crates.io/crates/cargo-graph https://crates.io/crates/cargo-graph can be used to produce them easily. Rust is somewhere between Ruby and Node here: leaning towards small modules (one of my crates is in this graph, and it exports four functions), but not to the same level. > It would be neat to visualise which language/framework has > the worst case of dependency hell So, one thing I've come to realize is that different people have different opinions on what "dependency hell" even means. If you have a lot of dependencies, but your tooling reliably makes it easy to get them, build them, and upgrade them, is that hell?
  - merb 10y ago
    > but your tooling reliably makes it easy to get them, build them, and upgrade them, is that hell? Dependencies are never free. If you have a bunch of dependencies and not have too much resources it's still hell. Managing dependencies is not hard because of the tooling. It's hard because a dependency upgrade could cause pain, or the current version is buggy but the fix inside the upgrade works, but there will be another bug and so on.
    - steveklabnik 10y ago
      Right, this is what I mean: different people mean different things by "dependency hell". Difficulty of upgrading is certainly a possible meaning, but it's not a unified term.
      - merb 10y ago
zalmoxes 10y ago
r/golang discussion: https://www.reddit.com/r/golang/comments/50uni1/dependency_graphs_of_go_web_frameworks/ https://www.reddit.com/r/golang/comments/50uni1/dependency_g... Also relevant: https://talks.godoc.org/github.com/broady/talks/web-frameworks-gophercon.slide#1 https://talks.godoc.org/github.com/broady/talks/web-framewor...
mholt 10y ago
Just want to highlight a couple points of caution/clarification by groob from the reddit discussion[1]. In response to "What conclusion should I draw from this?": > I don't think the lesson here is to judge these frameworks. The graph alone is not an indication of quality, there are other things to consider. I think the lesson is that goviz is awesome and you should run it against your own projects, where you know the code well. Having tightly coupled code should be avoided. A dependency graph can pinpoint areas of your application that are in need of refactoring, as well as code that is either easy or hard to remove. In response to "what's the deal with net/http?" > Please don't draw the wrong conclusion from these graphs. Vault is a complex, production ready application which does much more than your typical CRUD app. I find the vault http code to be of good quality, and written in an idiomatic style. If I was learning how to wrote APIs in Go today, I'd look at the vault http package to learn from. [1]: https://www.reddit.com/r/golang/comments/50uni1/dependency_graphs_of_go_web_frameworks/ https://www.reddit.com/r/golang/comments/50uni1/dependency_g...
inglor 10y ago
Could someone tell me what sort of useful information I can distill out of those graphs? I'm really not sure at the package level what conclusions we can draw outside of "many circular dependencies - bad". I don't think the graphs would be very difference in Node for example - but unless you're doing something like chunked code bundling I don't understand why this information is meaningful.
- karma_vaccum123 10y ago
  Go doesn't allow circular dependencies so rest easy.
Ciantic 10y ago
It would be interesting to see graph on different authors (or people with publishing and committing rights), to see what sort of attack vector we are seeing in here. E.g. Beego there seems to rely only on astaxie's own packages (and Go packages). That was my primary take away from NPM debacle, injecting malicious code on one repository from hundreds of authors of small packackges is risk, whereas it's not as big with few dependency authors.
petre 10y ago
Go and Node's problem is the dependency hell. Caddy, a simple HTTP 2 webserver, pulled N packages to build. There are Node packages depending on trivial things (remember left-pad?). Too much modularity and relying on others' work sucks. Go's problem is solved by static linking, and Node's by installing all the required libraries in the node_modules directory.
- justinsaccount 10y ago
  > Go and Node's problem is the dependency hell. Just these two languages? No other languages or systems have problems with dependencies? > Caddy, a simple HTTP 2 webserver Caddy is simple to use, but is not a "simple" server. This is a simple server: package main import "net/http" func main() { panic(http.ListenAndServe(":8080", http.FileServer(http.Dir("./")))) } > Too much modularity and relying on others' work sucks One of the things caddy implements is automatic ssl support by depending on a library that implements the acme protocol. This type of thing is not exactly simple or something you really want to be writing from scratch if you don't have to. The problem with node is that there is no such thing as a javascript standard library and javascript tooling is not great at dead code elimination. This results in many trivial libraries that each contain a single function. Once the tooling gets better at dead code elimination there should be fewer larger libraries.
vhost- 10y ago
No gorilla mux?

114 points by markkit 10y ago

epse 10y ago

What's up with Revel? That's crazy!

breakingcups 10y ago
Syscall package for fsnotify. It's not that weird.
- sethammons 10y ago
  Thinking of fsnotify, know that it is configured to only be able to handle a given amount of notifications at a time. I ran into an issue where the number of monitored files exceeded that, and it silently ignored new files that were being created. Learned the hard way: check your OS for how to configure it and make sure you operate within its bounds. Or, said a different way, know your tools before you rely on them.

weitzj 10y ago

That's really great! I went to 'ThoughtWorks On The Beach' in Cologne, Germany, and there was this really nice idea to just print a dependency graph of your project to see if you can still grasp it or if it is getting out of hand.

karma_vaccum123 10y ago
Why is this even a concern? We have tools to walk that graph for us, they're called compilers and linkers. A small codebase can be buggy too. If you have success with a toolkit and it has good testing and community support, don't walk away because the graph looks weird. Take all those frameworks and inline them directly into your main package...now your graph collapses....are you better off?
- reitanqild 10y ago
  Agree. As long as your dependencies are good so you don't need to open the hood then don't worry about it. I just accept it: I'm not an artist or an F1 driver, elegance and unparalleled performance in the code shouldn't be my concern as long as it is solid and works. I'm in the business of solving business problems, not at scale, not in realtime but on a shoestring budget.
  - eikenberry 10y ago
    Elegance is the quality in code that makes it easy to understand, easy to extend and easy to maintain. It is what makes code solid. Code is art.
- quacker 10y ago
  > A small codebase can be buggy too. True, but in general, the more code, the more bugs. Now there are a number of qualifications to that statement: - More dependencies doesn't necessarily mean more code. Each dependency could be small (and well tested). - "More code" doesn't necessarily imply a higher percentage of bugs per amount of code. - Having more dependencies doesn't necessarily mean I'm calling more functions or hitting more code paths. However, a larger codebase will tend to have more "pieces" of code that can interact, which will tend toward combinatorial growth in the number of ways to (mis)use those bits of code. If I have more dependencies, there are more pieces of code interacting and exponentially higher potential for bugs. So, while I listed out those qualifications, I don't believe they are the norm. On the other hand, if I need some functionality, then either I use a dependency the provides the functionality, or I implement whatever it is myself. In that case, I'm taking a bet that my code will be better tested and more correct than the library author's code. In most cases, I think I would lose that bet.

ajacksified 10y ago

Checks dependency graph in his isomorphic React web framework This is gonna take a while. Maybe I'll learn Go while my cluster processes the tree...

merb 10y ago
Guess that's impossible without Spark or Hadoop.
- edem 10y ago
  Then try to analyze the dependencies of Hadoop.

EthanV2 10y ago

It would be interesting to see this kind of graph created for other languages like Python, Node.js, etc. to see how they all compare. It would be neat to visualise which language/framework has the worst case of dependency hell Edit: Spelling

steveklabnik 10y ago
Two months ago, someone made one for Servo, in Rust: https://dirkjan.ochtman.nl/files/servo-graph.svg https://dirkjan.ochtman.nl/files/servo-graph.svg https://crates.io/crates/cargo-graph https://crates.io/crates/cargo-graph can be used to produce them easily. Rust is somewhere between Ruby and Node here: leaning towards small modules (one of my crates is in this graph, and it exports four functions), but not to the same level. > It would be neat to visualise which language/framework has > the worst case of dependency hell So, one thing I've come to realize is that different people have different opinions on what "dependency hell" even means. If you have a lot of dependencies, but your tooling reliably makes it easy to get them, build them, and upgrade them, is that hell?
- merb 10y ago
  > but your tooling reliably makes it easy to get them, build them, and upgrade them, is that hell? Dependencies are never free. If you have a bunch of dependencies and not have too much resources it's still hell. Managing dependencies is not hard because of the tooling. It's hard because a dependency upgrade could cause pain, or the current version is buggy but the fix inside the upgrade works, but there will be another bug and so on.
  - steveklabnik 10y ago
    Right, this is what I mean: different people mean different things by "dependency hell". Difficulty of upgrading is certainly a possible meaning, but it's not a unified term.
    - merb 10y ago

zalmoxes 10y ago

r/golang discussion: https://www.reddit.com/r/golang/comments/50uni1/dependency_graphs_of_go_web_frameworks/ https://www.reddit.com/r/golang/comments/50uni1/dependency_g... Also relevant: https://talks.godoc.org/github.com/broady/talks/web-frameworks-gophercon.slide#1 https://talks.godoc.org/github.com/broady/talks/web-framewor...

mholt 10y ago

Just want to highlight a couple points of caution/clarification by groob from the reddit discussion[1]. In response to "What conclusion should I draw from this?": > I don't think the lesson here is to judge these frameworks. The graph alone is not an indication of quality, there are other things to consider. I think the lesson is that goviz is awesome and you should run it against your own projects, where you know the code well. Having tightly coupled code should be avoided. A dependency graph can pinpoint areas of your application that are in need of refactoring, as well as code that is either easy or hard to remove. In response to "what's the deal with net/http?" > Please don't draw the wrong conclusion from these graphs. Vault is a complex, production ready application which does much more than your typical CRUD app. I find the vault http code to be of good quality, and written in an idiomatic style. If I was learning how to wrote APIs in Go today, I'd look at the vault http package to learn from. [1]: https://www.reddit.com/r/golang/comments/50uni1/dependency_graphs_of_go_web_frameworks/ https://www.reddit.com/r/golang/comments/50uni1/dependency_g...

inglor 10y ago

Could someone tell me what sort of useful information I can distill out of those graphs? I'm really not sure at the package level what conclusions we can draw outside of "many circular dependencies - bad". I don't think the graphs would be very difference in Node for example - but unless you're doing something like chunked code bundling I don't understand why this information is meaningful.

karma_vaccum123 10y ago
Go doesn't allow circular dependencies so rest easy.

Ciantic 10y ago

It would be interesting to see graph on different authors (or people with publishing and committing rights), to see what sort of attack vector we are seeing in here. E.g. Beego there seems to rely only on astaxie's own packages (and Go packages). That was my primary take away from NPM debacle, injecting malicious code on one repository from hundreds of authors of small packackges is risk, whereas it's not as big with few dependency authors.

petre 10y ago

Go and Node's problem is the dependency hell. Caddy, a simple HTTP 2 webserver, pulled N packages to build. There are Node packages depending on trivial things (remember left-pad?). Too much modularity and relying on others' work sucks. Go's problem is solved by static linking, and Node's by installing all the required libraries in the node_modules directory.

justinsaccount 10y ago
> Go and Node's problem is the dependency hell. Just these two languages? No other languages or systems have problems with dependencies? > Caddy, a simple HTTP 2 webserver Caddy is simple to use, but is not a "simple" server. This is a simple server: package main import "net/http" func main() { panic(http.ListenAndServe(":8080", http.FileServer(http.Dir("./")))) } > Too much modularity and relying on others' work sucks One of the things caddy implements is automatic ssl support by depending on a library that implements the acme protocol. This type of thing is not exactly simple or something you really want to be writing from scratch if you don't have to. The problem with node is that there is no such thing as a javascript standard library and javascript tooling is not great at dead code elimination. This results in many trivial libraries that each contain a single function. Once the tooling gets better at dead code elimination there should be fewer larger libraries.

vhost- 10y ago

No gorilla mux?