C-like performance with a lot of modern conveniences and fairly straightfoward syntax. Lots of vendored libraries included. Makes worse burgers than beef.
As someone who is primarily a Go dev, I never understood this criticism and have never seen a language do it any better (but I'm open to suggestions). I think try/catch is worse. I kinda like JS's promise syntax with the `.then()` and `.catch()`, but it doesn't appear that different to Go's approach.
Ahhhh, got it: enforced correctness. Fair enough, I can definitely see the benefit of that. I do wish Go had more ways to do that, like first-class enum support, exhaustive switch cases, and, yeah, forced error handling. golangci-lint does a lot of this heavy lifting on behalf of the Go compiler, but it would be nice to have the compiler enforce it.
Personally I think Go style is worse, because the runtime and compiler don't force you to handle the error. I just had to fix a critical issue because a dev forgot to check the result coming from a function, exceptions would have forced it to happen.
> I kinda like JS's promise syntax with the `.then()` and `.catch()`, but it doesn't appear that different to Go's approach.
These days async/await is first-class and the function-based callback form of promises is largely discouraged. And for, at least in part, the same reason: it's harder to enforce correctness.
True, Go does require you to follow a convention here (dont use T if err is not nil). In practice it works pretty well, though obviously not bullet proof.
I believe some exceptional languages are similar, like Ruby. If you rescue but dont abort, the variable on the left hand side gets a nil when that may otherwise not be possible. Of course, that is handled cleanly as its own error.
LLMs are pretty good at it, too. I recently had Haiku rewrite all of my Quickshell Linux UIs (dux) to Odin + an immediate mode GUI library: launcher, Niri bar, WiFi manager, process manager, lock screen, HUD audio/brightness, etc. Did all but the process manager in a day, while I was spending 99% of my time paying attention to my day job.
Anyway, Odin is my favorite of the new systems languages. Lightweight, ergonomic, decent stdlib. It’s quite good.
For the record, the library I used was Skald[0]. It's decent. Not 100% fully featured yet, but performant and fairly low resource, especially compared to Quickshell.
I have tried all three, and I chose Odin because I prefer the syntax (especially over Zig) and the vendored libraries are a killer feature for me. You get a lot of graphics, maths and gamedev-adjacent packages with the language, that can take you very far without having to shop for third-party packages.
Odin for me is the (low level) systems language nirvana, along with Elixir which is my distributed system nirvana. They spark so much joy.
It's always interesting when the article title betrays the author's origins. I assume the author speaks British English rather than American English, because they tended to pronounce "NES" and "SNES" as acronyms ("Ness" and "Sness"), while we Americans tended to treat them as initialisms ("En-ee-ess"). So to my American eyes, I would have expected "An NES emulator" instead of "A NES emulator."
Could also be native vs non-native English speaker. Especially in computing world, it's common for non-native English speakers to utilize American spelling/punctuation while grammar/pronunciation is influenced by their native language. This appears in this post, and, arguably, even the title. In many languages (incl. Spanish, probably author's native language) acronyms are read phonetically.
Related: What are other C-like or systems programming languages other than Odin, Zig, C3 and Hare?
I have checked out all 4 some, only by reading the docs and examples so far.
Uneasy about Zig because of docs lagging code, and syntax.
Hare is Linux only. Doable, but prefer Windows too.
Need to try Odin.
Other interesting langs in this space whih are at a somewhat usable state, including docs and libs? I don't need a package manager or an LSP or much other tooling.
For now this is just for developing small apps of my own.
Odin needs too recent LLVM versions to work. A pity this Reticulum client it's written on that,
because if it were written in Go it would be instantly portable to legacy machines:
On Odin itself, it looks really simple, and I'd love it
if it were self-bootstrapable or compilable with just
a C99 compiler like cparser, cproc or TCC.
Among all of those interesting learnings, I suspect they will soon be learning the legal code too. Nintendo of America defends its IP ferociously and too excess.
How does Odin compare with C++, Zig, or Beef?
C-like performance with a lot of modern conveniences and fairly straightfoward syntax. Lots of vendored libraries included. Makes worse burgers than beef.
i love odin.
- manual memory management
- arena and pool allocators
- go style err!=nill style exception handling
- first class support for soa and vectorized simd, linear algebra and swizzling
- sanely typed and namespaces
- explicit unambigious overloading, subroutine context
- first class support for defer statements
- zero friction C ffi
if you haven't heard of odin, you should definitely consider it.
> - go style err!=nill style exception handling
Is this not widely considered to be the ugliest part of the language? Why do you prefer having to do this manually?
As someone who is primarily a Go dev, I never understood this criticism and have never seen a language do it any better (but I'm open to suggestions). I think try/catch is worse. I kinda like JS's promise syntax with the `.then()` and `.catch()`, but it doesn't appear that different to Go's approach.
Returning Result/Options that the compiler forces you to check so you can't forget.
Common in ML-family languages and Rust. They've been brought into most mainstream languages like Java by now because of how useful they are.
Ahhhh, got it: enforced correctness. Fair enough, I can definitely see the benefit of that. I do wish Go had more ways to do that, like first-class enum support, exhaustive switch cases, and, yeah, forced error handling. golangci-lint does a lot of this heavy lifting on behalf of the Go compiler, but it would be nice to have the compiler enforce it.
I hope that doesn't mean the compiler inherits the extra work
I'm considering glojure as an interesting new hobby language to try because it's benchmarks are impressive
If the go compiler ends up bloating itself with checks its static analyser could/should have done it would be a shame
Odin has @(require_results) that forces you to do something with returned values (e.g. T, Maybe(T), (T, bool))
Where Maybe is a polymorphic union of T and nil but the core library returns either (T, bool) or (T, E) where E is an error enum.
Personally I think Go style is worse, because the runtime and compiler don't force you to handle the error. I just had to fix a critical issue because a dev forgot to check the result coming from a function, exceptions would have forced it to happen.
> I kinda like JS's promise syntax with the `.then()` and `.catch()`, but it doesn't appear that different to Go's approach.
These days async/await is first-class and the function-based callback form of promises is largely discouraged. And for, at least in part, the same reason: it's harder to enforce correctness.
It is, which is why the or_return[1] keyword was created.
[1]: https://odin-lang.org/docs/overview/#or_return-operator
Errors as values instead of some special language construct is generally a nice thing (IMO)
Exceptions are values. There's nothing different between:
In only one of those examples do you get a T that's invalid.
True, Go does require you to follow a convention here (dont use T if err is not nil). In practice it works pretty well, though obviously not bullet proof.
I believe some exceptional languages are similar, like Ruby. If you rescue but dont abort, the variable on the left hand side gets a nil when that may otherwise not be possible. Of course, that is handled cleanly as its own error.
I don't see how. Unless it's the Go example where you get (nil, err)?
LLMs are pretty good at it, too. I recently had Haiku rewrite all of my Quickshell Linux UIs (dux) to Odin + an immediate mode GUI library: launcher, Niri bar, WiFi manager, process manager, lock screen, HUD audio/brightness, etc. Did all but the process manager in a day, while I was spending 99% of my time paying attention to my day job.
Anyway, Odin is my favorite of the new systems languages. Lightweight, ergonomic, decent stdlib. It’s quite good.
For the record, the library I used was Skald[0]. It's decent. Not 100% fully featured yet, but performant and fairly low resource, especially compared to Quickshell.
[0] https://github.com/BuLEEto/Skald
What's the decision-making in choosing Odin over something similar like C3 or Zig?
I can't speak for the implementor. And for that matter I also don't know what facilities c3 and zig provide.
However Odin comes prepackaged with a lot of bindings for helpful 3rd party libraries. Likely makes this sort of work a lot less tedious.
I have tried all three, and I chose Odin because I prefer the syntax (especially over Zig) and the vendored libraries are a killer feature for me. You get a lot of graphics, maths and gamedev-adjacent packages with the language, that can take you very far without having to shop for third-party packages.
Odin for me is the (low level) systems language nirvana, along with Elixir which is my distributed system nirvana. They spark so much joy.
maybe stability or completeness?
C3 and Zig are still evolving. Not sure about Odin. Check it.
Why not just use C?
Did not C3 basically render Odin useless? Its basically C that did not stagnate in the mid 90s.
The hardware from this era is always super interesting. Having circuitry in cartridges + in the console is wild when you think about it.
Nice to see other languages being used :)
It's always interesting when the article title betrays the author's origins. I assume the author speaks British English rather than American English, because they tended to pronounce "NES" and "SNES" as acronyms ("Ness" and "Sness"), while we Americans tended to treat them as initialisms ("En-ee-ess"). So to my American eyes, I would have expected "An NES emulator" instead of "A NES emulator."
Could also be native vs non-native English speaker. Especially in computing world, it's common for non-native English speakers to utilize American spelling/punctuation while grammar/pronunciation is influenced by their native language. This appears in this post, and, arguably, even the title. In many languages (incl. Spanish, probably author's native language) acronyms are read phonetically.
I've also read people refer to the "Super Nintendo".
My friends and I in Germany always called them Nes and Super Nes.
I always heard it “nez” and “snez” actually (south western England)
And in the Midlands. Ness is Nessie's home.
Author is Argentinian, I guess they teach British English in schools out there.
Yeah in Argentina they probably teach the kids that NES is pronounced "ness" during English lessons.
Related: What are other C-like or systems programming languages other than Odin, Zig, C3 and Hare?
I have checked out all 4 some, only by reading the docs and examples so far.
Uneasy about Zig because of docs lagging code, and syntax.
Hare is Linux only. Doable, but prefer Windows too.
Need to try Odin.
Other interesting langs in this space whih are at a somewhat usable state, including docs and libs? I don't need a package manager or an LSP or much other tooling.
For now this is just for developing small apps of my own.
Odin needs too recent LLVM versions to work. A pity this Reticulum client it's written on that, because if it were written in Go it would be instantly portable to legacy machines:
https://github.com/Quad4-Software/Ren-TUI
Reticulum in Go:
https://github.com/Quad4-Software/Reticulum-Go
On Odin itself, it looks really simple, and I'd love it if it were self-bootstrapable or compilable with just a C99 compiler like cparser, cproc or TCC.
Among all of those interesting learnings, I suspect they will soon be learning the legal code too. Nintendo of America defends its IP ferociously and too excess.
What can Nintendo do if someone builds an emulator?
Yeah this is true all the other emulator authors are in jail.
Source: onion article
Yes, Nintendo famous for hunting down hobbyist NES emulators. Give me a break.