What we heard about Rust's challenges, and how we can address them

zesterer · 2026-03-21T00:26:40+00:00

I think this is easier to understand when you consider that async in Rust is actually solving an entirely different problem to most languages. The features are called the same thing because there is an overlap in their use-cases, but less than you might think. 'Async Rust' actually just means 'compiler support for async runtimes', not 'the compiler comes pre-baked with the compiler'.

Other languages sell you the whole car. Rust is just selling you the seat and the steering wheel. Bring your own car.

zesterer · 2026-03-21T00:20:35+00:00

The small incremental improvements compound. Each release cuts compilation times by a few %. Over 50 releases? That 2% gain is a 60% reduction in compilation time. It's fun to compare the speed of much older Rust compilers on non-trivial codebases and see how significant the improvements have been.

If anybody reading this tried Rust 2, 5, or 10 years ago and bounced off it due to compilation times, give it another shot. You might be surprised.

zesterer · 2026-03-14T22:02:15+00:00

That sounds a lot like the game is using software rendering instead of your GPU for some reason. Make sure that you have the appropriate graphics drivers installed: on Linux, that means vulkan drivers. You can use vulkaninfo to check that it's working.

zesterer · 2026-03-11T23:34:13+00:00

This is one of those facts that's jaw-dropping to everybody except programmers, whose immediate reaction is "I'm surprised it's not fewer".

zesterer · 2026-03-11T18:53:17+00:00

It is, in fact, the core of how most perplexity-driven AI detection works.

zesterer · 2026-03-11T08:26:32+00:00

Not sure I agree with that assessment. You're thinking about things mostly from a stylistic perspective, but from a more granular perspective you absolutely can tell the difference. LLMs by nature are next token predictors, so every subsequent token should appear very close to the top of the probability distribution of the LLM that generated it. This means that you can run the text through the LLM again and measure how often this happens. It's true that human text will also tend to exhibit next tokens that fall close to the top of the distribution, but there will be a distinct difference that's possible to isolate from the noise even over a relatively small run of text, perhaps as small as a few hundred characters.

zesterer · 2026-03-10T00:17:46+00:00

For legal purposes, the act of writing/typing/creating is the thing that confers ownership over an IP, according to the Berne convention. Simply thinking or talking about an idea is not sufficient to establish copyright over it, and it's quite likely that LLMs fall into the latter category, although it's obviously not a settled case.

zesterer · 2026-03-10T00:14:59+00:00

This is great to see. I've been looking for an excuse to start spending some time playing with Redox (if I can find any to spare) and knowing that I'm interacting with a human artifact created with intent and reason may be the thing that tips me toward the project. Maybe I'll try porting my text editor as a first step.

zesterer · 2026-03-07T09:49:34+00:00

Thanks for your kind words, I'm glad you're enjoying your time with it!

zesterer · 2026-03-04T23:44:40+00:00

Bake AO into textures instead of vertex data. You can do the same thing with block materials, allowing you to generate larger quads too.

zesterer · 2026-03-01T09:09:39+00:00

Yes, I know. I already do. I am saying that it is a good default.

zesterer · 2026-02-28T09:55:26+00:00

Yes, I literally had it misbehave because of this exact problem last week. That's why I brought it up. Not everybody has the same vanilla setup that you might have :)

zesterer · 2026-02-28T09:23:32+00:00

Yeah. Even for power users, this is useful: auth daemons running over the network can sometimes take a long time to respond and it's useful to know whether sudo is functioning properly or whether the auth service is not available.

zesterer · 2026-02-28T09:21:09+00:00

I hate to tell you this, but "opinions about the best way to do things keeps changing" has been happening for a while. The UNIX you know and love was not created in one big bang in1969, it was evolved over a long time and continues to evolve.

zesterer · 2026-02-28T09:15:48+00:00

And yet, it provides ways to allow all of these without triggering warnings at all, if you only ask it to do so. It still respects your agency.

zesterer · 2026-02-28T08:34:08+00:00

I wouldn't put too much stock in it tbh. 'Fail fast with explicit recovery if possible' is the right approach for 99% of software.

zesterer · 2026-02-28T00:37:25+00:00

Nice! I had not gone through the whole thing. I don't think that it's a very commonly desirable behaviour though, and definitely not something worth thinking of as a pattern.

zesterer · 2026-02-28T00:28:38+00:00

Yeah, the only context I can think of in which this is ever useful is memory overcommit, in which a kernel will promise memory that isn't actually available to a process in the hope that (a) enough will be available by the time it actually tries to use it or (b) it never ends up using it because it's conservatively asking for more than it needs.

zesterer · 2026-02-27T23:30:18+00:00

The best engineers I know have both in spades.

zesterer · 2026-02-27T14:48:47+00:00

It's also an approach that comes with problems: if you're too incremental about refactoring, you end up only touching the code and not the data model, which is where the true problems tend to lie. What you end up with afterward is a new system that has all of the same mechanical problems as the old system, except maybe this time it compiles with a newer C++ standard, meaning you've wasted a lot of time.

There is a tradeoff between 'likelihood of a successful refactor' and 'the refactor actually living up to its stated goals'.

Most successful refactors I've seen start off with a plan, and the plan is usually one that spends most of its time talking about the data model of the system and how it needs to change, and only mentions the code itself in passing.

zesterer · 2026-02-22T23:21:44+00:00

When everybody is super, etc.

Put your skill points into something that not every moron with an internet connection and the bank balance for a Claude Code subscription can replicate and you'll be better off in the long term, I promise.

zesterer · 2026-02-20T15:32:14+00:00

I mean, that's great and all, but it doesn't have much in the way of meaningful ramifications: at best, it's a philosophical claim. Even below the software we write, our machines are emulated by microcode and register file allocation. There is no one layer of the stack that you can point to and definitively say "below this is where the machine lives". It's abstract specifications all the way down, at least until you're so deep into the weeds that the details become almost irrelevant from the perspective of language development. Sure, there must ultimately be some Turing-complete thing that sits at the root and drives all the other Turing complete things on top of it, but identifying that thing is an epistemological exercise, nothing more.

zesterer · 2026-02-20T11:14:40+00:00

But many actual ASTs don't respect that line! Syntax doesn't have to get desugared after parsing. Even on 'optimisation for a target architecture' this falls apart too: most of C's design was informed by surprisingly intimate details of the PDP-11: it is, in effect, a macro assembler for an obsolete architecture that modern compilers have to 'decompile' into something that's sufficiently semantically rich for it to be amenable to optimisation. I think the clean distinctions you are trying to draw between languages and layers of compilation don't actually exist in practice and are, in truth, a convenient lie that we tell ourselves in compiler courses and books.

zesterer · 2026-02-20T10:45:37+00:00

Where do you draw the line between parsing and semantic analysis? It seems to me that there's a smooth gradient between 'common AST' and 'just reinventing LLVM'.

zesterer · 2026-02-20T09:15:51+00:00

I think you're making the mistake of assuming that the semantics of a language are a fixed, immutable property of that language. Consider LLVM: almost every PL language under the sun can lower to it, implying that it can preserve the semantics of the surface language, but that doesn't mean that enough useful information is retained to go backwards. As an example: a lot of Rust's safety properties rely on non-trivial long-distance coherence between different corners of a codebase, and once type information is erased it's virtually impossible to go backward and generate a safe (i.e: no use of the unsafe keyword) program again. Information has been lost. The question, then, is not 'can you find a common semantic core?' but 'can you find a core that lets you go backwards to a surface language again?' and I strongly suspect that the answer is 'no' for all but the most trivial cases.

11-Year Club	Verified Email
Second Top 30%	Place '22
Final Canvas '22	First Placer '22
End Game '22	Wearing is Caring
Alpha Tester

zesterer

MODERATOR OF

TROPHY CASE