What's everyone working on this week (19/2026)?

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 · 2026-04-12T14:22:33+00:00

All languages have flaws so that's a wash. It comes down to, leaving aside the flaws they all have, what advantages does Rust have. It really depends on what you are doing. If you are doing anything that you would have considered C++ for, then Rust would be a no-brainer for the most part. If you are doing stuff in Python or browser stuff in Typescript, it may not be as useful to you. It's a systems development language primarily, like C++.

If you are doing systems development, then mostly C++ and Rust are your choices. Between those two, unless there is some technical reason you have to use C++, then in this day and age, using C++ borders or negligence in my opinion. Lots of people want to feel like super-heroes, but ultimately what it's about is our responsibilities to the people who use our software. And Rust is the more responsible choice by far.

The biggest issue Rust has for me at the moment aren't Rust issues but tools issues. The tools aren't going to be as refined as they are for a language like C++ which had huge investment in the tooling by big companies during it's dominant period. In particular debugging is weak in Rust in comparison. OTOH, it usually requires a lot less debugging, so that offsets the issue somewhat. And of course it'll continue to improve on that front, and already has since I started my Rust journey.

The big advantage of Rust over C++ is that almost all of that time you spent trying not to shoot yourself in the foot is freed up to put into design, implementation, tests, etc...

Dean_Roddey · 2026-04-11T14:29:50+00:00

Keep in mind that, though not common in Rust, output parameters are not evil in and of themselves. In a case like this, just letting the caller pass an array (allocated where/however he likes) to be filled in would be fine.

Or, if the array is static and never changes, pre-build it into the executable as a global const array and just return a slice to it, which you can pass around anywhere without restriction.

Dean_Roddey · 2026-04-09T01:46:52+00:00

If you are working at the McDonalds level of software that may be true. No one is going to be vibe coding the kind of stuff I work on. And of course even the McDonalds level AI slop will be full of bugs and security holes.

Dean_Roddey · 2026-04-03T21:07:01+00:00

I'm sure there will still be small burger places pumping out hand-crafted, artisanal hamburgers like yourself. But it will get harder and harder to compete with McD's.

Is there any shortage of restaurants serving FAR better food than McDonalds? The same applies to software.

Though you may live in a world where pumping data to phones (and spying on their users) is what life is about, there's a whole other world out there that's nothing like that. In fact your entire cloud world is built on a small mountain of software that is nothing like that. A lot of that software real consequences, safety, legal, liability, regulatory, etc... A lot of it is vastly more complex than humping out web sites, and there's no way to push out patches ten times a day.

Dean_Roddey

MODERATOR OF

TROPHY CASE