PrimalPower

I was building an pdf export feature for one of my projects the other day.

And safari still behaves differently than my other browsers.

I usually try to give safari a chance whenever I’m working on Macs. I’m always forced to install chrome for some reason or another.

Until the random compatibility quirks stop I don’t see myself returning to safari.

Tai Chi is interested. It's essentially a standing form of yoga.

IMO, in theory it's even more useful for desk workers than yoga.

If you look at the history of Ashtanga Yoga, it was primarily developed for the traditional life. Where even non-laborers spent a significant amount of time on their feet and moving around. This is why doctors, nursers, actors, laborers, retail workers, etc... sing praises about yoga. I struggled to get much out of it, as I found it stretched the stuff that wasn't that tight for me and didn't focus on my problem areas.

The martial arts background of Tai Chi, alongside the pivot to longevity focused practices in East Asia, makes Tai Chi uniquely suited to the woes of a desk worker.

Unfortunately Tai Chi lacks serious standardization or centralization, so it's hard to know if a particular school/class will work for you nor is it as easy to self-study.

Of course, you don't need the Eastern traditions to obtain these same benefits. Dynamic stretching, Pilates, and functional strength training can work too, but I find that the eastern stuff has a meditative/spiritual aspect that regular training does not.

I don't know if anything has changed, but last time I tried codegen for Common Lisp, the LLM would routinely mix up LISP dialects and language specific features.

Less so with Clojure.

during those cases, i've just asked them to give me control over zoom and it's worked fine.

I've never desired to have two people working on the same file at the same time during a debugging/teaching session.

>> why do you think Go is better compared to other languages?

> I didn't say that. :)

I call this the Go paradox.

I simultaneously believe we should reach for it 80% of the time to solve common collaborative problems. And being a poorer language is actually an asset in these cases.

However, in doing so, we get rusty lose our fluency in more expressive, perhaps even better languages.

Usually, if you're in microservices land, it's often possible to spin off a separate service and move the part that has different requirements over. Obviously that isn't always trivial, but service boundaries at least give you that option.

I had a team convinced that a particular subsystem was a mess and that they needed a stronger type system to build it properly because Go would just lead to hacks. They built a better one in Rust, deployed it, and moved traffic over.

Ditto, to some extent, if you're building desktop applications. Many large desktop applications already have multiple components or processes under the hood, and if you're at millions of lines, introducing that complexity may be worth it.

However, not all programs fit the above category. Sometimes you really do need a single lightweight binary and it needs to do a lot of stuff. But I think it's relatively uncommon to need one single binary that is simultaneously very large, architecturally diverse, and unable to delegate substantial complexity to other processes or services.

I see this most in the Kubernetes world, where something that starts as a simple binary gradually increases in scope and complexity. I've seen vendors struggle to keep up and start playing whack-a-mole with that complexity, but generally Go still scales surprisingly well here. Outside of K8s, there are also domains where you may strongly prefer a single-process or single-binary application, such as edge computing or developer tools.

Luckily, products where Go excels in these spaces also tend to have a natural upper bound on their domain complexity, because the operating model is generally about doing one or a few things well.

If Go's type system actually starts fighting you rather than merely being an inconvenience, then yeah, I would seriously look into moving off Go.

If you're working in a space that doesn't fit any of the above, I'd genuinely be interested in hearing about what you're building.

The beauty of go is YAGNI. Language design makes it much harder for people so do stupid and cute things.

During my design process if I start realizing that I’m missing maps, More expressive Types, Or more complex polymorphism. I ask myself if I really need those things.

If I really do. I move off of go.

That’s the beauty of the language. Go does not need more complicated language features because it’s can handle the majority of trivial software work without unnecessary complexity.

The language does not need to solve complicated problems.

perhaps, but chromebooks still come in laptop sizes these days. Other than a few stragglers (e.g lenovo duet), the majority of chromebooks are 12-14 inches.

If you are chasing the form factor, macbooks are serious competitors with really good battery life and tactile feel.

The beauty of netbooks was that ~10 inch form factor. Really the perfect companion device without needing a special bag to carry.

In many ways netbooks were a over a decade too early, and came right before the mobile hardware computing boom.

Netbooks are still not feasibile today, modern web design has made smaller lower res displays completely unusable today.

Tech Companies are trying to push foldable phones and tablets into this niche - but there was always something nice about a keyboard.

i've always found magit better than any opinionated git terminal UI. Including LazyGit.

With Claude, i find myself reaching for Magit even less.

Am I the only one who dislikes Go specifically for CRUD webapps?

I’ve worked with Go professionally for the past 5 years, and I genuinely like the language. I like the anti-framework philosophy, the simplicity, the resistance to over-abstraction or even worse... bad abstractions, fast builds, the light native binaries, and how easy it is for a team to converge on idiomatic code.

But the moment you’re building a normal product app, even “basic CRUD” is rarely just CRUD. You need a database layer, migrations, auth, validation, maybe an OpenAPI spec, background jobs, admin flows, maybe server-side rendering, maybe GraphQL, etc.

You can end up with a large codebase full of repetitive boilerplate for an app that does not actually do much conceptually.

Maybe some people see a large codebase and feel accomplished, but just because each line of code is readable doesn't mean you know what its doing.

I've concluded the only way to avoid workarounds it to reduce my own screen time. I stopped having a tablet myself. Got off the Iphone too.

I still need some smartphone for work. Got the smallest one possible so at least games aren't really fun.

agreed, ultimately claude is faster than an expert K8s in my org at finding things. kubectl has a lot of commands and things to cross-reference. AI Agents handle it like a champ.

That being said, Claude is dumb. I've seen it over-complicate diagnosing things - even though it's initial theory was correct.

I am convinced a good harness can solve this.

Outside of the k8s operating model, I don't see the point of becoming a wiz at the CLI. I learn by practice and I atrophy if i do not practice, there's no world where I will get enough practice to do it on my own anymore.

I compensate by trying to either move up or down the stack depending on the problem.

baby steps

Exactly game theory is that is that everyone make more as a "Senior" or "Mid-Level" in a wealthy/successful org over a "Staff" or "Senior" at a poorer one with less customers.

Of course, game theory implies "infinite games" and of course the real world doesn't operate like that.

And large bureaucratic orgs collapse under their own weight, and the enshittification is the norm despite the number of paying customers.