[deleted]
Rust without the async (hard) part
11–20 of 136 posts
Re: Rust without the async (hard) part
#12> However, if you are doing web apps or any networking stuff, massive concurrency benefits are almost always too important to ignore My problem is more that even if I don't need massive concurrency (say in a client that only talks to a single server, in a serial manner), I'm still more or less forced into async code because that's what the ecosystem switched to. No matter if you benefit from async or not, not using i…
There are still good synchronous alternatives, e.g. tiny_http for serving, and just binding libcurl for requests, but I agree it is becoming harder to avoid async.
Re: Rust without the async (hard) part
#13This sounds like what I'm looking for for building a set of networking/pentest tools. Ie, being able to spawn an arbitrary number of IO bound processes without the overhead of OS threads, and the contagion and fracturing of Async. There may still be some fracturing here, ie in the first example (but not the others, inexplicably?) `lunatic::net` vice `std::net`.
Hi, author here. All examples should have used `lunatic::net`, I fixed it now.
The reason why we provide `lunatic::net` and you can't just use `std::net` is that WASI (system interface for WebAssembly) still doesn't have support for sockets[0]. `lunatic::net::TcpStream` is for now just a drop in replacement for `std::net::TcpStream` and once sockets get standardised you will be able to use the standard library types instead.
Re: Rust without the async (hard) part
#14> However, if you are doing web apps or any networking stuff, massive concurrency benefits are almost always too important to ignore No, you will benefit from parallelism/multithreading. Why only use 1 core? Multitasking as it was once called, or "async" as it is now, is fundamentally _synchronous_ because everything still happens on one core. Just that the order of execution may be a bit wonky, which technically all…
Tokio has a multi-threaded scheduler.
Re: Rust without the async (hard) part
#15Anything using the green/lightweight or OS thread model is usually easier to use at the cost of some runtime performance. Whether the runtime performance matters for your use case can only be determined by measuring stuff. The perception that async rust is where you should start for concurrent rust because it's built in and everyone uses it perhaps should be revisited. I would argue that the other options are worth c…
Too many major packages in the ecosystem only support an async model now. It's pretty frustrating if you are just writing a synchronous program, or one with a straightforward OS threading model.
Re: Rust without the async (hard) part
#16> However, if you are doing web apps or any networking stuff, massive concurrency benefits are almost always too important to ignore No, you will benefit from parallelism/multithreading. Why only use 1 core? Multitasking as it was once called, or "async" as it is now, is fundamentally _synchronous_ because everything still happens on one core. Just that the order of execution may be a bit wonky, which technically all…
Almost all async Rust runtimes use a multithreaded work stealing schedulers by default, to equally utilise all available cores.
Re: Rust without the async (hard) part
#17Meanwhile, GoLang allows thousands of threads without problems.
Re: Rust without the async (hard) part
#18Meanwhile, GoLang allows thousands of threads without problems.
[deleted]
Re: Rust without the async (hard) part
#19I use Rust for the amazing types, map/filter/reduce, and, even if I never write macros myself, beautiful libraries like serde and clap. I do need to often use async to wait for multiple network requests at once, although I'm not quite comfortable with it.
Requesting urls n-at-a-time took me a while (https://play.rust-lang.org/?version=stable&mode=debug&editio...). In particular rust-analyzer itself cannot figure out `buffer`'s type here.
You can consider me very intrigued by Lunatic.
Re: Rust without the async (hard) part
#20> However, if you are doing web apps or any networking stuff, massive concurrency benefits are almost always too important to ignore No, you will benefit from parallelism/multithreading. Why only use 1 core? Multitasking as it was once called, or "async" as it is now, is fundamentally _synchronous_ because everything still happens on one core. Just that the order of execution may be a bit wonky, which technically all…
Even if you use N cores, you still get a massive benefit from being able to let >N threads wait on IO events simultaneously using concurrency/multitasking/async.