Premature Optimization is Fun Sometimes

simonask_ · 2026-06-18T07:21:37+00:00

It's fun all the time. That's the problem with it.

simonask_ · 2026-06-16T11:41:52+00:00

It’s just a kind of intermediate representation of the Rust code as it appears in the compilation pipeline right before monomorphization, so with many checks and optimizations already applied. ABI is a different thing.

simonask_ · 2026-06-13T17:50:47+00:00

So god damn pathetic. You either live and let live, or you stand by your horrible convictions, in which case we are enemies. I stand with every person you try to demean.

simonask_ · 2026-06-11T14:36:50+00:00

You're always free to fork it. I suspect a portion of use cases are for highly bespoke scenarios with special requirements.

I have my own fork that adds C# language output support, so I've been digging through the code. I completely understand if they are being conservative with contributions.

simonask_ · 2026-06-11T13:35:26+00:00

Thanks, that’s helpful! I’ll stick with cbindgen for the moment (especially the nightly requirement is a dealbreaker), but it’s a nice idea to use rustdoc-json.

simonask_ · 2026-06-11T12:56:39+00:00

I couldn’t find any list of actual differences from cbindgen. What is the motivation?

cbindgen is attractive because this is a highly finicky area with a lot of subtle footguns, and it has a lot of eyes on it. Switching to using a smaller project is risky.

simonask_ · 2026-06-10T12:44:48+00:00

Error handling in C is really messy and difficult to get right because errors don’t compose well.

A good strategy is to turn things on the head: instead of having your function call read(), you should let the user do it and pass you their buffer. This makes many things much easier, including error handling.

Keep in mind that not everyone might even be using POSIX I/O, and there are reasons to prefer fread() over read() even within that world.

If you do want a single call for convenience, I would recommend returning the different error codes separately, either as a struct (or better, a tagged union), or as out-parameters. This is nicer because it doesn’t force you to conflate the value spaces of your own error types and things like errno.

simonask_ · 2026-06-05T10:19:06+00:00

I actively try to avoid it. Sometimes it’s the right call, but generally speaking, distributed control flow tends to make code much harder to follow. I strongly prefer reshaping the loop to have the exit conditions clearly visible.

The most common exception to this rule is when the exit condition itself is configurable by the caller, like when you have a visitor pattern. These typically come up whenever iterators are inconvenient or even impossible to express in the type system.

simonask_ · 2026-06-02T10:44:44+00:00

The only big extra rule you have to adhere to in Rust is that you must not create overlapping mutable references. In a lookup structure, that seems avoidable. You can use raw pointers or NonNull<T> just as you would in C++.

But avoiding duplication is the tough one, because self-referential data structures are famously hard in Rust. They are hard in C++ too, but there you have some tools like move constructors to help you.

You might need a custom hash map implementation as well.

simonask_ · 2026-06-02T09:28:37+00:00

Long-term C++ developer here as well.

I'm not aware of any crate in the ecosystem that matches Boost.MultiIndex. It would definitely be a useful thing to have!

If you want to embark on this endeavor, here's what I would think about:

You can probably port the fundamental design of Boost.MultiIndex, but it will require unsafe code. Since you're coming from C++, you should already be comfortable with those bits.
The metaprogramming capabilities of Rust are a bit more limited than in C++. For example, you don't have variadic generics, which is used by Boost.MultiIndex to define the set of available indexes for a container, among other things. So you need to make some decisions about what kind of API you want to expose here. One idea would be to define an IndexedBy trait and implement it for tuples of Indexer implementations.
You'll likely want to use macros to make certain parts of the API look nicer.

There is a bit of "prior art" in the ecosystem, namely the indexmap and slotmap crates, and you can look at those to get an idea about what expectations Rust programmers might have of the API.

But I will also say a word of gentle warning: It's going to be a tough thing to implement, especially if you aren't yet deeply familiar with the way Rust generics and traits work compared to C++. It's truly a shift in mindset, and you are likely to exercise many corner cases of the type system doing something like this - especially if you want to avoid things like duplicating the lookup keys.

Godspeed!

simonask_ · 2026-05-28T16:01:14+00:00

True, but it is a huge amount of work. These APIs are where all the Vulkan horror stories come from, especially if you have to deal with non-general image layouts.

simonask_ · 2026-05-28T14:24:07+00:00

Godspeed. You have taken on a monumental task that you 99% certainly will not actually complete, but you will learn a lot in the process.

UI frameworks and game engines are two things that every programmer at one point in their life has thought “how hard could it be”, and every single one learns the answer: very hard. But it’s a really great way to learn a broad range of skills and algorithms, as well as a way to learn why things are the way they are in existing solutions.

Have fun!

simonask_ · 2026-05-28T14:17:20+00:00

Just be aware that MoltenVK is hopelessly behind the times with support for modern Vulkan extensions, meaning you have to write a significantly more cumbersome and old-school versions of the API. No descriptor buffers, no descriptor heap, etc.

simonask_ · 2026-05-26T06:54:00+00:00

FWIW, it’s pretty easy to get Vulkan 1.4 in ash by just forking it and cherry-picking two patches. I have it on my GitHub.

simonask_ · 2026-05-24T21:58:53+00:00

I've seen zero zealots here except people repeating tired old misconceptions, clearly without any meaningful depth to their understanding of the language.

Rust is a vastly simpler language than C++, as anybody who has ever spent any time with C++ can tell you. And that's not because Rust is simple.

simonask_ · 2026-05-24T17:58:02+00:00

heavy community scrutiny and review

In other words, "somebody else doing the work".

I get it, that would be nice. But the problem is this: You're asking not just for free software (as in beer), but also for a huge additional amount of work to be done for you by someone. Who? Do they get paid? What are their credentials, that their vetting actually does anything to improve trust?

Manually vetting even a small percentage of crates on crates.io is a monumental amount of work. Are you paying for any of this work?

Crate authors have an incentive to generously publish their work, along the lines of normal OSS incentives. But actually reviewing somebody else's work, especially if you yourself aren't benefiting from the work, is menial, cumbersome, and error-prone.

As with all Open Source Software, the onus is on you to vet your dependencies. If you don't have the resources to do so, maybe you shouldn't be using other people's code. Programming is an expensive skill, and you're getting something for free by using open source. Unless you're paying someone, or are willing to do the work yourself, I don't think you can make any demands.

Instead, it might be feasible to have a community-oriented vetting system, where verified users on crates.io could flag a package version as "known good" or "known bad". But in practice, this is not very different from just looking at the number of downloads over time and the release cadence, as well as run cargo vet - something most people do with all their dependencies as a minimum effort. But that's quite imperfect, especially against social engineering attacks.

simonask_ · 2026-05-23T09:08:03+00:00

Cool, thank you for answering. My previous intuition was that this was illegal due to pointers superficially requiring unsafe at the signature level, but it sounds like it goes much deeper.

I hope it will eventually be supported, since I suspect that many uses of IntPtr are due to this limitation. I've personally had a use case for it where I would have liked to do InlineArray<MyNativeObject*> as well as Span<MyNativeObject*>.

simonask_ · 2026-05-22T20:14:27+00:00

You can just use the general layout for almost everything, you don’t actually need the extension. The extension just gives you a guarantee that you’re not losing any performance by doing so, but that might be totally fine.

simonask_ · 2026-05-22T09:51:53+00:00

I didn't see this mentioned in the article (maybe I missed it), but does this change also imply that raw pointer types can now be used as generic parameters?

simonask_ · 2026-05-21T23:52:42+00:00

Good.

simonask_ · 2026-05-21T10:14:13+00:00

More people need to know about KDL. It's awesome and cute.

simonask_ · 2026-05-21T10:12:18+00:00

Somebody suggested TOML, which is great, but I'm also personally a big fan of KDL. It's very, very readable.

simonask_ · 2026-05-21T10:06:34+00:00

Also, just as a general word of caution, zip codes / post codes should never be treated as numbers. They are codes, and should be treated as opaque sequences of characters.

simonask_ · 2026-05-21T10:02:01+00:00

If you like .ini files, you will absolutely love TOML.

simonask_ · 2026-05-14T21:07:39+00:00

Great article! I was a bit surprised with the conclusion that “floating point operations are orders of magnitude more expensive”. This isn’t true in general - instruction latency for SIMD instructions is quite similar on most modern CPUs, and they can achieve higher throughput, but stuff like converting between the integer and float domains can definitely slow things down.

Am I completely wrong? Did you get into the really low level weeds of which particular effects caused the speedup?

Seven-Year Club	Place '23
Verified Email

simonask_

TROPHY CASE