I recently used Odin in a commercial project and had a great experience. For me the biggest hurdle was not the language, but having to write programs without an IDE like Visual Studio/Xcode. Having to write my own build scripts (shell or batch files) etc and maintaining them is a PITA.
But I'm glad I did it because it checks off all the "C but nicer" checkboxes.
The fact that it not only doesn’t have a built in build tool/package manager, but that the author has also said he doesn’t believe in them and will never make one was very off putting to me. I love how languages like Rust have cargo, or gleam has it built right into the compiler. I’m so fed up with how in C++ or Python there’s a billion competing tools. The language looked really cool, but without good author-blessed tooling, I doubt I’ll ever use it myself.
> The fact that it not only doesn’t have a built in build tool/package manager...
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.
Thanks for taking the time to tell us about your experience! I’m happy it works well for you! With that said, that doesn’t sound like it’s for me.
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.
As someone who writes C# for a living, I see some great advantages with package managers. We have setup a system where our own libraries are published to our local nuget repository and the results have been positive.
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.
These dependency managers are something of a double-edged sword. They avoid a lot of work if your project has a lot of external packages, but they also encourage pulling in lots of external dependencies without much thought. Every one of those, and every one of their sub-dependencies, exposes users of the software to significantly more risk. It's a breeding ground for common vulnerabilities and supply chain attacks.
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.
Well… we can’t save people from themselves. It’s always prudent to ensure the libraries you use are high quality, stable, and well maintained and your list is a good order of reference to live by, in any language.
It those things on Pypi depend on binary libraries that you need to compile yourself, there is going to be some fun, depending on the state of the current system.
But I'm glad I did it because it checks off all the "C but nicer" checkboxes.