The people outside of us didn’t care about your beautiful code before. Now we can quickly build their boring applications and spend more time building beautiful things for our community’s sake. Yes, there are economic concerns, but as far as “craft” goes, nothing is stopping us from continuing to enjoy it.

I'd add part of the craft is enjoying those minutiae, sharing lessons, and stories with others. The number of people you can do that with is going to dwindle (and has been for a long time from the tech sphere's coopting of all of it). That's part that I mourn.

Except that's not really true, because the work expands to fill the time allotted. Now we can build more boring applications with fewer people.

Yes, it is true that companies are always hungry for more. But once again, those same companies never cared about beautiful code. They wanted us to build something that works as quickly as possible. In my experience, the beauty of programming was often enjoyed outside of work for this very reason, and we can still enjoy it outside of work for it's own sake.

Don’t Erlang/Elixir model all concurrency as actors, to some level of success. I was under the impression that it allows for quite a bit of deployment flexibility. Actors are addressed in the same way whether they’re on the same machine or not.

yes, to huge levels of success. It's not clear what kibwen is going on about, but local + remote actor concurrency transparency, while not without its complications, comes with massive development and deployment wins.

This reminds of me calorie tracking: you cannot perfectly capture the number of calories or macronutrients, but measuring does seem to help people loose weight. There are probably many loop holes where eating large amounts of certain food, with a certain margin of error, can leads to wildly incorrect estimates.

I wonder how much this analogy applies to carbon tracking? Does using a wide variety of foods help make the tracking more accurate because no single bad estimate becomes overrepresented? Can a similar approach be taken via a wide variety of cloud technologies being used?

Yea, I actually saw something similar in the early days of Infracost, when we didn't track that many price points. The % change and the directionality was really helpful for engineers. Then we iterated on the prices, added more coverage etc, and the accuracy increased to a point where people trust the output of Infracost more than the AWS pricing calculator. That was a cool learning moment for me.

>This reminds of me calorie tracking: you cannot perfectly capture the number of calories or macronutrients, but measuring does seem to help people loose weight.

This probably would explain the success of many fad diets if it were the increased awareness of the eating having an effect beyond the decision making about what to eat.

Totally - something I've been thinking a lot about... I got pulled into these diets at one point in my life - I remember doing atkins, then went full vegan for a while, then went only meat lol

The diets were meh. But the cool thing was that I learnt so much about food in general! I honestly didn't know much about food growing up. I feel like I still don't know that much, but I know the basics, and i'm not afraid of digging into some of the details.

Definitely. It's even worse in educational fads - kids thrive when paid special attention to, often despite the methodology-under-test...

> You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code.

He was suggesting adding a prototype method, not replacing one. Unless the library your using is also adding prototypes, I can't think of an issue with this. Sure, if a new version of JS ends up using these names then things could break, but I'd bet this won't cause him a problem in actuality.

I'm discussing the "adding a prototype method" case and I'm explaining in my comment why this can be, in fact, an issue.

Thanks for the feedback. But you did recommend a method that takes the node as a parameter. What protects me from that method name being claimed by some library later in the exact same way?

This is basically a wrapper around Docker compose. The main advantage is that it takes care of GH action configuration and caching of images.

I couldn’t help but think this as well. I understand wanting software that feels snappy, but this is hardly a problem. Instead of trying to convince the reader that we should care about this, it would be nice if the writer admitted this is an inconsequential personal preference.

Author here . If you'd like an intro to FoundationDB, you can take a look at this blog post I wrote. This CI framework was created during the writing of this post.

https://jander.land/20251227_mutex.html

Perhaps it’s a bug in the VS code terminal? I don’t see anything like this in Kitty.

It depends on what you mean by "sucks". I don't think anyone here is denying that it's often the best tool for the job. You SHOULD learn CSS if you want to be an effective UI programmer simply because you'll encounter it everywhere. But the quality of the language should still be critique IMO.

Good suggestion. I take serializability for granted.