Hacker Newsnew | past | comments | ask | show | jobs | submit | gbuk2013's commentslogin

Right, this is what they said in the customer notification email I got today:

“The underlying causes of the increased costs are, among others, the exploding demand for AI-related computing power and for cloud services. In addition, raw material prices and production costs have also generally risen for manufacturers. The costs for RAM and SSDs especially have risen by a large amount. For example, the cost for DRAM memory has increased up to 500% since September 2025. And according to market researchers like TrendForce, this price trend will continue throughout the year.”


I have to say I am not a fan of doing this on the client side.

API gateways (which is what server side load-balancer can be abstracted as) serve as important control points for service traffic, for example for auth, monitoring and observability, application firewall, rate limiting etc.

In my general experience code running on the client side is less reliable due to permutations of browsers, flaky networks, challenges with observability.

That said, client side already has one type of load balancing - DNS - but that doesn’t address the availability challenge.


Basically this. My last several tickets were HITL coding with AI for several hours and then waiting 1-2 days while the code worked its way through PR and CI/CD process.

Coding speed was never really a bottleneck anywhere I have worked - it’s all the processes around it that take the most time and AI doesn’t help that much there.


True story; I wanted to make a tiny update to our CI / CD to upload copies of some artifacts to S3. It took 1min for the LLM to remind me of the correct syntax in aws cli to do the upload and the syntax to plug it into our GitHub Actions. It then took me the next 3 hours to figure out which IAMs needed to be updated in order to allow the upload before it was revealed that Actually uploading to the S3 requires the company IT to adjust bucket policies and this requires filing a ticket with IT and waiting 1-5 business days for a response then potentially having a call with them to discuss the change and justify why we need it. So now it's four days later and I still can't push to S3.

AI reduced this from a 5-day process to a 4.9-day process


Completely unrelated but https://protohackers.com/ is another one of James’s projects that I love. :)


He also built a homemade computer from scratch. James is a brilliant guy.


> So my questions is simple: you talk about "thousands of years". Easterners had "thousands of years" and they can... Release tension in the body?

This is a common misconception among those used to modern “western” medicine: while “eastern” medicine does have a range of options to deal with existing medical conditions the emphasis is always on prevention (there’s a famous Chinese medical maxim along the lines of it being better to fight the enemy outside the city walls than inside) whereas Western medicine mostly pays lip service to the idea (for reasons that unfortunately mostly come down to money).

There is no denying that our modern medicine is superior in treating the immediate symptoms (which may well be life threatening) including surgery.

The relaxation exercises being discussed are really there just for the purpose of making sitting meditation effective, essential to stop the body getting in the way of the practice and that is all. In a way the body (and the associated work required to keep it in health) is seen as a necessary evil by those on the spiritual cultivation path.


There is no similarity whatsoever.


One similarity is, if I'm correct, Russia claimed that the naval base of Sevastopol was vital for Russian security.

The protection of the population and the illegitimacy of the current government was an argument developed by Russia at the time, it has not been yet by USA but I suspect this might start develop in the next few weeks.

The common ingredients to justify an invasion/annexation is a mix of: - Self-Defense, security - Historical, Geographical claims - Protection of the population - Moral sugar coating (we had no choice)


Greenland was not part of the USA for a 150 years. It is also not mostly populated by ethnic Americans who speak English as their mother tongue. Nor is there a large American military base there that Greenland / Denmark is trying to evict them from and potentially hand over to a geopolitical adversary. Greenland is also an island a couple thousand miles away from Denmark.

Honestly, it is such a surprise that the difference is not obvious.


You are clearly wrong. Both Trumpism and Putinism are reactive ultra-conservative ideologies. Annexation of Crimea was motivated largely by Russia's "legitimate security concerns". Russian propaganda was busy convincing the population that Crimea gives strategic control over Black Sea region and if Russia didn't intervene, there would have been NATO bases on the peninsula after the Maiden revolution. Trump and his sycophants are saying the same thing: American security, Arctic, and American geopolitical foes: China and Russia.


I’m not going to bother replying to this because it’s is clear that your rational mind is obstructed by ideology to the point of being closed.


Please don't post personal attacks on HN. The guidelines make it clear we're aiming for much better than this. https://news.ycombinator.com/newsguidelines.html


IIRC V8 actually does some tricks under the hood to avoid malocs which is why Node.js can be be unexpectedly fast (I saw some benchmarks where it was only 4x of equivalent C code) - for example it recycles objects of the same shape (which is why it is beneficial not to modify object structure in hot code paths).


JITs are a great magic trick but it's nowhere near guaranteed you'll get good steady performance out of one, especially when the workload is wide not narrow.

https://arxiv.org/abs/1602.00602v1


Hidden classes is a whoooole thing. I’ve switched several projects to Maps for lookup tables so as not to poke that bear. Storage is the unhappy path for this.


One of the biggest mind-shifts for me moving from senior dev to lead was realising that technology is much less of an issue than people. The impact of good communication leading to people understanding and agreeing on what they are working on is overwhelmingly greater than the technology choices we devs typically spend our time arguing about.


Without contradicting "in general", my anecdotal experience is that even well-oiled teams with good internal communication and team spirit can have bad technologies that end a business.

You may well be correct about the general case: I've not witnessed cat-herding, the closest was managment constantly chasing new shinies and one time forgetting to tell the devs about the latest change.


I was absolutely only speaking “in general”. Even with 20 years in the industry my experience can only be anecdotal given that I only had time to work with fewer than 10 companies. :)

That said, I suspect a bad technical decision may have people and communication causes and not fixing the problem once it is apparent is definitely rooted in these.

Technical debt and leadership vacuum are both interesting and intertwined hard problems.


We’re generally fine and well paid. :) Frontend tooling churn is tiresome but the upside is that there is a lot of great tooling that more than makes up for any language deficiencies.


> 2. Every code change must be reviewed

At a couple of places I worked at this was a hard compliance requirement: there had to be at least one review by a human to guard against an engineer slipping in malicious code (knowingly or otherwise).


Yeah, there's whole industries where you simply cannot operate without enforcing this. The author's view is pretty narrow, both on this front and on the other points.


The author mostly write about average startup work, not about industries or more constrained environment. A good example of this is the sprint thing: you can do whatever pace you want when you work on your own product that is a web product, but as soon as you work on something with hardware or marketing, you can't just use random deadlines.


Conversely, feature flags can create annoying issues due to compliance requirements.

I worked on an underwriting system where we had to be able to explain the reason for a decision. This meant that you needed to have on file both the state of the flag and the effective logic at the moment in time that a line of credit was offered to a customer.

They're useful, but not necessarily simple.


Right, they add risk both in terms of inadvertently being turned on / off and also in terms of permutations of possible system configurations that need to be tested. Less of a problem for well engineered systems with good deployment practices but it’s rare to come across these mythical things. :)


It depends a lot on the domain. I've mostly worked in high compliance/regulation worlds. It can be kind of stifling, honestly, but "oops maybe we had the feature flag turned on" is not going to cut the mustard.

Most startups can ignore all that at least until they get to a scale where "run out of money, go bust" is not the biggest risk to their business :)


This is very true and is exactly why there is no magic right answer other than “it depends”.

There are different stages of company lifecycle, different industries, different regulatory environments etc.

The processes put in place always have a cost - if picked appropriately it is worth paying, otherwise it is a waste that can hurt or even kills a project. This balance is the “art” of the job that I personally am only starting to probe around at my level and so it is still quite interesting. :)


I was going to make the same observation - typically this will be defined in your secure development policy or similar, and be part of your ISMS controls for whatever frameworks you're aligning to.

It's possible this is more relevant in B2B contexts than B2C


Luckily, gemini catches a good amount of errors in PR reviews, less need for manual review unless you need to double check if the code structure and architecture is sane.


Until it doesn't, you f up but at least it apologizes later


Depends on how good the human reviewers are. It's hard to give a thorough code review, you need to understand the code and requirements, pull the changes locally, manually test the PR, think about security, readability, catch line level bugs like bad conditionals, but also think about the overall structure (classes, patterns, systems). But this requires a lot of effort, especially with larger PRs and it's easy for things to slip through. Nothing is perfect, but you can think of AI review like a supercharged linter, it might not suggest an alternative approach, but it will point out some glaring omissions or unhandled exceptions, etc.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: