illuminator83

malloc and free aren't overhead.

If I'm reading a file, then opening and closing a file is not overhead either. But if I'm reading a file and some convoluted system in my own process is slapping some 3000% extra work on top because it needs to asynchronously track opened files and close them at arbitrary time later - that is overhead and creates bugs.

Which is one reason why many GC languages end up with bad emulations of an almost overhead free pattern like "try-with-resources" in Java and "IDisposable" in C# etc.

Well, I think some people underestimate how old and badly written a lot of software can be.

I've seen some seriously bad legacy code bases. In fact, I've spent many years of my career hired specifically to redesigning and rewriting software. Either legacy code or code that wasn't written by pro software engineers in the first place (e.g. engineers of other fields or scientists with various specializations).

And thus, I also observe that many people aren't aware how much software (in production) was created by people for whom creating software is a secondary or tertiary interest and skill at best.

And yes, typically it gets much better when rewritten later and by a pro.

Not all software needs that, it doesn't always work. But it needs to happen quite often for the software to stay maintainable and extensible with new features. In a lot of these cases only the original author would even dare to touch it. Good for short term job security, bad for the company.

And it isn't a requirement for the original authors to be involved (though that helps a lot usually).

I myself rewrite my own code quite often and tend to refactor and iterate on it a lot. The first shot is rarely good. But it get's good after a while.

IMHO Garbage collection is and always was an evolutionary dead end. No matter how nice you make it, it feels wrong to make a mess and have some else clean it up inefficiently at some point later.

And because of that it always involves some sort of hidden runtime cost which might bite you eventually and makes it unusable for many tasks.

I'd rather have my resource management verified at compile time and with no runtime overhead. That this is possible is proven by multiple languages now.

That being said, I can imagine some C programs for which using Fil-C is an acceptable trade-off because they just won't be rewritten in language that is safer anytime soon.

Been doing that for many years now. Other printer companies don't exist for me.

Well, they've been using the whole internet and anything else they can get their hands on to train their models. If you are using LLMs and want to continue seeing them get better and more useful, you really have to accept that they train on data collected from their users. Unless there is another technology breakthrough somehow, this is going to be the best they can do to increase user satisfaction and make their product more useful.

TBH, I'd love to have a model which was specifically trained on conversation which I had with an earlier iteration. That would make it adapt to me and be less frustrating. Right now I'm relying only on instruction files to somewhat tune a model to my needs.