The map stuff the other posters summed up well but even std::vector is dogshit with pretty much all implementations having inlined grow code in push_back, a not too great API and missed optimisations e.g. no trivial relocation when growing the vector / moving it and no useful APIs such as "grow but don't initialise"...

Compilers might have bugs where the spec is supposed to work but it doesn't, and many extensions without standard equivalents, or implementation-specific behaviour where undefined things in the standard do get assigned a meaningful outcome.

I wholeheartedly agree, they're quite a regression.... although I don't think this is a popular opinion around here.

When people say "something used to be better" they usually don't mean literally, they mean that for the circumstances, it was better. Of course, more modern systems support more hardware, more features, etc., but if you made those same modern technical improvements on top of an older designs, you'd get much better results.

To me it looks like software design has been massively overtaken by "form over function", everyone just wants a unique "brand" but the actual UX is complete dogshit. Borderless buttons, zero indication what's clickable, no visual delimiters for different areas of programs, no good shortcut / altkey menu support, etc....

This has somehow infected even Linux to such a crazy extent...

I'm not claiming to have a definite answer to either, but I think the right question to ask is - are you going to benefit from using it in the long run? If yes, carry on, if no, re-evaluate what you're doing :)

Yes, it's not deterministic, and if you were using it commercially, the ROI would be terrible, and it's certainly not reliable but for a hobby project.... why not?

Encouraging people to understand the layer of abstractions they're building on is helpful, doesn't matter if they do it by hand or with clankers.

LLMs lower the barrier for execution - they make you faster. The unstated question is: faster at what - they can make you faster at something clever, or faster at the entirely wrong thing...

Your point is correct if we're looking at it through a scarcity lens - the effort to make it certainly decreased a lot - but that doesn't mean that anything is now worthless. We can just move onto doing bigger, better things now, until we hit the next limits...

1. the time for optimisation is limited

2. the constraints are overlapping and just completely intractable beyond a single function (do you want to inline this, saving on the call and increasing binary size, or not do it because it's cold?)

3. they don't have domain-specific knowledge about your code, and even with PGO, they might incorrectly decide what's hot and what's not - typical example are program settings. You didn't enable a setting during PGO instrumentation, compiler sees you didn't call that path, shoves it out of line. Now your PGO-optimised code is worse than -O2. And compilers have different levels of adherence to manual branch hinting - on MSVC you get a reorder at best, Clang and GCC try much harder at [[likely]] and [[unlikely]].

4. There's still quite a bit of low-hanging fruit left, mostly because progress is jagged ;) For example our calling conventions generally suck - this is actually why inlining is so helpful - and the inertia makes everyone emit the default calling convention and that's it.

For example, did you know that compilers have very inconsistent support for struct unpacking? It can be much faster to write

  int32 meow(int64 a, int64 b);

  struct mytype {
    int64 x;
    int64 y;
  };

  int32 meow(mytype a);

These examples might seem a bit cherrypicked but this is only scratching the surface, not to talk about the codegen in higher-level languages, which is even more dreadful. Manually optimising your code can usually get a magnitude worth of free performance, which is just tragic.

I wouldn't even rule out LLM codegen in the future - although they're quite unreliable today so you'd get miscompiles like crazy - but there's just so much low-hanging fruit left on the table that it wouldn't be too out of step...

Just yesterday I've reported a codegen bug in MSVC. (Luckily they've fixed it very fast.) Can you realise that it's an optimiser bug without inspecting the assembly? Hardly.

All the arguments people claim against LLMs are similarly applicable to compilers, but compilers are old technology and LLMs are new.

If you're an expert, just about every compiled function contains obvious inefficiencies, and a skilled assembly programmer can speed it up by in the ballpark of 3x. If we're talking about your average webapp, you can usually get 1000x better resource usage in most ways, including CPU, RAM, storage and so on.

And the output isn't deterministic either - the bugs no withstanding, code generation is highly chaotic, optimisations have non-local impacts and you can't easily predict optimised codegen output from source.

LLMs aren't much worse. They have non-deterministic output, but you can steer it - similarly to a compiler. An expert can use it to gain great speed and efficiency, but in the hands of someone not as capable, you can make something awful just as fast. Both tools are force multipliers.

Take the strawman: even if AI can one-shot basically any application below let's say, 1MLoC, if your prompt is 4 lines, it will generate something. It can't read your mind. If you make proper specs, then you'll get what you want - but many people don't know what they want. And even if they do, they might have contradictions in their requirements, might be asking for something impossible, etc.

My current codebase is ~3 million LoC all in all (not greenfield, really old code), working on it by myself, the complexity is definitely manageable between Claude and me :)

Basically on Linux the syscalls are the equivalent of Win32 except much narrower in scope.

1. In order to publish a game to a console, you do need an agreement with the console manufacturer. (Unless you're doing homebrew but then the point is moot.)

2. In that case, you do get access to the official documentation, everything is solid.

3. The word "legally" has a lot of bearing there. Sure, they have to. And if they don't, what? Will the other contributors sue them? If they aren't willing to do that, then they can get away with it.

4. The context is about someone trying to hack the devices. ("Who knows what some enterprising hacker might be able to glean about the workings of the console by looking at the APIs.") They certainly won't be bothered by NDAs.

At the same time, humans can move up the abstraction ladder faster than the LLMs can. At least, some humans. Agents can produce lots of code. They can also do the entirely wrong thing. The impact of wrong decisions have been massively write-amplified with more and more intelligent LLMs. With earlier ones, it got a sentence or a function wrong, you reprompted, the cost of a mistake was 10 seconds. Now, you can burn hours or even days of work on the entirely wrong thing without a competent human operator stepping in and course-correcting.

The trajectory of agents have been bigger and bigger context windows, bigger autonomy, but at the same time, a bigger blast radius. In this context, I don't think the human experts will be out of their jobs any time soon.

Even if something does look copypasted, it might actually be semantically distinct enough that if you couple them, you'll create a brittle mess.

Additionally, there's always going to be global changes (update the code style, document things, refactor into a new pattern, add new functionality to callers, etc.). The question isn't whether you use your lanuage's tools or you do it by hand, the question is whether you use an LLM or do it by hand :P

The only people who this stops are the people who want to do things "by the book". :P

If your data is encrypted, what your adversary needs is some information about you - which they can gather by either buying it from someone or by investigating you - and a $10 wrench to go over there and get the keys out from you...

Most secrets are only secrets because the combination of obscurity and incentives raises the bar high enough so no one who wants to bother really bothers.