I always feel like I want to use something like this, but then realize my NeoVim setup + tmux + Ghostty is good enough and I am not ready to learn a whole another system for modest gains.

The friction I have currently is obviously things like port forwarding, in app browser etc.

I keep thinking to try out cmux but haven't gotten around to it.

makes sense, well if you ever want to dabble, let us know how you like it :)

Funny that its hosted on vercel. Probably because its employee driven rather than top down. Saves all the bureaucracy to get someone to sign a budget item to buy a domain.

Not sure that site in itself is owned and operated by the Norwegian government.

Is this article really worth sharing? A speculative headline with no numbers, no estimates, 0 data.

Feels like click bait and HN is submitting to the bait.

Oh you want numbers?

Here’s a number: 3.5

That’s the number of years until we achieve AGI according to Sam Altman: https://techresearchonline.com/news/sam-altman-predicts-agi-...

This company’s current valuation is entirely speculative. So if you’re going to criticize the article, maybe direct some of that skepticism towards the company in question.

Isn’t it general knowledge AGI has been achieved ?

You don't need numbers when the person responsible for the numbers says they are bad.

The billions being thrown at openai and anthropic are speculative

Yeah I have always felt GPT 5.4 does too much. It is amazing at following instructions precisely but it convinces itself to do a bit too much.

I am surprised Gemini 3.1 Pro is so high up there. I have never managed to make it work reliably so maybe there's some metric not being covered here.

Is this guaranteed by the async specification? Or is this just current behavior which could be changed in a future update. Feels like a brittle dependency if its not part of the spec.

It's documented behavior for the low-level API (e.g. asyncio.call_soon https://docs.python.org/3/library/asyncio-eventloop.html#asy...). More broadly, this has been a stable behavior of the Python standard library for almost a decade now. If it does change, that would be a huge behavioral change that would come with plenty of warning and time for adjustment.

In my experience, developers who rely on precise and relatively obscure corner cases, tend to assume that they are more stable than they later prove to be. I've been that developer, and I've been burned because of it.

Even more painfully, I've been the maintenance programmer who was burned because some OTHER programmer trusted such a feature. And then it was my job to figure out the hidden assumption after it broke, long after the original programmer was gone. You know the old saying that you have to be twice as clever to debug code, as you need to be to write it? Debugging another person's clever and poorly commented tricks is no fun!

I'd therefore trust this feature a lot less than you appear to. I'd be tempted to instead wrap the existing loop with a new loop to which I can add instrumentation etc. It's more work. But if it breaks, it will be clear why it broke.

That gives me slightly more confidence but only slightly.

For example what happens if I use a different async backend like Tokio?

Haven't used it but have seen some online recommendations for gh-dash. https://github.com/dlvhdr/gh-dash

I don't get it. All these are provided by many different agent libs like langgraph, Pydantic AI etc. I thought DSPy was for prompt optimization but I could never wrap my head around that aspect since like Langchain, DSPy seems to hide stuff a bit too much.

So this article seems surprising since it emphasizes more the non prompt optimization aspects. If that was the selling point I would rather use something like Pydantic AI when I already use Pydantic for so much of the rest.

I think the reality is that prompt optimization is one of the only "legible benefits" (ie easy to understand why its valuable).

But I think it misses the point of what Dspy "is". It's less that Dspy is about prompt optimization and more that, Dspy encourages you to design your systems in a way that better _enables_ optimization.

You can apply the same principles without Dspy too :)

Yeah I have always struggled to figure out why I would use SQLModel.

Big fan of FastAPI but I think SQLModel leads to the wrong mental model that somehow db model and api schema are the same.

Therefore I insist on using SQLAlchemy for db models and pydantic for api schemas as a mental boundary.

This is my current position as well.

I think we are going through the same cycle of http leading to https, the rise of oauth and oidc. Its just way faster now.

Wow I though 300 Kph was some kind of physical limit. I mean every high speed train in the world used to max out at 300.

Now it feels like it was just lack of competition. Maybe now other countries will start producing lines and trains capable of 400 Kph and hopefully its not a China only thing going forward.

There is show and there is reality: French TGV achieved 574,8 km/h in 2007 for show, but it was under specific conditions, not in real world conditions.

While it is technically proven that it is possible to do 400+km/h on rail, it's not practical: maintenance, wear, noise, turns, embranchement, and overall cost, ... many considerations that are probably less important for Chinese railway now, which needs some "show".

You should update your data; in 2013, China's high-speed rail reached 605 km/h on experimental lines. The CR450 is scheduled to enter commercial service in 2026.

Sorry if I wasn't clear but was not talking about demo runs. There are plenty of those. Was more meaning operational speeds having a limit.

Like pretty much everything else, it's an optimization problem rather than a physical limit.

So running a train at 350kph is more expensive than 300kph, both in per-distance and pre-unit time terms. But if you can run more services that way then sufficient demand might make it economical. Also, if it's too slow, people may choose flying instead.

Maglev can go even faster but those have never been made economical, really. It's much more complicated and expensive.

It's a bit like how commercial planes have actually gotten slower. 747s used to fly closer to Mach 0.9. Now most commercial planes fly at around Mach 0.8. There are physical problems flying between Mach 0.8 and 1.2 but sometimes that doesn't matter so the best private planes top out at about Mach 0.93. Even then they rarely fly that fast.

In the case of private jets, the Mach figure is mostly a proxy for other performance metrics.

Flying an aircraft at max cruise can save a lot of time on longer flights, but it's also substantially more expensive.

300kph is the limit because aerodynamics make that about the best compromise on the effeciency cury. higher speeds are completely possibly - but air planes running with much less atmospheric drag start to become the better option.

of course the above is all about compromise and you can emphasize whatever numbers you want to get different results.

Edit: it is often a good idea to have everything capable of faster speeds - say 350km/h. You don't normally want to use those speeds, but if a train gets delayed (as happens) you can use that extra speed to make up time. Just don't let this become a normal thing.

What about if they added “wings” to trains? That could generate some lift reducing the effective weight is my shower thought.

No idea how much the wings would add versus the lift help.

The friction is almost entirely from drag/air resistance, not from the resistance of the rails.

the losses from weight are linear with speed - at high speed completely dwarfed by losses from pushing air out of the way which is quadradic with speed.

the wings on race cars are poited down - they increase weight to keep the car on the ground at the expense of more drag, which they overcome with a bigger engine (and more fuel use)

The French TGV managed to reach 574km/h, so 300km/h is not an hard limit. https://www.youtube.com/watch?v=EOdATLzRGHc