Anyone I want to work with on a project is going to have to have the same frustration and want to work on the project less. Only even more because you see they downloaded version 2.7.3-2 but the version I use is 2.7.3-1.
Odin's compiler knows what a package is and will compile it into your program automatically.
`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.
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.
Then those people will have to manage dependencies, which is a hell on its own. Which will cause problems. Because people are super lazy so they will automate it. In the end only thing no package manager gets you is multiple package managers to juggle.
Many languages started without package managers and eventually got them - Java, JavaScript, Python, C, C++
I know people are lazy and will automate hell. That's the entire point of the article: not everything that can be automated ought to be automated.
And the argument about multiple package managers to juggle is only the case IFF there are multiple competing ones, which with Odin, I honestly doubt it would happen if we enforced what a package is in the language. I just don't want to officially endorse one ever because I do view them to be evil.
And I don't care many languages started without them, I am not going to give in.
I don't see how changing package definition is going to help. JS had no concept of package and it was bolted on with NPM. If Odin becomes big enough, the community will override the will of the author.
Plus I don't see huge benefits to not having a package manager other than saving disk space.
Security isn't that much meaningfully better than NPM.
Trust problem exists regardless of package manager.
And people aren't far to trusting, but far too lazy. And importing packages gets job done quickly.
Dunno, hanging out in the Odin discord, it definitely attracts a crowd that thinks similarly to Bill. All the "automate everything" crowd have definitely gone to Zig, where you can create automated monstrosities with the comptime stuff and build.zig files. And the crowd that likes NPM gravitates to Rust. So Odin is just fine IMO. People on the discord share libraries that actually do things, versus an entire dependency to write a few basic procedures.
And speaking of JavaScript, nowadays ES6 does have an idea of what packages/modules/libraries are and it's so much better. All my JS dependencies for my Rails projects are just .esm.js files. I choose modules carefully, don't pull in obfuscated files, read the source, so I have 2 JS dependencies in one project and a single one in another, I write the rest myself in vanilla JS and life is great.
Sure, hence the big enough part. If you get big enough, you'll get people who are using it as a day job language, not their special darling. Having used JS and Java without package managers in a professional setting, they sucked to use.
You import a package, run the main program, see compiler/browser errors then search local repo or th Net for the missing library. Essentially you're the package manager. Which does little for bloat. You can still have a folder and import stuff en masse.
> 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.
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...
So how do you explain such a system to someone? This is a genuine question I am not sure how to answer.
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!).
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).
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.
Odin's compiler does more than rustc or clang, about the same as javac and less than Zig or Go's executables.
Some distos might try to support multiple versions of a library. That could require installing it to different prefixes instead of the default. Thus, the build system will have to comprehend that.
Literally all code I write runs on Windows, macOS, Android, and Linux. In roughly that order of priority. No I do not and will not use WSL2, it’s an abomination.