likeabbas

Async ruined rust and I’ll stand by that until I die

I haven’t moved any goal posts - I’ve coded async rust and is miserable compared to normal rust with threads. That has been my point which is why I started down this project.

My entire goal is to show that coding the same server with pre-async hyper vs post async hyper is nicer and more performant than async rust. I hope to show you it in just a few days.

Yes - brain fart.

You literally can't use one of the other async run times because of the current state of async/await does not allow library authors to easily write for multiple runtimes - they were written for one runtime in mind and that is just tokio. And if you're pulling in library methods you're still stuck with the method headers they specify.

All of your arguments are just mental workarounds trying to justify how fucked the rust ecosystem is for traditional backend services.

The project I'm working on is specific to making traditional kernel threads faster (150-200 nanosecond context switches compared to 1500-2000 nano seconds for normal kernel threads). It requires a user scheduler but you can swap those out without any changes to how you write rust. In my testing, it's not only faster than async rust but also much easier to write. I hope it convinces people like you, that are hell-bent on defending the current state of async rust, that there are better paradigms and we don't have to be locked in to shitty, verbose concurrent code.

I completely disagree. Having to make sure every little function is Send + Sync + lifetime even if it doesn't need it is fucking hell. writing concurrent code with plain kernel threads is so much easier to write and read.

If you just want to build a normal backend service, you can't escape async libraries. Wrapping the async functions with `block_on` is not ideal I'd rather just have access to standard sync primitives that don't need me to bring an entire async runtime into the system.

My ultimate point is - I would be happy if async stayed in its own world. But the fact is async has completely polluted the rust library landscape and you can't escape it. I'm working on a project that I hope to show rust users that async isn't needed for performant backend services, and that the code can be written much simpler without it.

Thank you for this! This is really helpful.

The UMCG implementation allows kernel thread context switches to happen in 150-200 microseconds, compared to the 1500-2000 microseconds for normal kernel thread context switches. My goal is to show that if UMCG could be merged into the Linux run time then then it would be competitive with async rust without the headache.

you’re talking to the core of the issue. In no other language did they try to satisfy the case of running on an embedded system vs general purpose computing. Async rust tried to, and came up with a solution that is not great for the majority of programmers writing rust.

I wish to God that the rust library devs would admit to this fact - say that async rust should stay for embedded runtimes usecases, but we shouldn’t be forcing async across the majority of general purpose computing libraries. It’s just not a pleasant experience to write nor read. And it really doesn’t give any performance benefits.

I'll have to check my work computer on Monday. It was 8 cpu virtual machine on a m1 Mac. the UMCG and normal threads were 1024 set on the server, the Tokio version was 2 threads per core. Just from the top of my head - the I/O bound requests topped out around 40k/second for the Tokio version, 60k/second for the normal hyper version, and 80k/second for the UMCG hyper version.

I'm pretty close to being done - I'm hoping to publish the entire GitHub repository with tests for the community to validate by next week.

UMCG is essentially an open source version of Google Fibers, which is their internal extension to the linux core for "light weight" threads. It requires you to build a user space scheduler, but that allows you to create different types of schedulers. I can not remember which scheduler showed ^ results but I have at least 6 different UMCG schedulers I was testing.

So essentially you get the benefits of something like tokio where you can have different types of schedulers optimized for different use cases, but the power of kernel threads which means easy cancellation, easy programming (at least in rust). It's still a linux thread with an entire 8mb(?) stack size, but from my testing it's far faster than what Tokio can provide, without the headache of async/await programming.

I have some test code that runs a comparison of Hyper pre-async (aka thread per request) vs async (via Tokio), and the pre-async version is able to process more requests per second in every scenario (I/o, CPU complex tasks, shared memory).

I'll publish my results shortly. I did these as baselines because I'm testing finishing the User Managed Concurrency Groups proposal to the linux kernel which is an extension to provide faster kernel threads (which beat both of them)

There's an attempt to make linux kernel threads context switching much faster (150-200us vs 2500-3000us) and if that happens, I'll really hope the rust community pivots from Async for backend development to normal threading. And if that happens, I'll happily use Rust like I used to.

null safety is very nice. But @Nullable and @NotNull annotations have worked very well for me so far.

If you're building tools that need to be deployed to machines, Go/Rust with their static binaries make a lot of sense. But for backend web services, it's hard not to go with Java imo.

fwiw - My favorite language is Rust, but Async Rust has ruined it for me.

My company is trying to force Kotlin as the default, but I just prefer modern Java tbh. Kotlin is a very nice language, and I'd be fine with writing it, but modern Java just seems like it has "caught up" and even surpassed Kotlin in some features lately.

Java 21 is pretty damn nice, 25 will be even nicer.

For your own application code, you don't have to use exceptions you can write custom Result objects and force callers to pattern match on the types (and you can always wrap library/std exceptions in that result type).

Structured Concurrency looks like a banger of a feature - it's what CompletableFuture should've been.

VirtualThreads still needs a few more years for most production cases imo, but once it's there, I truly don't see a point to choose Go over Java for backend web services.

It's not a fashion statement, it's a fucking deathwish

What part of the passage confirms GP's (who's GP?) statement? Again, I can't paste the entire 64 page bill in a hacker news comment. You have to do some effort to read the bill to figure out what they're talking about.

I pasted a link to the bill for everyone to read. You're expecting me to paste the entire 64 page bill in a hacker news comment?

Why do you assume I'm gullible? just because I'm a bit more open-minded than you?

It's one of the most comprehensive pieces of legislation in the last decade, and people just completely ignored it.

Why would some Von Newman probes colonize us instead of just observing?

We peaked in our radio frequency output in the 60s. It might be smarter to limit your technosignatures once you reach a certain point of technology.

It's not automatically assumed, and that's the conversation we're trying to change.

I apologize, I just had surgery a few days ago. My recovery isn't going as quickly as planned..

Now, I still recommend reading that proposed legislation because it sets the context up for these other links.

* Loose Threads PDF https://www.docdroid.net/3sZ9MaI/loose-threads-pdf (very, very long read) * Ratcliffe July 2023 https://twitter.com/highpeaks77/status/1685669297308282881 * Ratcliffe January 2023 https://twitter.com/UAPJames/status/1614644671589892101 * Ratcliffe June 2021 https://www.youtube.com/watch?v=pPDeuy_YSs0 * HOC Hearing July 26, 2023 https://www.youtube.com/live/SNgoul4vyDM?si=oBkDt3j63uDL63Tr * HOC Hearing Nov 13, 2024 https://www.c-span.org/video/?539937-1/hearing-unidentified-...

You really think the Senate Majority Leader would risk his reputation on a 60 page bill that references "non-human intelligence" 20+ times a misdirection? The only misdirection I see is your ignorance

Maybe if you would read the entire bill before commenting you'd realize that your comment is completely wrong.

I'm not going to stop what I'm doing because some closed-minded person told me to.

These politicians are not experts, but the witnesses that have testified under oath are.

Lue Elizondo - GS15 officer at the DIA, who's last assignment was running Special Access Program for the National Security Council.

David Grusch - GS15 officer at NRO then NGA who handled the Presidential Daily Briefing for the NGA (meaning he was cleared to thousands of SAPs to consolidate information and brief the president)

[Karl Nell](https://www.linkedin.com/in/karl-nell-98203510/details/exper...) - too many positions to list, but one of the most notable was being a senior technical advisor to the Army's future command.

I don't disagree that congress gets lost in conspiracy theories, but almost never do people pandering those testify under oath in public, or privately to the intelligence committees or ICIG. You should open your mind and take a deeper look than the headlines.

You can start with this bill that Senate Majority Leader Schumer and Senator Mike Rounds put out this year (and last year) https://www.congress.gov/118/crec/2024/07/11/170/115/CREC-20...

I have to get started with work, but I will come back and give you all the links I have once I get home to my personal laptop.

In the context of that bill, it does.

> NON-HUMAN INTELLIGENCE.—The term ‘‘non-human intelligence’’ means any sen- tient intelligent non-human lifeform regard- less of nature or ultimate origin that may be presumed responsible for unidentified anom- alous phenomena or of which

> You have to believe all the steps that make intelligent space-faring life elsewhere come into being

I would argue that it's very selfish thinking we would be the only intelligent life in the universe, let alone our own galaxy. If you're throwing out the entire argument based on that presumption, then this conversation is pointless.

Science is about optimism to learn what we don't know. There are things in the sky that we can't identify, as Obama has said https://www.youtube.com/watch?v=u1hNYs55sqs We should be open to the idea of all possibilities, rather than dousing fire on it.

I'm a researcher in this area if anyone wants to have a proper conversation. I'm 95% convinced that the major powers of the world have recovered crashed/landed non-human intelligence craft.

Before anyone responds to this comment, I would urge you to watch this video of Majority Leader Schumer and rising republican leader Mike Rounds giving a soliloquy on the senate floor to try to pass their UAP Disclosure Act and ask yourself - why would two senate leaders put their credibility on the line to try to pass a bill that references non-human intelligence 21 times?

https://www.youtube.com/watch?v=Z8a0P617nqw&t=93s

And, I would urge you to read the bill. It's one of the most comprehensive pieces of legislations that has been put out this decade https://www.congress.gov/118/crec/2024/07/11/170/115/CREC-20...