2 ms·

Did Java get lucky? I thought it was out with maven and in with gradle--though it's been several years since I've been in that world. It's just kind of awkwar

Did Java get lucky? I thought it was out with maven and in with gradle--though it's been several years since I've been in that world. It's just kind of awkward how they all do the same thing in slightly different ways. But not meaningfully different. They all have some kind of lock file, and they all have some kind of cache that you have to handle specially if you don't want to download the universe in CI, and they all let you specify version restrictions but each uses different files to store these things, terminology to describe them, and uses a different configuration language for you to express them. Learning languanges would be so much fun if I didn't have to learn a new package manager each time.

cogman10 3y ago
The important thing that happened for Java is the centralized repository. Gradle and maven both use the maven repository standard. So you can publish a new package and either system can pull it in. This isn't as true if you talk about plugins to the build systems so it's not as if java is unscathed. However, I'd say it's a lot better situation than what exists for C/C++ ATM.
- __MatrixMan__ 3y ago
  I'll agree that having strong consensus about the map: (Package name, version number) -> (cryptographic hash of package bits) Both is, and ought to be, table stakes for modern language ecosystems. But when it comes to tooling for hosting, fetching, installing, and contributing re: those maps, there's no reason to have each separate language community build an overlapping set of tools that solves those problems. I understand that when you have a new language, building all of that tooling is probably a fun way to flex it, but it's a bigger problem than most language communities really have the interest in to solve properly. So it ends up being a hack job every time. I'd argue that the only reason Java doesn't feel like a hack job re: packaging is that they've (wisely) solved a smaller problem. I can use pypi to install a python package with Java dependencies, but I can't (so far as I know) use maven to install a java library with python dependencies. Better would be to have some lightweight standard for mapping package names to hashes, and then decouple the hosting/trustworthyness indicating/installing/packaging concerns such that language designers don't have to worry so much about those things since they're not really language specific problems.

cogman10 3y ago

The important thing that happened for Java is the centralized repository. Gradle and maven both use the maven repository standard. So you can publish a new package and either system can pull it in. This isn't as true if you talk about plugins to the build systems so it's not as if java is unscathed. However, I'd say it's a lot better situation than what exists for C/C++ ATM.

__MatrixMan__ 3y ago
I'll agree that having strong consensus about the map: (Package name, version number) -> (cryptographic hash of package bits) Both is, and ought to be, table stakes for modern language ecosystems. But when it comes to tooling for hosting, fetching, installing, and contributing re: those maps, there's no reason to have each separate language community build an overlapping set of tools that solves those problems. I understand that when you have a new language, building all of that tooling is probably a fun way to flex it, but it's a bigger problem than most language communities really have the interest in to solve properly. So it ends up being a hack job every time. I'd argue that the only reason Java doesn't feel like a hack job re: packaging is that they've (wisely) solved a smaller problem. I can use pypi to install a python package with Java dependencies, but I can't (so far as I know) use maven to install a java library with python dependencies. Better would be to have some lightweight standard for mapping package names to hashes, and then decouple the hosting/trustworthyness indicating/installing/packaging concerns such that language designers don't have to worry so much about those things since they're not really language specific problems.