But I'm glad I did it because it checks off all the "C but nicer" checkboxes.
I've been programming in Odin for a few months now, and I've come to actually like this choice.
I still use the occasional dependency, and installing it is even easier than with a package manager!
I download a repo as zip from github, extract it in my project, and voilà, it's ready to use. No compilation, transpilation, peer dependencies, locking versions, etc.
Another positive of this approach is that I can now easily read the dependency source code and if needed modify it, as it's become a part of my project, not some transpiled and minified version of that code sitting in an unversioned folder.
Overall, in Odin I use dependencies much more sparingly than when I work with JS. The reason is that the core and vendor packages of the language already include a surprising amount of things you'd normally reach npm/cargo for. Need linear algebra primitives? Specialized data structures like a priority queue? SDL2? stbi? It's all included in the language (and so much more), ready to use.
I've come to realize that more often than not it's fine to reinvent the wheel to solve your specific problem rather than relying on a generalized (and thus unoptimized) 3rd party library.
This sounds like what I already do in C++ (except I use git submodules for dependencies because it makes it easier to pull new versions, check for versions, etc), and tbh I don’t much like it. I do it out of necessity. I’d much rather keep tabs of all my libraries and versions on a project file and have a tool that will download the version for me, build it, tell me when new versions are available, update to the latest version (if I so choose), and so on. In C++, I have to manually do to each dependency and check if there’s a new version, and pull it if I decide I want it. In, eg, Gleam, I can ask gleam what’s new.
In Odin, it sounds like I have to do the same — either use submodules or download the release files by hand. I have to manually check for updates and then replace my local files.
It’s just not something I personally like to do. The author is entitled to be opinionated about this, but it clashes with my own opinion, so that means I probably won’t try the language even though it looks pretty good from a language design point of view.
With that said, could we do this without a package manager? I mean.. yes.. instead of a nuget folder structure it would be a dll folder structure. Certainly possible, generally speaking.
I guess there is negatives on either side. Without a package manager you have to be more manual. With it updating is easy.. and I know developers that update them without looking into the details. There was one example where nuget said there was an update.. so the developer updated it and it caused errors. Thats because the update was for a later .NET version.
However, when it comes to odin, I have found it to be a pleasant experience doing a `git pull` of any odin library I need to a 'thirdparty' directory and to import them into my odin code.
So we have the builtin ones like core, vendor, etc... then I have thirdparty. If any of those libraries in thirdparty made its way into odins vendor.. it would be a simple change in the code.
I use Odin in my own personal projects but if I used it at my current workplace, I would likely setup a structure similar to my C# setup.. with a shared directory holding libraries we need -- simply git pulls, etc.
You can't be a general language without general tooling.
Partly because of this, I try to avoid external dependencies as much as possible. When I need something that's not built in to the language, I choose in the following order of preference:
1. The standard library and target platform libraries, augmenting any inadequate features with my own extensions if necessary.
2. A very well known, well maintained, and widely used library with few dependencies of its own. Something that could almost be mistaken for #1.
3. Write my own minimal version of what I need, if I can do so with a reasonable level of effort.
4. A lesser-known third-party library, if it appears well maintained, and if I am willing to audit it and every future update to it.
A happy side effect is that a language with no built-in dependency manager is still perfectly viable for me, since it wouldn't be saving me much work anyway.