6 ms·

Everytime I see a language creating their own package system, all I can think of it how much we've missed here. The only exception is C/C++, where there is non

by malkia 3mo ago

Everytime I see a language creating their own package system, all I can think of it how much we've missed here. The only exception is C/C++, where there is none established that well, for good or bad. These choices may create later super-convoluted processes when you have to mix more than one language together. Packaging systems makes thing easy, but complicate further the line if another language needs to be used.

forrestthewoods 3mo ago
The world has yet to standardize on a good crossplatform polyglot build system. The only real such build systems are Buck and Bazel. But they have way too much baggage from their overlords. It’s a shame.
- himata4113 3mo ago
  build systems using llvm as the backend are getting there, but zig is making their own compiler too.
  - forrestthewoods 3mo ago
    compilers and build systems are and should be different. A good polyglot build system should support llvm and zig and python and literally any toolchain under the sun.
    - himata4113 3mo ago
      the problem is that you need a compiler capable of compiling said zig, python, rust. LLVM does that, you can compile something as untyped as javascript(with a lot of hacks) or as strict as rust.
      - forrestthewoods 3mo ago
        > the problem is that you need a compiler capable of compiling said zig, python, rust no! No you do not!! It’s perfectly totally fine to have multiple different compilers. Literally not a problem at all. That’s my point! Compilers and build systems are separate. It is perfectly fine for one build system to invoke multiple different compilers.
        himata4113 3mo ago
        cargo pretty much does that, but then you have to have to bundle all those compilers which becomes a fuckfest.
        forrestthewoods 3mo ago
        Ehh. Cargo has build.rs but calling that a polyglot build system is like calling bash scripts a polyglot build system. Buck and Bazel have the right architecture. Just need a version written fresh without all the baggage.
- arikrahman 3mo ago
  Zig is pretty good for my use case. It may not be fully pollyglot at a technical level, but I can use it for my embedded C use case, for Jank to export the .cpp to other platforms, and thereby Clojure.
afdbcreid 3mo ago
What do you think we've missed? Do you want one build systems for all languages? There are such systems (e.g. Bazel) and they're often used for multi-languages projects, but I think reality has proven that build systems with language-specific knowledge are much easier to navigate.
- __float 3mo ago
  I'm not sure how outlandish we're allowed to get here, but IMO we have a fundamental mismatch between application <> operating system <> CPU in terms of dependencies and trust. Fixing this is beyond any one tool, of course :)
small_model 3mo ago
C should have fixed its various issues and added a package manager (or blessed one), Zig is filling that gap.
- malkia 3mo ago
  No it's not. Not everybody uses Zig. Rust/Python/And others have also tried "fixing" it.
Panzerschrek 3mo ago
I think it's actually good that C++ has no standardized packaging system. This forces one to think carefully before introducing a dependency, since often such dependency have hidden costs, like security vulnerabilities. Since many critical systems are written in C++, it's too much risk to depend on dozens of easily-accessible third-party packages without properly auditing each of them.
- simonask 3mo ago
  I'm sorry, I have to address this take every time someone brings it up. The lack of a modern, ubiquitous, cross-platform packaging system is an absolutely terrible thing for C++. I've worked on many large projects in C++, and every single one of them contains a bespoke, buggy, undermaintained JSON parser, URL parser, configuration file parser, async framework, and so on. It used to be the case that almost every large C++ project started out by defining its own friggin' string type. Dependency anxiety is a variant of NIH syndrome, and it leads to much, much worse quality software in the average case. Most companies are not in the business of writing a bug-free async framework, and yet here we are. The cost of vetting your dependencies is much, much lower than writing and maintaining all these things from scratch.
  - Panzerschrek 3mo ago
    I didn't say one should not use thirdparty dependencies at all. They are sometimes useful. But they should be chosen carefully and ideally reviewed. And any updates should be done manually in order to prevent security chain attacks. Having a standardized package manager allows lowering the bar and bypassing careful thinking. It has also a cumulative effect - if one adds each dependency in its project one by one with proper audits, transitive dependencies may not be managed so carefully. And then we have cargo-style cancer with trivial projects having hundreds of dependent packages.
    - simonask 3mo ago
      I don't think masochism is a reliable or sound security strategy.
pjmlp 3mo ago
Conan and vcpkg are established enough.
lukasco 3mo ago
Cross platform building and packaging in C/C++ is such a hot mess. There's so many dimensions to unpack I don't even really know where to start. (I say this as the person who has been packaging GIMP for Mac for the last good number of years.) OK, here's a few (with a MacOS slant): - compilers (gcc, clang, and their many versions) - libc (and friends) compatibility (I can't say I even ever delved into this one, but it's bit me) - package manager (macports, homebrew) - building for backward compatibility; what's the earliest MacOS version to support (the package managers either like to build for the OS they are running on, or force you -- yes I'm looking at you homebrew) - dependency and dependency version management (love you pkgconfig) - build system for each package (cmake, autotools, meson, ...) - bundling everything into an application - turning that application into a Mac application - code signing and notarization - creating the DMG - debug symbols - crash detection and notification Like right now, libheif on 26 can't be built for 11 and it's not clear why (or maybe they just fixed it...but it's been weeks)

by malkia 3mo ago

forrestthewoods 3mo ago

The world has yet to standardize on a good crossplatform polyglot build system. The only real such build systems are Buck and Bazel. But they have way too much baggage from their overlords. It’s a shame.

himata4113 3mo ago
build systems using llvm as the backend are getting there, but zig is making their own compiler too.
- forrestthewoods 3mo ago
  compilers and build systems are and should be different. A good polyglot build system should support llvm and zig and python and literally any toolchain under the sun.
  - himata4113 3mo ago
    the problem is that you need a compiler capable of compiling said zig, python, rust. LLVM does that, you can compile something as untyped as javascript(with a lot of hacks) or as strict as rust.
    - forrestthewoods 3mo ago
      > the problem is that you need a compiler capable of compiling said zig, python, rust no! No you do not!! It’s perfectly totally fine to have multiple different compilers. Literally not a problem at all. That’s my point! Compilers and build systems are separate. It is perfectly fine for one build system to invoke multiple different compilers.
      - himata4113 3mo ago
        cargo pretty much does that, but then you have to have to bundle all those compilers which becomes a fuckfest.
        forrestthewoods 3mo ago
        Ehh. Cargo has build.rs but calling that a polyglot build system is like calling bash scripts a polyglot build system. Buck and Bazel have the right architecture. Just need a version written fresh without all the baggage.
arikrahman 3mo ago
Zig is pretty good for my use case. It may not be fully pollyglot at a technical level, but I can use it for my embedded C use case, for Jank to export the .cpp to other platforms, and thereby Clojure.

afdbcreid 3mo ago

What do you think we've missed? Do you want one build systems for all languages? There are such systems (e.g. Bazel) and they're often used for multi-languages projects, but I think reality has proven that build systems with language-specific knowledge are much easier to navigate.

__float 3mo ago
I'm not sure how outlandish we're allowed to get here, but IMO we have a fundamental mismatch between application <> operating system <> CPU in terms of dependencies and trust. Fixing this is beyond any one tool, of course :)

small_model 3mo ago

C should have fixed its various issues and added a package manager (or blessed one), Zig is filling that gap.

malkia 3mo ago
No it's not. Not everybody uses Zig. Rust/Python/And others have also tried "fixing" it.

Panzerschrek 3mo ago

I think it's actually good that C++ has no standardized packaging system. This forces one to think carefully before introducing a dependency, since often such dependency have hidden costs, like security vulnerabilities. Since many critical systems are written in C++, it's too much risk to depend on dozens of easily-accessible third-party packages without properly auditing each of them.

simonask 3mo ago
I'm sorry, I have to address this take every time someone brings it up. The lack of a modern, ubiquitous, cross-platform packaging system is an absolutely terrible thing for C++. I've worked on many large projects in C++, and every single one of them contains a bespoke, buggy, undermaintained JSON parser, URL parser, configuration file parser, async framework, and so on. It used to be the case that almost every large C++ project started out by defining its own friggin' string type. Dependency anxiety is a variant of NIH syndrome, and it leads to much, much worse quality software in the average case. Most companies are not in the business of writing a bug-free async framework, and yet here we are. The cost of vetting your dependencies is much, much lower than writing and maintaining all these things from scratch.
- Panzerschrek 3mo ago
  I didn't say one should not use thirdparty dependencies at all. They are sometimes useful. But they should be chosen carefully and ideally reviewed. And any updates should be done manually in order to prevent security chain attacks. Having a standardized package manager allows lowering the bar and bypassing careful thinking. It has also a cumulative effect - if one adds each dependency in its project one by one with proper audits, transitive dependencies may not be managed so carefully. And then we have cargo-style cancer with trivial projects having hundreds of dependent packages.
  - simonask 3mo ago
    I don't think masochism is a reliable or sound security strategy.

pjmlp 3mo ago

Conan and vcpkg are established enough.

lukasco 3mo ago

Cross platform building and packaging in C/C++ is such a hot mess. There's so many dimensions to unpack I don't even really know where to start. (I say this as the person who has been packaging GIMP for Mac for the last good number of years.) OK, here's a few (with a MacOS slant): - compilers (gcc, clang, and their many versions) - libc (and friends) compatibility (I can't say I even ever delved into this one, but it's bit me) - package manager (macports, homebrew) - building for backward compatibility; what's the earliest MacOS version to support (the package managers either like to build for the OS they are running on, or force you -- yes I'm looking at you homebrew) - dependency and dependency version management (love you pkgconfig) - build system for each package (cmake, autotools, meson, ...) - bundling everything into an application - turning that application into a Mac application - code signing and notarization - creating the DMG - debug symbols - crash detection and notification Like right now, libheif on 26 can't be built for 11 and it's not clear why (or maybe they just fixed it...but it's been weeks)