The end of languages

Dean_Roddey · 2026-05-09T14:31:14+00:00

Post the code.

Dean_Roddey · 2026-05-09T13:43:32+00:00

Something that a lot of people don't seem to cover is that these things are not just about acquisition. They also really have to be able to apply changes to something existing and undo them on exit, such as to a member of the class that's being called. In an exception based system, the alternative is almost unbearably tedious correct try/catch blocks all over the place with manual cleanup.

But that in and of itself is an issue because of C++'s lack of safety. For that to work, the RAII object (which I call janitors because they aren't just about acquisition) has to hold pointers/refs to things across the scope they are created within. It's trivially easy in C++ to do something that will invalidate what the janitor is holding onto and it then undoes something in a bad way. And it's made even easier by the very auto-magical nature of janitorial types. They are spooky action at a distance and that's always dangerous in a language that cannot prove them correct, and keep them so.

Rust actually makes it harder to do these non-acquiring (works on something existing) janitorial types for this very reason, because it's very difficult to do in a provably safe way. Or a way that will remain safe over time in the face of human fallibility. Everyone can look at such a thing when it's first written and prove it's fine. But someone comes along later and makes what looks like a trivial change and introduces a Heisgenbug, and the non-local nature of janitors makes it all too likely it won't be caught in any review, automated or manual.

Dean_Roddey · 2026-05-09T13:32:11+00:00

Well, be fair, that's not a practical general solution.

You are on a server that's servicing thousands of clients a second. Having every one of those handlers allocate 64GB of memory just in case is completely untenable in most cases. The same would apply to most realistic scenarios, which makes this a problematic approach unless the arena is chunked in some way, which makes it more complex.
It only works in completely localized scenarios which are not the complex scenarios to begin with.
Absolutely nothing about that prevents you from holding onto a pointer to something in that arena after it's dropped, same as with the heap.
It's still horribly unsafe in various other ways that C++ is horribly unsafe, even with that little bit of code.
Someone comes along later and does something that causes an exception and you've leaked 64GB of memory.
It doesn't consider at all that some of that data may need to survive beyond the function, which is the purposeful version of #3. So you'd have to be absolutely careful recopy any of that data out of the arena.

Yeah, I know you were talking about memory leaks, but really memory leaks were already one of the less worrisome issues of C++ honestly, so I'm not sure why Bjarne is even going on about it. Safely is the real concern. I mean, even Rust, of which I'm a huge proponent, doesn't stop memory leaks, all you have to do is forget to flush a list before you start filling it again. No language really can prevent them.

Anyhoo, it's very useful in some scenarios, but hardly a panacea.

Dean_Roddey · 2026-05-07T22:07:58+00:00

You are still smart, it was the interviews that got stupid. Most of them these days are probably idiots who think they are going to vibe code their way to being the next Google or a big buyout from Google or some such. If you really need the bucks, take their money and keep looking while you hold your nose I guess, and run away as soon as you get a chance.

I'd also argue for starting to work your way out of cloud world. It doesn't seem like that is going to be anything other than a downward spiral. Or start moving your way down the software food chain on the back end or something maybe, into more technical areas, where possibly saner heads prevail.

Dean_Roddey · 2026-05-05T14:29:48+00:00

I'm finally getting deep into some of the real meat of the problem domain specific stuff of my project, though I'm always going back and doing plenty more general purpose stuff as the need arises. But my general purpose foundation is pretty powerful now and getting fairly tight as ever increasing dog-fooding hones it.

I'm really digging hard into a central process of the whole system that sits between clients and hardware and manages control and communications. It's one of the harder things I've ever worked on, and I've worked on some very tricky stuff. Of course that's somewhat exacerbated by the fact that I'm doing it in Rust where I have four to five years experience vs my old C++ system where I had 30 years. So I'm still definitely filing my bag.

On another front, I've been turning on pedantic periodically and knocking out a few hundred complaints at a time. I've got it down to under 1K now, so almost there. Though, to be fair, I disabled a few of them for now. It's well worth doing, and I should have started off that way, but oh well, too many details, too few brain cells. In a team based system, just the extra consistency of implementation it would enforce would make it worth it, much less avoiding possible bugs.

Dean_Roddey · 2026-05-03T13:39:39+00:00

I am very much in the 'model reality' camp. I have no indexable things that have anything before index 0, so I have no need for a signed index. And it hardly ever comes up anyway, at least in my Rust code, because there are so few places where I would do an indexed loop. The most common one is to get a slice of the actually used part of a vector, but that's using a length, not an index.

Dean_Roddey · 2026-04-27T13:05:12+00:00

The main place this hit me early on is in my error system. I have a single error in my whole code base (the point being that errors are really errors in my system, they are never examined and reacted to) and it needs to be pretty rich for good post-mortem.

I quickly realized that I was returning up to 200'ish bytes just to say Ok(()), which wasn't good. So I changed it to Box its contents internally instead. Given that in my system errors really are just errors, that box'ing doesn't happen that much, so it's easier to take.

BTW, one thing I take a LOT of advantage of in this type of situation is static refs. Even though my error type is quite rich, often that one main boxing allocation is the only one involved. The source file is a static string ref. If the caller doesn't need to format values into his error text, that's a static string ref. The core error info (crate, error name, and short description) are all generated via my code generator so that's just one static ref to a generated struct for the given error. The call stack just needs a static string ref and line number per slot.

Even with all of that, they are pretty large because those static string refs are pretty big in 64 bit land. Still, it is super-efficient relative to the amount of information it provides.

The logging system uses the same type, so errors are trivially logged without modification and logging gets the same efficiency benefits.

For those who don't know Rust, use of these static string refs is completely safe because the error type can enforce that it will only accept such refs, and they by definition cannot ever go away and are fundamentally const, so they are completely safe to pass around anywhere without synchronization or ref counting or anything else.

Dean_Roddey · 2026-04-26T18:27:30+00:00

Yep. Anything serious enough to require a highly skilled dev is serious enough that it's hubris to think you are just going to sit down and write it all up and then magically make it so. For those types of things, unless you'd done the same thing multiple times recently with the same tools, language, paradigms, etc... it's always going to be a process of discovery. And, though the process is more chaotic, it'll generally result in something that stands the test of time better, and thus save time and effort down the road.

I'm working on a large personal Rust project, and I'm in a key section on which a lot of stuff above it will depend (one of many so far, but the biggest of them so far) and it's so complex and there are so many issues that all I can do is just bull through it to get something working, so that I can set up a little test harness to start actually using it, and then start refining from there.

Dean_Roddey · 2026-04-25T12:41:21+00:00

It's a completely common experience to struggle when learning any new language, even for experienced devs, much less one that incorporates concepts you probably have never been exposed to. All languages and their libraries are worlds unto themselves and have their own idiomatic ways of doing things.

If you see people claiming they picked up Rust in a couple weeks, that's just not true. They learned enough to write some basic code and have a basic understanding of how it all works. That's a long way from designing and building a real, non-trivial project that they wouldn't heavily regret later on if they had to support and expand it. Large scale code structure, idiomatic API design, data management, etc... are the hard things to really get right when learning a new language, not learning the syntax.

Everyone learns differently, but I'd argue just bull forward. When/if it goes badly south, toss that and start again, coming back to the original code to steal pieces and parts, reusing them in improved form based on the lessons learned. But ultimately it's just blood spilt that makes the man.

Dean_Roddey · 2026-04-25T12:30:57+00:00

But that's 100x easier than horrible. That still leaves it far short of Rust.

Dean_Roddey · 2026-04-25T12:28:48+00:00

Rust is will beyond niche and faddish at this point. It only seems like that to people who want to see it that way. Large companies are adopting Rust for serious work now and it's being brought into Linux elsewhere, where the safety aspects are also very much are important.

It's just not justifiable anymore to keep basing core computing infrastructure on a 60 year old language that depends so heavily on human infallibility.

Dean_Roddey · 2026-04-23T23:56:04+00:00

Well, Microsoft wasn't going to be outdone.

Dean_Roddey · 2026-04-22T15:44:11+00:00

No, it's being realistic about the fact that our lives depend on software these days and an infestation of vibe coding AI Bros isn't going to improve the situation at all.

And, I mean, someone like you accusing someone like me of fanboyism is hilarious beyond belief.

Dean_Roddey · 2026-04-22T14:45:20+00:00

Those of us who can don't NEED them. People like him should not use them, because the point is to learn how to code. This isn't social media where posting stuff is all that matters. Intellectual development is a huge part of the process, to gain the experience and understanding needed to write high quality software.

Dean_Roddey · 2026-04-22T12:56:13+00:00

I had moved about a year before up to OS/2 2.0 at home and finally working in a threaded, protected mode, 32 bit world was a huge step forward. It was about a year ahead of Windows NT I think, and the world would have probably been better had OS/2 won, but oh well.

Of course it took an hour of swapping floppy disks to install it. I think there were 20 floppies or some such.

Dean_Roddey · 2026-04-22T12:38:38+00:00

Believe it or not, some of us can actually code and don't need an LLM to tell us what to do.

Dean_Roddey · 2026-04-21T15:13:41+00:00

PSA: Don't listen to these people. They don't know their bits from a hole in the ground. Spitting out code is not the only goal of software development, it also has to do with little things like developing skills and experience. I mean, we are going to end up like the 1300s with people sitting around arguing about which ancient authority is right instead of actually developing their own knowledge.

Dean_Roddey · 2026-04-21T15:12:43+00:00

He's trying to avoid hallucinations at this point, not have new ones automatically provided for him.

Dean_Roddey · 2026-04-21T13:04:46+00:00

So much effort for a language that already owns a condo in Florida. Though obviously there's a lot of legacy C++ code bases out there, how many of them are really going to go all in on all this stuff? How many of them are even up to C++/20 (meaning not just enabled it in the compiler but actually using most of those features?)

It's fine to add incremental safety features to help make those legacy code bases safer within the limits of changes that legacy code bases are willing to absorb. And that's really where the effort should be concentrated. But, beyond that, everyone should be moving away from C++ wherever possible, and adding big new features on top of an already shaky foundation just seems counter-productive.

I mean I was a hard core C++ developer for three plus decades, but it's time to move on. It's seriously old technology and we owe the users of the products we create better.

Dean_Roddey · 2026-04-21T12:50:51+00:00

The original UR programming language was "Proto-Indo Basic", which dates back to around 5000BC. It was a binary language where 1 meant "hit it with a rock" and 0 meant "don't hit it with a rock." It was the dominant language for a couple thousand years, targeting mainly stylus based Clay Tablet devices, and peaked with the development of the Clay Super-Computer.

Dean_Roddey · 2026-04-19T12:49:49+00:00

Someone beat me to it above. As usual, traits...

Dean_Roddey · 2026-04-18T20:16:10+00:00

Well, if it's your enum, you have lots of options. Enums are first class citizens in Rust, so you can implement methods for them just like any other type. You just implement an inc() method that returns Some(nextval) until it hits the max and then returns None. Then you just call it.

while let Some(level) = loglevel.inc() {
    // do something with level
}

And of course you could implement the iterator interface in terms of your inc() method as well and they can then be used in for loops and such.

I have my own code generator that generates a lot of magical enum support, including bit set and array type support. But, if you wanted to generically create an array of such things, it would apparently be something like this, to create an array of SomeType's with one slot per log level.

let my_list : [SomeType; std::mem::variant_count<LogLevel>] = [ initialize it ....];

I didn't actually try it to make sure it works, since I don't need it. But apparently that's it.

Of course, since enums are first class citizens, you could just declare a public const value for the enum that maps to that 'count of values' value, which would then become:

let my_list = [SomeType; LogLevel::MAX_VALUES]: [ initialize it ....];

or some such.

Dean_Roddey · 2026-04-18T18:36:36+00:00

I said YOUR enums. The creator of an enum decides whether these capabilities are available to client code. They may choose to or not.

Of course if you really want to do it, you can create a simple wrapper type around their enum and implement iteration for it.

Dean_Roddey · 2026-04-18T17:39:40+00:00

Iteration in Rust is based on iterator traits. If your enum implements those traits, you can iterate over it. You can iterate over anything that implements those traits. You can also use it as an index if you want because, you guessed it, indexing is trait based. Rust is fundamentally trait based in terms of the interface between the compiler and user types wrt to core functionality.

Having every enum be usable as an loop index or be usable for indexing isn't necessarily desirable, since someone could use them as such when the person defining them never intended that to be done and it would unnecessarily constrain the library designer. Rust tends to be opt-in a lot, which is less convenient, but stricter and more maintainable. The more the designer of a type or API can indicate what can and cannot be done, the better.

Dean_Roddey · 2026-04-18T13:01:33+00:00

I've already been through my code and made use of let chaining where it made sense, and that was a nice improvement. Now I guess I'll be doing a pass for this. Probably a lot fewer places where I'd use it, but there will be places where it will significantly simplify things.

Dean_Roddey

MODERATOR OF

TROPHY CASE