4 ms·
I'll stray from the others and mention Unison Lang. It's a whole new everything but has yet to prove itself useful for production code. Its promises, if they
by heliophobicdude 4y ago
I'll stray from the others and mention Unison Lang.
It's a whole new everything but has yet to prove itself useful for production code.
Its promises, if they pan out, could change how we design data-intensive applications. Its idea about code and data as content-addressable can help simplify some distributed workflows.
https://www.unison-lang.org/ https://www.unison-lang.org/
Great summary here: https://jaredforsyth.com/posts/whats-cool-about-unison/ https://jaredforsyth.com/posts/whats-cool-about-unison/
- thelazydogsback 4y agoThanks for the pointer -- looks like (OCaml/F#)++ with an effect system and some other niceties. I guess I'd rather go that way then enter the Scala effects mire. There are some obvious issues I didn't see up front (unless I missed them) - - How do content addressable fns and their codedabase integrate w/git (seems like it really has to for the time-being) - The usual: What's the execution model & perf characteristics? - I see it's written in Haskell, but don't know if it's interpreted or further transpiled, etc. - Debugger? Interop? - Type and efficiency of GC - Impl. of collection types - simple conses vs. HMAT or r/b trees, etc. A strongly-typed pluggable effect system like this should really replace in a more structured and powerful way what Python does today, which is really just to proxy out to efficient external libs (often written in native code, like Numpy or various AI engines, etc.) If Python is used for actual compute, you're adding several 0's to your runtime. So I'm curious if Unison is of that ilk, or can be used dependency-free for CPU-intensive (and in my case, non-numeric) workloads.