blog-comments VS hyper

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.

> If you are equally picky and constrain yourself to parts of the ecosystem which care about binary size, you still have more options and can avoid size issues.

What's an example of this for, say, libcurl? On my system it has a tiny number of recursive dependencies, around a dozen. [0] Furthermore if I want to write a C program that uses libcurl I have to download zero bytes of data ... because it's a shared library that is already installed on my system, since so many programs already use it.

I don't really know the appropriate comparison for Rust. reqwest seems roughly comparable, but it's an HTTP client library, and not a general purpose network client like curl. Obviously curl can do a lot more. Even the list of direct dependencies for reqwest is quite long [1], and it's built on top of another http library [2] that has its own long list of dependencies, a list that includes tokio, no small library itself.

In terms of final binary size, the installed size of the curl package on my system, which includes both the command line tool and development dependencies for libcurl, is 1875.03 KiB.

[0] I'm excluding the dependency on the ca-certificates package, since this only provides the certificate chain for TLS and lots of programs rely on it.

[1] https://crates.io/crates/reqwest/0.11.24/dependencies

[2] https://crates.io/crates/hyper/0.14.28/dependencies

hyper-based HTTP server generating JSON responses. Written in Rust.

tokio / hyper / toml / serde / serde_json / json5 / console

Using Rust here was immensely helpful, using libraries made by the community like https://github.com/hyperium/hyper really powered up the development of Signway, so glad to see this kind of awesome crates made public. Hope that it continues to be like that despite the current controversies.

- Discord sends a slightly weird request by specifying content length (a bug in hyper we've not yet upgraded to fix, https://github.com/hyperium/hyper/commit/fb90d30c02d8f7cdc9a643597d5c4ca7a123f3dd)