Publicly based on my calculations[1] there only ~20k tests. I would say they are usual tests for the runtime. Constantly running on the CI much lesser amount. Average test count/line of code ratio drops after rewrite. And even before Node have denser tests count/LOC ratio
As person who was in blackout in Jan 2022 in Kazakhstan, I’ll say it’s very unpleasant situation when you known that some people go into protests. Some security service building was looted of arms. Police nowhere to be seen. No communications and you don’t know if should you do some limited self protection available in form of running or not. So even if government control what they say, it does not control your ability to find out what’s going on via other people. That’s big deal for your physical security and wellbeing
As grandparent said, Blazor optimized for fast delivery. For public products you will have places where you should care about interactivity a lot. Their solution is interop with JS. You may try WASM but it’s definitely slow for UI.
WASM good for complicated tools, but you better probably with other language if you looking for next Figma.
Hybrid approach which is default have two issues.
- round trip to the server. That’s not nice for interactivity and responsiveness.
- hybrid hydration model is needlessly complicated. And again it will not fully solve your problem when you need to go extra mile.
Overall cold start for WASM require large payload, for Hybrid you need Websockets for updates. That sucks outside of cities or on junkie mobile. Not for public product.
Working with Blazor from Net Core 2.2
For internal tooling, or B2B where you don’t care that much is very efficient.
I really don’t understand whole discourse us vs them? Why it is should be only Google fixing the bugs. Isn’t if volunteers not enough, so maybe more volunteers can step up and help FFMpeg. Via direct patches, or via directly lobbying companies to fund project.
In my opinion if the problem is money, and they cannot raise enough, then somebody should help them with that. Isn’t it?
The finally behave slightly different in CIL. You have protected regions and finally/fault/catch/filters handlers attached. So in order to support continue inside finally you should introduce some state machine , which is complication and generally against Roslyn design limitation.
I was in same position as Mozilla guy when I slowly crawl through Cordova Russian translation. Then suddenly MS have initiative with Cordova Tools for VS, they redesign Cordova website (which is great) but completely drop docs website, and say - hey, we can use automatic translation if you want read in your mother tongue. Ironically I speak with MS manager and he was Russian speaking as well. So even if large corps made mistakes, their mistakes can const community contributors. But they are cheap, so who cares...
Yeah. After reading article I become supper interested in looking how they uplift things and was honestly a bit disappointed. Did not try to look for Huawai work for obvious reasons
I did take a look at the projects which attempt to address conversion of C to Rust and even if article talk about about uplifting C to idiomatic Rust, or to utilize decompilation techniques, I do not see anything of that in any existing project.
I really don't see any project which attempt to reverse engineer Rust idioms from C, even if in limited contexts. Maybe the goal of the article to inspire all of us. Or Maybe I miss some other existings projects?
[1] https://kant2002.github.io/en/llm/2026/05/16/bun-pr-analysis...