sokol-odin VS nim-chronos

* 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:

* https://github.com/floooh/sokol-odin/blob/main/sokol/gfx/gfx... (and the rest)

I maintain auto-generated bindings for my C libraries for Zig and Nim (and Odin and Rust - although the Rust bindings definitely need some love to make them a lot more idiomatic).

I think looking at the examples (which is essentially the same code in different languages) gives you a high level idea, but they only scratch the surface when it comes to language features (things like the Zig code not using comptime features):

Zig: https://github.com/floooh/sokol-zig/tree/master/src/examples

Nim: https://github.com/floooh/sokol-nim/tree/master/examples

Odin: https://github.com/floooh/sokol-odin/tree/main/examples

Rust: https://github.com/floooh/sokol-rust/tree/main/examples

I'm actually dabbling with Odin a bit in the scope of language bindings for the sokol headers:

https://github.com/floooh/sokol-odin

It's a very enjoyable language!

I recently wrote a bindings generator to Odin for my C libraries, and the FFI is very well thought out, down to defining things like linker dependencies in the code. For instance see here:

https://github.com/floooh/sokol-odin/blob/main/sokol/gfx/gfx...

The only minor downside (compared to Zig) is that Odin still requires a separate C/C++ toolchain to actually build the C dependencies. But I guess that's a typical 1st-world-problem ;)

(but AFAIK Odins FFI system isn't in any way related or depending on LLVM).

Ones that have not been mentioned so far:

nlvm is an unofficial LLVM backend: https://github.com/arnetheduck/nlvm

npeg lets you write PEGs inline in almost normal PEG notation: https://github.com/zevv/npeg

futhark provides for much more automatic C interop: https://github.com/PMunch/futhark

nimpy allows calling Python code from Nim and vice versa: https://github.com/yglukhov/nimpy

questionable provides a lot of syntax sugar surrounding Option/Result types: https://github.com/codex-storage/questionable

ratel is a framework for embedded programming: https://github.com/PMunch/ratel

cps allows arbitrary procedure rewriting to continuation passing style: https://github.com/nim-works/cps

chronos is an alternative async/await backend: https://github.com/status-im/nim-chronos

zero-functional fixes some inefficiencies when chaining list operations: https://github.com/zero-functional/zero-functional

owlkettle is a declarative macro-oriented library for GTK: https://github.com/can-lehmann/owlkettle

A longer list can be found at https://github.com/ringabout/awesome-nim.

don't forget your fourth option: chronos