Odin VS koka

There's also Odin[0] too. I tried using them all and Odin was pretty nice. Nim is also good too but a lot more features.

But - I concluded that language matters a lot less compared to APIs. Yes, the language should have enough good features to let the programmers express themselves, but overall well designed APIs matter a lot more than language. For example -tossing most of the C stdlib and following a consistent coding style (similar to one described here -[1]), with using Arenas for memory allocation, I can be just as productive in C.

[0] - https://odin-lang.org

I don't know about a list online but here's what I know off, in the C/C++ realm

Odin - https://odin-lang.org/

I highly recommend looking at:

* The Overview: <https://odin-lang.org/docs/overview/>

* examples/demo: <https://github.com/odin-lang/Odin/blob/master/examples/demo/...>

As for the first example: a basic lexing example is probably boring, but it does show some basic ideas of what the language is about. If people want to write better examples or just reorder the current ones, please feel free to make an issue or PR on the website's GitHub page: <https://github.com/odin-lang/odin-lang.org>.

There's also MojoLang[0] that brands itself as a alternative to Python, and Google will look to release Carbon soon as well. It'll be interesting to see how these two grow.

There's also Odin[1] that looks promising.

I don't think C# is going anywhere, F# on the other hand :shrug: is at the mercy of MS - they always seem to be on the fence about it.

[0] - https://www.modular.com/mojo

[1] - http://odin-lang.org/

You can try using Odin language: https://github.com/odin-lang/Odin

Odin shares some common ancestors with Go and has some similarities:

It also offers a great Inversion of Control mechanism where everything is customisable, and, unlike Capability Objects, AESs also offer compatibility with type inference (you can pass functions doing IO to map, and it Just Works(TM)) and first-class control over stack frames (because really a continuation function is just some stack frames, which you can manually move to the heap if you want a closure; which means async is an effect!). It also is composable in ways Monads are not.

Koka and other languages implementing Algebraic Effect Systems make everything a user-defined case of coroutines: async is just another effect/Monadic type. Zig does something similar by having first class stack frames, making all function calls possibly asynchronous.

Super interesting, there is a proposal to add this to JavaScript and several languages that use this, unison, koka & eff. I had no idea this was even a thing!

https://github.com/koka-lang/koka Algebraic effects and reference counting. https://github.com/mit-plv/koika hardware description DSL for coq

Koka, already cited in this thread, early 2010s. Koka's first claim to fame was a usable effect system (at the type were, basically, effect systems were not usable in practice; in fact few languages have managed to do as well as Koka since). Now its author is working on cool implementation strategies for functional languages as well.

I'm a software engineer with 3 years of professional experience. I worked for 2 years at Microsoft on Azure Compute and now work at Google, working on improving Google search. I am the sole maintainer of the popular open-source library microlens with 80k downloads. I've also contributed to the Koka programming language developed at Microsoft Research.

By implementing all of those optimizations in the Koka programming language, they achieved GC overhead much less and execution time faster than the other languages including OCaml, Haskell, and even C++ in several algorithms and data structures that frequently keep common sub-structures of them, such as red-black trees. For more information, see the latest version of the paper.

5) https://github.com/koka-lang/koka

Yes -- I think historically the power of condition handling was not well understood and algebraic effect handlers were a "rediscovery" coming from well-studied category theory (Plotkin, Power, and Pretnar).

If you want to play with "structurally typed condition handling", then the Koka language has "row-typed algebraic effect handlers" that compile to C: <http://koka-lang.org>