duped (u/duped) - Readit News

duped commented on Ergonomic errors in Rust: write fast, debug with ease, handle precisely gmcgoldr.github.io/2025/0... · Posted by u/garrinm

echelon · 16 hours ago

Are all of these proc macros worth it? The compile times for proc macros explode.

I'd rather hand-roll errors than deal with more proc macros. Or better yet, have code gen pay the cost once and never deal with it again.

duped · 13 hours ago

Frankly, std::io:Error::other is good enough most of the time.

duped commented on Io_uring, kTLS and Rust for zero syscall HTTPS server blog.habets.se/2025/04/io... · Posted by u/guntars

hobofan · 2 days ago

> The only guarantees in Rust futures are that they are polled() once and must have their Waker's wake() called before they are polled again.

I just had to double-check as this sounded strange to me, and no that's not true.

The most efficient design is to do it that way, yes, but there are no guarantees of that sort. If one wants to build a less efficient executor, it's perfectly permissible to just poll futures on a tight loop without involving the Waker at all.

duped · 2 days ago

Let me rephrase, there's no guarantee that a poll() is called again (because of cancel safety) and in practice you have to call wake() because executors won't reschedule the task unless one of their children wake()s

duped commented on Go is still not good blog.habets.se/2025/07/Go... · Posted by u/ustad

traceroute66 · 2 days ago

> Rust intentionally chooses to have a small standard library to avoid the "dead batteries" problem.

There is a difference between "small" and Rust's which is for all intents and purposes, non-existent.

I mean, in 2025, not having crypto in stdlib when every man and his dog is using crypto ? Or http when every man and his dog are calling REST APIs ?

As the other person who replied to you said. Go just allows you to hit the ground running and get on with it.

Having to navigate the world of crates, unofficially "blessed" or not is just a bit of a re-inventing the wheel scenario really....

P.S. The Go stdlib is also well maintained, so I don't really buy the specific "dead batteries" claim either.

duped · 2 days ago

Do you think C and C++ should have http or crypto in their standard libraries?

duped commented on Io_uring, kTLS and Rust for zero syscall HTTPS server blog.habets.se/2025/04/io... · Posted by u/guntars

newpavlov · 2 days ago

>That problem exists regardless of whether you want to use stackful coroutines or not. The stack could be freed by user code at anytime. It could also panic and drop buffers upon unwinding.

Nope. The problem does not exist in the stackfull model by the virtue of user being unable (in safe code) to drop stack of a stackfull task similarly to how you can not drop stack of a thread. If you want to cancel a stackfull task, you have to send a cancellation signal to it and wait for its completion (i.e. cancellation is fully cooperative). And you can not fundamentally panic while waiting for a completion event, the task code is "frozen" until the signal is received.

>it's actually something that would be useful in this context.

Yes, it's useful to patch a bunch of holes introduced by the Rust async model and only for that. And this is why I call it a bunch of hacks, especially considering the fundamental issues which prevent implementation of async Drop. A properly designed system would've properly worked with the classic Drop.

>And that said there's an easy fix: don't use the pointers supplied by the future!

It's always amusing when Rust async advocates say that. Let met translate: don't use `let mut buf = [0u8; 16]; socket.read_all(&mut buf).await?;`. If you can't see why such arguments are bonkers, we don't have anything left to talk about.

duped · 2 days ago

> The problem does not exist in the stackfull model by the virtue of user being unable (in safe code) to drop stack of a stackfull task similarly to how you can not drop stack of a thread.

If you're not doing things better than threads then why don't you just use threads?

> And you can not fundamentally panic while waiting for a completion event, the task code is "frozen" until the signal is received.

So you only allow join/select at the task level? Sounds awful!

> Let met translate: don't use `let mut buf = [0u8; 16]; socket.read_all(&mut buf).await?;

Yes, exactly. It's more like `let buf = socket.read(16);`

duped commented on Io_uring, kTLS and Rust for zero syscall HTTPS server blog.habets.se/2025/04/io... · Posted by u/guntars

newpavlov · 2 days ago

No, the fundamental problem (in the context of io-uring) is that futures are managed by user code and can be dropped at any time. This often referred as "cancellation safety". Imagine a future has initialized completion-based IO with buffer which is part of the future state. User code can simply drop the future (e.g. if it was part of `select!`) and now we have a huge problem on our hands: the kernel will write into a dropped buffer! In the synchronous context it's equivalent to de-allocating thread stack under foot of the thread which is blocked on a synchronous syscall. You obviously can do it (using safe code) in thread-based code, but it's fine to do in async.

This is why you have to use various hacks when using io-uring based executors with Rust async (like using polling mode or ring-owned buffers and additional data copies). It could be "resolved" on the language level with an additional pile of hacks which would implement async Drop, but, in my opinion, it would only further hurt consistency of the language.

>He even calls out how naïve completion (callbacks) leads to more allocation on future composition and points to where green threads were abandoned.

I already addressed it in the other comment.

duped · 2 days ago

That problem exists regardless of whether you want to use stackful coroutines or not. The stack could be freed by user code at anytime. It could also panic and drop buffers upon unwinding.

I wouldn't call async drop a pile of hacks, it's actually something that would be useful in this context.

And that said there's an easy fix: don't use the pointers supplied by the future!

duped commented on Io_uring, kTLS and Rust for zero syscall HTTPS server blog.habets.se/2025/04/io... · Posted by u/guntars

newpavlov · 2 days ago

This actually one of my many gripes about Rust async and why I consider it a bad addition to the language in the long term. The fundamental problem is that rust async was developed when epoll was dominant (and almost no one in the Rust circles cared about IOCP) and it has heavily influenced the async design (sometimes indirectly through other languages).

Think about it for a second. Why do we not have this problem with "synchronous" syscalls? When you call `read` you also "pass mutable borrow" of the buffer to the kernel, but it maps well into the Rust ownership/borrow model since the syscall blocks execution of the thread and there are no ways to prevent it in user code. With poll-based async model you side-step this issues since you use the same "sync" syscalls, but which are guaranteed to return without blocking.

For a completion-based IO to work properly with the ownership/borrow model we have to guarantee that the task code will not continue execution until it receives a completion event. You simply can not do it with state machines polled in user code. But the threading model fits here perfectly! If we are to replace threads with "green" threads, user Rust code will look indistinguishable from "synchronous" code. And no, the green threads model can work properly on embedded systems as demonstrated by many RTOSes.

There are several ways of how we could've done it without making the async runtime mandatory for all targets (the main reason why green threads were removed from Rust 1.0). My personal favorite is introduction of separate "async" targets.

Unfortunately, the Rust language developers made a bet on the unproved polling stackless model because of the promised efficiency and we are in the process of finding out whether the bet plays of or not.

duped · 2 days ago

> You simply can not do it with state machines polled in user code

That's not really true. The only guarantees in Rust futures are that they are polled() once and must have their Waker's wake() called before they are polled again. A completion based future submits the request on first poll and calls wake() on completion. That's kind of the interesting design of futures in Rust - they support polling and completion.

The real conundrum is that the futures are not really portable across executors. For io_using for example, the executor's event loop is tightly coupled with submission and completion. And due to instability of a few features (async trait, return impl trait in trait, etc) there is not really a standard way to write executor independent async code (you can, some big crates do, but it's not necessarily trivial).

Combine that with the fact that container runtimes disable io_uring by default and most people are deploying async web servers in Docker containers, it's easy to see why development has stalled.

It's also unfair to mischaracterize design goals and ideas from 2016 with how the ecosystem evolved over the last decade, particularly after futures were stabilized before other language items and major executors became popular. If you look at the RFCs and blog posts back then (eg: https://aturon.github.io/tech/2016/09/07/futures-design/) you can see why readiness was chosen over completion, and how completion can be represented with readiness. He even calls out how naïve completion (callbacks) leads to more allocation on future composition and points to where green threads were abandoned.

duped commented on Sequoia backs Zed zed.dev/blog/sequoia-back... · Posted by u/vquemener

yurishimo · 4 days ago

You can try it out. I would say it’s aiming to be a more modern Sublime Text, which is a win to be considered in the same category imo.

duped · 4 days ago

I have tried it out and by default it was so slow as to be unusable. After discovering it required some customization in /etc (because it's the only GUI application that fails to recognize my GPU on a very popular distro with next to zero customization, because I game a lot on Linux - weird how that's a me problem and not a Zed problem) it got better, but still noticeably slower than VS Code.

The modern Sublime Text is Sublime Text. There is way too much "extra" in Zed to compare it. If anything, it's a new IntelliJ.

duped commented on Modern CI is too complex and misdirected (2021) gregoryszorc.com/blog/202... · Posted by u/thundergolfer

sambuccid · 4 days ago

I'm not sure why no one mentioned it yet, but the CI tool of sourcehut (https://man.sr.ht/builds.sr.ht/) simplifies all of this. It just spins a linux distro of your choice, and executes a very bare bone yml that essentially contains a lot of shell commands, so it's also easy to replicate locally.

There are 12 yml keywords in total that cover everything.

Other cool things are the ability to ssh in a build if it failed(for debugging), and to run a one-time build with a custom yml without committing it(for testing).

I believe it can checkout any repository, not just one in sourcehut that triggers a build, and that has also a GraphQL API

duped · 4 days ago

A big reason people use actions is because they need to run things on MacOS and Windows.

duped commented on FFmpeg Assembly Language Lessons github.com/FFmpeg/asm-les... · Posted by u/flykespice

Sesse__ · 6 days ago

> Normally you spin up a tool like vtune or uprof to analyze your benchmark hotspots at the ISA level. No idea about tools like that for ARM.

perf is included with the Linux kernel, and works with a fair amount of architectures (including Arm).

duped · 6 days ago

perf doesn't give you instruction level profiling, does it? I thought the traces were mostly at the symbol level

duped commented on The Weight of a Cell asimov.press/p/cell-weigh... · Posted by u/arbesman

madcaptenor · 6 days ago

I hadn't thought about this, but this is probably why in baking recipes where amounts of flour, sugar, etc. are specified by weight, baking powder and any spices will be specified by volume.

Of course this is all false precision once you start adding eggs.

duped · 6 days ago

imo the reason to bake by weight is because the ratios of the major ingredients (flour, fat, sugar, and water) determines the properties of the dough, and it's impossible to measure by volume reliably (especially flour, which is the largest ingredient by weight in most recipes). Meanwhile you don't have to be precise with baking soda or yeast. Mix-ins like herbs are completely to taste. Salt could go either way.

Recipes absolutely adjust for the weight of the eggs and some rules of thumb for water and fat content. But that said, a chicken egg is like 55g with 10% tolerance (at least the eggs I buy, and I do everything by weight). 5g of mostly water one way or the other doesn't have a massive amount of impact on the dough, and you can always adjust based on feel after mixing.

At scale everything is measured by weight fairly precisely. But you really don't care about accuracy, since it's the ratios of ingredients that make the product and not the raw amounts.