I use Claude at work and Kimi for side projects. My org has LiteLLM and Kimi 2.5 enabled but it rarely works, so Claude and GPT are my main tools. I actually enjoy Kimi more as it feels like a dev in a job interview. Watching it reason through problems is a lot like I tend to explain things during whiteboarding sessions. The number of times it says, "wait", is just funny. Claude on the other hand is much more like an employee (or team of employees) that already know they have the job. It doesn't do a ton of explanation up front. (you can dig into processes if you want). It just goes along, asking questions only when it needs... and then delivers a comprehensive report or plan. OpenCode is a better harness. I don't have a direct comparison on costs, as I haven't tried to do the exact same prompt on both models. I can say that I recently had Kimi generate a wrapper around libpq for the ZenC programming language: https://github.com/nobleach/zenc-postgres and it took about an hour or so and cost around 4 dollars.
Recently I had to migrate an old SpringBoot app that had a React front-end to a new cluster. Not wanting to mess with super-old dependencies, I opted to rewrite it on a new version of Java/SpringBoot. When it came to the frontend, I paused. I couldn't come up with a single good reason why this app needed React. I rewrote the frontend in straight HTML with a little bit of JavaScript for DOM manipulation. I literally used `var` instead of `let/const` just to drive the point home... (yes, that was overkill). But you know what I didn't need? A BUILD PROCESS! No npm deps. No vite/rsbuild/etc. It was like I had forgotten we could even DO that.
Don't get me wrong, I actually have enjoyed React over these past 10 years. But, including it blindly is just silly.
esm.ah let's you include "complicated" JS that isn't usually found in CDNs.
it doesn't work for everything and imo is worse for (p)react due to the lack of native JSX, but it does allow for bringing in stuff that usually takes an `npm install && npm build`
Yeah in this case, I needed to pop up a <dialog /> and take some form info, persist it via POST and then show the result of a "used" card/token. So there just wasn't a lot of need for libraries. I'm from the VERY old school so I do recall the fresh hell of including many deps via script tags (pre-Bower!)
So far the place where I've seen "more code being written" having a postive effect, has been in paying down tech debt and reduction of overhead. We've rewritten services (bringing multiple microservices back under moduliths) and cut costs. But I'm talking about net-negative code. That's not the point you're making. I agree that puking out 20 new features likely wouldn't gain us more revenue.
I've loved Vite from the moment it was public. I also tried Snowpack back in the day. (fun story that Fred "fks" went on to create Astro after Snowpack didn't gain traction). The fact that we can "just forget it exists" is a major win in my case. Webpack - while maybe a win over Grunt/Gulp, was MASSIVELY complex.
I too am a bit uneasy. It's not always the case but, corporate ingestion is often where cool projects go to die. The good news about open source is that we have enough Terraform->OpenTofu & Redis->Valkey stories out there.
Sounds like something that a browser like Brave was built to combat. I haven't visited the site in question but for a lot of the ad-heavy sites I do visit, I jump over to Brave to deal with the nonsense.
And to bring it full-circle, this is the exact same thing I run into with Go. When I mention how nice it is that Lang X has feature Y, someone is quick to point out that either, "You can BUILD that in Go" or, "You don't really need feature Y". We've proven that we don't really NEED compilers either... but I would hate to have to do my job without them.
I read Hacking Exposed around that time period. Up until then, my only "hacking" experience was with AOHell and everything that came along with that. It was interesting, but I wasn't really into the idea of trying to use CreditWiz to increase my odds of prison time. (I was a kid, I thought everything would lead to prison). Back Orifice just seemed like a great sysadmin tool!
We used this extensively when I worked in this space (2010 - 2014). My favorite addition was using https://github.com/topojson/topojson to add arcs. That cut down on quite a bit of points to represent curves.
Dang, fun memories of when I was first getting in to geo/data stuff and doing a lot of web mapping stuff with D3, Leaflet and friends. Seems as tools like Vector tiles/PMTiles have supplanted topojson for a lot of visualization oriented use cases.
I'm gonna have to dive into a rabbit-hole! I was working on an ESRI Shapefile to GeoJson converter back in those days. But D3 and Leaflet were such cool tech! MapBox too. Linking SagaGIS with PostGIS to do pre/post wildfire analysis was my jam.
I get that folks love a good Linus rant. But as someone who's been at the end of that style of "feedback", nothing can be more humiliating or demotivating. Certainly there are contributors that are making "rookie mistakes". There are folks that aren't willing to ingest the entire context of what was tried back in 2.0.36, 2.2, 2.4... etc. And perhaps it's wise to simply stay away until you're completely certain you've got the chops to contribute. More than half the folks that enjoy that sort of abuse don't have those chops.
I can defend someone who is unwilling to yield on quality. Afterall, this truly is his baby. Issuing scathing rebukes to well-intentioned contributors is like slapping my kid when he brings me the wrong type of screwdriver.
I don't think a Linus rant ever hit anyone that was a rookie, they are always AFAIK against people "who should know better". Veteran developers, with multiple commits merged.
This is a system used and relied upon by billions of people around the world. Your intentions, while good, are not material to the problem. Put another way we have an endless supply of people with "good intentions" but we don't enjoy the same largess of people with "good skills."
https://lwn.net/Articles/343828/ describes Alan Cox trying to fix the TTY layer, being trashed by Linus, and removing himself from the maintainer page.
It also didn't just happen out of the blue. It's also true that Alan had already been working on the kernel for 15 years, was an employee of RedHat at the time, and his Wife's health was starting to fail.
If you follow the thread it goes back and forth across quite a few messages with frustration building on both sides with Alan ultimately deciding to step away from a single (and very hairy) subsystem.
reply