whitim · HackerTrans

Interesting project. Koka does have great interop with C code. An async library has existed in the past, and will likely be reintegrated soon. Unfortunately that will most likely be backed by the LibUV event loop which is not WASM compatible. However, Koka's delimited continuation machinery does not require stack suspension or stack swapping at all. All it requires is a bit of thread local state. Koka builds up continuations through a series of function pointers and closure state, and only when needed. So theoretically all you need is some sort of event loop.

whitim

há 3 anosdiscuss

Yes, essentially. Theoretically it could outperform Rust since it has aggressive local reuse of to-be-freed memory. Several papers have shown that it gets close to or outperforms C in some benchmarks. Whether this holds in practice is up for debate, but if you don't have to annotate lifetimes and don't have to manually manage memory, are you really going to care if you are 5% slower than C? There is a lot of performance optimizations still available for Koka to target as well. So far they've just taken the lowest hanging fruit (memory management).

whitim

há 3 anosdiscuss

I think that it is poised for rapid growth this year. I've been using it quite a bit, and once it gains a more comprehensive standard library, I think it will be much more useful in practice. Given the activity on GitHub, I would suggest checking back in a few months for a more out-of-the-box experience (it will still be a new language - but more ready to entertain serious projects). However, I would give it a try now if it looks interesting to you, install the VScode extension, look through some samples and leave some feedback on github.

As a side note, it has pretty great C interop, so you should be able to use C libraries or your own C code, for missing functionality. Documentation on this feature is unfortunately lacking right now though.

whitim

há 3 anosdiscuss

Koka currently uses the same approach that it does for compiling to C. It essentially does a very efficient low level monadic translation of a delimited control monad. So basically it all just ends up as a tiny bit of thread local state, and building up continuations on returns from functions if they are yielding.

See this paper for details, it gives a good high level overview before diving into the nitty gritty: https://www.microsoft.com/en-us/research/publication/general...

whitim

há 3 anosdiscuss

I would say that research language is an appropriate description currently. For example it has very little standard library. Though I would say that it is well positioned to take off in the next year with several important improvements coming soon.

whitim

há 3 anosdiscuss

Agreed, Koka has great documentation, although I will acknowledge that it is incomplete. The papers are suprisingly approachable with good user applicable examples and motivation before they get too deep into type theory etc. I recommend reading a few of the more recent ones, which have mind blowing implications.

https://www.microsoft.com/en-us/research/publication/fiptree... https://www.microsoft.com/en-us/research/publication/tail-re... https://www.microsoft.com/en-us/research/publication/fp2-ful...

whitim

há 3 anosdiscuss

Effects can pile up for sure, but with Koka's effect polymorphism it is actually quite a bit less than I first expected. (I've been contributing to Koka recently, and writing a lot of Koka code). Type aliases for effects that are commonly used together also help with typing. With the strong typing discipline and good type inference it is actually quite easy to make your code a lot cleaner than other languages in my opinion. You don't have as much boilerplate such as those introduced by monad transformers in Haskell, and since everything is purely functional it is a lot easier to reason about than other languages.

whitim

há 3 anosdiscuss

The `run` function is actually quite optimized in Koka. At the point of the call to an effect function there is a O(1) lookup, due to this paper (https://www.microsoft.com/en-us/research/publication/general...).

After that depends on whether a continuation actually needs to be captured or not. Many useful effects can be implemented as `val` or `fun` clauses which can be called / accessed in place without any unwinding of the stack. Only in cases where a continuation is required is the continuation built up.

comments