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

61–70 of 136 posts

Re: Rust without the async (hard) part

#61

Post by zaphar »

pornel wrote: post #54
zaphar wrote: post #3

Anything 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…

Rust used to have green threads before 1.0 (libgreen). Early Rust was meant to be more like Erlang[1]. The problem with them wasn't only the overhead, but also interoperability and how they affect every interaction of the language with the OS and other libraries. It made the whole language dependent on its own custom runtime. Rust isn't meant to be a language for CRUD apps (despite making inroads in this space). It's…

I'm aware of the history there. I think the decision not to ship a builtin async runtime was probably correct. I also think shipping async syntax sugar and allowing people to build their own custom runtimes is just fine.

I just think that the cultural decision in the wider ecosystem to make, practically speaking, everything io related, async is possibly a mistake.

Re: Rust without the async (hard) part

#62

Post by xrobledo84 »

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…

What you are looking for is called Erlang

Re: Rust without the async (hard) part

#63

Post by toolz »

jstx1 wrote: post #60
toolz wrote: post #58

Earlier quoted context omitted.

If you're trying to break into the industry you're not going to be working on problems that the language really matters. Pick a popular language, learn enough to be dangerous and specialize once you find categories of problems that interest you. Go and rust are only compared a lot because they're sexy buzzwords - they do not target the same problems and they aren't competing languages. Learning both at some point cou…

> they do not target the same problems and they aren't competing languages. Is this really true? All the problems that are solvable in Go should be solvable in Rust too right (but not vice versa because Go is GCed)? They might not compete on every front but there definitely should be overlap in the use cases.

There is a ton of overlap with every general purpose programming language. So it's correct to say you can solve the vast majority of problems with the majority of programming languages, but languages differentiate themselves in many different ways. One of the main differences between rust and go is that go is a garbage collected language. That feature alone typically creates a large divide in what languages are trying to achieve.

Re: Rust without the async (hard) part

#64

Post by geodel »

zaphar wrote: post #61
pornel wrote: post #54

Earlier quoted context omitted.

Rust used to have green threads before 1.0 (libgreen). Early Rust was meant to be more like Erlang[1]. The problem with them wasn't only the overhead, but also interoperability and how they affect every interaction of the language with the OS and other libraries. It made the whole language dependent on its own custom runtime. Rust isn't meant to be a language for CRUD apps (despite making inroads in this space). It's…

I'm aware of the history there. I think the decision not to ship a builtin async runtime was probably correct. I also think shipping async syntax sugar and allowing people to build their own custom runtimes is just fine. I just think that the cultural decision in the wider ecosystem to make, practically speaking, everything io related, async is possibly a mistake.

Well I think it happened because a large number of Rust committers, core-devs doubled down on multi-year Rust async effort. What larger ecosystem would take away from this?

IMO the message was Async is the future so everyone better hop on this train.

Re: Rust without the async (hard) part

#65

Post by estebank »

Animats wrote: post #55
dboreham wrote: post #23

Earlier quoted context omitted.

This "async virality" syndrome is the main reason why async is harmful imho. _Some_ async can be very useful in certain constrained circumstances, I believe. However forcing the async execution model on all code is a terrible idea.

Yes. I've been saying this for some time. I call it "async contamination". The async model assumes you spend most of your time waiting for your slow users to do something. (Why a web site, which is inherently stateless, should be doing that routinely is another issue.) I'm writing a metaverse client that has about 10-20 threads, many of them compute bound, running at different priorities. Works fine, but is totally d…

> Why a web site, which is inherently stateless, should be doing that routinely is another issue.

Because most web sites that would be doing this are not stateless? Any dynamic site will need to access a database, which means that the will be IO blocking, which means that given enough traffic the server will run out of available threads before being able to service the IO operations for all of these users. And because different parts of the website will likely have different DB load, you could easily cause a DoS by hitting an expensive endpoint repeatedly.

Re: Rust without the async (hard) part

#66

Post by api »

mikevm wrote: post #53
api wrote: post #41

Earlier quoted context omitted.

Great to hear! That's really the solution. Rust async code can be a bit challenging until you get it, but I can't think of a way to make it that much simpler without sacrificing the whole "systems programming language" concept or support for embedded. The only good alternative is Go-like fibers and that requires a fat runtime. We use both Rust and Go at ZeroTier and find that they both have their own niches. (We are…

Where do you use Go?

Backend to my.zerotier.com and internal analytics code.

Re: Rust without the async (hard) part

#67

Post by gjvnq »

duped wrote: post #26
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 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 the computer model and cpu architectures themselves.

We need something that is designed from scratch to run things concurrently.

Re: Rust without the async (hard) part

#68

Post by zokier »

Has anyone seen any recent solid benchmarks of thread per connection architecture web application? What is actually the break-point load where it's perf starts to regress and async really becomes useful?

Re: Rust without the async (hard) part

#69

Post by jstx1 »

toolz wrote: post #63
jstx1 wrote: post #60

Earlier quoted context omitted.

> they do not target the same problems and they aren't competing languages. Is this really true? All the problems that are solvable in Go should be solvable in Rust too right (but not vice versa because Go is GCed)? They might not compete on every front but there definitely should be overlap in the use cases.

There is a ton of overlap with every general purpose programming language. So it's correct to say you can solve the vast majority of problems with the majority of programming languages, but languages differentiate themselves in many different ways. One of the main differences between rust and go is that go is a garbage collected language. That feature alone typically creates a large divide in what languages are tryin…

I feel like you’re ignoring my point. The GC prevents Go from competing with Rust on some use cases. But that still leaves a lot of overlap of potential use cases and if your work falls in that region of use cases, you get to pick between the two languages (and a bunch of others too).

Re: Rust without the async (hard) part

#70

Post by brickbrd »

What does "stream.write_all(&number_as_bytes).unwrap();" do if the socket buffer is full? Does it block this virtual thread running this function? Or does the stream keep buffering? or is it sending the message to some other process which is accumulating those messages. What if I don't wait this thread to block and instead do something else?

I believe all of these are handled. I just cannot find sufficient documentation to understand the details of how this works.

Post reply on HN