Hacker News new | past | comments | ask | show | jobs | submit

A NES emulator written in Odin

https://lucypero.com/lucynes.html
loading story #50512039
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.

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.
loading story #50510542
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:

    T someFn() throws E;
    fn someFn() -> Result<T, E>;
    func someFn() (T, E)
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.

loading story #50509596
What's the decision-making in choosing Odin over something similar like C3 or Zig?
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.

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.

loading story #50511323
Did not C3 basically render Odin useless? Its basically C that did not stagnate in the mid 90s.
loading story #50510877
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."
loading story #50510332
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.
loading story #50511906
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.