aspnetskeleton2 VS .NET Runtime

There's another sample project which demonstrates how to set up the latter strategy. (In this case the TS compiler configuration is included in the csproj but, of course, you can use tsconfig.json as well. For that, here's another example.)

It's not at all. For more complex applications (which benefits from a service layer) I use exactly this architecture you described. I've built a few applications with it and it worked fine for me. If you want to take a closer look, I also have a template for this. (Haven't had the time for documentation yet but it can still give you some ideas.)

Table rendering logic (implemented as global razor helpers)

As for TypeScript, you're kinda out of luck because the TS compiler is written in TS, so it inevitably needs a JS runtime (like node) to run. However, IMO it's strongly advisable to use TS for any client-side logic bigger than 100-200 lines of code. So regarding this I usually just accept the compromise. At least, the following setup works for me perfectly: I configure the TS compiler to emit ES6 modules and I bundle the emitted JS modules using the lib. You can find a working example of this in my web project template: tsconfig.json, bundler configuration.

I use this code generation strategy combined with .NET Core Local Tools to generate boilerplate code (2-3 source files at specific locations) for CQS commands and queries and I'm quite satisfied with this method so far. You can check out the sources of my codegen tool here if you want to explore it. Might give you some ideas.

But TBH the only feature I really missed when I work with STJ is polymorphism support. You don't even need a 3rd party lib for that: it requires some gymnastics but it can be implemented relatively easily by creating a custom JsonConverterFactory + JsonConverter. This implementation of mine can give you some ideas. (Also does type whitelisting based on Protobuf configuration.)

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.