The original Skunkworks optimizes for a low production volume of vehicles which operate in a very extreme band of performance. And yes these projects are able to deliver within budget, but they are still very expensive machines. This is totally opposite to what is applicable to Ford, where really the innovation needs to be in the factory.
The other key lesson from the Skunkworks book, which is applicable, is that to the greatest degree possible, one should not reinvent the wheel. Reuse parts from other high production vehicles, which have proven their reliability. Focus the innovation tactically.
Its never been quicker or cheaper to build something with bad foundational assumptions and principles. Its never been easier to add features whilst not recognizing that it comes with added responsibility. And it will never be too late to hire me for your V2 migration project.
There are performance reasons to handle memory allocation manually and tactically. This is why languages which deal with memory manually are not going anywhere.
Whether Zig will become dominant in that space remains to be seen.
Ok, but doing manual memory management in Rust is a bit like digging a ditch with a spoon. I get that its technically possible, that does not mean it should be done outside the most exceptional of circumstances.
This kind of thing is totally routine here in South Africa. Probably about a third of power cuts in my area these days are due to some kind of cable or electrical theft.
I'll wait until they do some PAL emulation: take an NTSC source, blurrily upscale it to 576p, apply a crap deinterlacing algorithm to produce a technically progressive image, and some frame blending to get it to 25 fps. Shitorific.
I think the 80/20 solution for reliable workflows is:
- Ensure the workflow is idempotent - if it stops or fails at any point, you should be able to start it from scratch and skip / happily redo various elements.
- Store the messages which trigger workflows.
- Track failures (if your log aggregation is good, even that's enough to start).
Then when the odd thing fails (or sometimes a bunch of things fail, because e.g. a core integration goes down) you can lookup the messages and have a little script or tool to go and re-queue them. This is an easy starting point that can keep you going for a long time until you really approach huge scale.
At my last company, I wrote a little tool for pretty printing our JSON logs. You pipe into it and it prints out. It's quite easy to write such a thing in Go, and useful for assigning preferred timezone conversions, and colors for your special common log items.
Google's Search and its AI result can alternatively help or hinder me, I find.
If I'm looking for a relatively straightforward and simple piece of information quickly (e.g. "wooden arch mirror stores linden") then the AI summary can be useful, because I don't need more than surface level info.
If I intend to analyze and understand something (e.g. "developer API issues Zoho Thrive"), then the AI summary and the general degradation in the quality of search results from Google really hinder me. I have to work to avoid a lazy and low value answer, whereas what I really want to do is go through various actual websites and reflect on them to gain insight.
I feel like the second scenario was never good with Google. You had to go through several search results describing other problems, and there was a high chance you still didn't find anything relating to yours; and then, it wasn't guaranteed that a years-old problem got fixed.
If I have an issue with my Mac, seeing an Apple Discussions result at the top readies me for disappointment.
Meanwhile, I've found a normal chat with current ChatGPT to be very helpful, as long as it isn't about itself or other OpenAI products.
My usecase would be investigating a potential integration - I want to go and see everyone's comments on the websites themselves. I'm not looking for an answer - I don't know the question - I'm looking for understanding.
I find it to be a fundamental hinderance as they use a cheap model. The cheap model gets confused based on conflicting reddit threads and then I get a wrong answer.
It's better to just ask codex to do the search for me, but this is much slower - but increasingly my go to. I wish there was a fast search api codex could hook into to answer internet questions faster.
There, fixed it for you.
reply