A critique of package managers

Isn't that a (built-in) package manager if it works for general packages? Or does it work only for selected dependencies?

From what I've seen. The Odin has three package collections: `base`, `core` and `vendor`.

`base` is intrinsically necessary to port Odin. `core` seems to be its standard library, your `libc`, `xml`, etc.

And `vendor` is everything else. So you basically get the Python's '`core` is where packages go to die' approach iff they take backwards compatibility seriously. Otherwise, they have breaking changes mid-language version change.

EDIT: Package collections not packages per gingerBill.

It doesn't necessarily "manage" the packages. It just sees them in your project and compiles them. You manage them yourself.

If that's what happens, I think in the following claim:

> Odin's compiler knows what a package is and will compile it into your program automatically.

...the word "automatically" should be dropped. Of course compilers compile any supplied dependency "automatically", but it is so obvious that we don't often use the adverb just for that.

So they are trying the Linux distribution model of packages, right? (Compare `vendor` with, say, Ubuntu's `universe`.)

Those are library/package collections which contain multiple different packages, not the packages themselves.

And we will take backwards compatibility seriously when we hit 1.0, and only "break" on major versions.

> And we will take backwards compatibility seriously when we hit 1.0, and only "break" on major versions.

I'm talking about post 1.0 language choices:

- Choose backwards compatibility. Packages frozen in time, you get "Packages go to std to die." - Choose to break backwards compatibility. The ecosystem is split, some choose to go Odin 2 some are Odin 3.

I already know all that, that's why we are being very conservative and slow when it comes to figuring out what is meant to be in 1.0.

> Of course compilers compile any supplied dependency "automatically", but it is so obvious that we don't often use the adverb just for that.

They often don't though. Rust, C, C++ need either long command line invocations or a build system for anything beyond hello world. Zig needs a build file for anything beyond hello world.

With Odin, you just invoke "odin build ." and all your dependencies are taken in without needing a build system, build file, make file, etc...

We call that a build system. It is not like that there is no build system; you have an integrated build system that is optimized for typical situations. Which is great by its own, but other languages and toolings would have optimized other metrics (for example, you can't ignore Cargo when talking about Rust's build system) so it is not a fair comparison.

It is a build system in the technical sense but it's hard to explain to people because they expect it to be separate from the language entirely. If I said Odin had a build system, they'd be expecting an external build script. And when you say you don't need that, they usually get really confused.

So how do you explain such a system to someone? This is a genuine question I am not sure how to answer.

I mean, is a "build system" even real? Or does it just exist because of a shortcoming with a compiler? All "compilers" have multiple steps usually invoking other programs at some point: parsing, actual code transformation, linking, etc..., some also find packages, some rely on an external tool or long command line invocations.

But yes, Odin builds it into their compiler. Rust doesn't but does have Cargo. Both are easy, as far as typical usage goes. Rust automates dependency management, Odin doesn't automate it per se but does make it easy. Which is what the whole discussion is about. A bunch of HNers whining that Odin makes it too hard, even though everyone sane uses Git anyway, and you can add dependencies using Git, and Odin will compile them without a build tool.

So for a Rust project you use Cargo + Git, for an Odin project you use Odin + Git, for a C/C++ project you use Meson (or something else if you hate life) + Git. In the end it's mostly the same, Bill just doesn't seem to want to deal with an NPM or Crates.io situation (and fair enough!).

This seems like a loss of separation of concerns. As a result Odin's compiler is full of completely unrelated stuff because it takes on this far larger role supervising everything about a project not just being a compiler.

Both Zig and Rust supply all of what you needed in the box, so all that Odin is doing here is commingling these features inside a single executable - there's no end user benefit that I can see.

?? Zig's compiler does way more, from automatically generating bindings to C files to including the entire C toolchain in its executable to running Zig build files (which allow you to do stuff like fetch files from the Internet) and being a compiler.

Odin's compiler does more than rustc or clang, about the same as javac and less than Zig or Go's executables.

> All "compilers" have multiple steps usually invoking other programs at some point: parsing, actual code transformation, linking, etc..., some also find packages, some rely on an external tool or long command line invocations.

There is no technical reason the compiler can do the job of build system, but they are typically separated because of separation of concerns. Rustc needs not be tightly coupled with Cargo---it just has to understand enough of package concepts (`--extern`) for the actual compilation, so they can be independently managed and evolve. Odin's would be the polar oppsite, while Zig's approach is somewhere in the middle (compiler-as-a-library).