BlazorWorker VS .NET Runtime

I've given BlazorWorker a try in order to get this running in a separate thread/in the background, but it didn't seem to help here. Do I have any options other than to convert this to an ASP.NET hosted app and do the heavy lifting on the server?

Another possible option is to use web workers for parts of your application that are more demanding. See this library for more info and demos: https://github.com/Tewr/BlazorWorker

A little more on topic, if you like SIMD and C#, dotnet/runtime now has an introductory guide to Vector128/256/512 API:

https://github.com/dotnet/runtime/blob/main/docs/coding-guid...

Now, the default syntax can still be a bit more wordy with byref arithmetics than ideal, but you can add a few extension methods to look it closer to Rust's pointer arithmetics: https://github.com/U8String/U8String/blob/main/Sources/U8Str...

You must be trolling and not evaluating either on their current state, or have little understanding of the subject matter as others have pointed out.

Please write an efficient text element scanner that uses all AVX512 vector width in Java that matches LLVM codegen and can take any source of memory? You can easily do that in C#, it's impossible to do it in Java alone.

https://github.com/dotnet/runtime/blob/7cd8459e7bd3883f0aa86...

This library is based on modified code from the Microsoft System.IO.Compression repository, and includes the Deflate64 algorithm from the same source.

This looks like a fun project but for serious work, if you need runtime codegen, you should use .NET which has been successfully using reflection and IL emit for more than a decade:

- Regex https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...

- Json https://github.com/neuecc/Utf8Json/tree/master?tab=readme-ov... (this project is archived but nonetheless impressive and continues to show good numbers despite obsoletion)

- LINQ to DB query compilation https://github.com/dotnet/efcore/blob/main/src/EFCore/Query/...

There is nothing wrong with System.Linq just like there's nothing wrong with Rust's std::iter::Iterator. If anything, this makes writing Rust very familiar if you have C# experience and vice versa.

The performance profile of LINQ, while much maligned, has been steadily improving over the years and, in the example of Sum itself, you actually do want to use it because it will sum faster than open-coded loop[0].

I do have grievances regarding LINQ still - my (non-negotiable) standpoint is that Roslyn (C# compiler) must lower non-escaping LINQ operations to open-coded loops, inline lambdas at IL level and similar, making it zero-cost - .NET (IL compiler/runtime) provides all the tools necessary to match what Rust's zero-cost-ish iterator expressions offer and there just needs to be more political will in the Roslyn teams to do so. Because of this, I'm holding my breath waiting for DistIL[1] to be production-ready which does just that.

[0]: https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...

[1]: https://github.com/dubiousconst282/DistIL

When .NET (that is, what became CoreCLR runtime flavour) became open-sourced, it was done in such a way as not to cause issues for existing Mono, Xamarin and Unity code, and allow cleanly merging the first two into overarching .NET ecosystem.

https://github.com/dotnet/runtime/blob/main/LICENSE.TXT

https://github.com/dotnet/runtime/blob/main/PATENTS.TXT

Given that MSFT never sued anyone for .NET or .NET-related matters, so far their reputation is clean in that area, unlike certain Java-related company.

Async/await is not a tight corner as showcased by a multitude of languages adopting the pattern: Rust, Python, JavaScript and Swift.

In fact, it is a clean abstraction where future progress is possible while retaining the convenience of its concurrency syntax and task composition.

Green threads experiment proved net negative in terms of benefit but its the follow-up work on modernizing the implementation detail was very successful: https://github.com/dotnet/runtime/issues/94620 / https://github.com/dotnet/runtimelab/blob/feature/async2-exp...

It also seems that common practices in Java indicate that properties are not a mistake as showcased by popularity of Lombok and dozens of other libraries to generate builders and property-like methods (or, worse, Java developers having to write them by hand).

.NET has explicit tailcalls - they are heavily used by and were made for F#.

https://learn.microsoft.com/en-us/dotnet/api/system.reflecti...

https://github.com/dotnet/runtime/blob/main/docs/design/feat...

The description indicates it is not production ready, and is archived at the same time.

If you pull all stops in each respective language, C# will always end up winning at parsing text as it offers C structs, pointers, zero-cost interop, Rust-style struct generics, cross-platform SIMD API and simply has better compiler. You can win back some performance in Go by writing hot parts in Go's ASM dialect at much greater effort for a specific platform.

For example, Go has to resort to this https://github.com/golang/go/blob/4ed358b57efdad9ed710be7f4f... in order to efficiently scan memory, while in C# you write the following once and it compiles to all supported ISAs with their respective SIMD instructions for a given vector width: https://github.com/dotnet/runtime/blob/56e67a7aacb8a644cc6b8... (there is a lot of code because C# covers much wider range of scenarios and does not accept sacrificing performance in odd lengths and edge cases, which Go does).

Another example is computing CRC32: you have to write ASM for Go https://github.com/golang/go/blob/4ed358b57efdad9ed710be7f4f..., in C# you simply write standard vectorized routine once https://github.com/dotnet/runtime/blob/56e67a7aacb8a644cc6b8... (its codegen is competitive with hand-intrinsified C++ code).

There is a lot more of this. Performance and low-level primitives to achieve it have been an area of focus of .NET for a long time, so it is disheartening to see one tenth of effort in Go to receive so much spotlight.