blog-comments
monadless
blog-comments | monadless | |
---|---|---|
1 | 4 | |
0 | 275 | |
- | 0.0% | |
0.0 | 0.0 | |
almost 6 years ago | 2 months ago | |
Scala | ||
- | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
blog-comments
-
Why asynchronous Rust doesn't work
This was a great article, very easy to understand without leaving out the fundamental pieces (the saga that is async implementation difficulty). I think I can even boil this situation down to Rust having it's Monad moment.
It's in this (HN) comment thread and a bunch of informed comments on the original article:
https://github.com/eeeeeta/blog-comments/issues/10#issuecomm...
https://github.com/eeeeeta/blog-comments/issues/10#issuecomm...
https://github.com/eeeeeta/blog-comments/issues/10#issuecomm...
The comments are correct in my view -- Rust can't/shouldn't do what Haskell did, which was to create use a general purpose abstraction that is essentially able to carry "the world" (as state) along with easy-to-trade chained functions on that state (whenever it gets realized). Haskell might have solved the problem, but it has paid a large price in language difficulty (perceived or actual) because of it, not mentioning the structural limitations of what Rust can do and it's constraints. The trade-off just isn't worth it for the kind of language Rust aims to be.
Realistically, I think this issue is big but not enough to write off rust for me personally (as the author seems to have) -- I'd just do the move + Arc shenanigans because if you've been building java applications with IoC and/or other patterns that generally require global-ish singletons (given example was a DB being used by a server), this isn't the worst complexity trade-off you've had to make, though the Rust compiler is a lot more ambitious, and Rust has a cleaner, better, more concise type system as far as I'm concerned.
I think another thing I've gained from this article is another nice little case where Haskell (if you've taken the time to grok it sufficiently, which can be a long time) offers a bit of a nicer general solution than Rust, assuming you were in a world where those two were actually even substitutes. In the much more likely world where you might compare Rust and Go2, this might be a win for Go2, but the rest of the language features would put rust on top for me.
monadless
- "A New Library For Imperative ZIO Programming" by Alexander Ioffe at Functional Scala 2022
-
Kind: A Modern Proof Language
Well `RecordWildcards` has been around for 14 years... but even without it instead of `{..}` you'd just have `_`s. The main thing that is different is that your Kind example had nested case statements while your Haskell example tried to match everything on one shot, which makes for a non-equivalent comparison.
> Not sure how that could work, though. Idris had an interesting syntax, but IIRC it wasn't general.
I assume you're talking about idiom brackets for applicatives? The general syntax is given in something like https://github.com/monadless/monadless. The idea is to basically take async-await syntax and generalize it to any monad.
So e.g. your `Maybe` example (using `!` for the equivalent of `await` for concision) would look like
Maybe {
-
Why asynchronous Rust doesn't work
> If anything, async-await feels like an extremely non-functional thing to begin with
It, like many other things, forms a monad. In fact async-await is a specialization of various monad syntactic sugars that try to eliminate long callback chains.
Hence things like Haskell's do-notation are direct precursors to async-await (some libraries such as Scala's monadless https://github.com/monadless/monadless make it even more explicit, there lift and unlift are exactly generalized versions of async and await).
What are some alternatives?
async-trait - Type erasure for async trait methods
py2many - Transpiler of Python to many other languages
ureq - A simple, safe HTTP client
Formality - A modern proof language [Moved to: https://github.com/kind-lang/Kind]
rupy - HTTP App. Server and JSON DB - Shared Parallel (Atomic) & Distributed
reqwest - An easy and powerful Rust HTTP Client
rust - Empowering everyone to build reliable and efficient software.
kind - Kubernetes IN Docker - local clusters for testing Kubernetes
hyper - An HTTP library for Rust