That was most of your original comment and it remains wrong.

Now you’re talking about specific memory-safety-related features, but you’re making a big assumption. Not everything has to look like Rust. Goodness no! And C++ is still improving in that area too.

“An incremental language change would be to adopt a Rust-like iterator.” One of many possibilities.

“That would be a small language change, but a migration away from begin/end would be a massive churn for C++ codebases that sounds more ridiculous than rewriting in Rust.” Obviously not. Nowadays maybe it could be easily done with AI, even if a Rust-like iterator is not necessarily something that C++ programmers would want.

Not touching a codebase only applies to legacy software which is feature complete. Any actively developed software will benefit from incremental improvements.

Quality C++ projects continuously improve their code and tooling. It would be very convenient for the rustafarian community if the competition stood still, but that’s not the case. Quite happy to see that golang’s also providing solid opposition.

On the other hand, I read an interesting substack blog from an ex-Azure employee the other day: the Russinovich-dictated Rust rewrite was allegedly vaporware for a long time and caused lots of headaches that were not widely known. A highlight for me was the use of over 1000 third party crates in their products.

Would be interesting to know how it’s going nowadays.

As any company, the one I work for also has its decent share of rustafarians. The Rust penetration is modest and slow, but the PR is remarkable.

There are no wood equivalents to Pax, Platsa or Besta, the Ikea workhorses with a modern design. And even if they existed, I don’t think people would rush to buy them. Solid wood’s not what Ikea’s known for and would cost too much for their target market.

I’m not saying they’re bad - I own several of their products, and while I’m overall pleased with them, I don’t love them. The compromises and cost-cutting design choices are always there if you know what to look for. None of my Ikea furniture brings me joy or makes me want to touch it. It’s functional and looks decent to good.

Hollow panels are too light, not robust enough and essentially unrepairable. One could buy some Ikea pieces and cut them / adapt them in irder to upgrade them. These panels make that impossible.

It can help out with understanding tools, workflows, materials, etc but doesn’t actually understands what it’s writing about and is prone to over-engineering, making critical mistakes or just replying with nonsense (for example swapping dimensions, recommending a completely inappropriate procedure, the wrong tool, etc).

This is all with Opus and Sol. Paying 22€ per month for that is a bit pricy for what one gets in return.

Even their absolute high-end stuff is at best particle board with veneer. And you can bet the back will still be that thin 3mm fiberboard, no matter how high-end they look.

Unfortunately, top models nowadays have more and more hollow panels. Seems to me that quality’s going down and they’re trying to save money with the materials they offer. But they can still be a good enough compromise, as I found out when looking for e.g. a TV sideboard.

Doing the right thing for the customer is independent from good design and good code. It’s a problem of requirements and project management. This is an excuse some poor programmers use, that they can’t write good code, but at least they fulfilled the customer requirements :D

Iterative processes are state of the art. The RUP iterative lifecycle illustrates this nicely, with a big chunk of design in inception (first project phase), but also a non-trivial amount of implementation. The design & implementation flow in parallel in the next phases.

It also matters a lot what scale one is operating at. Bigger scale will require more effort up front, PoCs, several big iterations, etc.

To give a smaller scale example, I defined a general simple protocol for two local components, picked the IPC and defined the handshake and teardown sequence. The developer defined the message contents. Reviewed together, then it was implemented. Testing showed that component B, which was OSS and had a fixed rate was sending too fast so the developer patched it to do debouncing.

Coding is nothing like changing tires. To abuse an incorrect analogy even more, the architect would prescribe the properties of the tire or even the behaviour of the vehicle and the developer would design and construct the tires/tracks/whatever either from existing parts or from scratch. Possibly going back and forth on the actual means of locomotion.

To wrap it up. Requirements, architecture and design can be changed. When implementing features I always do architecture review with the team and adapt it based on their feedback. We have rejected or negotiated requirements based on PoC or just developer evaluation.

Sometimes that doesn’t work, sure. If it’s a critical feature or there are hard architectural restrictions one puts in the dev work to figure it out and maybe this leads to a non-ideal implementation. Fundamental mistakes at requirements or architecture level do have higher impact, but iterating and having a good arch <-> dev feedback loop is one of the best methods I know to tackle that.

To give another example, I investigated the potential implementations for a feature and prepared a list of technical approaches sorted by specific architectural attributes. The dev team wrote the code to validate them and option 1 turned out to be impossible because of platform constraints. I adjusted the architecture to use option 2.

They’re orthogonal to AI and to the actual hard technical skills needed to execute on a specific strategy. And if the technical skills are lacking, it doesn’t even matter how good an organisation is at collaboration, whereas hard skills plus organisational disfunction are a known successful pattern :)

Many people did look at this through an individual lens and claimed that design skills, domain knowledge are the truly important abilities. I remember reading on HN at least a couple of popular articles claiming that. Actually, they’re all important and having great design skills without matching coding skills is IMO not really possible. The code feeds into the design, the requirements, the architecture and shapes them.

While the former can certainly be challenging, it’s by far not rocket science. Any reasonably intelligent human can discuss requirements or design a product at a decent level.

Writing code at a decent level is beyond the average reasonably intelligent human. If your mind doesn’t tick a certain way, you will not be able to do it and it will be painfully obvious to anyone that can do it.

Some architecture work and design will be done beforehand, but many details will fall into place as the code is being written, thrown away, adapted, etc.

The idea that code is mere transcription - which I see a lot in these AI discussions - is completely false. Code is a form of low-level design and is where the rubber hits the road.

The best requirements, designs, marketing, etc are worth jack if one fucks up the code. The code is the actual product.

One of the top two issues with Rust is its cumbersome and overbearing syntax and anything which sidesteps that is automatically attractive to anyone which is worried about memory safety and doesn’t like to encode every little detail about in the type system. That’s the majority of programmers… think about it, that’s one of the big reasons people switched to GC languages which are the most popular languages.

The classic Rust approach to addressing criticism of the syntax was a mix of downplaying, gaslighting and “you’re holding it wrong”. But if easy to use, reasonably ergonomic alternatives become available, I expect that most would prefer them to Rust.

A nice example was the EUCDC guidance on AstraZeneca’s vaccine which showed that for young age groups the vaccine was more dangerous than the disease. That allows anyone to make an informed decision for themselves instead of being bullied or emotionally blackmailed “for the greater good”.

Par for the course, I can’t access the actual study from The Lancet and have to settle for second-rate journalist summaries which are typically biased and ultimately worthless.

It think the guidance was more nuanced for teens, but for kids it was very clear.

The vaxmaxxer vs. antivaxxer - like most culture wars - is a US phenomenon.

Anyway, that statement is actually useless. The moment it became clear that some vaccine increases the risk of myocarditis, several European countries swapped them out for the less risky variants, like any sane person would.

The only people still fighting these windmills are the online kind.

Perhaps C++ will start using them en masse and address the biggest memory-safety gaps :)

It is disappointing that some new features are default-unsafe but it is the C++ philosophy.