They refuse to spend less in other areas, which is the big reason why they haven't already solved the glaringly obvious drone problem. Not surprised they just want to throw more money at a new program instead of stepping on anyones toes in the other branches.
They also started construction before they even finalized the route, including not realizing they would have to move tons of utility lines along the way (they didn't get sign off from the public utilities beforehand), then it got bogged down by environmental reviews, land acquisition issues, etc.
That is likely a drawback to their ACP wrapper scheme, it helps exposes IDE functionality but they have to keep up with Claude Code functionality in the other direction. VSCode's Claude code plugin is just like using the CLI.
Entirely right it's a limitation to the ACP side. They're in the middle of adding functionality where you can have terminal/CLI threads and ACP threads too. https://github.com/zed-industries/zed/pull/54729
On MacOS I never really felt there was a noticeable performance difference to using Zed vs VSCode. I still like the idea of it being Rust/GPU based but just like those GPU optimized terminals (Kitty, Alacritty, etc) the difference is usually pretty marginal for day to day stuff.
The only time VSCode gets slow is if you use a bunch of poorly written plugins, which hasn't been an issue for me in years. It's just like Chrome, chrome is extremely fast as a base but you can mess it up by not being careful with what you add to it.
I still plan to revisit Zed in another year or so once it progresses further, as I find it's still behind Cursor in many ways.
Personally Cursor feels like a vibe coded slop these days, I canceled the subscription and went back to vscode with AI features off. Claude Code is my third hand and that's it. I need to try Zed though, I remember Atom changed the way I use text editors, I'm certain Zed will provide the same experience.
Had the same experience with a rails project, it injected an LSP+linter we don't use in our project and it has really annoying to figure out how to disable it in a settings. Having to debug an editor's settings JSON the first time you use it is not a good UX, it should be optional to enable it instead of assuming we want aggressive on-save linting/autoformatting (that the repo doesn't even have configuration files).
Not like the US didn't try. California spent 15yrs trying to build a high speed train and failed. Canada has been talking about building trains forever too and it usually goes nowhere because the budgets explode like every major infrastructure project these days.
I wonder what's different between these English speaking countries you mention failing to build out rail transit, and places like Japan and China that have built fabulous rail networks.
Japan is a fairly unique case, and probably does not share much with China aside from being in the same region. Japan is geographically well suited to serving a large portion of the population with one long line with a few branches. That's a convenient advantage.
China just doesn't have to worry about environmentalists or anyone else locally trying to stand in the way, they just bulldoze them and build.
China also has much lower labor costs, and even Japan is a good bit cheaper (than the US, at the least)
Most of the rail has get around mountainous, uneven terrain subject to earthquakes, strong winds, and heavy rain. California should be able to build rail parallel to the I-5, a long, flat terrain without extreme weather or strong earthquakes. The problem seems to be a political one, not an engineering one. In fact, if the Interstate Highway System did not already exist, I doubt the U.S. today would be able to accept and complete it.
> one long line with a few branches
I currently live in Japan, and that does not really match what I've observed. There are three distinct railway companies in my area (JR, Tokyu, Yokohama Municipal Subway), each with their own dedicated rail, trains, power supply, etc.
The situation is more like "a disjoint union of graphs, where some of the graphs are connected".
LA proper seems to have a density of 3000/km^2 according to Wikipedia
A perhaps more interesting use case is the utsunomiya light rail. Utsunomiya has a density of around 1200/km^2.
What they ended up doing was building a new tram with exactly one line. The main thing they did was make sure the tram comes frequently, including off peak.
End result is people rely on the tram line and the tram is making good money, being operationally profitable (still gotta pay back construction costs of course).
Utsunomiya is obviously not exactly greater LA, but Utsunomiya has on average 2.25 cars per household[0]. It has traffic issues and people feel the need to own a car. And yet the tram line is finding success because transportation is a local issue, not a global one!
You can solve for transportation issues in crowded areas. Few reasonable people are lamenting that you don't have a train between madison, WI and Chicago every 15 minutes. Many are simply lamenting that even at a local level PT in many places is leaving a lot on the table despite there being chances of success!
Smaller focused PT has proven itself to work time and time again, and compounds on other PT projects in the area.
California high speed rail isn't running now but it is improving lots of things along the way. For example one of the most dangerous crossings in the state is now grade separated with the Rosecrans/Marquardt Grade Separation Project.
I wonder if California high speed rail will ever surpass quadcopter personal vehicles in passenger miles per year. I know which way I'd bet for the year 2040.
Github released that split PR beta, so sounds like they are still thinking about the future which is moving towards small manageable PRs which are part of a parent ticket. That's a solid way to dealing with AI codegen bloat.
https://www.kyivpost.com/post/55897
Either way the US needs way more drones instead of just expensive missiles/jets/boats/armor if they are going to face anyone serious like China.
reply