Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust without the async (hard) part

lunatic.solutions

Post reply on HN
Print view View original

101–110 of 136 posts

Re: Rust without the async (hard) part

#101

Post by jen20 »

hu3 wrote: post #82
jen20 wrote: post #78

Earlier quoted context omitted.

Yes, it does matter. It has excellent throughput and latency for certain classes of systems, while others are impossible to build. Rust may not impose this constraint while meeting its goals.

Seems like Rust is better in every way right? I can't help but wonder why is it that Go is so much more popular when it comes to language of choice for networked and multi-threaded applications.

It's not better in every way at all - it is more flexible. I regularly bounce between Go and Rust in different contexts.

Re: Rust without the async (hard) part

#102

Post by Georgelemental »

slightknack wrote: post #76
jen20 wrote: post #72

Earlier quoted context omitted.

What would you prefer the alternative to be? Library authors to do dual implementations of everything?

A language with a function-color-agnostic effect system, generic over asynchronicity?

https://news.ycombinator.com/item?id=31620340

Re: Rust without the async (hard) part

#103

Post by int_19h »

woah wrote: post #98
Matthias247 wrote: post #81

> The problem is that threads just don’t work in practice for massive concurrency. That's an assumption that is repeated very often recently, and measured very rarely. Truth is that they amount of applications for which they don't work is surprisingly low. I'm working at a well known cloud provider, and lots of people would really be suprised which applications at largest scale are working fine with a thread-per-requ…

Why would you assume that all software is written for servers in datacenters? Rust tends to be used in embedded devices, WASM, and other weird contexts where there might not be as many resources available. If you're writing a CRUD app, sure, do it in PHP and spin up a thread per request.

Embedded is much less likely to need async in the first place at all.

Re: Rust without the async (hard) part

#104

Post by duped »

gjvnq wrote: post #67
duped wrote: post #26

Earlier quoted context omitted.

I just want to say there are mountains of research on this, and recent development is exciting, but some of the techniques (like stack switching and moving) are very old. Project Loom is very intriguing because of how it solves the practical problems of introducing old concurrency techniques into existing language implementations that were not designed around them. A lot of this stuff is intriguing from the implement…

> imho the issue isn't function coloring, threads, whatever. It's a compiler that defaults to async code in the calling convention and then optimization passes to de-async-ify (remove unnecessary yield points) the code at compile time. The result would be code that looks synchronous but is async where it matters (i/o). Sounds like Erlang and single assignment languages. Jokes aside, part of the problem seems to be th…

Concurrency is mostly a higher level abstraction than the ISA, they don't care what the stack pointer is pointing to or what the return address is. Actually implementing concurrency efficiently is a solved problem, both in the trivial (stack less) and more complex (stackful) cases.

And that's sort of my point, concurrency primitives are really easy to define and implement but pretty hard to use by programmers up the stack.

Re: Rust without the async (hard) part

#105

Post by vips7L »

amelius wrote: post #73
smilekzs wrote: post #71

Earlier quoted context omitted.

FTFY: thousands of GREEN threads

Does it matter? The point is that Go has excellent throughput and latency, while using only a single concurrency model.

What happens if you need to do computational work on a go routine? Isn’t that going to block the carrier thread and then murder throughput?

Re: Rust without the async (hard) part

#106

Post by bsder »

Matthias247 wrote: post #81

> The problem is that threads just don’t work in practice for massive concurrency. That's an assumption that is repeated very often recently, and measured very rarely. Truth is that they amount of applications for which they don't work is surprisingly low. I'm working at a well known cloud provider, and lots of people would really be suprised which applications at largest scale are working fine with a thread-per-requ…

> > The problem is that threads just don’t work in practice for massive concurrency.

> That's an assumption that is repeated very often recently, and measured very rarely.

I would go further--there is a whole infrastructure that needs to appear when massive concurrency is involved and very few times is that taken into account.

For those people interested in genuine massive concurrency, I encourage people to investigate Erlang. In my opinion, the language itself is just "meh", but OTP, the infrastructure around managing, upgrading, restarting, etc. processes/threads, is extremely on point.

Side note: Erlang still has the absolute best handling of binary parsing of any language ever. https://www.erlang.org/doc/programming_examples/bit_syntax.h...

I really wish the Rust people would pick something like the Erlang Bit Sytax up and integrate it with their pattern matching (probably necessitating some pattern matching language fixes) rather than the amount of effort they continue to piddle on async/await.

Re: Rust without the async (hard) part

#107

Post by lalaithion »

bruce343434 wrote: post #34
lalaithion wrote: post #20

Earlier quoted context omitted.

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.

There's only so much a "apache" or "nginx" can do though in between io operations right? And there's only so much io per second a whole system can do. Basically, from disk to memory, maybe run a language interpreter if the site is not static, then from memory to the internet. Maybe if your pages are very dynamic and involve a lot of scripts it could be worthwhile. Do you have any numbers to back up your claim?

I don’t have a reference offhand to hard numbers, but I’ve definitely run webservers which have a significantly higher number of concurrent in-flight requests than number of cores.

Even for a static site, what you’re basically doing is

    page = readFile(“foo.txt”)
    response.write(page)
That’s no CPU usage at all. ~Zero time spent in process. All the time is spent waiting on the data to be loaded into memory from disk, and then copied from memory out onto the network. If you use concurrency for those two functions, then you can handle ~100s of in-flight requests at the same time.

Re: Rust without the async (hard) part

#108

Post by IshKebab »

vips7L wrote: post #105
amelius wrote: post #73

Earlier quoted context omitted.

Does it matter? The point is that Go has excellent throughput and latency, while using only a single concurrency model.

What happens if you need to do computational work on a go routine? Isn’t that going to block the carrier thread and then murder throughput?

Yes, you have to manually insert yield points. Exactly the same as with every cooperative threading system, including Lunatic and Rust's native async/await.

Kind of feels like we need user space preemptive threading somehow.

Re: Rust without the async (hard) part

#110

Post by ghoward »

verdagon wrote: post #21

Does anyone else get the feeling that we (as a field) are missing something basic about concurrency? Like there's a really elegant solution just around the corner, that has the low overhead of async/await without the complexity. Or otherwise put, the ease of goroutines but without GC. I know it sounds crazy. I recently dove into the area, and was pretty surprised at how many interesting building blocks there are out…

I'm betting on structured concurrency. I think it will be the same sort of revolution for concurrent programming that structured programming was for single-threaded programming.
Post reply on HN