js-ts-csharp
.NET Runtime
Our great sponsors
js-ts-csharp | .NET Runtime | |
---|---|---|
16 | 602 | |
122 | 13,914 | |
- | 2.7% | |
0.0 | 10.0 | |
almost 2 years ago | 2 days ago | |
C# | C# | |
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
js-ts-csharp
-
We migrated to SQL. Our biggest learning? Don't use Prisma
The thing is, if you're comfortable with TypeScript, it's really more or less just a small step to C#.
A small repo here: https://github.com/CharlieDigital/js-ts-csharp
And a practical example of a Playwright web scraper in C# and TypeScript: https://github.com/CharlieDigital/playwright-scrape-api
"Too many keywords" is the weirdest objection to a programming language versus actually using the language to build something practical.
-
Why isn’t dotnet core popular among startups?
[1] https://github.com/CharlieDigital/js-ts-csharp
-
Is it a bad idea to build a marketplace app using .Net core?
Modern C# isn't that big of a lift from TypeScript. If you can write TypeScript, you can write C#. Much easier transition than say Go or Rust. See also: https://github.com/CharlieDigital/js-ts-csharp
-
Ryujinx: Experimental Nintendo Switch Emulator written in C#
> ...this project is a nice showcase how versatile C# and .NET is
C# and .NET are highly underrated/underappreciated because of some early flops and the Microsoft branding.
It's converging with TypeScript in the best way possible[0] and has some really great language features that even TS is lacking (really powerful switch expressions, for example).
It seems like the natural option for teams that want to move from TypeScript to a compiled, multi-threaded, statically typed language but it seems that there's a lot of teams that would rather use Go or Rust; neither of which are as easy to step up to from TypeScript, IMO.
-
I'm on the JS/TS/Node stack is it worth learning another stack (C#)?
Should it be C#? I think the transition to C# is the easiest because of how similar TypeScript and C# are at some levels (small repo here showing the similarities: https://github.com/CharlieDigital/js-ts-csharp)
-
7 Reasons for Startups to Choose ASP.NET Over Node.js
For me, I use TypeScript and C# almost interchangeably now. Most of the patterns I would implement in C# I can also implement in TypeScript. It's very easy to move between them (exhibit A and exhibit B).
-
Ask HN: Examples of Top C# Code?
> C# is VERY different from even just what things were 2 years ago
C# and TypeScript are converging (both from Anders Hjelsberg).
Small repo here showing just how similar they are syntactically: https://github.com/CharlieDigital/js-ts-csharp
I'm surprised we don't see a bigger uptick in C# usage given the growth of TypeScript and how similar the two languages are. If you know C#, it's pretty easy to pick up TypeScript and vice versa.
-
.NET Myths Dispelled
.NET and C# as a platform are evolving extremely fast compared to many other runtimes and languages. In fact, it's kind of been converging with JavaScript and TypeScript. I have a small repo here that highlights this: https://github.com/CharlieDigital/js-ts-csharp
If you stopped working with .NET and C# around version 4, the language itself has transformed.
Local functions, pattern matching, records, and more!
-
25 Years of Friendship
A small repo highlighting some of the common constructs: https://github.com/CharlieDigital/js-ts-csharp
.NET Runtime
- Writing x86 SIMD using x86inc.asm (2017)
-
Why choose async/await over threads?
We might not be that far away already. There is this issue[1] on Github, where Microsoft and the community discuss some significant changes.
There is still a lot of questions unanswered, but initial tests look promising.
-
Redis License Changed
https://github.com/dotnet/dotnet exists for source build that stitches together SDK, Roslyn, runtime and other dependencies. A lot of them can be built and used individually, which is what contributors usually do. For example, you can clone and build https://github.com/dotnet/runtime and use the produced artifacts to execute .NET assemblies or build .NET binaries.
-
Garnet – A new remote cache-store from Microsoft Research
Thank you, I missed the [stack allocation](https://github.com/dotnet/runtime/blob/main/docs/design/core...) design doc stating it’s on the roadmap.
Appreciate the detail about the stack allocated bits in .NET.
Yeah, it kind of is. There are quite a few of experiments that are conducted to see if they show promise in the prototype form and then are taken further for proper integration if they do.
Unfortunately, object stack allocation was not one of them even though DOTNET_JitObjectStackAllocation configuration knob exists today, enabling it makes zero impact as it almost never kicks in. By the end of the experiment[0], it was concluded that before investing effort in this kind of feature becomes profitable given how a lot of C# code is written, there are many other lower hanging fruits.
To contrast this, in continuation to green threads experiment, a runtime handled tasks experiment[1] which moves async state machine handling from IL emitted by Roslyn to special-cased methods and then handling purely in runtime code has been a massive success and is now being worked on to be integrated in one of the future version of .NET (hopefully 10?)
[0] https://github.com/dotnet/runtime/issues/11192
[1] https://github.com/dotnet/runtimelab/blob/feature/async2-exp...
-
The Mechanics of Silicon Valley Pump and Dump Schemes
The math of the above is really simple. Microsoft has 13,000 stars on their GitHub profile for their flagship product. SupaBase has 63,000 stars on their GitHub project for their flagship product. 27% of all software developers in the world are using .Net. SupaBase has 4.5 times as many likes as the .Net Core runtime, so they must be 4.5 times as large, right? 4.5 multiplied by 27% becomes 130%. Implying 130% of all software developers that exists on earth are using SupaBase (apparently!)
-
OpenD, a D language fork that is open to your contributions
> The amount of unsafe code used to implement C# vastly outweighs the amount in Rust's standard library.
According to bing.com chat, https://github.com/dotnet/runtime has 3.5M LOC, and https://github.com/rust-lang/rust has 6M LOC. The left panel of https://github.com/dotnet/runtime says 80% of the .NET runtime is written in C#.
This makes me wonder, do you happen to have a link for your “vastly outweighs” statement?
-
Ask HN: What's the fastest programming language with a large standard library?
Movemask keeps coming back. Rather than emulating it, it appears to be more efficient to separately handle IndexOfMatch, LastIndexOfMatch and GetMatchCount scenarios it is used for most of the time:
- https://github.com/dotnet/runtime/pull/94472/files#diff-5824... (it's closed for now but I'm hoping to get back to it at some point)
- https://github.com/jprochazk/tmi-rs/blob/ac3ce6aee8bbe038a98...
It can account for good 30% performance variance depending on the use case (on Apple's M-series cores).
.NET's standard library is very heavily vectorized, vectorization is considered in all scenarios where it is applicable, the compiler will also apply it to copies of known length and string comparisons fully eliding and unrolling Memmove and SequenceEqual calls.
The gives languages that run on top of .NET massive performance advantage in a variety of scenarios versus any other language - C++ and Rust stdlibs are far more conservatively vectorized because neither language has stable SIMD vector API and even then out of modularity constraints a lot of routines have to either rely on autovectorization which is fragile or manually vectorized with intrisics for each individual platform.
A short non-exhaustive list of examples is
- Shared SIMD helper for Aho-Corasick, Rabin-Karp and other text search algorithms https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...
- Bloom filter https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...
- Base64 encoding and decoding https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...
- Element search (memchr and the like) https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...
- UTF-8 transcoding https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...
The above are examples of 1% code that ends up used by 99% of other codebase in one way or another. Regex engine, JSON serialization and parsing, substringing and etc. all use these.
Rust has had a stable SIMD vector API[1] for a long time. But, it's architecture specific. The portable API[2] isn't stable yet, but you probably can't use the portable API for some of the more exotic uses of SIMD anyway. Indeed, that's true in .NET's case too[3].
Rust does all this SIMD too. It just isn't in the standard library. But the regex crate does it. Indeed, this is where .NET got its SIMD approach for multiple substring search from in the first place[4]. ;-)
You're right that Rust's standard library is conservatively vectorized though[5]. The main thing blocking this isn't the lack of SIMD availability. It's more about how the standard library is internally structured, and the fact that things like substring search are not actually defined in `std` directly, but rather, in `core`. There are plans to fix this[6].
[1]: https://doc.rust-lang.org/std/arch/index.html
[2]: https://doc.rust-lang.org/std/simd/index.html
[3]: https://github.com/dotnet/runtime/blob/72fae0073b35a404f03c3...
[4]: https://github.com/dotnet/runtime/pull/88394#issuecomment-16...
[5]: https://github.com/BurntSushi/memchr#why-is-the-standard-lib...
What are some alternatives?
Ryujinx - Experimental Nintendo Switch Emulator written in C#
ASP.NET Core - ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
actix-web - Actix Web is a powerful, pragmatic, and extremely fast web framework for Rust.
WASI - WebAssembly System Interface
CoreCLR - CoreCLR is the runtime for .NET Core. It includes the garbage collector, JIT compiler, primitive data types and low-level classes.
vgpu_unlock - Unlock vGPU functionality for consumer grade GPUs.
runtimelab - This repo is for experimentation and exploring new ideas that may or may not make it into the main dotnet/runtime repo.
dotnet-wasi-sdk - Packages for building .NET projects as standalone WASI-compliant modules
sdk - Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
Uno.Wasm.Bootstrap - A simple nuget package to run C# code in a WASM-compatible browser
SharpLab - .NET language playground
Roslyn - The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.