I think Odin is the best language in this niche so far. And although I prefer it slightly to Zig, I expect Zig to eat Odin's lunch.
Odin seems to have procrastinated the important things that cause a language to really take off, in favor more trivial features. At this point I think Odin has crossed into the territory of being wrong in the direction of too many features rather than too few. While having not delivered important tools that would cause the language to accrete an ecosystem.
A must-have for wide adoption is a package/dependency manager. As I've said before: Just clone what Go has. Just take it, you need it to be popular, and you probably aren't going to do better. `import "github.com/whatever"`.
I believe Zig has already started on a package manager, while the sentiment in the Odin community is that the unnecessary concept of "collections" somehow solves the dependency problem.
Why not use a system package? Well, because the user's system might not have such a package. They might be on Windows, for example. Or their package might be out of date. [Or the system might have chosen sides in a nasty fork war](http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html).
So, while system packages are nice for end users, they might not always satisfy the needs of upstream application developers.
I wish Nix grew into this niche. It's fine now if users want to install a system daemon or deal with multi-user mode, but it'd be neat to have a polyglot package installer that you can run from the project directory, like you can do with Gradle (about the only positive thing I have to say about Gradle).
I haven't tried it yet, but the Zig package manager should be flexible enough to deal with binary blobs? After all it's just pulling in an external directory and runs its build.zig (which then can make available precompiled libraries to the rest of the build process).
Such binaries will not be able to use anything but the special C-compatible types and calls, which is quite the limitation. Image if C++ static libraries could only use C compatible POD structs and none of the C++ parameter types for example.
> Image if C++ static libraries could only use C compatible POD structs and none of the C++ parameter types for example.
That's the only way to expose a C++ library to other languages though, or even make a DLL written for one C++ compiler consumable by a program written with another C++ compiler.
It's a limitation for sure, but definitely not a show stopper.
As far as I'm aware, COM based APIs *are* C-APIs, just with a couple of additional conventions for lifetime management via refcounting, versioning interfaces and wrapping C++ classes into structs with function pointer jump tables ;)
I am the creator of the Odin programming language, and thank you for the rhetorical insult :)
> procrastinated the important things that cause a language to really take off, in favor more trivial features.
So I should have focused on making a hype language rather than actually solve problems in programming that can be solved a the language level? I don't think anyone would call that "procrastination".
> At this point I think Odin has crossed into the territory of being wrong in the direction of too many features rather than too few. While having not delivered important tools that would cause the language to accrete an ecosystem.
That's vague as anything. Can you give any concrete examples?
> A must-have for wide adoption is a package/dependency manager.
And because Odin has a well defined concept of what a package is in the language itself, then creating one would be trivial for someone to do. Now this is going to be a VERY VERY controversial take but I do not want to __officially__ support a package manager. I know it's "so nice" to do something like `go get`, but I am not a huge fan of package managers in general and I honestly and truly believe that they have caused a huge amount of problems that cannot be solved by their existence. Please do not speculate what I "prefer", but I will not explain in this comment since it would take an entire article's/video's worth of explaining.
> while the sentiment in the Odin community is that the unnecessary concept of "collections" somehow solves the dependency problem.
This is just incorrect. There are few people who are working on a package manager for Odin, there is just not an OFFICIAL package manager.
And that is not what a library collection is for either. A library collection is a named search lookup. All imports are relative to either the current file OR a named library collection (a named directory). This solves the problem in C with `#include <...>` where you don't know how it is searching, whilst in Odin `import "core:fmt"` or `import gl "vendor:OpenGL"` or "import "../foo" has been made EXPLICIT where it is searching from.
----
I am not trying to create a "hype language" but actually make a language that solves mine and loads of people's actual problems. I do not view that as any form of procrastination whatsoever, and that you do is quite sad.
I think the C++ experience gets to why a modern language intended for widespread use needs one package manager, whether that's an "official" package manager or a "de facto" package manager - not zero and not six.
Having looked at the Odin "core" library it seems to me it's mostly "Stuff Bill wanted" which won't scale.
But I'm not an Odin user, so there's no particular reason you should care what I think.
I have well over a decade of C++ experience, and the Odin compiler is written in C++. I agree having 1 de facto (not de jure) package manager is the best option. Making it official (de jure) does reduce the chances of de facto package managers from arising.
A lot of "core" isn't "Stuff Bill wanted". There are loads of things in there that I never use, but I feel is necessary for a "core" library. I didn't even write half of the core library, loads of other contributors did.
> But I'm not an Odin user, so there's no particular reason you should care what I think.
> A lot of "core" isn't "Stuff Bill wanted". There are loads of things in there that I never use, but I feel is necessary for a "core" library.
It's uh, esoteric is I guess the most polite term I can think of. SM3 hashes? TGA images? I found some typos for whatever that's worth: e.g. "If you the elements to remain in their order" is I think missing a word, maybe "want" or "intend")
`core:crypto/sm3` is just one of the many cryptographic hashes that exist in Odin. You've just told me you have never done any cryptographic work like SSL, and how useful that is for things like encrypted web protocols.
As for TGA images, that is an image format that people still use, along with many others Odin supports. We want to be able to load an image regardless of its format, be it PNG, TGA, JPEG, etc.
> You've just told me you have never done any cryptographic work like SSL
I'm no ekr, but I think I've been around quite a bit actually :)
TLS (and before it SSL) was plagued by what we call "national vanity" algorithms. Suppose you're the Swedish government's cryptography team. Your political bosses just found out that literally everyone uses North American cryptography† for HTTPS and they demand to know why there aren't Swedish or at least European cryptographic algorithms they can use instead. You could explain why this is very stupid and risk getting fired - or you could publish some mediocre own brand technology with your country's name on it and hope the politicians are distracted by the next news cycle and go away.
SM3 is one of those "mediocre own brand technologies". Twenty years ago, SSL was largely a product of engineers. An actual cryptographer would be asked to glance over the final result, but they weren't integral to the design work - after all this is engineering right? The engineers assumed that if we have a dozen choices then we can more easily pivot if things go wrong and that'd be meaningfully safer. AES-128 broken? Just use this Italian algorithm I read about last year instead. So the "vanity" algorithms proliferated. But once we had cryptographers in the room they were horrified - these algorithms are basically untested, you'd be largely trusting to luck in using one because nobody knows if they're riddled with unsuspected holes.
Accordingly TLS 1.3 deliberately doesn't provide even the broad smear of somewhat known crypto algorithms that had featured in earlier standards, it focuses on a handful of known good options, knowing that if we can't do any of those we're actually fucked and shouldn't waste our time with whatever some random national vanity algorithm does.
SM3 specifically is a Merkle–Damgård construction, which means it was obsolete when it was made. The SHA-2 family (like SHA-512/256) is the tail end of this design, and SM3 is like those except Chinese. Does it being Chinese matter? Not in the least bit. One day, when we need a new cryptographic hash algorithm we will either use SHA-3 or, more likely use what has been learned since SHA-3 to design a more promising sponge construction, we are not going to ship another Merkle–Damgård hash function.
Because it's a national vanity algorithm it has been certified by the appropriate national authority (China's National Cryptography Administration) and is in fact used nowhere.
So that's why it's weird that Odin decided this should live in its "core" library. You aren't using it for "cryptographic work like SSL". Hopefully it's just stubbed out and isn't actually used anywhere at all.
† RSA was invented by Americans, but technically a British man invented the same algorithm first... for the British government, who kept it secret so it was worthless.
You've misunderstand the purpose of having the suite of cryptographic packages. I agree NO ONE __should__ use SM3, but it exists in the wild and thus people do use it.
The `core:crypto` packages match that of the Botan ones (of which we support in `vendor:botan`). It's not about whether or it's a good algorithm or not, but that it exists.
Using your logic, Botan should remove most of its stuff too, but that would stupid to do.
I would argue that Zig’s inability to produce static or dynamic libraries that use Zig features in its API is a much bigger problem that Odin’s lack of a package manager.
Neither Odin nor C3 has any problems with this, and it simply follows from Zig’s semantics that it is rendered impossible.
So will Zig semantics change (which would be a big change indeed), or will Zig precompiles libraries always be forced to go by way of special C-compatible calls and types?
Before I’d declare Zig the winner due to a package manager I’d be sure to figure that one out.
The creator, gingerbill, uses it to build real time flame and smoke rendering [0]. AFAIK they have vectors and matrices built into the stdlib as well as various graphics apis[1].
So I'd say from what I know the niche is "batteries included high performance code that can target the gpu"
Odin is a general purpose language, in the same way C.
Professionally, we use Odin to create all of our software at JangaFX: EmberGen, LiquiGen, and GeoGen.
Many people have been using Odin for similar purposes:
* game development
* application development
* 3D graphics
* physics related stuff
* etc
This is what a lot of people feel Odin's "niche" is, even if it is not restricted to that. A good example of this is Odin's first class features for array-programming, swizzling, matrices, quaternions, and many other things useful when dealing with 3D related things (graphics, physics, games, etc).
Odin seems to have procrastinated the important things that cause a language to really take off, in favor more trivial features. At this point I think Odin has crossed into the territory of being wrong in the direction of too many features rather than too few. While having not delivered important tools that would cause the language to accrete an ecosystem.
A must-have for wide adoption is a package/dependency manager. As I've said before: Just clone what Go has. Just take it, you need it to be popular, and you probably aren't going to do better. `import "github.com/whatever"`.
I believe Zig has already started on a package manager, while the sentiment in the Odin community is that the unnecessary concept of "collections" somehow solves the dependency problem.