Ginger Bill famously hates package managers, so if the lack of one is a deal breaker for someone they might as well look for a different language.
For example, I don't particularly like Python as a language, but I will use it because it has 677,633 packages in PyPI.
I think he would say either copy the code you want into your own project, or clone down the repo and control the code yourself.
He hae interviews on Primeagens channel and Developer Voices where he talks about it.
Yet any language has to reinvent the wheel and write yet another archive downloader.
No, I don't think they need to do that. They want to do that instead of using the already existing OS packager, breaking and messing up things left and right.
Take for example the ridiculous state in the python ecosystem. It would be entirely eliminated by using the existing tools of make altinstall, the system-package manager and properly using Site files. I don't know when altinstall was introduced, but in this issue from 2013 it is already mentioned: https://bugs.python.org/issue19553 .
The OS package managers already go out of their way (e.g. Debian) and renamed site-packages to dist-packages, so that OS installed and other vendored python packages don't conflict. The Python maintainers provide make altinstall and the python program provides site files. Linux distros have /usr/ vs. /usr/local to avoid programs conflicting with the OS versions. So many problems could never occur by people using their tools correctly instead of adding layers on top, which causes other breakage and is "fixed" by even more layers on top.
Chances are 677,634 of those will be broken next week though :-P
The problem with package managers is that they encourage piling on dependencies and creating deep (and thus fragile and often hard to reason about) dependency trees.
I loathe having to install anything more complicated than simple scripts[0] based on Python because unless the developer constantly chases after all their dependencies to keep them in working order, i'll be the one who will have to do that when something inevitably breaks (assuming it wasn't already broken the time i decided to try it - which is sadly something i encountered more than a few times). And once the developer moves on, the bitrot spreads alarmingly fast.
[0] and even that isn't reliable if the scripts rely on more than whatever comes preinstalled with Python
Sure, you can choose to write everything yourself, but you are limiting the size, scope, and complexity of the problems that you can solve. We have to stand upon the shoulders of others to get stuff done.
instead of the user having to resolve conflicts or manage the dependencies
The short version is: projects should vendor their deps and manually resolve package versions. I don't think he states his argument very clearly. But I do think he's basically correct.
Vendor your damn deps!
I have no idea what using the noun vendor as a verb means. I'm guessing deps is dependencies.
> To bundle third-party dependencies with the source code for one's own program.
I hate to say this, but vendor is an extremely common term for this operation. Rust’s cargo has a “vendor” sub command built in.
You’re far from alone in not being familiar with the term. Which is a great travesty because it really should be considered best practice and default behavior!
And it doesn't in any way describe the activity of bundling open source libraries that are not even supplied from vendors for the most part! So a poor neologism, in my opinion.
Look at Rust and NPM... Insane amounts of dependencies for almost every library.
C and C++ famously don't have package managers, well, at least not blessed ones (although you could argue Linux/Unix is a C package manager).
The idea is to be more informed about the dependencies you're bringing in, to encourage libraries to be more standalone things, and just not to automate dependency hell.
On the plus side, the Odin compiler makes it very, very easy to compile your program with dependencies.
Hell, even in my Ruby journey I've realised that 99% of what's on Rubygems is absolute trash. I basically use Rails, Faraday, RubyLLM, and not much else.
> although you could argue Linux/Unix [package managers] [are] C package manager[s]
Exactly. It's just that they don't have the bug, that they only work with programs written in a single language.
GingerBill and the Odin community put tremendous effort into making sure that the Odin compiler ships with "batteries included". You get base, core and vendor library collection that cover almost everything a developer would need to the point that you can argue that you don't need a package manager for Odin.
That being said it's way to early to say it "never became an issue". Odin is still small and not well established. If/when it starts to grow in popularity someone is going to develop a solution eventually. It's impossible for the language to offer EVERYTHING people could need, and developers love package managers.
Is it in vendor package yet? No? Then Odin vendor package will be a bottleneck for development.
Also, all the libraries you demanded have almost nothing to do with the language itself. Odin, as a solo project, lacks both the financial backing and the cult-like obsessive adoption within its community-both of which are essential for breaking into the industry and reaching the mainstream status. It's the industry's adaptability and the community's enthusiasm that determine how many new libraries will emerge for a programming language. Unlike modern languages like Rust and Zig, which have their respective foundation organizations that employ and pay several full-time developers, languages like Odin and C3 that stripped-down complexity and subjectively annoying features got no serious fancy features to market to the target consumers, making it hard for them to gain any exponential momentum. So, give the current state of things, we can certainly say that Odin will not provide any of those libraries any time soon.
Besides, the Odin developers are perfectly fine using libraries written in other languages, whether Rust, C, or anything else. If a library in another language works and will get the job done, re-writing it in Odin is logically pointless for getting the job done. The only people who seem to have an issue with Odin's ecosystem are backend developers. Low-level systems programmers and graphics developers have their needs well met(there are no built-in green threads or fibers but there is support for SIMD and all major graphics API bindings). Networking requires stable, secure maintenance, so unless someone from the community steps up to create and maintain an HTTP/3 or QUIC implementation, there will never be native HTTP/3 support in Odin. The same applies to Aerospike, YAML, JPEG XL, Slint, and everything else. Gotta see how things will turn out.
> Odin kinda feels like a modernized somehow even more boring C but in the best way possible.
I think they should be avoided for common operations in newly designed programming languages.
There are not enough good symbols trivially typed on a keyboard to sacrifice half of them to dead keys. Either the dead key or the programming symbol can be mapped to a key combination.
If that's the rationale for choosing which symbols should be allowed, then let's ban {} as they require AltGr+Shift in many layouts. And let's avoid <> (used as parentheses, e.g. for templates or XML tags, not as less-than/greater-than) because in ISO keyboards they loose all their symmetry. And what about shells, with /, one of the most used characters, relegated above 7 in many layouts?
Jokes apart, I like the choice of ^ or any other characters distinct from * for pointer dereference. To be more precise, I despise the use of the same symbol with different meaning. In C the same * is used for multiplication, pointer dereference and takes part in commments, too. You need full context to parse some cases, or you have to play with spaces:
(a)*(b) // multiplication or casted deref?
x/ *y // multiplication
x/*y // comment start
m&&n // logical and
m& &n // masked addressI'm Portuguese but live in the UK. The Portuguese layout (especially on macs) is dreadful for programming (because a bunch of important characters like brackets require Alt Gr to type), the UK layout sucks for writing Portuguese (because of the diacritics), so I ended up having to get used to US International as the compromise layout. I've gotten kind of used to it over the years, but the exact behaviour for dead keys varies a fair bit by platform, and especially on Linux can get quite aggravating.
From my experience so far, Odin is a delightful modern alternative to C.
Besides, the duo make-delete is easy to understand, but I find disturbing that one has to call delete on objects allocated with
X=map[string][]proc(...){}
I guess things get exciting when that allocation fails, given that such a failure is nowhere checked for and the possibility of such failure is nowhere mentioned.
it was indeed a mistake on my part, line-height got applied to code blocks as well as the paragraphs
I fixed it now so that codeblocks do not have a very loose line height.