Our great sponsors
-
v
Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation. https://vlang.io
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
zig
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
Odin has numerous concurrency primitives in the core library. And the synchronization primitives are based on a the modern construct of a `Futex`:
Well, such things can be subjective. Yes, Odin does not do concurrency and channels. This appears to be because Odin doesn't do automatic memory management, and has more limits on the language, in terms of focus.
My understanding is that Odin does not plan to ever attempt to put concurrency nor channels into the language. It looks like that some type of workaround, if it ever happens, will have to be implemented by a 3rd party library.
It should be added, Vlang (another Go alternative) because it was designed for various memory management options (both automatic and manual), does do concurrency and channels (https://github.com/vlang/v/blob/master/doc/docs.md#concurren...). Vlang aims to be more general purpose versus more specific.
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).
I'm happy to see Odin chose snake_case instead of camelCase. At one time Zig debated switching to snake case, but that ship has sailed [0], sadly.
It seems like a small bike-shed level comment, but when I consider the code I have left in me, I'd like it to look as nice as possible.
You state that as a blank and white fact, but there's nuance.
https://github.com/lotabout/skim/issues/317#issuecomment-652...
Here, a GC implemented in Oberon, a GC enabled systems programming language,
https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...
For something more modern in D, also a GC enabled systems programming language,