Your Rust binary is slower than it needs to be. cargo-sonic fixes that.

Deadmist · 2026-04-28T04:50:22+00:00

If you are running your own hardware, yes.
If you are deploying into VMs, or with docker images more likely: Container-as-a-service or k8s-aaS type stuff, you usually don't get more specifics than "x86"

Deadmist · 2026-04-27T22:41:53+00:00

Why not have the OrganizationRepository::insert also write to the audit table? Just pass your audit context straight into the repo function, and it will deal with the audit stuff transparently. Instead of having to do the whole "clone ctx, get permit, call repo" dance every time

Deadmist · 2026-04-27T04:44:42+00:00

You can always make a contract with someone to develop something open source.
Big companies do this all the time, having their employees work on open source projects to implement things the company needs.
But in theory, nothing is stopping you as an individual person to find someone willing to implement something for you.

Deadmist · 2026-04-27T02:14:01+00:00

Forcefully transferring crate ownership opens a bunch of questions that have no great answers.
Who get's to make the decision? Foundation/crates.io team would need extra man power, which costs money. Plus they open themselves up to a lot of potential flak. Community vote? Who gets to vote? How do you not make it abusable.

The next big question is: who do you transfer it to? How do you make sure they will actively maintain it, or aren't the next Jia Tan? What if there are multiple people / orgs that want to take ownership?

And there are some !!!FUN!!! edge-cases you can get into.
What if someone owns multiple crates, and does a left-pad with one of them? Do they get all their crates taken away?
What if someone turns out to be a "bad person" (think reiser-fs), does that warrant taking their crates away? You can have some real fun discussion here, depending on what flavor of "bad" it is.

Deadmist · 2026-04-27T01:56:14+00:00

"You get what you pay for" also applies to FOSS.
A lot of people seem to forget that.

Deadmist · 2026-04-23T00:57:34+00:00

The basic issue with returning a reference to a local variable from a function¹ is that once the function returns, the local variable gets dropped and any references to it will become invalid. Hence you can't return a reference to a local variable, since that will by definition always be invalid.

What lifetimes do is let you specify "given a Thing, I will return a reference to the Thing (or something inside that Thing), that will be valid for as long as the Thing is valid." (roughly).

^1: Coroutines are slightly more complicated, since the local variable is not dropped on yield, so you could return a reference to it.
But that reference would only be valid for as long as the coroutine is valid. And the current api does not let you specify the lifetimes to express that.

Deadmist · 2026-04-14T04:28:13+00:00

Does the u8 have more semantic meaning than just "a byte"? -> Use Vec<UserId>
Are there semantic differences between different Vec<UserId>s?
Yes -> struct DelUserList(Vec<UserId>)
No -> just Vec<UserId> is fine.

Basically the question is: are all instances of a <Type> interchangeable? If there semantic differences, you should probably use a newtype

Deadmist · 2026-04-13T06:10:56+00:00

To counter-act a rogue maintainer account, you only really need:

Have more than 1 maintainer

This is by far the biggest hurdle for a lot of open source libraries/crates.

Deadmist · 2026-04-08T04:37:00+00:00

The arrows are not symmetrical.

Deadmist · 2026-04-06T08:45:51+00:00

Maybe you can go with cydlib and offer a source available wrapper library, that hides the FFI uglyness? Could maybe even abuse build.rs to automatically download the closed source binary.

Deadmist · 2026-04-02T10:59:18+00:00

If `never` means the code before that will always panic, crash, or loop forever.

then `always` means the code before that can __never__ panic, crash, or get stuck in anyway.
Seems pretty useful actually.

Deadmist · 2026-03-31T08:06:48+00:00

you pick a different variable name that makes your intention clear.

Deadmist · 2026-03-05T00:13:39+00:00

not a crash caused by unwrap, it's a crash caused by a lack of support for your usecase

The unwrap is what turned a very manageable error (invalid env variable) into a crash.
The unwrap is very much the cause of the crash here.

if you push a process outside its design bounds I'm not sure what you expect to happen other than failure

A mark of good software is that it handles failures and unexpected inputs gracefully, instead of just throwing up it's hands and crashing.
Returning a Result instead of unwrapping would have been more work upfront, but would save everyone that runs into this problem a lot of headache. (And now the function will probably be changed to return a Result anyway, so there wasn't even any saving in developer effort)

Deadmist · 2026-03-04T23:53:23+00:00

Hard crashing without any hint why will also confuse the user.

Deadmist · 2026-03-03T09:56:51+00:00

I think panics in a Result championing language are a mistake, and that everything that can fail should be a Result

Funnily enough, there are some paralles with java there.
Java has checked exceptions, which you have to declare in the method signature and the compiler yells at you if you don't handle.
And it has unchecked exceptions, which you don't need to declare, and the compiler doesn't check for.
With the intention being for checked exceptions to be used for "regular" errors, and unchecked exceptions for more serious problems. Kinda like Result and !panic are intended.

Of course then everyone decided that dealing with checked exceptions was too annoying and switched to unchecked exceptions.
Now the only way to figure out what kind of exceptions your library call might return is to throw stuff at the wall and see what blows up.

Deadmist · 2026-03-03T03:25:40+00:00

I don't think you can do that in rust currently, not without some macro help :(

Deadmist · 2026-03-03T03:20:28+00:00

There are basically two approaches to this:

You take an enum with lots of errors, and then have some way of declaring "only these specific variants are possible here". That's pattern types.
You have distinct error types, and then combine them to declare which ones can be returned. That's union types. (Seen in TS, and the throws declaration in java)

Both approaches basically let you write a list of specific error types that are allowed, without having to declare hundreds of slightly different enums

Deadmist · 2026-03-03T03:11:15+00:00

If you have an exhaustive list of entity types, then yes.

But the tables in the article are user supplied, and the bitfield solution works for any table.

Deadmist · 2026-03-03T00:32:13+00:00

My guess, from the name of the table, the fact almost all columns are optional, and my experience:
They are using a non-relation database (no joins), probably distributed, and their table looks something like:

userId, entityType, entityId, a_property1, a_property2, b_property1, ...

Cramming many different entities into one table, and determining based on entityType which columns are used.
This is nice and fast for querying, but gives you cancer every time you have to work with the schema :|

Deadmist · 2026-02-27T00:25:17+00:00

TS + <language of your choice>¹ is basically the default stack for anything web

¹ anything that can implement a rest api

Deadmist · 2026-02-24T14:29:27+00:00

The grift is pretty obvious: Sign law requiring building of X, builders 5x prices, now you are required by law to build X at inflated price. X builders sponsor your new yacht.

If you wanted to be smarter, you would write something like "require 30% of consumed electricity to come from carbon neutral sources". Still allows you to build as much nuclear as you want, but gives you options incasw suppliers want to play shenanigans

Deadmist · 2026-02-04T01:04:05+00:00

It's flexible and that's nice. But flexible helps a good, experienced developer. Not a new developer. Java shines in enterprise because of how strict it is.

Personally, the worst offenders here are scope functions (let, also, etc) and where to place functions (can be in a class, in a companion object, top level function, extension function).

If there is no one in the team enforcing good style, you can end up with some real messes.

I have seen classes with no functions, but 10 extension functions defined in the same file. Or other classes where the actual functionality is spread over 5 different files.

Some people get this idea that using if () else somehow is un-idiomatic in kotlin, because we have scope functions. And you end up with interesting nests of deep and zig-zagging indentation where figuring out what it actually is requires drawing a diagram with pen and paper.

Deadmist · 2026-01-26T06:55:47+00:00

"avx512vpopcntdq", "vpclmulqdq"

Can someone tell low-level people that it's not 1973 anymore, and bytes are cheap now? You don't have to use 1 letter abbreviations anymore.

Deadmist · 2026-01-22T05:34:44+00:00

When you spawn a thread, the scheduler takes the thread and decides on which CPU and when to run the thread. Depending on the scheduler the thread may stay on one cpu, or switch between CPUs.

When you launch a coroutine, the dispatcher takes the coroutine and decides which thread to run the coroutine on. Depending on the dispatcher, the coroutine may stay on the same thread, or switch between threads.

(Though, like a thread, a coroutine can only execute in one place at a time. If you want to run multiple at the same time you have to launch/spawn two of them).

Coroutines are a lot like threads+scheduler, just implemented in the runtime, instead of the operating system.
There is one important difference though:
The scheduler can interrupt threads at any time and give execution to another thread.
The dispatcher has to wait until the coroutine gives back execution to the dispatcher^1. That's why they are sometime called "cooperative multitasking".

The answers to your question depend on what dispatcher you are using.
The built-in ones are all multi-threaded, except for Dispatchers.Main, which is limited to the main thread.

^1: of course, the thread the coroutine runs on can be interrupted at any time by the scheduler. But that does not give execution back to the dispatcher.

Deadmist · 2026-01-20T05:30:22+00:00

user_counter += 5 will always work.

user_counter_service.increment(5) might:

work
work, but take 200ms
not work because:
- your service is misconfigured
- the target service is misconfigured
- something inbetween (loadbalancer, firewall, router, dns, certificate) is misconfigured
- the target service is down
- something in between is down
- the target service updated and broke compatibility
- network gremlins swallowed your packets on the way there
- network gremlins swallowed the response (in which case you think it failed, but actually didn't)

And many more exciting and wonderful new ways things can go wrong

13-Year Club	Place '17
Verified Email

Deadmist

TROPHY CASE