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.
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.
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.
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.
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?
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:
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.
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.
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.
Did not C3 basically render Odin useless? Its basically C that did not stagnate in the mid 90s.
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 always heard it “nez” and “snez” actually (south western England)
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.
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.