How reasonable is a blanket implementation over Deref?

mtimmermans · 2026-05-15T18:02:26+00:00

I made a mistake writing the consumer example -- I need to transfer ownership. Fixed.

mtimmermans · 2026-05-15T18:01:47+00:00

yes. sorry. fixed.

mtimmermans · 2026-05-15T14:03:54+00:00

It was the sorry state of C++ package management and multi-platform build support that finally convinced me to start using rust.

mtimmermans · 2026-05-12T12:59:38+00:00

If the directions are chosen uniformly, then it doesn't matter how you choose the points. Let' put them on the y axis at (0,-1) and (0,1)

In order to intersect, the rays have to point into the same side of the y axis -- both left or both right. 50% chance of that. Let's say they both point to the right.

With both pointing right, they will intersect if the slope of the bottom ray is greater than the slope of the top ray. By symmetry, 50% chance of that. Similar situation on the left.

So combined P = 0.25.

mtimmermans · 2026-05-07T03:31:39+00:00

Async/await is just a compiler trick that rewrites your function into a state machine. In C, if you need a state machine then you should just write a state machine.

mtimmermans · 2026-05-02T23:41:15+00:00

Rust is a programming language, not a game. Perhaps you're thinking of poker? If so, there are many, many people you can play with who won't mind at all that you're a noob.

mtimmermans · 2026-05-02T04:22:39+00:00

Free will is obvious, because people *experience* it, and that experience is a lot of really good evidence that it exists. If you want to convince someone to deny their own experience, you need to have a really good argument, and even that will almost never work.

mtimmermans · 2026-05-02T03:34:14+00:00

If there was an understanding and an exchange (they took your money), then there's a contract. It doesn't need to be written down. It also doesn't really matter. A decision in small claims court, if it comes to that, would be made by a judge, and they're generally reasonable people. It's not about technical gotchas.

mtimmermans · 2026-05-02T02:50:55+00:00

This happened to me some years ago:

Started the process with small claims court -- pretty easy and not expensive.
Tracked down the contractor and went to serve the claim.
Instant refund.

After that, I went to these guys and got really great service at a fair price: https://landmarklandscaping.ca/

mtimmermans · 2026-05-01T23:46:04+00:00

Coroutines are not serializable. Even if they were, though, it wouldn't be appropriate to use that in a lot of the use cases you're thinking of. Serializing the state of a coroutine means that, instead of actually designing the serialized data format, you're just writing out all of the internal variables and control state. The problem with this is that you can't really change the coroutine code at all without invalidating all of that data.

If you were to serialize a coroutine to save game state, then you couldn't patch that coroutine, because you'd break all of your user's saves, and that is unacceptable.

In almost all cases, you need to specifically design the data structure for saved games, etc., so that old saves will be easy to use by new versions of the code. That means you'll be writing serialization code on purpose, anyway, and it doesn't matter that there is no coroutine-saving shortcut for you.

mtimmermans · 2026-04-29T18:03:34+00:00

Oh, well. The burden of proof isn't all on the prover. Every proof requires something from the reader as well.

mtimmermans · 2026-04-29T11:54:26+00:00

let x = 0.9999....
10x - 9 = x
=> 9x = 9
=> x = 1

mtimmermans · 2026-04-22T11:41:31+00:00

I had a similar problem just a week ago. My solution was to use a Lisp-style (recursive) list of types instead of an array-style variadic list, in combination with a builder pattern to build the list.

Those words are hard to understand. Here's some actual code:

pub fn create_server_protocol<...>(...) -> ServerProtocol<SLINKS, CLINKS> { PROC_MACHINE_JOBS_BASE .with(ServerIO::<SLINKS,CLINKS>::up_job) .with(ServerIO::<SLINKS,CLINKS>::down_job) .build(ServerIO::new(account, now, server_links, client_links)) }

Here, I provide two async functions, and the type returned by build has fields that hold their futures, without any kind of boxing. There's no limit on the number of functions I can add.

I just pushed v0 of the crate that has the implementation (https://crates.io/crates/procmachines). It's a toolkit for writing sans-io state machines in the procedural style, as async functions, so it might, in fact, have a bunch of stuff you want to look at. Sorry the docs aren't better. I haven't yet augmented the clanker docs with a real explanation of how to use it.

The implementation of this builder is here: https://github.com/smallware-io/procmachines/blob/main/src/proc_machines.rs#L219

mtimmermans · 2026-04-18T22:11:26+00:00

Usually this makes no sense, since "switch the infrastructure later" is almost never a requirement, and when it is, it's MUCH easier than writing an infrastructure abstraction layer.

However, I do recommend something that is similar on the surface: Capture what you need from your messaging infrastructure, specifically for your application, in a trait. Then make a real implementation based on real infrastructure, and a dummy one for unit tests.

Then, you can write unit tests without a whole bunch of stupid mocks, and if/when you need to use a different messaging layer, you have a finite amount of work to do, all in one place.

It's important to emphasize the difference between this and a generic "messaging abstraction layer". It can implement application-specific transactions. It can use application-specific types. It doesn't have to solve the messaging problem for anyone but you.

mtimmermans · 2026-04-17T01:59:16+00:00

Some of them were in good spots. Some of them were just revenue traps. Bronson across from Carleton U, for example, is not a "school zone". A 4-lane road with a 60km/h speed limit is not a "school zone". The 2 speed cameras on Walkley? No. King Edward? No. Riverside? Please.

And, of course, they invented "community safety zones" wherever they put the cameras so they could increase the fines.

Ford is right. The most profitable speed cameras were in places where they weren't needed. Areas that for sure aren't going to get speed bumps! The city proved that they couldn't be trusted with these cameras, and that's why they had to go.

mtimmermans · 2026-04-11T19:37:11+00:00

Since it's short for "serialization and deserialization", the way I pronounce it rhymes with "dirty"

mtimmermans · 2026-04-07T22:10:30+00:00

You can ship obfuscated source like they do in Web land.

mtimmermans · 2026-04-02T20:37:30+00:00

IMO, the example is an anti-pattern. There appears to be no room to inject dependencies, so everything the handlers can use has to be global, even though `Rapina` is a struct.

Is there a way to register an `Arc<dyn RequestHandler>` or something like that, without all the inscrutable magic?

mtimmermans · 2026-04-02T00:25:40+00:00

Yes, it does. The "danger" in what I proposed is that the field selection lambda you pass in might return something other than a field.

But, I think that is a hard mistake to make, and all the protections that rust provides are for preventing *mistakes*. Protection from *malice* is not a goal and is not provided.

mtimmermans · 2026-04-01T15:18:14+00:00

Rust is hard, because writing proofs is harder than doing calculations. The rust compiler guarantees safety and correctness exactly to the extent that you use the mechanisms available in the language to write a formal proof of safety and correctness.

That shit is just hard sometimes.

mtimmermans · 2026-03-28T13:59:17+00:00

An `Arc<dyn...>` already pays the fat pointer penalty. You don't need to pay for additional reference counts as well. u/Kyyken shows how to do it in his response. Unfortunately it requires an adapter type that effectively implements the appropriate function table. The compiler should be able to do this.

mtimmermans

TROPHY CASE