I wish Google was able to actually push the industry further, either in terms of quality (intelligence) or quantity (price) but they've been playing catch up a lot.

They are playing the game a bit differently than all the others. The others have useable IDEs etc. while Google has a boatload of half-assed products.

Google better come out with a banger 3.5 Pro because who would have thought that Grok and GLM would be beating them?

E.g. 1. Intro about issues with concensus 2. Intro to QuePaxa 3. Comparison to other algos that are close to it 4. Mentioning active work on implementation via Meerkat and intent to bring to production with followup posts.

As always when it comes to concensus it's all about trade-offs. And with QuePaxa that might be the increase in messages (note: I don't mean message round-trips). We'll see how it goes but it will definitely be interesting.

Maybe the blog post is just premature. It would be much more valuable if they posted it after actually having run it in production and validated the strengths and weaknesses with real world data.

Comments URL: https://news.ycombinator.com/item?id=48816025

Points: 61

# Comments: 11

And now this. How would they even enforce this restriction when they can't know what nationality the end user behind some API query belonging to a company account has? It seems like nobody is thinking things through anymore and the end result is total unreliability from every angle. What a huge mess all of it, sigh.

With a wealth tax using his calculation, the higher your returns, the lower the comparable income tax would be. If your returns are 10% you'll pay $1 on $10 capital gains which is 10% and you end up with $109. Conversely someone achieving a mere 1% cap gains would be essentially taxed for 100% of his return.

With income taxes it's usually the opposite: the more you earn, the higher the tax bracket you will be put into.

Somebody like Paul Graham surely has higher than 10% capital gains, otherwise he'd not be exactly a great investor.

Personally I'm against wealth taxes, I think capital gains taxes are a much more appropriate and fairer tool. I also think taxes in general are way too high, if you are part of the middle class and add up everything you pay in taxes, fees, insurance, duties and whatnot you can end up losing 70-90% of whatever you earn. It's extremely hard to actually accumulate wealth for the vast majority of people.

I did not expect such a huge (3x) price increase from 3.0 Flash and I bet many people will not just blindly upgrade as the value proposition is widely different.

One interesting point to note is that Google marked the model as Stable in contrast to nearly everything else being perpetually set as Preview.

[0] https://artificialanalysis.ai/models/gemini-3-5-flash [1] https://artificialanalysis.ai/models/gemini-3-1-pro-preview

New models are on average better than older models, the average skill of the population of models increases over time and so you are mathematically guaranteed that any existing model will over time degrade in Elo score even though it didn't change itself in any way.

It's like benchmarking a model against a list of challenges that over time are made more and more difficult and then claiming the model got nerfed because its score declined.

Elo is good at establishing an overall ranking order across models but that's not what this is about.

To detect nerfing of a model, projects like https://marginlab.ai/trackers/claude-code/ are much much better (I'm not affiliated in any way).

You can't use Elo scores to measure decay of a models performance in absolute terms. For that you need a fixed harness running over a fixed set of tests.

Cloudflare is a growing company by most metrics so if efficiencies through AI were the reason for the layoffs they'd just take the boost and grow even faster.

It all doesn't check out and I think the real reason for the layoffs and the negative sentiment by the market on the news is that their revenue growth was not as fast as their expenses and they realized they overhired. Leadership doesn't want to dive too much into the red even if it would mean bigger growth down the line. They are now beholden to the near and mid term stock performance.

I've had the chance to talk to some SWEs working at Cloudflare off the record in recent months and the one concensus I heard was that there was many times some tension between the boots on the ground and the decisions from senior managment but of course nothing they could do and especially after this they'll make sure to be quiet should they remain. There seemed to be a lot of pressure to deliver features and new products but quality has been left behind which means the SWEs felt pressure to deliver while also having to deal with the ensuing issues to resolve.

Either way I wish everyone affected the best and a speedy job hunt - there'll be quite a few really good people on the market now for no fault of their own.

https://android-developers.googleblog.com/2026/04/AI-Core-De...

The article is talking about one particular optimization that one can implement with Apple Silicon and I at least wasn't aware that it is now possible to do so from WebAssembly - so to completely dismiss it as if it had nothing to do with Apple Silicon is imho not fair.

You just wrap your DB queries in your own timeout logic. You can then continue your business logic but you can't truly cancel the query because well, the communication layer for it is stuck and you can't kill it via a new connection. Your only choice is to abandon that query. Sometimes we could retry and it would immediately succeed suggesting that the original query probably had something like packetloss that wasn't handled properly by CF. Easy when it's a read but when you have writes then it gets complicated fast and you have to ensure your writes are idempotent. And since they don't support transactions it's even more complex.

Aphyr would have a field day with D1 I'd imagine.

> What about reads? We use D1 in prod & our traffic pattern may not be similar to yours (our workload is async queue-driven & so retries last in order of weeks), nor have we really observed D1 erroring out for extended periods or frequently.

We have reads and writes which most of the time are latency sensitive (direct user feedback). A user interaction can usually involve 3-5 queries and they might need to run in sequence. When queries take 500ms+ the system starts to feel sluggish. When they take 2-3s it's very frustrating. The high latencies happened for both reads and writes, you can do a simple "SELECT 123" and it would hang. You could even reproduce that from the Cloudflare dashboard when it's in this degradated state.

From the comments of others who had similar issues I think it heavily depends on the CF locations or D1 hosts. Most people probably are lucky and don't get one of the faulty D1 servers. But there are a few dozen people who were not so lucky, you can find them complaining on Github, on the CF forum etc. but simply not heard. And you can find these complaints going back years.

This long timeframe without fixes to their network stack (networking is CF's bread and butter!), the refusal to implement transactions, the silence in their forum to cries for help, the absurdly low 10GB limit for databases... it just all adds up. We made the decision to not implement any new product on D1 and just continue using proper databases. It's a shame because workers + a close-by read replica could be absolutely great for latency. Paradoxically it was the opposite outcome.

But even without network issues that have plagued it I would hesitate to build anything for production on it because it can't even do transactions and the product manager for D1 openly stated they wont implement them [0]. Your only way to ensure data consistency is to use a Durable Object which comes with its own costs and tradeoffs.

https://github.com/cloudflare/workers-sdk/issues/2733#issuec...

The basic idea of D1 is great. I just don't trust the implementation.

For a hobby project it's a neat product for sure.

As always, we'll have to try and see how it performs in the real world but the open weight models of Qwen were pretty decent for some tasks so still excited to see what this brings.