5 ms·

Go ecosystems seems to choose quality over quantity (fewer higher-quality libraries) over Rust. What seems to be causing this?

olalonde 3mo ago
I'd say ease of package management. You can see this with Python too.
- inigyou 3mo ago
  Package management is easier in Go than almost any other ecosystem, including Rust, Python and Javascript. And Go projects may have tens of package dependencies. Yet it's closer to a C++ project which has single-digit dependencies than a Javascript project which has tens of thousands.
  - olalonde 3mo ago
    Interesting. When I learned Go a while ago, it didn't have a package manager. You just pulled down master branches directly into your global GOPATH. So pulling in a dependency was a big decision and people naturally favored "batteries included" libraries. That probably still permeates the culture today.
    - inigyou 3mo ago
      That is the package manager. The package has a URL. You import the URL and you're done.
      - olalonde 3mo ago
        Back then there was no versioning. When you imported a URL, you had to hope that all your projects and transient dependencies happened to be compatible with whatever commit was currently sitting on the master branch. Because one update could silently break an unrelated project on your machine, adding a dependency was a bigger decision. That naturally led the ecosystem to favor fewer, larger libraries. PS: it looks like this issue was addressed in 2019 with the introduction of Go Modules.
whstl 3mo ago
Money dictates personal philosophies. Rust and Node have too many deps because you can't make a Patreon or Github Sponsors page for contributions to stdlib. Go is batteries-included because it was made by Google by people with a salary. The people writing "thousands of small packages are good" are the people making money from the clout of having made thousands of small packages.
- inigyou 3mo ago
  What is Python?
  - whstl 3mo ago
    It's probably both? Started famously as batteries-included, until people started realizing there's money in dependencies. I'm not a lot into Python, though. I still write a lot of it, but I don't really read or participate in its community.

olalonde 3mo ago

I'd say ease of package management. You can see this with Python too.

inigyou 3mo ago
Package management is easier in Go than almost any other ecosystem, including Rust, Python and Javascript. And Go projects may have tens of package dependencies. Yet it's closer to a C++ project which has single-digit dependencies than a Javascript project which has tens of thousands.
- olalonde 3mo ago
  Interesting. When I learned Go a while ago, it didn't have a package manager. You just pulled down master branches directly into your global GOPATH. So pulling in a dependency was a big decision and people naturally favored "batteries included" libraries. That probably still permeates the culture today.
  - inigyou 3mo ago
    That is the package manager. The package has a URL. You import the URL and you're done.
    - olalonde 3mo ago
      Back then there was no versioning. When you imported a URL, you had to hope that all your projects and transient dependencies happened to be compatible with whatever commit was currently sitting on the master branch. Because one update could silently break an unrelated project on your machine, adding a dependency was a bigger decision. That naturally led the ecosystem to favor fewer, larger libraries. PS: it looks like this issue was addressed in 2019 with the introduction of Go Modules.

whstl 3mo ago

Money dictates personal philosophies. Rust and Node have too many deps because you can't make a Patreon or Github Sponsors page for contributions to stdlib. Go is batteries-included because it was made by Google by people with a salary. The people writing "thousands of small packages are good" are the people making money from the clout of having made thousands of small packages.

inigyou 3mo ago
What is Python?
- whstl 3mo ago
  It's probably both? Started famously as batteries-included, until people started realizing there's money in dependencies. I'm not a lot into Python, though. I still write a lot of it, but I don't really read or participate in its community.