janderland

SQL is a horrible language. I’d gladly program in something composable like Elm.

YouTubers monetize fair use all the time. Is that significantly different?

Maybe you’re implying that message passing makes compile-time validation of messages difficult? The types themselves are a solved problem, as long as you allow actors to fail when they receive a message they can’t handle.

What kind of codebase do you work on (number of lines?). How many tokens does your local context support?

Maybe your statement is true for smaller codebases and shorter conversations, but I’d be surprised if you actually achieve good results on millions of lines of code with a million token context.

Granted if your setup works well for your workload then that’s all you need.

Has Kimi found a way to vastly reduce the amount of VRAM required without running at 3 tokens per second? That’s the real concern.

This is a ridiculous analogy. Test the app. Read its source code. Developers could always write toxic instruction in your tools. AI may write inefficient or messy code, but it’s far from nefarious. “Asbestos” code is written intentionally by humans, not unintentionally AI.

JMESPath is what I wish jq was. Consistent grammar. It only issue is it lacks the ability to convert JSON to other formats like CSV.

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.

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.

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.

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?

> 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.

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