> Haven’t hit that wall with GPT-5.5

I’m seeing a similar improvement with Opus 4.8, which is acting like an engineer that cares about correctness. The harder the problem the better it seems to do.

I think a golden age of software is just starting for indie software. It’s just going to take a while to see the first really good results.

I like the concept. Assuming you were the inspiration for this (very possible) how do you feel about the usability?

I spent an hour today trying to get it working the way I’d expect and it still does odd things, like after disabling automatic reordering based on usage the order is different when 3 finger swiping previews as opposed to actual windows. The visual order is as expected but the swipe order is not linear.

My criticism of MacOS Spaces is one I have of all Apple's window management efforts over the years: It's a great start and a foundation to build upon, but they never really followed through with iterative improvements informed by real-world usage.

In Spaces' case, the problem is a combination of an overly rigid model (only two full-height windows per space) and high friction to management (the process of moving full-height windows from one space to another requires multiple steps). Traditional free-form windows are a little better, but it's easy to lose track of them because the overview itself requires two steps to access (open Mission Control, hover the top bar to expand thumbnails). These could have been gradually improved over the past 14 years, but Apple has somewhat frustratingly left these core workspace features to wither on the vine.

> rather than showing you a preview, the bar just says "Desktop 1", "Desktop 2"

I never noticed that behaviour because I only use mission control in full-screen mode. If you swipe up with three (or four) fingers from a full-screen window the previews are visible immediately. I have no idea why we need a different preview for desktop vs full screen however.

The part of this UX that annoys me is the spaces get re-ordered for no apparent reason. I usually have a few IDE windows open and it's tiring to have to double-check the window hasn't moved.

The full-screen mode handling might be a clue about what went wrong: if you swipe up from a space that contains a full screen app, it has an animation where the app goes into a slot in the preview strip, but that animation doesn't make sense visually for a non-full-screen space. So, perhaps someone was implementing that animation, didn't want to implement an alternate animation for the non-fullscreen case, and decided to minimize the preview strip instead? And because this was after Steve Jobs had died, there was no one left in charge of UX to explain why that was a bad idea?

The animation for the full-screen case serves a useful purpose: drawing the eye to the window in the preview.

The non-fullscreen (desktop) case uses an animation for the same purpose, locating the current app window in a sea of others.

So what would the preview be in the swipe-from-desktop case? A preview of the window-sea, or the desktop as is? What should the animation be? I suspect those questions are why they chose to just name the desktop.

I think it would be more consistent if the tab based preview only existed for the desktop window-sea and transitioned to the actual space previews when swiping between spaces.

> If you swipe up with three (or four) fingers from a full-screen window the previews are visible immediately.

Previews are also visible immediately if you set Mission Control as a hot-corner action. In never see the title-only spaces — i forgot it even did that until this discussion.

I also wish I could name the Spaces. "Desktop N" is pretty useless.

that's a setting you can turn off. settings -> desktops and spaces -> reorder spaces

Ah thanks!

The setting is "Automatically rearrange Spaces based on most recent use" which explains why the behaviour felt so intermittent.

Does it work nowadays? Back in High Sierra days whenever I tried turning this off it did absolutely nothing and still reordered my shit.

Turning off "Automatically rearrange Spaces based on most recent use" keeps the spaces in the order I left them. That's nice. Three finger swipe between spaces when not using the preview seems to work.

However, swiping beetween the previews, it sometimes jumps to random places in the order - which is not nice.

Possibly a bug, but I might as well just write this as a letter to Santa because it's got more chance of being read than a feeback.

that is an incredible rage-inducing default, and really makes no sense. why would i want a system that scrambles my spaces?

Maybe someone can explain why an encoder would ever create the padding bytes allowed in LEB128. I contributed the parser for LEB128 in apple/swift-binary-parsing and I’m still none the wiser. I’m genuinely mystified.

I can think of two reasons.

The first is what they describe here: as an attack. It's like why would anyone ever overflow a buffer with shellcode.

The second is that they are implementing a spec that requires appending a varint length-prefixed field to a buffer but don't really care about the space optimization, don't know the field's length when they start appending it, and don't want to put the field into a second, temporary buffer or slide it down into place. https://github.com/FFmpeg/FFmpeg/blob/468a743af1653a08f47081... vs say my own code which does the slide: https://github.com/scottlamb/retina/blob/6972ac4261ce7bf5b58...

Third is by accident, including by buggy code, and the permissiveness means it's easier for bugs to go unnoticed. See, e.g., https://qht.co/item?id=48327115

Let's say you are writing into a byte[] and have a LEB128 length-prefix followed by a payload, but that determining the length actually involves nontrivial encoding work. For example, you have a UTF16 string and want to write out a UTF8 string, you want to go over the characters and write them out, but the UTF8 length is not known without doing all of that work.

If you can choose a fixed number of bytes for the length prefix, you can skip that number, do the encoding and find out the length, and then come back and fill in the length-prefix after.

But you actually don't know how many bytes it will take without doing all of the work to know the payload length (since larger payloads take more bytes to represent the length).

If you allow overlong representation you can reserve a few bytes and sometimes it'll just be the effective no-op bytes. If you don't, you won't be able to.

Thank you for solving that mystery!

It allows you to fill in padding in a buffer. For example, all data in a buffer will be interpreted by a downstream system, and someone pre-calculated the size of that buffer. Rather than encode everything twice (once to figure out the exact size needed, and a second time to actually populate the buffer) the buffer size was calculated using foreknowledge of how many values would be written to that buffer and then just pessimistically assuming all of them are max-size so writing will never fail. Another situation is when you're rewriting part of an already-encoded file. If you want to change a bit of payload then using padding bytes gives you more flexibility so you can do that without having to do any memcpy into a new buffer.

It's uncommon but I've definitely seen it done (with media containers like Matroska, not actually LEB128) in extremely high-throughput systems that can't spare any cycles.

Maybe you want to byte align some data, or pack to a certain size but keep compat. I think they're going to be rare cases, but I can see it being used.

The issue is that non-unique encodings are an attack vector, because parsers may in practice behave differently for noncanonical (or nominally invalid) encodings.

For example, you have an envelope format that goes: length prefix in LEB128, message, signature. One party controls the length prefix and signature, a different party controls the message. The message-writing party carefully crafts the message so that, in isolation, it appears innocuous, but when wrapped in the envelope, the first few bytes of the message look like continuation of the length prefix. Best case is the receiving party safely fails to parse the message, worst case is the receiving party successfully parses the message, verifies its digital signature, and interprets it differently than the signer did.

Laziness probably. Maybe there's an argument if you want to avoid branches and just blast the integer out in a fixed number of statements/instructions/bytes, but that sounds a bit fringe.

I happen to be guilty of a variant of this, where I don't bother emitting a 16-bit floating point number instead of a 32-bit one in my CBOR encoder even if it can be represented exactly. That one is laziness.

It's useful whenever you don't know the value of an integer but would like to allocate space for it now, and then fill in the value later. Many have mentioned length-prefixed data, which is a good example. Another use case is static linking. I believe LLVM uses this when generating WASM object files.

I think this is probably the real reason such encodings are considered valid. The webassembly spec is explicit about allowing valid over-wide encodings:

https://webassembly.github.io/spec/core/binary/values.html

Maybe a robust parser would benefit from a strict mode, disallowing over-wide encoding.

So why does the spec allow it? Like a good engineer I read the spec and tested against the over-wide example encodings given.

Because it's not a real standard and there is no blessed RFC for it. The DWARF spec is as close as you'll get and it says, "The integer zero is a special case, consisting of a single zero byte." So in a way, it doesn't.

Either way, a properly written decoder (and it's like ten lines) should really not have any problems with it. I was agreeing with you.

Edit: to clarify, I was talking about the author's argument being strange, not yours.

The WASM spec is more explicit about over-long LEB128 encoding.

Edit: a properly written decoder is a lot more than 10 lines if you properly deal with integer overflow and both signed and unsigned ints.

Working on my own product using Claude, I feel like front-end coding hasn’t changed much. It still requires a lot of manual tweaking and understanding users at a human level.

Personally I’m happy that the backend and algorithmic side writes itself.

That's refreshing to read (frontend is my wheelhouse). I mostly agree. It seems like most people using AI treat FE as a solved problem, satisfied using tailwind and settling for "looks close enough".

I think there will always be space for good artisanal FE. This is a Ford Model T moment, the software production line has just been invented, but that didn’t stop smaller sports car manufacturers pushing the envelope.

Just an anecdote on UK local government tech incompetence: I received a ticket “Failing to comply with a prohibition on certain types of vehicle” from Hackney council. Initially I thought my car had been cloned as I haven’t driven for months, but either a person or an AI had misread my car number plate. It was all just such a waste of time, especially navigating the Ai designed to annoy you into paying.

Addendum: The really annoying part was when the AI asked me for my ticket number, then asked me for the two digit contravention code.

First, surely they know the contravention code because they gave me the ticket?!

Second, the two digit contravention code was actually a part of a three digit alphanumeric code found in this sentence "52m Failing to comply with a prohibition".

Welcome to the future.

The paradox being the adtech industry is a central part of the national security apparatus.

Nietzsche: "the worst enemy you can meet will always be yourself"

Humanizing this technology seems like a step in the wrong direction.

There's so much intelligence here on HN and so little humanity.

Is it realistic to have multiple coding agents hammering out piles of code and expect good results?

Genuine question, is it worth it? I just find that using Claude via the web interface gives such good results I don't want to spend time messing with my tooling. Neither do I need more code to be generated than I have already.

One person and one LLM building one component at a time seems optimal to me.

Genuine question, where does te average developer go to learn CPP in 2026? Despite the usual complaints it’s alive and well and Rust will not replace it.

CPP has become infinitely easier to write for me. That’s an exact figure, my total output of usable CPP lines was zero prior to LLMs.

I do however need to at least be able to write basic CPP to evaluate the code I’m generating. It’s just so hard to comb through all the bad and over complicated code out there, bad advice and outdated opinions.

Read Bjarne Stroustrup’s intro to programming book and then read other books.

find more books from additional readings sections of books you end up liking.

Don’t use LLM for learning as it is useless compared to searching amazon or doing general web search to find books.

You can recursively learn anything you need by finding books about needed subjects.

> Despite the usual complaints it’s alive and well and Rust will not replace it.

to some degree it is already being replaced:

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj...

source: https://blog.google/security/rust-in-android-move-fast-fix-t...

Why does any mention of C++ nowadays turn into a Rust debate? These can coexist even in a single project via C ABI. Also, despite the vast syntax and semantic differences, an experienced dev will be able to apply most of their knowledge from one to the other.

My fault for mentioning Rust (perhaps I did it because it’s vaguely amusing watching Rust maximalists flex).

Just to add to the bait, I find CPP libraries much more terse and functional, Rust libs tend towards over complexity and feature flexing.

It's because crowing about Rust is like sending dick pics. I suspect it's the same part of the brain responsible with the same neural pathways stimulated.

>"Why does any mention of C++ nowadays turn into a Rust debate?"

Because for most developers language is a religion rather than just a tool.

If a tool had been replaced by a better tool, wouldn't it be natural to discuss that?

First - the tool in question had not been replaced. Second -discussion based on merits is one thing. Holy war is something totally different.

Personally I do not consider Rust to be a better tool but it does not matter. Each one is free to drink their own poison. I do not get obsessed about screwdrivers and I have used many.

In many instances the tool has been replaced.

You have written a glib and low effort reply to anything that disagrees with your Rust-maximal worldview. The sheer immaturity of Rust devs is enough to put me off the language.

That's actually a common pattern and to me that's a bit off-putting as well.

I have seen examples where some opinion gets momentum and it's repeated over and over again on the Internet even though the merit is very questionable.

Haven't looked enough into Rust to form an opinion though.

I haven't voiced an opinion, but a fact.

Otherwise, I don't respond to (imo) obvious provocations from questionable motives.

I dont think so.

The problem is the sunk cost fallacy.

You mean there are still people left who do not want to rewrite everything in Rust?

> We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code.

This is a pretty poor post. It’s impossible to see what exactly they’re comparing but they seem to be comparing post LLM code to pre LLM code.

Don't distract, please.

Here you can find a general discussion of the article: https://qht.co/item?id=45918616

Don’t tell me what to write.

Nevertheless, your feedback, despite its rudeness, backs up my criticism so thanks. Are you a Rust dev?

Since you are already making use of LLMs, you could also ask questions about the code that it produces. I've been asking Google's AI overview and Deepseek while doing my first ever C++26 project, usually not to produce any code but to give advice or list possible approaches to implementing a feature. It's a very slow path, to the point that my project has currently more git commits than lines of code, but I'm convinced that it will pay off in the long run.

Cppreference.com is my favorite resource for up to date info.

Most important thing is to use material (or tell LLMs) that use C++20.

If you don't need compile time techniques (templates, concepts, consteval, context, ...) then C++17 might be acceptable, too.

Modern C++ is pretty nice to write and compile errors are sane as long as you utilize concepts where it makes sense.