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...
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?
C2Rust is the largest project here, it was born out of corrode. The general idea of it is to do a direct C -> unsafe Rust port, and then also provide tooling to convert unsafe Rust -> safe Rust, as a secondary tool to be used as a second step. I don't think they've shipped much of that second tool yet, but I haven't checked in in a while.
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 think you overestimate ability of Dotnet to trim unused things. As a person who spend a lot of time wandering across ecosystem and measuring what can be done, I would say we have very bulky and complicated libraries in the .Net.
Just bringing HttpClient(without SSL support) add 6Mb of generated code.
Minimal API gets you additional 21 Mb. And we not even talk about desktop applications here.
Reflection is very very core of .Net ecosystem and you cannot reliably trim with how we use it currently
Last time I checked the base web template (the one which uses minimal API) was around 10-12 MB (which is pretty good for something with a full web server, GC, async runtime and more). I’ll message you in private to see what’s going on.
But otherwise yes, reflection is used heavily even when completely unnecessary.
Usually better start with small scale fixing typos and improving docs. That’s great canary for me. If it’s accepted within day or so, that’s project which I willing to learn. I would say you can select projects for your value and you would be fine contributing there. Eventually people will learn you and will trust you more
I understand your point and it's good advice. Typos and documentation though? That's boring... I want to do interesting things. Ever wondered why some program can't do something? Surely someone much smarter would have thought of it, right? And then you code it up and it actually works? That's the kind of thing I like to do.
I once tried to retrofit a library system into GNU bash of all things. Let's just say it didn't go well.
Works for me. I can easily organize and reuse functions now. Made scripting much more pleasant. Even made a package out of it so I could install it alongside the upstream version.
Nope, but if you click into their paper[0] and follow the link to PL-Detective[1] there, that's the one! (Hat tip to another commenter who was also familiar with this.)
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.