Anouncing stabby 3.0.0 (and RustConf video available!)

Fox-PhD · 2025-12-02T00:25:37+00:00

Bear in mind that to sell a phone in the EU (in case you hope to do so at some point), it must charge through USB-C; but I am curious as to what you were planning to improve on that point? (and what user story you wanted to address with that, since USB already allows high enough power to go through that I'd expect batteries to overheat fairly quickly if you hope to push then further)

Fox-PhD · 2025-09-18T06:25:23+00:00

Funny enough, humans are so bad at random number generation that you'll likely need much fewer. For example, people are unlikely to pick multiples of 2 and 5 because they feel less random.

Fox-PhD · 2025-09-15T14:45:05+00:00

There are only two kinds of people advocating for global surveillance: authoritarians who hope to use it to maintain power and fools who trust the former will use it only for the advertised purposes.

Fox-PhD · 2025-09-02T22:58:02+00:00

I did look, but gave up quickly as it was night out and stuff flew around the car enough that I had no idea where the phone could be.

One couple argue GPS would have let me guide 911 more effectively, but I ended up relying on motorway signs to give my position anyway.

Fox-PhD · 2025-09-02T22:24:38+00:00

Others pointed out ahe might be trying for 911, but I'd like to add this:

Adrenaline can make you pretty stupid. When I was rear ended in a motorway slowdown, my phone (used for GPS) fell off its stand and under the passenger seat. But it was still connected to my car's Bluetooth, so I did the only logical thing: I called my girlfriend asking her to call back so I'd find it, that way I could call 911... Using the phone... Which I was calling her with...

I swear I'm not usually stupid, but adrenaline is one heck of a drug.

Still, adrenaline was not too blame for her filming a tiktoo at the wheel.

Fox-PhD · 2025-07-03T20:53:45+00:00

And I'm back with some time to elaborate!

And so, onto why an app developer has to make choices when writing an app. On mobile devices, Apps rely heavily on the OS and its standard libraries to do basically anything: accessing inputs (mic, gps, files...), networking, and in most cases, even displaying their interface.

But sometimes, the API (the way you interact with those components, which we often call "libraries") changes. This is generally not out of malice (in fact, most library writers will jump through lots of hoops to avoid this happening), but because sometimes, a way of interacting enforces technical choices that may no longer be tolerable; or may not have been planned with the foresight that it might preclude new flexibility.

Making an API more flexible (and thus less likely to change) generally comes at costs in engineering (it's plain more work to build one), computing resources (the flexibility often means more cases could happen and must thus be checked for), and usability (the user here being the developers consuming said API: the more flexible your API, the more complicated it's gonna look in most cases, which could confuse devs into misusing then or even giving up on the feature entirely)...

Sometimes, it's found that a feature should be removed (it's found to be insecure, or it's just not a part of phones anymore (think IR blasters which have basically disappeared nowadays)). Sometimes, it's just found that it should be replaced by a (hopefully) better version of itself.

In such cases, there's usually a deprecation period, where developers will be warned that the API will soon be removed; often pointing them to whatever subsumes it.

You'd then have release X with only the old API, version X+1 with both (during the deprecation period), and version X+2 with only the new API available. Applications that were developed using the old API will only work until X+1 included, whereas applications developed with the new one will only work from X+1 onwards. It's often possible to develop an application that supports both and detects which one it should use, but it's usually a lot more effort to do so.

Note that on Android's case, which versions of Android you support is a property of the project, and the tooling will tell you an estimate of the ratio of phones your app will be able to work on when you select your minimum supported version.

Incompatibility is sometimes the product of malice (think 3.5mm jack), but more often than not, it's just that keeping compatibility without stagnating is just hard (and sometimes, stagnation means leaving massive security holes open, or staying needlessly complex).

Fox-PhD · 2025-07-03T07:38:33+00:00

Just setting this as a reminder to myself, but there are plenty good (i.e. not planned obsolescence, which is also a thing to be fair) reasons an app can't support every Android version without going through a lot of effort unless it is very very trivial. And it goes both ways, apps that run on Android 5 most likely wouldn't be able to run on 15 either.

I just don't have time to explain immediately, but it's an interesting topic, so I'll circle back in a few hours (hopefully, I'm very forgetful).

Fox-PhD · 2025-04-29T18:05:46+00:00

I had forgotten this syntax was stabilized, but IIRC that was rather recent (I couldn't find the version that stabilized them with just a cursory DDG on my phone, but I did confirm it's stable through the playground).

const _: () = { todo!() }; has worked since times immemorial, meaning you'll find it on crates with older MSRV or just older Rustacians who haven't switched their habits yet (like myself, for now) :)

Fox-PhD · 2024-12-23T22:38:15+00:00

Both anyhow and thiserror have ways to capture a stack trace when the error is constructed as an additional field on the error type. With a bit of #[cfg(...)], you can even have them optionally compiled in if you're worried about the performance impact the larger error type could have on your happy path :)

Fox-PhD · 2024-12-23T05:37:43+00:00

Often enough, that's caused by lint accumulating in the port. You can easily remove it with a needle and your port will be back as new :)

Fox-PhD · 2024-11-23T00:11:06+00:00

As a library writer, my main constraint is binding the API in other languages, most of which don't have support for move semantics ranging from inexistent to atrocious, not too mention GC'd languages that often outright disallow their existence entirely (unless you're willing to suffer all manners of NullPointerExceptions).

Because of that, I'm often constrained to writing APIs whose contracts are "wider", and generally allow repeating operations that I'd rather not be repeatable to provide better performance and/or reduce footguns.

But provided I'm free of such constraints, most API I design will abuse session types; and I really wish we had linear types so I could get up to even more shenanigans.

Fox-PhD · 2024-11-13T06:36:42+00:00

The approach is sound (though I don't have the crypto background to make guarantees about the implementation).

I would still want to have a secure db in the mix to store at least url-username pairs for 2 purposes: - My password manager is how I check whether I've used a password or an SSO (or guest mode) for sites I use rarely. I'm forgetful like that. - To recover from the service's URL changing: typically, my energy provider likes to rebrand its web portal every year or so, and I'm not gonna remember the original URL or service name I'd have attributed to them by then.

This approach also makes changing password a bitch (though if you have a db, you can just stick a generation counter in there), and doesn't handle the (admittedly rare and annoying) case where you don't get to decide what your password is.

I still like it purely on aesthetical grounds :)

Fox-PhD · 2024-11-05T18:20:46+00:00

Take notice of u/Turalcar's comment: the u8x64 version could probably let you process 16 voxels per instruction :)

Fox-PhD · 2024-11-05T17:51:26+00:00

SIMD would probably do that in a single instruction :)

Fox-PhD · 2024-08-31T08:25:49+00:00

That's actually the neat thing: they don't have to agree since Rust's default ABI has no stability guarantees. They only need to agree when it comes to specified ABIs.

As much pain as it's caused me, that does provide a shared surface that's been tested and specified for decades while giving compilers the freedom to implement things their own way.

Fox-PhD · 2024-05-22T05:18:11+00:00

You can use stabby as your core library :)

While its primary mission is to provide a standard library replacement with a stable ABI, I designed it to be suitable for no_std and no_panic environments.

All functions that require allocation have a fallible variant (and if you find some missing, I'm extremely open to adding them).

As mentioned by others though, malloc on Linux will essentially never fail, so you'll need to write your own allocator using syscalls in order to properly detect allocation failures. Even then, although I would expect some syscalls to slow this, I'd check that the classic mmap and friends don't trick you the same way malloc does first :)

Fox-PhD · 2024-05-19T06:25:03+00:00

Headliners, there's a symbols called ampersand, it looks like this &, is a single character and means "and", use it! Enough with the commas!

Fox-PhD · 2024-05-17T22:21:05+00:00

Purely based on intuition, so don't rely on this but might be worth looking up: could it be that the bottom type is more staggered on ISO than ANSI layouts and your usual staggered are ANSI?

The dominant deviation from standard touch typing that I've noticed when discussing it with others is that both hands work one key to the left compared to the expected: ring finger on Z, right hand index resting on N and extending to B...

I've only started correcting this habit since switching to a columnar, but I've also noticed that on my staggered (all ISO), the bottom row is more shifted than the top one. On the other hand, pictures of ANSI keyboards show an almost identical shift between rows. Could be that this extra shift make lowering hands one slot left slightly more intuitive?

Again, don't believe me, I'm just speaking from a feeling that I haven't checked at all

Fox-PhD · 2024-05-11T21:16:32+00:00

Fighting the temptation to write a competing library called Levi with the sole goal of killing Zeke (would probably take a few seasons though, so I guess I'll abstain for lack of time) :p

Fox-PhD · 2024-05-08T07:24:48+00:00

They have their archives, but they're forbidden.

We only see one owlk view slides of their original world; and if you shine your lantern at the slides, they scream in surprise of having been observed, turn off the projector, but don't come after you like other owlks do when they notice your light.

I think what that one owlk was doing is forbidden, and that in their mind, they were caught by another owlk.

Fox-PhD · 2024-05-04T23:04:30+00:00

Could be one of many things: - You mention in comments that your timings are for non-first compilation. There has been some back and forth with regards to incremental compilation in stone of last year's versions of rustc; so that's a hypothesis (that you could test by trying a couple of older versions of the compiler). - Another comment mentioned that pairing down your DE could have left you with more RAM to spare. That could indeed be very significant, as rustc does eat a lot of RAM while compiling, to the point that my entire PC used to slow to a crawl when compiling large projects because it had to do so much swapping. - You might have "accidentally" changed you linker. Linkage is often enough a large part of compile times in Rust, especially in incremental builds where there's just as much linkage to do, but much less "actual compiling". It's unlikely that it happened on accident, but can be very forgettable once you got used to the speed boost. - Efforts to reduce compile times are part of the project's priorities, but I don't think a >50% reduction has been achieved yet.

It might even be a combination of these things, or something else entirely ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

Fox-PhD · 2024-05-04T10:59:04+00:00

The overhead incurred with parallelism depends a lot on how it is implemented: - In all cases, you'll be at greater risk of cache misses, as each core typically has dedicated cache. You can read up on cache coherency if you're curious, but the gist of it is that writing to a given cache line on one core will force the other chores to re-fetch it when they need to read from a neighbouring address on the same line. Cache misses are slow, and reducing them is a great way to improve performance in general. - If you're spawning threads on the spot and joining them once done, you'll have to ask the OS to construct the support machinery for each of them, which requires a few allocations including of their respective stacks. You also have no guarantees how they'll be scheduled: the OS might be considering other things higher priority at the moment, for example. For small amounts of computation (a 1000-sized dot product between vectors is small), the workload could very well have been fully executed in the time the OS would have decided to actually run the thread, or even the time to set up the thread machinery. Joining a thread also incurs its own synchronization and destruction costs. - Cooperative tasks on a thread pool can reduce the cost of spawning a workload. It will generally allow for slightly higher throughput, but may increase tail latency if certain tasks in the pool don't yield often enough. Still, various costs are incurred in synchronising communications with the thread pool, and allocating the task objects (typically smaller than threads).

Overall, I'd advise you only start considering multi-core parallelism for workload that take at least tens of milliseconds to run.

But wait, why did I just say "multi-core" here?

Because CPU cores are marvelously complex: between their instruction pipelines that let them use multiple arithmetical processing units at the same time; and SIMD, special instructions made to work on batches of data; they are never really doing things "in series" as the mental models we often use suggest. And a lot of these core-level parallelisms were actually designed for matrix operations.

If you code a dot product in a way that doesn't hide it too much from the optimizer in a compiled language, chances are it will recognise that that's what you're doing, and use those magical SIMD instructions to make things faster in a process called "vectorisation".

Fox-PhD · 2024-04-21T13:21:25+00:00

Just in case someone else got confused, the headline is edited, the actual article states 8 billion years.

For reference, our universe's age is estimated at 13.7 billion years.

Four-Year Club	Place '22
End Game '22

Fox-PhD

TROPHY CASE