South African dev. Love using Go and finding simple, pragmatic solutions. Working to financially empower kids, schools, and parents. Love arty-farty movies.
Having deno desktop do the framework handling for a bunch of popular options is an interesting choice. It seems deno is trying less to be an agnostic JS runtime, and more an "integrate everything toolkit" (not unlike Spring in the Java space).
At a previous job, we introduced a simple Optional generic type, with JSON implementation, and it pretty much solved uncertain nil issues. Sometimes the solution is simple and boring.
There is a core 20% to Kubernetes which is very nice, mostly being the Deployment and Service management stuff. That along with a very basic GitOps for cluster management (an infra repo for operators using Flux, applying service level yaml from app repos in CI) above a cloud managed Kubernetes cluster, where you still keep your DB and build servers off the cluster, can be quite nice for a small team.
Beyond that, there are massive holes of despair to fall down if a novice team starts to engage with extensive operators (starving the control plane), DB operators (distributed persistence) and build operators (spikey, expensive loads). At least, I know that I've had to dig out of those holes.
I just hope people don't use k8s in the same way many use microservices: as a way to introduce complexity for complexity's sake.
Most stupid animations I have seen introduced to UIs are done because they are stupidly effective at impressing business stakeholders, especially non-technical ones.
It never fails to astound me how some people will fawn over "delightful" transitions. I guess I can understand it in the sense that it is an easy thing to help communicate the perception of high quality to the broader business.
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.
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.
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.
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.
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.
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.
Developing software is as much about the journey as the destination. I build a lot of my understanding of the actual problem in the pursuit of solving it.
There are many times when writing a feature that my spidey senses flare up and tell me that this thing is a lot more painful to code then I was expecting (and will be painful to maintain) and that a more elegant process may actually solve the problem, at which point I'll draw up an alternative option and talk to the product owner.
I've definitely started to see the consequences of the converse, which is large amounts of shite brittle code that solved the original spec narrowly, but is now an elephant on our back when we need to add other concerns to the system that cross over.
(BTW, this isn't against the use of coding agents entirely, its more against high-level agentic usage. I tend to use Claude Code to do little well defined tasks whilst I reflect on it).
As a millenial, I first got into something-like-programming by playing around with Game Maker. A few of my colleagues have said similar. I'm curious to see where others in my cohort started...
https://liampulles.com/
me(at)liampulles.com