> I feel that LLMs and their overtly verbose output trick less knowledgeable programmers of the quality of their output. When Claude spits out refactored code with tons of comments, documenting each method and variable, and tests for everything as well, it looks impressive, at a first glance. But if you dig deeper, it's sometimes just complete bullshit.
This is pretty spot on. But it's important to note that the resulting code, is still often significantly better than what those developers used to produce. Especially under tight deadlines and pressure to complete CRUD like interfaces. We simply can't afford spending a whole day tweaking a sortable table on the web anymore.
I agree that it produces code that is better than many of my colleagues. I have spent the last 14 years honing my ability to build code in a scalable way that works for basically any domain. I still produce better output than the LLM. But the incentive to encourage my colleagues to reach that kind of level is just gone, and that's what frustrates me. As humans, we could have been so much more efficient, but instead LLMs came in and are steering us towards the median of slop code. Slop by my standards anyways.
I still am not sure whether wasm/webgl is suitable for 3d games with some complexity. You'll eventually have some GC pauses during game play. This one included, despite the rest of the game being smooth.
Had a look at their website [1]. Initial thoughts: this is a bit ridiculous, I can just build that myself. And in fact, I have done already.
Thoughts after about 3 minutes of browsing: OK, this actually makes sense and I see why people would pay for this. The value proposition is definitely there
Thanks, "I could build that" → "oh, that's what the other 90% is" is pretty much how Unleash started for us too. What does your homegrown version do? Always interested in where people draw the line between building and adopting.
Just basically various means of turning features on/off based on static rules. Settings mostly but occasionally user based or URL params.
Your platform has that and a ton of other things that would be useful for larger platforms, but it would be a pain to develop when you're already building a complicated roadmap.
Perfect candidate for a FF if it really is temporary. I have my own personal rule. If the FF lives beyond a certain amount of time, it gets turned into a setting.
I haven’t used unleash but it’s pretty clear your characterization is wildly wrong. 30 seconds looking at docs shows it has features for gradual rollouts, A/B testing, experimentaion with analytics, authentication to control available features, and probably a lot more I missed in a quick skim.
> Can you write by hand any text that you plan to post to HN? Here's an important tip we send to users about this:
> Write any text that you post to HN by hand. Don't use an LLM to generate any of it (not even a tiny bit, including to edit or spruce it up). Reason: the community is super fussy about this right now, and LLM language has a certain quality that is generating quite some backlash when it appears on HN itself. This is a big dividing line at present!
I pay for it for my team... it's expensive to be honest, but worth it IMHO. Building it would be a ok, supporting it a pain.
If you work on a small startup, not worth it... on a Big corp with a lot of bureaucracy? It's worth it I think.
We have tried self-hosting it, but it's always a pain to allocate people on infra to do it, so I gave up and started paying for it for my teams, and they love it.
From the infra side, it’s something I don’t think makes a lot of sense to self-host. Metrics are the other notable one here.
They have non-linear scaling complexity, so they work fine with bumping up resources until they don’t and now you’re looking at queueing metrics on Kafka or something equally complicated. They’re horrible to change out because a lot of the APIs aren’t compatible and literally everything uses them.
They’re also awful to maintain. Everything uses them so there’s never a window when it’s convenient to shut down the feature flag system for upgrades or to test backup restores. People are much more accepting of “the vendor will be down for 2 hours on Saturday” than “I’m taking the system down for 2 hours on Saturday”.
I'm not sure which provider you are paying for metrics, that you think has acceptable pricing.
We are on ~400k series, and switching to any hosted provider would instantly make that our single biggest infrastructure expense.
Instead we're self-hosting with less than $100/month for hosting and ~less than a hour per month of maintenance with Victoriametrics (have also switched fron singe-node to cluster over time), and it's a breeze.
The things I most disliked about our in house feature toggle system were:
1) the line between toggle and reloadable config is always fuzzy, in part because you don’t know for sure if it’s a toggle until users give their feedback. About half a percent of toggles stick around in perpetuity as either preferences or emergency relief valves for the operations team. That seems small but when you are doing CD aggressively that’s happening to you once a month or every few weeks which makes it a constant companion.
2) you need a system to track and complain about old toggles. If they survive the end of the Epic that birthed them, they become immortal. And you can see variations on Knight Capital play out when they get toggled years after they were supposed to be static.
Regarding number two, that's what I designed featureflip to handle. It tracks dead flags and will submit a pull request to your repository to remove it for you. That's always been a big pain point of mine with launch darkly.
Feels like something that should be a solved problem though.
Part of my last job was winnowing down a convoluted feature toggle system, rebuilding parts of it on top of a FOSS library that did a fraction of the same work. It had become convoluted enough though that it was materially affecting both our deployment time and our cluster density.
To be a little fair to the original author, despite not really respecting him, I had to file a couple serious PRs upstream to simplify the most tortured parts. He worked around a couple of bug/misfeatures but took the scenic route to do it. Guy “never met an abstraction he didn’t like” is not true because his favorite thing was replacing one abstraction with three. And he was one of those guys who learned big words all from books and so he used definitions nobody under 65 has ever used in conversation.
I thought LLMs were supposed to be the death knell for services like this, since you could replicate them and maintain your own code-base with little effort?
The thing that separates feature flags from “why not vibe it” is reliability. Flags going down can take everything down, so you really ought get the most reliable system you can. That means multi-cloud deployment and good thought as to failover. Secondarily, flags really benefit from some good telemetry to understand what is being used and that expands scope as well. Oh and SDK that are really good under various failure conditions.
What AI dev is doing to this space is commoditizing it, not replacing it. Prices for the crystallized judgment of these tools will fall to near compute. But that still doesn’t mean you ought burn tokens to get an inferior solution to what’s available off a shelf.
Lots of tools work like that: You can get to 80% of the value with 20% of the work. I kid, it's even better than that! Sometimes, 80% of the value comes from 2% of the effort to build what they built.
But over time, you realize that half of the remaining 20% matters to you, and it turns out that the remaining 10% you care about is harder than it seems, and until you have it doing everything you need, you're stuck with an ad hoc, informally-specified, bug-ridden, slow implementation of half of LaunchDarkly.
————
Personally, I have worked on an in-house feature flag system, and I told everyone who would listen that its purpose was needs validation, and that as soon ass we were 100% sure we knew EXACTLY what we needed, we could go shopping. And that was in the hand-written code era. Today, you could vibe an 80% solution and do your needs assessment from there.
I don’t know? They have blog posts about it but I don’t know how much I’d trust them because their chosen replacement only lasted 5 months before the next replacement.
I think it was closer to what they need; it comes down to keeping TB of data on local SSD and having a query engine next to it. That takes persistent, shared CPU, caching, sharding, resource management, etc.
Duckdb is an interesting approach to resource management (all ephemeral), but TB's are TB's. I doubt it was finding data where it needed it.
Clickhouse seems slow at getting to the top end of scaling; it's stuck with the 99% of its userbase doing 1 GB queries. I'm hoping they put some of their money into it.
DuckDB is now close to competitive with Trino. As the post shares, large distributed multi-tenant data systems require a ton of work no matter what technology you use, but as a huge DuckDB fan, I do have to agree that it is not an out of the box data warehouse, though check back in a year or so when DuckLake and DuckDB 2.0 have had time to mature a bit more for this use case.
As a huge duckdb fan, I can’t think of a workload set I have where the two overlap, so I don’t see them as competitive - I would either pick Trino/Presto or DuckDB as the obvious solution.
> We have no infrastructure, servers or people in Russia. The original engineering team successfully moved out of Russia and are now working in our Amsterdam office.
reply