-
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
-
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.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
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`:
https://github.com/odin-lang/Odin/tree/master/core/sync
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.
0 https://github.com/ziglang/zig/issues/1097
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,
https://github.com/dlang/dmd/tree/master/druntime/src/core