Is async in Rust really this bad? Last time I used Rust was before that existed. I know it's a pain in Python because they bolted it on way after, but in JS it's a breeze because everything standardized on promises early.

▲

asa400 4 hours ago | parent | next [-]

> Is async in Rust really this bad?

No, it's not. It works. Perfect? No, absolutely not. There is plenty you could improve, plenty of rough edges you could smooth out. Stuff that caused us problems at the job I had writing low-ish level machine control services. But it's totally workable and we were able to ship working devices, especially compared to doing async stuff in other most other languages, especially the memory-unmanaged ones.

Kind of like Rust itself, a ton of people have tried it and bounced off it because they couldn't get it working in 10 minutes, and in doing so have declared it impossible/for geniuses only/broken/ecosystem-destroying. The narrative around async Rust is probably 70% meme/bad PR, 30% real, actual issues that could be improved.

I hope this comes off as fair. I don't want to excuse any of the shortcomings, but it's a working, useful tool.

	▲	tracker1 4 hours ago \| parent [-]
		Funny... I started off with very little knowledge, totally cheated with what I wanted to do by cloning everything crossing various library boundaries and it still worked surprisingly well. Then I learned about (A)RC, Box etc... and I still kinda really hate the lifetime syntax. Note: most of what I've used it for has been relatively simple... API's with tokio and axum in rust are emphatically not much more difficult than say C# with FastEndpoints, or JS/TS with Hono. It's a bit different.

▲

steveklabnik 5 hours ago | parent | prev | next [-]

Rust’s async makes some design decisions that make it a unique feature: no other language has zero allocations to do async, for example. (In C++’s version you can get it to do no allocations if you do certain things, like making the required allocator a no-op, in my understanding, but it conceptually requires a call to an allocator)

This makes it suitable for a much wider variety of tasks than other languages with similar features, but does mean that there are more details that you need to care about than in other languages that are higher level.

This means it is controversial: some people would prefer a higher level experience, but for those who do use it for its full range of tasks, it’s great.

There are some rough edges, but it’s just a feature that, even outside of Rust, some people just fundamentally dislike. So it draws a lot of heat from all sides.

It is also probably the single largest driver of adoption of the language. Rust started truly taking off once it landed.

	▲	tracker1 4 hours ago \| parent \| next [-]
		I can only speak for myself, but I kind of refused to get started with Rust until async landed... only because it's kind of a core of scalable services. I think it's pretty great in that you can use an async runtime, but still launce native threads if you want/need to for specific scenarios. It's pretty great and for most high level tasks, I wouldn't classify it as significantly more difficult than C#. A few other things I've done with it have been written by AI as much as myself... which has similarly been pretty nice... Rust code can be very easy to reason with (lifetime syntax not withstanding). For some reason Rust lifetimes burn my soul.
	▲	traderj0e 5 hours ago \| parent \| prev [-]
		"it’s just a feature that, even outside of Rust, some people just fundamentally dislike" is why I have a hard time gauging this. I know Python users whine about it endlessly just because it's a feature from JS, even though Python's existing concurrency features were the worst of both worlds. The Rust-specific async sounds interesting. I should give it a try.

▲

Aurornis 4 hours ago | parent | prev | next [-]

If someone finds normal ownership concepts in Rust to be difficult, making the leap to async is only going to make that worse.

I don't think it's friendly to Rust beginners but I also think the complaints about if have been overblown

▲

tracker1 4 hours ago | parent [-]

I think it depends on what you're doing... getting to a point where you understand Arc helps a lot, and if you're mostly using it with something like Axum, there's very little you need to worry about specific to lifetime or a lot of the burrowing logic in practice. You can definitely get by with less than perfect code.

	▲	Aurornis 4 hours ago \| parent [-]
		[dead]

▲

nothinkjustai 5 hours ago | parent | prev [-]

No it’s not bad at all. If you’re creating a library you might run into some hard problems, but for application code it’s pretty easy.