blog-comments
ureq
blog-comments | ureq | |
---|---|---|
1 | 7 | |
0 | 1,569 | |
- | - | |
0.0 | 8.5 | |
almost 6 years ago | 4 days ago | |
Rust | ||
- | 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.
ureq
-
Thermostat Control for Ecobee
I also enjoyed using ureq as an http client.
-
An HTTP request parser with rust and pest.rs
After a quick check of the available rust http client libraries I opted for reqwest. It has a pretty simple API and it seems to be among the most used libraries for this matters. But I'm a bit concerned about all its dependencies so I might try ureq later.
- Why asynchronous Rust doesn't work
-
HTTP-client agnostic crate
Async is only useful when you have hundreds of connections open at the same time and idling most of the time; otherwise it's a liability. If your web API does not allow that (e.g. it has rate-limiting, which most APIs do), I suggest going with a client that performs blocking I/O and spawning threads if you need parallelism. https://github.com/algesten/ureq should fit the bill.
-
Client/Server Communication Help
I think you'll find a lot of people claiming its overkill, but it will have excellent documentation for both sides, offer reasonable speed, and let you hash out the actual logic of your system without worrying too much about if your low-level implementation is correct. Two good frameworks for the server would be Actix or Rocket. For the client, i'd reccomend either using reqwest or ureq. From there, you can just set up a few POST endpoints, and get to going.
-
http client facade library?
If you want an HTTP client with few dependencies and little unsafe code, take a look at https://github.com/algesten/ureq
-
Tokio, the async runtime for Rust, hits 1.0
Give ureq a try: https://github.com/algesten/ureq
What are some alternatives?
monadless - Syntactic sugar for monad composition in Scala
reqwest - An easy and powerful Rust HTTP Client
async-trait - Type erasure for async trait methods
hyper - An HTTP library for Rust
curl-rust - Rust bindings to libcurl
rust-http-clients-smoke-test
teepee - Teepee, the Rust HTTP toolkit
smol - A small and fast async runtime for Rust
surf - Fast and friendly HTTP client framework for async Rust
tokio - A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
async-std - Async version of the Rust standard library
rust - Empowering everyone to build reliable and efficient software.