There's a Joel On Software post [1] in the same vein as this, which totally changed the way I think about writing software. You should aim to write software which can be verified locally with the smallest window of context. It's informed a lot of my decisions around linters, static analyzers, assertions, etc. I'm always looking for assertions that narrow state and reduce the number of lines you need to read to verify the correctness.
Rust has definitely caught my eyes a few times here, since most of what I described is manual. Particularly in the embedded space RTIC [2] has some really neat stuff going on. Other languages have good type systems and spatial memory safety, but nothing else seems to have Rust's killer features around concurrency.
> Isolated QA should not exist because anything a QA engineer can do manually can be automated.
I almost entirely agree. You'd certainly want a majority of QA responsibilities to fall to devs since that keeps the feedback loop tight. Also with the amount of compute we have you can trivially outpace a typical QA team with a single dev working on fuzz tests and property based tests. If you really still feel the need to outsource then there are cool tools like Antithesis [1] which let you trade money for compute in their complicated fuzz testing suite.
Where that falls apart imo is when your software interacts with hardware in any non-trivial way. Fuzz testing doesn't really work when your system is spinning big and heavy things for example. Real hardware that interacts with the world will always create this gap where the devs don't know how to fully test it. Your systems engineers are best equipped to handle this and ensure certain controls follow the right curves, but they typically don't have the bandwidth or are very inexperienced with software. I think a QA organization _can_ fill this gap and deliver value. But I'd almost always prefer hiring another 1 or 2 system engineers who can work towards this problem full time instead. It's much easier to train someone in software than it is to train them in motor control or sealed systems.
But they're not willing. And they'll often just cause more damage/loss than they provide in benefit to the company. Even the most benign drug which people claim is fine is one that makes you lazy and slow. Why would you employ someone so addicted to it that they can't abstain for a few weeks?
"Piss tests" filter out a lot of anti-social behavior.
I think it mostly comes down to the standard library guiding you down this path explicitly. The C stdlib is quite outdated and is full of bad design that affects both performance and ergonomics. It certainly doesn't guide you down the path of smart design.
Zig _the language_ barely does any of the heavy lifting on this front. The allocator and io stories are both just stdlib interfaces. Really the language just exists to facilitate the great toolchain and stdlib. From my experience the stdlib seems to make all the right choices, and the only time it doesn't is when the API was quickly created to get things working, but hasn't been revisited since.
A great case study of the stdlib being almost perfect is SinglyLinkedList [1]. Many other languages implement it as a container, but Zig has opted to implement it as an intrusively embedded element. This might confuse a beginner who would expect SinglyLinkedList(T) instead, but it has implications surrounding allocation and it turns out that embedding it gives you a more powerful API. And of course all operations are defined with performance in mind. prepend is given to you since it's cheap, but if you want postpend you have to implement it yourself (it's a one liner, but clearly more expensive to the reader).
Little decisions add up to make the language feel great to use and genuinely impressive for learning new things.
Antithesis talks about some very particular use cases, but they're not the first to explore this. SQLite has something similar in the form of their `testcase` macro. [1]
What's most shocking about their whole website is how it goes to show how unserious the software industry is at large with regards to testing. It's not surprising when a good chunk of the programmers I know are vehemently opposed to "adding too many assertions", let alone something like this.
I don't think it was that strong of an over-generalization. AI doesn't seem to help out in the same way a human would. My teammates will push back and ask for proof of effort (a PR, some typedefs, a diagram, etc.). And sometimes they'll even know how to solve my problem since they have experience with the codebase.
On the other hand you have AI which, out of the box, seems content to go along with anything and will happily write code for me. And I've never seen it have a single insight on the same level as my teammates. All of which is to say, AI doesn't really feel like something you can properly "ask" something. It's especially far away from that when it's just generating code and nothing else.
I think what the article gets at, but doesn't quite deliver on, is similar to this great take from Casey Muratori [1] about how programming with a learning-based mindset means that AI is inherently not useful to you.
I personally find AI code gen most useful for one-off throwaway code where I have zero intent to learn. I imagine this means that the opposite end of the spectrum where learning is maximized is one where the AI doesn't generate any code for me.
I'm sure there are some people for which the "AI-Driven Engineering" approach would be beneficial, but at least for me I find that replacing those AI coding blocks with just writing the code myself is much more enjoyable, and thus more sustainable to actually delivering something at the end.
Type hints seem fantastic for when you're in maintenance mode and want to add sanity back to a system via automated tooling.
However for new projects I find that I'd much rather pick technologies that start me off with a sanity floor which is higher than Python's sanity ceiling. At this point I don't want to touch a dynamically typed language ever again.
Vibes are totally different though. People go childfree by choice, whereas men go MGTOW because there __is no other choice__ (that they find easy or preferable). I've heard it described before as "men sent their own way (MSTOW)", which is fitting since one usually identifies with the label after many unsuccessful relationships.
It's fine, I take every opportunity I can to shit on my own job lol.
Ironically what you're looking for can be found in the lowest end, and the highest end products. Low end means low features, so you can get away with just a knob and maybe a few LEDs. Look at Hotpoint (GE's low end brand) or a low end LG washer [0].
High end usually forgoes a flashy UI as well since it's about the style and being a centerpiece.
The mid end is where it's weird because features justify the extra cost. In order to make those available you need to have an LCD screen and more buttons.
In all these categories you'll run into software though. It's cheaper than a electro-mechanical solution. We only fall back to the old ways when required for safety/compliance.
I work on embedded appliance software at my job. A few comments:
It's quite easy to find yourself having non-zero boot times for some unfortunate reasons. At least in my org, the software as a whole is RAM/ROM constrained rather than speed constrained. Even when you're this close to bare metal, devs tend to write over-abstracted code riddled with inefficiencies. And of course most people don't profile the application at all. This is a symptom of the software being under-tested imo. I have personally written tooling to integration test the whole application for a few appliances, and for one appliance initializing the application 56 times took over 1 second. On a modern machine it should take milliseconds. After profiling I found that 99%+ of our time was spent servicing a subscription tied to all events, that really only needed to subscribe to just one or two.
Along with that there are other reasons for long apparent boot up times:
- Waiting for other boards to connect and talk to each other. Your UI can't do anything until it knows the state from the main control.
- Randomized delays to prevent current surges after a blackout. You'll see this on ACs or other appliances that might have hundreds of identical units in a building.
- Waiting for flash memory to be readable
All of this adds up to seconds of boot time. Yet ultimately none of this matters to the business people because we're an appliance company, NOT a software company. Our software is mostly incidental to having a functioning product, and boot times could go way higher without the business being worried. Though recently yes, we have entered the data market hence the push for smart features. Word to the wise, avoid any appliance with Android in it if you don't like the idea of forced connected features!
I unfortunately don't have any solutions to most of the problems presented in the article. All I can do is continue to try writing bullet-proof software and push back against forced connected features.
And those checks are well worth paying for, enough that Rust also has them! I'm sure Rust would have even worse ergonomics if it insisted on no runtime bounds/unwrap checks. The performance cost is low enough that every systems programming language should have spatial safety. To illustrate, Google found that hardening libc++ by adding bounds checks only led to a 0.30% performance impact on their services [1]. It's not hard to imagine that a similar run-time cost affects Zig and Rust. Both languages make attempts to optimize the checks away if the operation is known-safe. Although, maybe Rust is more successful due to the borrow checker.
> and/or misusable allocator passing.
Could you clarify how allocator misuse might lead to a spatial safety violation?
> And this is where Rust differs; Rust will reduce the likelihood of bugs from happening in the first place. I'm not saying Zig doesn't also do that, Rust just does it more.
I'd argue that it does this a LOT more. When it comes to spatial safety, Rust and Zig are on par. However in terms of temporal safety I think Zig lags far behind Rust... along with basically every other compiled systems language.
If you had to come up with a single good reason to use Rust over Zig, it would definitely be temporal safety. A majority of applications don't need this though, or can be designed such that they don't.
One of my main issues with Rust is that it makes it easy to write spaghetti code that uses reference counting all over the place. I don't recommend people to use Rust until they become a "N+1 programmer" that Casey Muratori describes as "grouped element thinking" [1]. At this point, most of that programmers problems are solved and suddenly the Zig vs Rust debate becomes much more nuanced.
Most of the human-made slop you'll see is going to be, at least on its surface, high quality and well produced since that's what goes viral and gets shared. To that end, I agree with you.
It is worth noting though that the other 99% of human-made slop doesn't make it to you since it never gets popular, hence why hard to filter human-made slop can seem over-represented just through survivorship bias.
Rust has definitely caught my eyes a few times here, since most of what I described is manual. Particularly in the embedded space RTIC [2] has some really neat stuff going on. Other languages have good type systems and spatial memory safety, but nothing else seems to have Rust's killer features around concurrency.
[1] https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...
[2] https://rtic.rs/2/book/en/