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).
Huge fan of Odin, true C successor. Much better ergonomics and fun to program than say Zig. But needs the following in my view -
- A way to generate bindings automatically from C Headers or even better - not having to generate bindings separately and just import C headers directly.
- Better tooling and standard library improvements.
I think Odin & Nim are my two favorite "modern" languages but they fill different niches. I see Odin as mainly replacing C while Nim is more a C++ replacement (but with Python like rapid development). I'm always amazed at how productive Nim is but the language has many areas that I'm not familiar with (the AST Macros for example). But Odin mostly fits in my head.
> A way to generate bindings automatically from C Headers or even better - not having to generate bindings separately and just import C headers directly.
We do want to have an official bindings generator as part of the toolchain. There have been numerous third-party ones that people have created, but we need to have an official one now.
However, automatically importing C headers is not actually what virtually anyone wants in practice. Once you have imported the C header file, you pretty much want to:
* wrap the entire thing
* change the types to better reflect what things are (using Odin's richer type system)
* change names of things to better reflect usage and intent
* reorganize the declarations to better read things
* etc
There is also the second issue that C is technically TWO languages: the C programming language and the C preprocessor. People mix the two together and things cannot be easily translated. A good basic example of this is people using `#define` for constants, and thus that name has no semantic meaning in the language itself. A translator has to try and make some semantic meaning from the intersection of these two languages, even if people don't make a distinction when making APIs.
And Odin's `foreign` system allows [1] for a lot of really nice things that most other languages cannot do so tersely. Here are two examples of demonstrating bindings of C libraries that feel as if they were native Odin libraries WITHOUT any wrappers:
> There is also the second issue that C is technically TWO languages: the C programming language and the C preprocessor. People mix the two together and things cannot be easily translated. A good basic example of this is people using `#define` for constants, and thus that name has no semantic meaning in the language itself. A translator has to try and make some semantic meaning from the intersection of these two languages, even if people don't make a distinction when making APIs.
I completely agree that this a giant PITA. But glad it's being considered to be part of toolchain. I would also suggest you reconsider the functionality of importing C headers directly. Yes, they won't be as nice as Odin bindings but they'll definitely give a nice stop gap. Just recently I had a project that uses WebGPU but couldn't generate Odin bindings automatically or find an existing one. So had to go with C++.
Another aspect is, many times I deal with proprietary APIs that have headers with all sorts of macros, bitfields and byte paddings. Having a direct C header import might also help with this case. Yes that API will still be ugly and less ergonomic but everything else would be nice. A bit like Futhark for Nim[0] or lcpp for LuaJIT[1] would really help to write more Odin.
Standard Library - I don't remember off the top of my head but I tried strconv procs a while ago to parse OBJ files and found that the floating point parsing to be slower than strtod. Maybe it's not the case anymore I'll give it a try again and open issues on Github for any feature requests.
Bitfields - In my line of work this is a must-have.
> I would also suggest you reconsider the functionality of importing C headers directly.
Trust me, as this is not as good of an idea as you think. You will just wrap it regardless unless it is absolutely trivial, which in those cases, you could have manually written the code to call the foreign code. And even if it was not as trivial, the types will be mostly wrong too, which means you'd need to correct them.
> Just recently I had a project that uses WebGPU
WebGPU is a mess regardless. Automatic bindings would still not work as you'd expect. For this specific API, we will add it to the `vendor` library collection along with all of the other graphics APIs. No one has gotten around to adding it yet, that is all.
To be clear, I am talking about a tool that will generate the Odin bindings for the specified C header(s). A magical "import c code", is what I am arguing against. It rare, if ever, that you need to regenerate the headers every single time you compile your Odin code, and that you don't even have wrap the code. Wrapping the code is effectively equivalent to just writing it yourself.
I am talking from experience from other languages. Pretty much every time those languages have the automagical C header importer, they either:
* The code had to be wrapped any way
* The types need corrected (thus wrapping)
* Rarely work correctly
* Missed code
* It didn't include everything you needed (e.g. preprocessor values as named constants, macros that were effectively normal wrappers, etc)
Another problem is that Odin does not support C's way of doing bit fields either, so some concepts will not map directly either. This means that Odin would have to completely embed the entire C type system as part of its language, rather than have those types be _compatible_ and _transformable_ with Odin types.
> To be clear, I am talking about a tool that will generate the Odin bindings for the specified C header(s). A magical "import c code", is what I am arguing against.
Ok I understand now. I think even having such a tool i.e. to generate bindings from a C header file would be godsend.
> WebGPU is a mess regardless.
Interesting, it's not perfect but better than writing shaders in multiple languages and maintaining multiple render pipelines. Right?
I know it's hugely unpopular with some of the HN crowd, but V (vlang) is definitely a worthy competitor in this space. I tried Nim, Zig, etc. but liked Odin (in spite of some oddities in syntax and usage). Now I've moved over to V in this space (although Zig has a lot of traction, so I keep following it).
Vlang is infamous for crowdfunding on the back of many extremely grandiose, but not actually implemented claims. The poor quality of what did exist was very evident as well. It also had at least a few keyboard warriors associated with it who would play motte and bailey up and down every comment section. I can't speak much to the present state, but I suspect only a few people view it in any serious light.
I can barely keep track of the number of languages that exist today. I feel like the answer is Wikipedia, but it would be great to have a central resource that language authors and communities could contribute to. Just answering the questions:
- What is the origin of the language?
- What use cases are the language best suited for?
I'll reply to this comment, just in case anyone else is curious.
The origin of the language: gingerBill got drunk one night and wrote a compiler. Seriously though, it was an attempt to create a language that would be a reasonable C alternative - simple semantics, usable for performance-critical applications (mainly games and engines), good support for tooling. I would also describe it close to something with underlying mechanics of C combined with the niceness of Go. Odin does improve on Go in a lot of places.
The use cases would be similar to C or C++. There's not much different in the way of memory management / the way objects are stored in memory etc. There is a concept of an allocator which could make Odin a better candidate for good performance when you allocate memory (i.e. putting everything on heap can be slower than bump allocators)
Some of the coolest features I've found using the language - bitsets (make a set of flags out of an enum), slices, which C didn't have but are so nice to use, the or_return, or_continue and or_break operator (hello, Go programmers, tired of writing if err != nil yet?).
Language comparisons:
unlike C: Has simpler syntax, easy to parse, has slices, bitsets, sized enums, templates.
unlike C++: doesn't have operator overloading, has simpler semantics, the standard library is readable.
unlike Rust: no borrow checker, limited lifetime checking (can detect using stack values that have dieded), no lifetime annotations, limited support for typeclasses, no pattern matching, no traits. I wouldn't compare it to Rust, honestly, it's a different kind of language.
unlike Go: I haven't used Go in a while so forgot a few details, don't quote me on these: it doesn't have var syntax for declaring values, you can not shadow tuple declarations at all, support for or_return syntax, tuple returns can be used to saturate arguments of another function, doesn't have garbage collection. Doesn't have a package manager.
> The project started one evening in late July 2016 when Ginger Bill was annoyed with programming in C++. The language began as a Pascal clone (with begin and end and more) but changed quite quickly to become something else.
> Bill originally tried to create a preprocessor for C to augment and add new capabilities to the language. However, he found this endeavour a dead-end. That evening was the point at which Bill decided to create an entirely new language from scratch instead of trying to augment C
---
> What use cases are the language best suited for?
> Odin is a general-purpose programming language with distinct typing built for high performance, modern systems and data-oriented programming.
> Odin is the C alternative for the Joy of Programming.
Even though Odin is a "general purpose" language, in the same vein as C, many people have been using Odin for:
My time on it is limited at the moment. I am working 2 jobs which is eating my weekly hours. When I have more time (leaving one job in April.. yay!) I plan to contribute to Odin more.
Currently, I would guess many view Odin as a niche language in the gaming circle. A bit like Jai. I want to try and change that mindset or reputation.. to build apps in Odin that are not games (though I plan to move a game I wrote in C to Odin as a fun experiement)
I am currently binding a C library to Odin which my early tests are working pretty well. Plan to announce more, hopefully, in the coming months. I have also experiemented with existing libraries like odin-http and odin-mysql (by a chap named layton who helps alot on odin discord) -- I need to build a family website/blog and tempted to use Odin with htmx.
The only area of critique to Odin, especially those that are accustomed to them... is a package manager. Now I am in favour of package managers. C# Nuget is good. However, for Odin, I have been happy to create a third-party folder and 'git clone' the repos I need:-
That account is not led by a person with performance knowledge despite what the name suggests.
Previously, its author failed to profile the code and use existing package which does the vectorized sum suggested by multiple people and was comparing the code where the compiler couldn't prove it doesn't go out of bounds versus pointer arithmetics.
The comments to other posts of that account pointed that out yet the feedback was completely ignored. It's a skill issue to try to want to use FFI for this over implementing a function in C# out of personal spite.
I like what Hare sets out to do, and I like how it is going so far. But in terms of a C alternative it doesn’t really fit the bill. Hare is explicitly not supported on anything but open source platforms and that is a big divergence from C in 2023. I do not doubt there will be a Windows compiler at some point, but the language’s goals are never going to mesh with a large chunk of C usecases.
This is an odd list when responding to a ‘C-alternative’ question. I’m not saying the list is bad or outrageous, just that the parent uses ‘C’ and in a topic about a language like Odin I would expect for a response list to not include C++ and it’s competitors.
Again, not saying your list is not a good capsule of C and C++ ‘strata’ languages (with one very notable exception), but people looking for C alternatives in 2024 are (most likely) explicitly ignoring complex languages like C++.
About that exception, Haskell may compile to C, using an ill-maintained and not up to date, part of GHC, but it is still Haskell and so compiles to C program source with GC included via header. The Haskell source code does not offer the bit-banging, memory manipulating abilities of C (in any way an imperative language programmer would recognize) and is practically devoid of memory management capabilities to assist in achieving C level performance requirements.
> I would expect for a response list to not include C++ and it’s competitors.
While it is a common trope on the internet that C and C++ are totally different and nobody that prefers C over C++ would like the more "complex" languages that are "C++ replacements, not C replacements," in the real world, it's not that clear-cut. I happen to work with a bunch of people who used to be C folks, never really liked C++, but now happily write Rust instead of C.
What any "x replacement" needs to be accurate is to define what "x" actually means to you. C means different things to different people! And that's okay.
(That said I agree with you that Haskell, at least, is quite the stretch.)
While I don’t disagree with your point in general, and if this was an article about Rust, D, or maybe even Zig, I may have left off the part about C-esque vs C++-esque languages.
However, in a topic about Odin, Hare, or Go, I think the comment was germane. These languages value simplicity as a stated goal, and whatever one thinks of the position of C on the simplicity scale, I’d like to think that it is a valid consideration in language comparisons.
I will certainly acknowledge a subjective basis for defining and assessing ‘simplicity’ in PL design, but I can not put a language as complex as Rust in a bucket with C, Odin, Go, or Hare. The syntax, semantics, and implementation issues associated with ad-hoc polymorphism alone take it into another strata.
I am obviously aware of who I’m talking to and that you would certainly be the person who would know plenary of dev’s from any number of backgrounds happy to have replaced C with Rust. So I’m not trying to imply or say that it doesn’t happen. But there is a difference in working in Rust (happily, preferably, or otherwise) vs C, and in compiling a list of language similar to C. I took the question to hinge on similarity (in at least the complexity characteristic, if not the syntax or type characteristics), while I think you looked at it as a question about valid or preferable replacements for development.
Finally, I’m sure it was personal preference and philosophy that led me to assume complexity characteristics were inherently at issue in the GP post’s request for a list. You were certainly correct to point out it is a pretty narrow POV.
Yep! Great comment. I certainly agree that if someone was looking for a language that does "simplicity" as an ideological thing, grouping stuff together that way would absolutely make sense. I suspect, in the same way that you reach for that comparison initially, I also do not, because I don't particularly enjoy that framing of programming languages. We truly are all the products of our own experience and biases.
I'm one of the type of people Steve was describing, albeit not someone Steve knows - people who "used to be C folks, never really liked C++, but now happily write Rust instead of C".
Simplicity is really an "eye of the beholder" situation. In particular often (implicitly) implementation simplicity is meant, a lot of what was simple about C, especially K&R C and to an extent C89, is because a PDP-11 isn't very powerful. But while that simplicity is valuable to the compiler author (in the case of Odin, Ginger Bill) it doesn't have much value to users. Delivering simplicity in use through regularisation is expensive for the implementer.
For usage I worry that C-style simplicity comes in the form of just declining to explain the tricky corner cases. That is, I worry that if we documented all these cases properly, suddenly the "simpler" lowl level languages might look fiendishly complicated after all. Certainly I'm not confident that C was "really" simpler than Rust in many regards.
Odin's official compiler is not a "simple implementation", and Odin was not designed to be trivial to implement either. Where did you get this falsehood from? None of what you said is correct.
Odin is fundamentally about simple as-in _intuitive_ to use, and intuition are anything but simple as-in _simplex_. Intuitions are extremely complex and complicated things, even if they seem "easy" to use.
Designing for people's intuitions about what feels right and feels "intuitive", is a lot more complicated than you realize. The entire constant value system requires a big-number implementation to get right.
Looking at the compiler for more than 10 minutes would you should that it is anything but trivial (I will refrain from using the term simple here since it is overloaded). Odin is more complicated than C, but less complicated than C++. That is both in terms of the language and the compiler itself. You can write a C compiler is <8KLOC (in C). It would probably take <50KLOC to write a _minimal_ Odin compiler (in C), if not more.
Which falsehood? That K&R C was written to fit on the PDP-11 and its limitations reflect that? I think that's well attested.
It may very well be that Odin fits your intuitions, it certainly doesn't fit mine. Take your "range based for loop" - it does something for a handful of built-in types. What it does is presumably whatever your intuition said it should do, and then for custom types it just doesn't work at all. I'm sure that in your mind this is simple, "It just does what you expect". But to my mind it's extremely complicated - it does these different specific things I'd need to remember, and in any other cases it's just not legal Odin at all.
> The entire constant value system requires a big-number implementation to get right.
Unless "big-number" is rather over-stating what was needed here I don't get this.
That’s basically what the sibling comment was saying, i.e. I was the one being overly narrow in my interpretation of your question. And in light of that and your clarification, the list is more than accurate to cover nearly all the common options.
Maybe, but it’s always fun to get to be hyper specific and quibble about things, so I can at least thank you for providing something for me to comment on this evening. Seriously, like I said in my reply to a sibling comment, I was being picky about my personal preferences and interpretation of the parent question.
Nim is particularly C-like. The automatic memory management is optional and exposes destructors, it exposes pointers and is quite usable on embedded systems (see: Futhark, Ratel), there are a wide variety of design decisions made to ease interop with C... I do not know about D.
Carbon is really exhibit A of why MVPs exist. Jai and Cppfront have the same problem but Blow and Sutter probably don’t care if they never gain much traction. Conversely, Carbon is Google-backed (IIRC) and will soon die if it can’t justify its continued existence.
I can't comment on Herb Sutter. But Jonathan Blow, from what I've seen and heard, is deeply passionate about the domain Jai is targeting and appears to have Jai already in pre-production use in his next in-development game/engine.
I agree about the MVP stuff; in contrast to things like Zig, Jai is the completely opposite, it's being built behind closed doors with little to no community feedback, with the creator and inner circle have say in the direction.
I'm not sure how well it will pan out. Seems like, from the outside, Blow is scratching his own itch and maybe it's possible Jai will never take off. The only real world similar example is Elm, which while open source, is/(was?) also heavily design behind closed doors in many ways, albeit not to the degree to which Jai is.
There's also Mojo, the Python-like language. It's also being built behind closed doors, but it seems to have a lot of hype behind it already.
Carbon was started by Chandler Carruth, at Google, but they wanted to move it to broader governance quickly. It's not under the Google GitHub today, but its own org.
If you aren’t looking for languages that have more fancy memory management things (ref counting, borrowing or similar) then the active ones I know of are in alphabetical order:
C3, Hare, Jai (might be slightly more of a C++ alternative), Odin and Zig.
Additionally: Hare stated Win and Mac will be unsupported. Jai is still closed source.
I’ve been leaning more towards a dual language approach recently. A language with tight integration with C like Lua, or Gambit, that makes it easy to drop down to C. C gets treated like a block of unsafe Rust code, and you keep as little of the code base in C as is necessary
This is what I've been thinking lately i.e. C and Lua (throw in LuaJIT too if speed is needed).
But I've found out that using functional parts of modern C++ (bear with me) as a higher level language with C underpinnings also works very well. But you need tremendous discipline to do it successfully. For eg - using only C POD structs, no constructors, no exceptions, no inheritance, limited template usage etc. Some would say a very C style C++ with a lot of syntax sugar.
That's how any C++ stuff of mine goes, "given the chance", ie. the self-contained, private/hobbyist stuff. With structs instead of classes you still have the convenience of instance methods (rather than just mynamespace_funcname funcs), statics, even namespaces (hardly necessary with methods and statics), yet can avoid inheritance and the whole public/protected/private noise (public by default, otherwise structs and classes are exactly equivalent in C++) except for the rare case where it does seem beneficial over a simple field.
I also stopped writing destructors (because eventually that leads to writing move constructors); instead now just use a unique_ptr to wrap resources (covers most of the cases) or a simple scope_exit (ala "defer"). Turns out separating ownership and lifetime really helps to write much better C++ code for me.
These simple rules coupled with great modern C++ syntax sugar like lambdas, tuples and 'auto' along with the basic data structures in it's standard library makes it a breeze.
What I never get about the huge Lua popularity in C/C++ land is how people manage the mental switch between 0-based and 1-based indexing. Or is this tunable from the VM/JIT-hosting side? Because if I were to use Lua-the-language standalone, I'd lose all my "mental automatics" for real basic arraying/looping stuff that serve in day to day in the non-Lua workloads of C/++, Go, the occasional TypeScript etc.
It might be because I'm old and grew up with carpentry and fence and post around a paddock real life problems but there's no switch if you seperate the two as two distinct things.
If you make a pigeon hole row of boxes, box number 1 has an index of 1 and an offset of 0 (from the origin mark).
C arrays are syntactic sugar for origin based offsets, Fortran arrays are indexed by element number.
In C arr[i] is equivalent to i[arr] is equivalent to arr + i and to i + arr.
Interesting: this looks heavily inspired by Go, but it supports things like sum types
(the lack of support of which is one of my biggest gripes with Go).
Looking at their front page, they have the following distinguishing goals: Simplicity, speed, modern, pleasant. Is there _any_ language that doesn't aim for those four things? I have no idea why I'd choose Odin.
Many languages don't aim for that. As it states on the front page:
> Odin is a general-purpose programming language with distinct typing built for high performance, modern systems and data-oriented programming.
> Odin is the C alternative for the Joy of Programming.
So if you have a problem that would have traditionally use C (or even C++), then Odin provides a more modern approach built for modern systems and higher control over low-level things such as memory, memory layout, memory access, and custom allocators.
They could really improve their sample code/demos. Particularly the default one - for a "data-oriented" language, having the first demo be parsing and executing a nonsensical calculator language is a weird choice.
As for the first example: a basic lexing example is probably boring, but it does show some basic ideas of what the language is about. If people want to write better examples or just reorder the current ones, please feel free to make an issue or PR on the website's GitHub page: <https://github.com/odin-lang/odin-lang.org>.
I always feel like a bit of an outsider with these things; I see stuff like Zig and Odin and Nim being posted, and everyone on HN talking about how great they are, and I feel like I'm missing something.
I have absolutely no desire to going back to manual loops instead of `map` and `reduce` and `filter`, and I have no desire to go back to imperative style, but I appear to be somewhat in the minority on this. Everyone seems to love Go now, and people keep telling me that they like the language because it's "simple", but I have absolutely no god damn idea how they explain that. I know C well enough to do an interview or hack on FreeRTOS, and I've done a fair amount of paid Go work in the last few years, and despite that I am always craving for a functional language. Any functional language. Give me Haskell or Lisp or OCaml or F# or Rust or even JavaScript.
It's the aesthetic of programming as "solving the actual problem", vs. programming as "solving the problem of how to solve the problem".
When you're solving the actual problem imperative is largely the right default: each line clearly relates to the actual problem; and it's clear how the actual problem is being solved.
When you're bored, or have no actual problems, it's fun that every line is a little puzzle.
I think I disagree with this entirely. With imperative you’re actively translating the problem in terms of how things are going to be interpreted by the CPU. With functional you actual express how to solve the problem and trust that the language constructs will handle stuff like loops for you.
> I have absolutely no desire to going back to manual loops instead of `map` and `reduce` and `filter`
Not everyone wants nor desired to use a functional language. They might want or even need an imperative (and procedural) language. Odin is an imperative procedural language, and has no "functional programming" aspects to it. Odin is not of that tradition.
If you love functional programming languages and they are useful for solving your problems, then Odin is not the language for you, and that is absolutely great! Odin is for people who wanted a C alternative for systems-level programming, and thus an imperative procedural language is what they desire. And as such, Odin is not a mixed-paradigm language either, since it does not make sense for it (e.g. explicit manual memory management, imperative style, etc).
---
Isn't it great that there is choice now between programming languages?---in the domains people work in.
Sure, I wasn’t really asking permission to prefer functional languages.
I’m just a bit confused to why everyone on HN seems to prefer imperative languages, and it’s not quite as simple as preference. If an imperative procedural language gets popular, that affects the job market. It seems like every job now requires a million years of Go experience. That’s fine, times change, but it just feels like the wrong direction. Personally I was more rooting for Rust or Swift becoming the lingua Franca.
> ...manual loops instead of `map` and `reduce` and `filter`...
...you're free to implement such functions in a Zig/Odin/Nim library as well, but in the end it's just another way to loop over data, and inside your own implementation there will be regular loops, so why bake this stuff into the language when it can be done just as effciently in a library.
I'm waiting for the language and toolset to mature before I give it a serious chance. Not having an increment operator also is kind of disappointing. Why not name Odin C+=1?
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.