8,877 karma · joined June 22, 2009
Couple of WTFs that come to mind:
* How many bugs did one have per commit, that commits have to noticeably grow in order to not have those bugs in the first place?
* How does one even do software engineering if the (best) developers can’t reason about the code?
Replacing that with AI is the kind of SV-stupid which starts making sense after the educational system was hollowed out for profit reasons and is failing. The human in that system is just checking in and DGAF.
The revealing thing is how the cheating is seen as normal and how the other people are considered out of touch or wrong.
Real designers would avoid them in the first place.
This may be a failure mode similar to juniors using AI and making it much harder for seniors to find the bugs, because the code actually looks good at first sight.
I don’t think the blog author actually has any design skills based on the prompts and the AI obviously can’t nudge them in the right direction or help them clarify their brief, like a real designer (i.e. not random online freelancers) would.
A disgruntled former Azure employee posting what a clusterfuck their SW, including their Rust effort is? That’s both rare and interesting.
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.
For the first issue of complexity, the reply is along the lines of show me the code and then either nitpicking that to pieces or explaining in several paragraphs how the behavior is perfectly reasonable and in fact quite easy to understand. Beginners get intimidated, professionals don’t have time to write novels on HN. Complexity in Rust is systemic. It’s little things accumulating and amplifying each-other that add up to having to spend significant time just designing types to satisfy the static analyzer. Many Rust programmers seem to see the type system as a hammer to be used liberally, an predilection also known in the C++ metaprogramming community.
On the second topic (also present in this thread) the counter-argument is that other languages do it too and nothing bad happened so far. The former is not valid, because Rust is uniquely bad in its competitor group and security by waiting is not a valued approach.
First of all, Rust is default safe. In C++ developers always trade performance for safety, in Rust they just swallow the penalty (which is often still performant enough). C++ code will often not be as memory safe as it could because someone decided to not use particular checks (like compiler-driven integer overflow checks).
Secondly, Android C++ code is not particularly high quality, also when it comes to memory safety. A lot of it is also quite old. I would consider it your average massive project, not a masterpiece coded by amazing engineers.
Thirdly, it has a massive target on its back and is under attack by pretty much everyone. They have to use whatever they can to keep up with the attackers.
Several companies have these issues and approach them in different ways. Rust is a very attractive approach for developers, since it’s just another programming language. It’s also quite ugly, people complain about its complexity and is unfortunately suffering from dependency explosion. I hope it’s a stepping stone to something better.
Good luck with your revolution. :)