5 ms·

BYOD combined with "we don't need a package manager" sounds like a particularly bad combination. I understand Rust's "small stdlib but great package ecosystem",

BYOD combined with "we don't need a package manager" sounds like a particularly bad combination. I understand Rust's "small stdlib but great package ecosystem", but whats the appeal of "anemic stdlib plus no package ecosystem"? Maybe I would come up with something like this if I only ever worked on Linux software using C, but outside those niches these choices seem weird.

orthoxerox 5y ago
> but whats the appeal of "anemic stdlib plus no package ecosystem"? You can declare your language feature complete sooner
capableweb 5y ago
Correct me if I'm wrong, but Hare doesn't say "we need no package manager" but instead "we don't need a new package manager, use the one your OS provides", at least from how I understand it.
- mumblemumble 5y ago
  That strikes me as another C-ism that didn't deserve to be carried forward into a 21st century language. There's a reason we call it "dependency hell" and not "happy fun fussing with dependency version conflicts among projects that are completely unrelated except that you happen to be using the same computer to work on them time."
  - steaminghams 5y ago
    The state of the art in package management could be considered Nix and Guix and those are both operating system level package managers and thats why they are better than npm or pypi or cargo, as the aforementioned language specific package managers _dont_ handle dependency hell as native dependencies exist. they all have the same problem as 'they work on my computer' and also encourage this ecosystem of thousands of micropackages, which in a thread so focused on security seems a little ironic given there is no way to guarantee all of those dependencies are made by good actors without a lot of vetting that just is not happening.
    - duped 5y ago
      I've never had a "works on my machine" bug when dependencies are managed per project. The only time I have ever had them is with global/os-level dependencies. And I've used cargo/npm a lot in the last few years.
    - mumblemumble 5y ago
      I do agree on the micropackages. What I keep daydreaming of is a package manager that resolves and download packages, but doesn't automatically grab transitive dependencies. I don't even want it saying, "Hey, we need to grab these 15 other ones, too, is that OK?" I don't want to hide the pain of huge dependency graphs like that; I want to feel it acutely. Give me an error message saying, "Oops I couldn't add FancyPackage because it depends on X, Y and Z transitive dependencies," and send me on a fetch quest. And I want the whole community around the language I'm working in to feel it acutely like that. That way we're all in the same boat, and collectively incentivized not to create the problem in the first place.
  - wheelerof4te 5y ago
    That is on the library developers to settle out. Keeping your library API stable requires the mind of a genious and discipline of a monk. Now, keeping your language design stable and backward-compatible is a no brainer. Given that, it's possible to handle "dependency hells" simply by building from source. Hare is designed to be ultra conservative, so you don't have to worry about dependency hells. Features are in code, not builtin into the language. It is a win-win situation.
- xigoi 5y ago
  That's a great way to make a program work only on specific distros.
  - capableweb 5y ago
    Seems it fits Hare perfectly then, as one of the explicit goals of Hare is to only support non-proprietary OSes.
    - Koshkin 5y ago
      Why? Proprietary OS have package managers.
    - xigoi 5y ago
      How is being free related to having a specific package in the package manager?
    - mumblemumble 5y ago
      I'd guess it does the opposite? If I'm writing for a proprietary OS, that's probably Windows or OS X. Both of which give me a more stable target to aim at when it comes to what dependencies I can expect. If I'm writing for an open source OS, that's probably some flavor of Linux. But which flavor? And which package manager does it use? And do they support all the dependencies I need, in the versions I need? Without pulling non-standard package repositories into the mix? When open source software has difficulty working on proprietary OSes, I think it's usually not because of the package manager. More often it's because of something like a glibc dependency. At which point the domain of support isn't really "open source OSes", it's usually something more like "glibc-based linux distributions."
  - Koshkin 5y ago
    How so?
    - xigoi 5y ago
      Because you can't guarantee that every distro's package manager will have the packages you need.
ddevault 5y ago
I question the assertion that Hare's standard library is "anemic"; it includes a pretty decent set of batteries for many use-cases: https://docs.harelang.org https://docs.harelang.org Many Hare programs will not need to have dependencies at all. We encourage a more conservative approach to dependencies than is common in many modern languages such as Cargo, PyPI, npm, Go, etc. Even dependency-heavy Hare projects will not have hundreds of dependencies, but maybe dozens at most. Think more C, not Node. https://harelang.org/distributions/ https://harelang.org/distributions/
- nicoburns 5y ago
  That does look like a decent collection of functionality, but a HashMap as mentioned in the submission seems like a pretty glaring omission. I can't remember the last time I wrote a program that didn't use a Map. Even dynamic languages that tend to be quite light on types almost universally include a map type. I can definitely see the problems with the Node "explosion of modules" approach, but if we're looking at fixing issues with C then IMO "everyone implementing their own data structures and not always with the care and attention they deserve" is right up there with things like lack of proper arrays/strings and poor null handling. It seems like it ought to be possible to find a middle ground where dependencies are easy to find, install, update and integrate with a standardised build system, but where there is a cultural norm of being conscious of dependency size and not using micro-dependencies
  - ddevault 5y ago
    Take a look at this comment where I explained why a first-class hash map is not a good fit for Hare: https://news.ycombinator.com/item?id=31258759 https://news.ycombinator.com/item?id=31258759
CyberRabbi 5y ago
Package dependency resolution is fundamentally impossible to do efficiently and often broken (for legacy reasons) in specific implementations. Programmers are terrible at semantic versioning. Community package repositories are security nightmares. Under those conditions not including a package manager seems like a reasonable decision.

orthoxerox 5y ago

> but whats the appeal of "anemic stdlib plus no package ecosystem"? You can declare your language feature complete sooner

capableweb 5y ago

Correct me if I'm wrong, but Hare doesn't say "we need no package manager" but instead "we don't need a new package manager, use the one your OS provides", at least from how I understand it.

mumblemumble 5y ago
That strikes me as another C-ism that didn't deserve to be carried forward into a 21st century language. There's a reason we call it "dependency hell" and not "happy fun fussing with dependency version conflicts among projects that are completely unrelated except that you happen to be using the same computer to work on them time."
- steaminghams 5y ago
  The state of the art in package management could be considered Nix and Guix and those are both operating system level package managers and thats why they are better than npm or pypi or cargo, as the aforementioned language specific package managers _dont_ handle dependency hell as native dependencies exist. they all have the same problem as 'they work on my computer' and also encourage this ecosystem of thousands of micropackages, which in a thread so focused on security seems a little ironic given there is no way to guarantee all of those dependencies are made by good actors without a lot of vetting that just is not happening.
  - duped 5y ago
    I've never had a "works on my machine" bug when dependencies are managed per project. The only time I have ever had them is with global/os-level dependencies. And I've used cargo/npm a lot in the last few years.
  - mumblemumble 5y ago
    I do agree on the micropackages. What I keep daydreaming of is a package manager that resolves and download packages, but doesn't automatically grab transitive dependencies. I don't even want it saying, "Hey, we need to grab these 15 other ones, too, is that OK?" I don't want to hide the pain of huge dependency graphs like that; I want to feel it acutely. Give me an error message saying, "Oops I couldn't add FancyPackage because it depends on X, Y and Z transitive dependencies," and send me on a fetch quest. And I want the whole community around the language I'm working in to feel it acutely like that. That way we're all in the same boat, and collectively incentivized not to create the problem in the first place.
- wheelerof4te 5y ago
  That is on the library developers to settle out. Keeping your library API stable requires the mind of a genious and discipline of a monk. Now, keeping your language design stable and backward-compatible is a no brainer. Given that, it's possible to handle "dependency hells" simply by building from source. Hare is designed to be ultra conservative, so you don't have to worry about dependency hells. Features are in code, not builtin into the language. It is a win-win situation.
xigoi 5y ago
That's a great way to make a program work only on specific distros.
- capableweb 5y ago
  Seems it fits Hare perfectly then, as one of the explicit goals of Hare is to only support non-proprietary OSes.
  - Koshkin 5y ago
    Why? Proprietary OS have package managers.
  - xigoi 5y ago
    How is being free related to having a specific package in the package manager?
  - mumblemumble 5y ago
    I'd guess it does the opposite? If I'm writing for a proprietary OS, that's probably Windows or OS X. Both of which give me a more stable target to aim at when it comes to what dependencies I can expect. If I'm writing for an open source OS, that's probably some flavor of Linux. But which flavor? And which package manager does it use? And do they support all the dependencies I need, in the versions I need? Without pulling non-standard package repositories into the mix? When open source software has difficulty working on proprietary OSes, I think it's usually not because of the package manager. More often it's because of something like a glibc dependency. At which point the domain of support isn't really "open source OSes", it's usually something more like "glibc-based linux distributions."
- Koshkin 5y ago
  How so?
  - xigoi 5y ago
    Because you can't guarantee that every distro's package manager will have the packages you need.

ddevault 5y ago

I question the assertion that Hare's standard library is "anemic"; it includes a pretty decent set of batteries for many use-cases: https://docs.harelang.org https://docs.harelang.org Many Hare programs will not need to have dependencies at all. We encourage a more conservative approach to dependencies than is common in many modern languages such as Cargo, PyPI, npm, Go, etc. Even dependency-heavy Hare projects will not have hundreds of dependencies, but maybe dozens at most. Think more C, not Node. https://harelang.org/distributions/ https://harelang.org/distributions/

nicoburns 5y ago
That does look like a decent collection of functionality, but a HashMap as mentioned in the submission seems like a pretty glaring omission. I can't remember the last time I wrote a program that didn't use a Map. Even dynamic languages that tend to be quite light on types almost universally include a map type. I can definitely see the problems with the Node "explosion of modules" approach, but if we're looking at fixing issues with C then IMO "everyone implementing their own data structures and not always with the care and attention they deserve" is right up there with things like lack of proper arrays/strings and poor null handling. It seems like it ought to be possible to find a middle ground where dependencies are easy to find, install, update and integrate with a standardised build system, but where there is a cultural norm of being conscious of dependency size and not using micro-dependencies
- ddevault 5y ago
  Take a look at this comment where I explained why a first-class hash map is not a good fit for Hare: https://news.ycombinator.com/item?id=31258759 https://news.ycombinator.com/item?id=31258759

CyberRabbi 5y ago

Package dependency resolution is fundamentally impossible to do efficiently and often broken (for legacy reasons) in specific implementations. Programmers are terrible at semantic versioning. Community package repositories are security nightmares. Under those conditions not including a package manager seems like a reasonable decision.