HN user
I might get flak for saying this but if you aren't a postgres expert already: just use RDS or a similar cloud DB. The amount of money you're saving by hosting and managing your own postgres instance is absolute peanuts compared to having battle-tested infrastructure for HA, backup and restores, point-in-time recovery, read replicas, etc.
Good article overall, some comments:
Use foreign keys with cascading deletes for low-volume tables, particularly where database consistency and correctness are important. Careful at higher volume.
This might be just me, but I hate cascades, for a very simple reason: at most places, the majority of developers "live" in the Python/Node/Go/whatever application that talks to the database, not the database itself. Cascading deletes (or updates) is basically magic and it can be very hard to understand "why did deleting a row from table A delete something from table B automatically". Especially if someone sets up the cascading wrong! IMO it's better for long-term maintainability to emit explicit delete clauses. Correct use of foreign keys will prevent any issues with database consistency.
Tricks for large table migrations
The pitfalls and workarounds are all correct, but worth pointing out tooling already exists[0] for managing this for you. Making changes to large tables should be as simple as running a command (and then nervously monitoring for the next 24 hours as the data copies).
Other things to consider,
1. Get used to separating application and database deployments early. It is impossible to transactionally deploy both a schema change and an application change simultaneously, there will always be some delay where the versions of database and application are out of sync, and you will eventually run into a situation where the database change deploys fine but your application change does not. Once your app is in production, get in the habit of only doing backwards compatible schema changes: all new columns are nullable or have a default, no renaming of tables/columns, etc.
2. In the same vein, figure out a schema management strategy early. You really don't want your database deployment process to be "senior dev runs some DDL manually on production from his machine". I'm still partial to liquibase because it's the devil I know, but there's other tooling like Flyway which exists.
Kubernetes vs AWS?
How is this even a direct comparison? Most companies I know of which use Kubernetes are using it on a cloud provider. Even if it's kubernetes on EC2 rather than hosted e.g. EKS, those companies are also happy to use lock-in services like RDS and S3.
Also, for some reason Optional[T] became deprecated, just as the ecosystem finally embraced types ~3 years ago.
Optional[T] is now T | None. Means exactly the same thing but doesn't require an import. Support for the older syntax presumably won't be removed for a long while regardless.
This is unprofessional and embarrassing for Zig.
It is. It's also why Anthropic and Bun moved off Zig.
Zig is effectively a one-man show, and that one man has been making increasingly erratic decisions.
It's his project so it's well within his rights, of course. But when you're a ~trillion dollar company you don't want to get hit by a supply chain risk like this.
For Anthropic, it's better to nip this in the bud rather than invest more into the Zig ecosystem, where there's a demonstrated risk of the not-so-BDFL going off the rails.
You're framing this as a thing done by a greedy corporation in an evil manner, which maybe it is, but it's also just a sign of the times.
For most of the 90s and 00s, your game engine, specifically idTech in this case, was a competitive advantage. Doom and Quake/2/3 all represented massive technological jumps over their predecessors and were way ahead of their competition in terms of looks. Games like Unreal (Tournament) and Tribes competed using their engines' strengths; those engines didn't look as good but were capable of rendering much larger spaces than idTech, and those games emphasized that, e.g. Tribes' massive multiplayer maps with vehicles, or classic UT maps like Facing Worlds and Lava Giant.
Then in the late 00s to 10s, things started to hit a wall. Probably peaking with Crysis in 2007, which is likely more remembered for its engine, graphics, and system requirements (all of which were truly mind-blowing at the time) than its actual gameplay. After that, games' graphics improved at a much slower rate; it started to be less about the engine's capabilities, which were increasingly homogenized, and more about art direction.
Now in the 2020s, we have UE5 for AAA games with high-fidelity graphics and Unity for everything else... what is the competitive advantage in maintaining your own engine? As you mention, you have to have internal expertise, which is less well-documented than UE5/Unity because you don't have dedicated documentation staff; you have to maintain your own tooling, which is likely worse because you haven't invested as much in it. From a ROI perspective, unless you're planning on investing so you can license out the engine and become a UE5/Unity competitor, it doesn't make sense to maintain your own engine.
And looking ahead, frankly, consumer GPUs are now so expensive that game graphics have likely peaked for at least a decade. There will simply not be better hardware available to gamers for the foreseeable future. Games "looking good" will be more about art style and direction, and you sadly do not need a team of game engine programmers for that.
No missing "k", really just 191 players. https://steamdb.info/app/3043580/
- The make around 5 billion in revenue per quarter - The problem according to them is profit margin - around 150-160 million
So first of all, they are big! Secondly they are not at a loss. They just have a "thin, non-growing margin". So to fix all this they are trimming down, so they can "return to growth" (which I think is ridiculous).
How is that profit margin distributed though? King (Candy Crush etc) and Mojang (Minecraft) are specifically called out as money-makers, it's possible that they're carrying the majority of profits while everything else is a dud:
We have also learned that we are not the best home for every type of studio; in a typical year, we lost 64 cents for every dollar we invested.
As an example, Double Fine (one of the studios being chopped) has released 2 games since 2021, Keeper (191 peak player count on steam) and Kiln (163 peak players); these would be flops even for a normal indie game, for a studio getting Microsoft salaries those are enormous flops.
I think this article is a good demonstration of how the nebulous concept of "taste" still dominates, despite AI taking over so much.
IMO -- and apparently the opinion of others -- adding an AI-generated picture every single paragraph in your article in which the primary purpose is to, presumably, discuss a topic rather than show off your AI-generated art, is in extremely poor taste. It's distracting, it makes it hard to focus on the text, and to be perfectly blunt, nobody is impressed by your ability to create pictures by AI.
Honest question : does it need to be said ?
At the current time I'm writing this, all other top-level comments are engaging with the article as if it were sincere. So, yes.
I mean I agree with this as well, the people who yell and swear at LLMs are just as bad as the people who chit-chat with them like they're friends. It's all very unsettling because it's prepatory for psychological manipulation at unprecedented scale. Targeted advertising on steroids.
I'll go a step further and to say this it's genuinely unsettling someone type to a computer like this. I won't claim to be a psychologist, but with how many instances of "AI psychosis" have been reported (and I've seen first-hand) it seems like treating the computer like a computer is safer, not to mention more effective e.g. lower token usage.
... except this is on-prem with their own infrastructure, not cloud?
The loudness war in the strict "we must compress and slam everything as much as possible to make our stuff sound good on the radio" sense is over thanks to Spotify et al doing loudness normalization, but there's still an open question of "how much compression does sound good?" which is extremely subjective. A lot of modern music is louder than peak loudness war stuff just because the creators want their music to be slammed to shit. I listen to/make aggressive bass music and -5, -4, -3 LUFS are common. (By comparison, some of the common examples of loudness war era CDs like Definitely Maybe and Californication sit between -8 and -6 LUFS.)
Especially since the answer to any loudness problem is to simply for the user to turn up the volume.
This isn't quite true as compression addresses differences in volume. Unless you expect the listener to actively turn up the volume during the quiet parts and down during the loud parts of your song, or be listening in a completely quiet environment with nothing but the music so they can appreciate the dynamics--which is the way a lot of vinyl aficionados do listen to music.
Now, yes, but in the 90s/00s the alternative to CDs was cassette tapes, which were both inferior audio quality and took up more space. CD players in cars were a very desirable feature back then.
At my peak in the mid-00s I remember counting and finding I had just over 500 CDs in my car, almost all of which were MP3s burnt to playable CD-Rs laying in the passenger seat... the good old days. Nice thing about using CD-Rs is you didn't have to care about them getting scratched, either.
"How do I acquire users" is the entire function of sales and marketing. A single HN comment explaining how to do sales and marketing, which is highly dependent on your product and market (and much more difficult than technical people tend to believe), is a bit unrealistic. And a great opportunity to use Claude/ChatGPT for something other than code. There's no silver bullet but as a springboard you can think about:
Who is your ideal customer profile (look up buyer personas) -- if you're B2B figure out both the profile of the company who would buy, as well as the person who would actually buy, and the person who would actually use the software: remember that buyer != user in B2B scenarios, and you'll have to figure out if the buyer, user or both is the best path to getting a sale. If you're B2C figure out your buyer personas so you know where to advertise.
Why would people want your product; sounds like you may already have this down but be ready to explain your value proposition concisely.
How will these people hear about your product -- a SaaS that falls in the woods doesn't make a sound, you need people to learn your product exists before they can pay for it. This is the point of figuring out buyer personas, you need to meet your customers where they are, and you can't know where they are unless you know who they are. This is highly dependent on your product/personas, and could range from running LinkedIn ads to SEO to having a Bluesky brand account to going to local meetup groups or conferences and trying to get your first handful of users in-person.
I am glad you like some things. Some people like other things, such as LLMs, or hosted server infrastructure.
Now explain to me why you are allowed to have the things you like which use a lot of water, while other people are not allowed to have the things they like which use a lot of water.
That's exactly my point! Everything has negative externalities, and focusing on them is the way to seem "rational" even though you don't actually care about them. It's the same as how people will protest high density residences "ruining the character of the neighborhood" when they really just don't want poor people living near them. You can't just outright say you don't want poor people in your neighborhood, so you talk about how these residences ruin neighborhood character, disrupt view cones, cause traffic problems, etc.
Here it's the same thing--the people protesting don't give a damn about water waste, electricity usage, or wasted land. If they did, there are tons of other offenders who are way worse. But they don't want to outright say they're protesting against AI because it makes them seem like luddites.
It takes 870 gallons of water to produce 1 gallon of wine -- if people were genuinely protesting water waste it would be a good idea to start there. Almonds too.
Then there's the fact that many of those datacenter are being built over what would otherwise be usable farmland. I'm sure many will say "it's not that much land", but then tech billionaires would like to build datacenters the size of Manhattan. What for? To train a bigger LLM? Yay?
Sure but you can say this about everything. Where are the protests about the wine industry in California? 500,000 acres of land for vineyards, far more water used for growing grapes than cooling data centers, all so a handful of people can make fortunes selling empty calories to the rich?
If you want to focus purely on utilitarian "optimal land use for essentials only" arguments there's way worse offenders than datacenters, the anti-DC sentiment is purely part of the anti-AI wave.
I love Linux and think it's better than ever to have Linux as your daily driver, especially thanks to the work of Valve with Proton, but I'm gonna be real and say "the year of the Linux Desktop is a personal journey" is a retrofit. The "Year of the Linux Desktop" meme came out of Slashdot in the 90s/early 00s where people were insisting that Linux was due to overtake Windows as the way an average, non-technical user interacted with a computer.
Of course, this did turn out to be true... in the form of Android, which is maybe the most monkeys-paw-curling way YotLD could possibly happen.
Right, the confusion is that the quote-unquote "subsidized" monthly pricing is often used by Anthropic/OpenAI skeptics as proof that inference is unprofitable, i.e. the API would have cost $2000 but you only paid $200 for a subscription, therefore OpenAI is selling dollars for 95 cents and the house of cards is about to collapse. As the GP says, this is faulty logic because we don't know what the actual cost of a token is; OpenAI might only pay $1 in inference costs, in which case they're merely "incredibly profitable" making $199 off you instead of "ludicrously profitable" making $1999 off you had you used the API.
But to your point, re-reading the article, this is not what Simon is saying at all; he's just pointing out that he got to use ~$2000 "worth" of tokens on his $200 plan. Which makes total sense! Subscriptions are sticky, that's why the entire software industry moved towards subscription models (as much as we hate it); the person paying $200/month is more likely to stick around than the person who paid $2000 using the API.
Yep, member since May 21 2005 here, still scrobbling with Spotify. Don't think I've ever used any of the radio features on the site, really; even back in the 00s all I used were the WinAmp/Foobar plug-ins.
It seems like the fair solution to this problem is to open source server code if you are going to cease support for an online game. That way the community has the opportunity to run their own servers if they want to.
It's nice in theory, but in practice many (most?) games are using middleware they don't have the rights to redistribute as open source. IIRC when the source code for Doom, the first major commercial game that went open source, originally came out, it had all of the sound code removed because it was dependent on a third party library. Not that you're going to have sound code in a server, but you may be using third party libraries for networking, replays, anti-cheat, etc.
Yes, with the caveat that the 30% work allocation counts toward likability. You can be friendly, charming, well-spoken, fun, etc., but if you fail to deliver and make work for other people, cause your coworkers frustration, and make your manager look bad, you're not going to move up. You will be able to coast for a while though, as managers have a hard time firing people they personally like.
It's ultimately a combination. A pretty good software developer who is friendly and pleasant is, in most organizations, going to get promoted over the grumbling angry software developer who is brilliant but everyone hates talking to. A lot of this has to do with most work at more senior levels being communication.
I've heard similar stories from AWS and other non-AWS FAANG employees. All of the token leaderboards have a "this doesn't count toward your performance review" disclaimer, but there's an implied nudge nudge, wink wink after that statement.
One person I've talked to has someone in their org who is running GasTown and chews through tokens 24/7. They don't contribute very much, but they're comfortably in the #1 spot.
This is Rust we're talking about. It doesn't even need to work; as long as it compiles, it's correct.
Python has had type hinting for quite a while, and adding validation with mypy/pyright/ty as a step in CLAUDE.md (as well as having it as part of your CI pipeline) can emulate static type checking pretty well.
Some have expressed the opinion in this forum that the future of software lies in programs that are created and adapted at runtime, using genAI.
Good luck with that. Users will flood you with complaints if a button moves 5px to the left after a design update. A program that is generated at runtime, with not just a variable UI but also UX and workflows, would get you death threats.
OpenClaw is a good example of a completely new project written using coding agents that made a significant impression on the world and would not have been built without them.
Nobody is denying that OpenClaw is popular, and nobody (in this thread, at least) is denying that AI rapidly speeds up the ability to make an initial release or prototype for greenfield projects. But the comment that spawned this discussion was:
we still have no companies compressing 10 years into 1 year thus exploding past all the incumbents who don't "get it".
The issue is that you're extrapolating OpenClaw, which upon release was a month of pre-AI development work compressed into a few days, to cover the "10 years into 1 year" scenario. However, this isn't appropriate because software development is non-linear. As anyone who has worked on a greenfield project pre-AI should know, those first weeks and months have much faster development cycles. There's no tech debt to worry about; there's no urgent bug tickets or feature requests from customers; there's no thinking about whether it's okay to ship a breaking change.