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?
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
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
That’s very interesting. I see similar attitude in the C# JIT/Roslyn developers where they take this very seriously. Interesting are this is influenced by Anders, or just whole thing tick for a lot of compiler developers?
I like ACE it's very interesting application of Prolog. While it focused on writing logical definitions, I think there interesting way of looking at how we try to express programming languages syntax to newbies in classrooms. I personally think that it is possible to find way of speaking about code which sounds a lot like English. Maybe that's because my English is not adequate.
Just in case that maybe interested to you. Currently (with nightlies) using NativeAOT + C# you would be able to have approximate same as Go. Even fully statically linking executable. And given that MS working on making apps have less size, gopefully it would be comparable to Go in app size.
Not sure if this is project related, but I discover port (https://github.com/ptrelford/FunSharp) of Small Basic style on F# and that look awesome for displaying simple concepts. I think all programming languages can have simple setups which would be easy for kids.
I was interested enough to port from Gtk to Avalonia, since that looks much better for Windows and do not degrade anywhere on Linux/Mac OS. Also I run small experiment by try to "internationalize" that library, by porting F# to my language - Ukrainian, just to look if that would be easier to pickup. I think for early education, immidiately after Scratch expressing algorithms in native language maybe beneficia.
Technically you can always write you own C compiler like this project https://github.com/ForNeVeR/Cesium. Obviosuly C++ is much more complicated journey and require real investment. But at this point this is not CoreCLR limitations mostly.