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.

I love Twilight Princess because of this dichotomy. Yes it has all the flaws you have mentioned, but it also suggests at what a Zelda game could look like in an era where people thought that the Zelda series was Nintendo's competitor to games like Shadow of Colossus, ICO, Drakengard, Legend of Kain of the era.

Ultimately, Nintendo realized that that's not the way they want to take the IP. They wanted game-play to feel timeless and take a priority, and the narrative to take a backseat.

It's was definitely the right choice and revived the IP, but despite it's technical excellence and dynamic game-play I can not get into the latest entries.

It's a shame you did not like Spirit Tracks. I found the puzzles to actually be interesting and the boss battles to be the most exhilarating in the series - with a good soundtrack to boot.

There’s plenty of vegetarians due to ethical or cultural reasons that never acquired the taste for traditional plant based foods and are looking for a more substantial, protein heavy alternative.

Is it niche? Yes, but vegetarians were always niche.

While the late 2010s fixated on “protein” and “macros” - allowing products like Beyond or Soylent to shine.

Much of the health discourse around the 2020s has focused on quality of the ingredients and “processed foods”. So naturally Beyond is caught on the crossfire.

Is there a future where this stuff is proven to be better for you in the short and long term? I sure hope so. But there’s way too many unknowns right now and it’s expensive to boot.

Garbage in garbage out as they say. I will be the first to admit that Claude enables me to do certain things that I simply could not do before without investing a significant amount of time and energy.

At the same time, the amount of anti-patterns the LLM generates is higher than I am able to manage. No Claude.md and Skills.md have not fixed the issue.

Building a production grade system using Claude has been a fools errand for me. Whatever time/energy i save by not writing code - I end up paying back when I read code that I did not write and fixing anti-patterns left and right.

I rationalized by a bit - deflecting by saying this is AI's code not mine. But no - this is my code and it's bad.

Yea, it's not not necessarily that the LLM itself is better at customer support than a human.

But i've found that it's just good enough that support and teams can handle addressing the systematic problems while the LLM deals with operational overhead.

Guess who also benefits from well structured, clean, modular, well documented, and concise code?

Computers and LLMs!

I've been a JetBrains suscriber for a while, because at the time I saw that I preferred the UI experience over Jetbrains to VSCode. The IDE is well built, they have a better product/user experience team driving and coordinating those changes.

I cannot stand VSCode - even if I configure it to my liking I am unable to make it look or feel the way that makes me feel at home.

I cancelled my subscription a week ago. Yes I still dislike VSCode. But the same product Jetbrains has honed has struggled to integrate with AI agents as well.

I've played with some combination of picking vim/emacs with Claude CLI. I find navigating code a little bit slower since I have trouble building the muscle memory. I've always been big at using my mouse to jump around the file tree.

Configuring LSPs for these text editors and getting things to "just work" takes a little bit more time. I don't know what special sauce is in IntelliJ but for the supported languages, but it took a while for me to be okay with LSPs compared to IntelliJ.

But LLMs and Agents remove a need for a lot of the the advanced IDE features and I've found it better to return back to just treating everything like a text buffer again and using specialized tools to fill in the gaps that were missing with the loss of IntelliJ

I don't need lower level than go. I just really like Rust' type system and error handling and I want it in a compiled language.

Zero Cost abstractions and it's memory model is fascinating - but isn't particularly useful for the part of the tech stack I work on.