Comment by gingerBill | Hacker News Reader

Comment by gingerBill | Hacker News Reader

Parent Full thread

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.

> there is just not an OFFICIAL package manager

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.

> C++ experience

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.

So why comment? :P

> 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")

> So why comment? :P

You don't have to read the comments either :D

`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.

[Edited to fix ekr's initials]

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.

Reply on news.ycombinator.com