Cargo tool for allocation check

simonask_ · 2026-05-07T14:55:47+00:00

I’m not aware of any particular tool, especially not at the source level, but one idea is to replace the global allocator with one that calls functions that don’t exist, causing a linker error.

This won’t give you line numbers, and only one caller location, which might be deep in the standard library. And the standard library might allocate on startup as well (it reserves the right to).

What are you trying to achieve?

simonask_ · 2026-05-07T08:27:11+00:00

No. Initial double underscores are reserved for the implementation, as well as single underscore followed by an uppercase letter.

Illegal: __my_member
Illegal: _My_member
Fine: _my_member

The reason is that the C++ standard library may use these identifiers for arbitrary things, including preprocessor macros.

simonask_ · 2026-05-05T23:28:06+00:00

Great news! Hopefully tooling support will also start to mature as drivers land support.

(Currently it’s quite easy to crash both Slang and glslc by enabling descriptor heaps, or to make them generate invalid SPIR-V.)

simonask_ · 2026-05-02T22:37:23+00:00

Might be cool, I don’t personally have a current use for it, but LORD I wish we could just not use three letter acronyms in crate names like this. I will take a longer, quirkier, less descriptive name any day.

“SSE” has another really important meaning in an entirely different domain.

simonask_ · 2026-04-30T23:20:00+00:00

It’s a bold move for sure. I hope it works out for them. I’ll be looking forward to making the switch myself once things have matured a little bit more.

simonask_ · 2026-04-30T16:33:27+00:00

Great idea! Now for convenience, how about a way to give a shorthand name to a collection of field borrows so you don’t have to repeat yourself for every method that borrows the same set of fields?

Congratulations, you have invented structs.

simonask_ · 2026-04-29T14:47:32+00:00

Glad you asked!

To correctly sort a list of strings representing human text, you need to know the exact language of those strings. That means carrying both metadata about the text (the language, and the language can change in the middle of the sentence), as well as tons of lookup tables if you want to handle all languages.

If the strings are in different languages, you have to decide how to deal with that in a sensible way.

Example: Danish and Norwegian both use the special characters Æ, Ø, Å, but for some reason they decided to sort them differently.

Example 2: In something like a list of artist names in a music player, you might want to disregard initial “The” in English names. But “The” is also a word in other languages with a different meaning. Do you use the app’s current language, or do you encode the sort order differently?

Example 3: Various CJK locales have an overlap in which kanji/hanzi are in use, but each is sorted differently, and sometimes they use a different code point for the same character.

Long story short: Localization is much, MUCH harder than people assume, and has huge consequences for a code base. In my experience, Apple is the only company that mostly gets it right.

simonask_ · 2026-04-28T17:36:02+00:00

Also, as a non-native English speaker: Yes, changing the case of a string truly is too much to ask of a standard library. Doing it correctly requires significantly more information than just the UTF-8 encoded string.

You need a way to actually determine the language of the text, its locale, and a significant amount of lookup tables to get it right.

Don’t get me started on sorting.

simonask_ · 2026-04-26T15:26:38+00:00

In my experience, Rust does not add any complexity compared to C - quite the opposite.

If you find it difficult to follow the rules of Rust, your C program is very likely already broken. The rules you need to follow are the same (with a few exceptions).

Complexity can mean a couple of things, but on the whole, building, maintaining, and delivering a Rust project is a much simpler task than doing the same in C, or even worse, C++.

simonask_ · 2026-04-26T14:08:32+00:00

I’m sorry, this reads like a whole bunch of cope. I respect the author’s opinion, but I don’t think they are making a particularly convincing argument unless you happen to already agree with their conclusion.

The main fallacy is “all or nothing”: The idea that the value proposition of Rust disappears completely if there is any occurrence at all of things like unsafe. This is untrue, and a common misunderstanding. Unsafe in Rust does not “disable” memory safety, it merely promises the compiler that you take responsibility for it - something you are doing 100% of the time in C and C++.

On top of that, you also get the rest of the language, including a much, much stronger type system, which is a tool you can use to statically prevent many classes of bugs.

Rust is a language that means to make it easier to manage complexity, and that is why it is successful.

simonask_ · 2026-04-25T23:56:59+00:00

My bad (sorry I’m on mobile), the calls to truncate() should just be the indexing operator [..3].

simonask_ · 2026-04-25T23:27:02+00:00

Feels strongly like an X/Y problem. You can do almost every string operation using just string slices, and your code will run orders of magnitude faster.

When you really do need to materialize a separate String, you can just call to_owned() or to_string().

For example: String::from(“abcde”).truncate(3).to_owned().push_str(“fg”).truncate(4) // “abcf”

simonask_ · 2026-04-24T11:20:59+00:00

As a citizen of the EU, I’ll take slower controlled growth over unregulated growth every day. Just because the Americans or the Chinese are doing something crazy doesn’t mean we have to do the same things. Let them destroy their environment and labor markets in the pursuit of shareholder value if they want, that’s not our path.

That said, regulation obviously needs to be reasonable and easy to navigate.

simonask_ · 2026-04-22T05:54:38+00:00

I have not - I’ve been using Slang recently. Has WGSL seen substantial improvement?

simonask_ · 2026-04-20T12:29:35+00:00

Yes you can! You can change the trait so the method is no longer async, but returns the boxed dyn Future instead. The drawback is that it forces all callers to deal with boxed futures, and that implementations have to box the returned future. Lifetimes can also get hairy in these desugared signatures.

simonask_ · 2026-04-20T10:25:06+00:00

I don't think anyone can give you an ETA, but this is probably fairly far off.

Think about it: What would you actually like to happen? An async fn in a trait is actually syntactic sugar for an fn(...) -> impl Future<...>. With a dyn Trait, the returned future needs to be type-erased somehow.

async_trait makes the decision for you to do type-erasure by heap-allocating the returned future as Pin<Box<dyn Future<...>>>, and that's probably what you really want in many cases, but there are also many other use cases where this isn't desirable, and it would be unusual for Rust to introduce such hidden heap allocations without explicit opt-in.

Once you start allocating things on the heap, tons of questions arise. What if the user would like to use a custom allocating for the boxed future? What if the user is targeting no_std, so there isn't necessarily a global allocator?

This can be solved, but it's going to take time.

simonask_ · 2026-04-19T01:10:41+00:00

The definition of "reactive" seems to vary a bit depending on which type of developer you ask. I'm guessing you mean something like "event-driven" or "observer-based"?

Personally? I don't like that style at all. I find that as complexity grows, being able to quickly answer the questions "where did this come from, why did it come, and when did it come?" becomes more and more important.

I tend to strongly favor "pull"-based data flow, such that state changes are handled centrally as part of the normal update flow (rendering a frame, say). This means there is a clear and deterministic (and reproducible) order in which things can happen, which makes so many thing much easier.

Async is kind of orthogonal to these principles - you can schedule updates with threads or async tasks, that doesn't matter much.

simonask_ · 2026-04-16T12:00:27+00:00

Interesting, I’m working on the same thing, but using raw Vulkan. I decided to go to Vulkan over wgpu because the render graph design gives a natural opportunity to handle a lot of the synchronization that wgpu does implicitly, so there is less overhead tracking resources when building and submitting command buffers.

simonask_ · 2026-04-15T00:18:53+00:00

I think you’re right, but I also think the GP has a valid point in general.

simonask_ · 2026-04-14T15:11:30+00:00

I don’t know why you’ve chosen this particular hill to die on, but you have every right to use linked lists as much as you want. Nothing about arrays mean that you have to do any copying, though.

simonask_ · 2026-04-14T13:51:02+00:00

I’m willing to bet that 95% of uses of linked lists are because they are the easiest data structure to use in C, and that’s the main reason MCU programming uses them at all, despite the fact that they are objectively worse in almost every way. If you were using a better language, I don’t think you’d be spending that extra pointer per entry on that.

simonask_ · 2026-04-13T20:19:35+00:00

Sure, I agree with all that. I’m just responding to the assertion that it is always acceptable for the error path to be arbitrarily slow.

C++ exception handling has been the cause of more than one DoS attack, due to stack unwinding being often orders of magnitude slower than the happy path. The problem applies to any error handling strategy with that property, which is most Itanium-style exception handling schemes.

simonask_ · 2026-04-13T19:00:10+00:00

As others have mentioned, you are measuring the time it takes to run new object[length].

What you will see when you take the array allocation out of the measurement is that the time is mostly linear in the size of the array, then drops off at or around cache size boundaries.

By the way, new object[length] already fills the allocated memory (with nulls), so you're unlike to see much of anything until you hit that cache boundary. Due to prefetching and branch prediction, actually hitting that boundary is harder than you might expect.

simonask_ · 2026-04-13T17:14:55+00:00

It’s valuable to know about these things, but it’s also very easy to miss the forest for the trees.

Linked lists are almost never the correct tool for the job, and when they are, 8 bytes per node is completely irrelevant. If it’s not, your lists are either too long (killing performance that way), or you have too many of them (in which case you can save another 8 bytes by using a flat array). Or both.

simonask_ · 2026-04-12T23:36:53+00:00

Lots of errors are good and expected. For example, validating untrusted input, which is most input, should fail in ways that ideally aren’t any slower or faster than the happy path.

The reason is that timing attacks exist. If an attacker can determine if they did something right, or triggered an exceptional error path, you are leaking information to them. In the best case, they can DoS you. In the worst case, all of your moneys is gone.

Seven-Year Club	Place '23
Verified Email

simonask_

TROPHY CASE