3 ms·

> C# ties you to CLR C++ and Rust have runtimes as well. For C++ that’s normally a DLL like libstdc++ or msvcrt. CLR is larger but still reasonable, for 64-bit

> C# ties you to CLR C++ and Rust have runtimes as well. For C++ that’s normally a DLL like libstdc++ or msvcrt. CLR is larger but still reasonable, for 64-bit Windows VC_redist.x64.exe is 14 MB, dotnet-runtime-3.1.13-win-x64.exe is 25 MB. > and is also garbage collected by default By default yes, but that’s avoidable. Modern .NET with their spans, value tuples, ref structs, ArrayPool, etc., make it relatively easy to write C# code which doesn’t allocate much. Or even at all, as you can see on the link in my previous comment.

pianoben 6y ago
I strongly disagree. The vast majority of extant .NET APIs encourage or require allocating memory dynamically, thereby requiring GC. Sure, if you rewrite everything that isn't already defined in terms of `Memory` or `Span`, you can do it, but that's a _tall_ order. Even supposing you still mange to write a whole program that doesn't allocate dynamic memory, or that quickly stabilizes around a finite `ArrayPool`. You're still pulling in all the runtime GC machinery. Further, the minute someone _else_ contributes code, you run the risk of allocating again. As much as I love C#, _this isn't its niche_.
- Const-me 6y ago
  > vast majority of extant .NET APIs encourage or require allocating memory dynamically A lot of APIs in modern .NET already supports spans. They can be backed by anything, not just GC-managed memory. For that project, some of these spans are backed by the memory mapped by V4L2 or ALSA API calls. Others are backed by unmanaged buffers allocated on startup with Marshal.AllocHGlobal. For small temporary stuff I use stackalloc, e.g. both mp4 and mkv use tons of variable-length encoded integers. > the minute someone _else_ contributes code, you run the risk of allocating again. Good point. On the other hand, someone else contributing code can introduce any bugs at all, not just GC-related performance issues. > As much as I love C#, _this isn't its niche_. A while ago some people were saying the same about C, and were instead coding assembly :-)
jayd16 6y ago
Relevant to the topic, annoyingly, you still can't cancel a task without a ton of garbage.
- Const-me 6y ago
  You can easily forget pending tasks. That’s a single line of code like this: task.ContinueWith( t => { }, TaskContinuationOptions.OnlyOnFaulted ); However, graceful cancellation is indeed hard. Doable in .NET but not easy, you gonna need to manually pass these cancellation tokens all the way down. Do you have an example of a language/runtime/etc where the cancellation's easy? It's easy to kill processes from the outside, but even for threads it's borderline impossible without horrible side effects.
  - jayd16 6y ago
    I don't. I don't use Rust but I'm quite sad I can't use this system in C# without paying for a stacktrace/exception. Cancellation tokens sure...but many libraries will still throw the cancellation exception.

pianoben 6y ago

I strongly disagree. The vast majority of extant .NET APIs encourage or require allocating memory dynamically, thereby requiring GC. Sure, if you rewrite everything that isn't already defined in terms of `Memory` or `Span`, you can do it, but that's a _tall_ order. Even supposing you still mange to write a whole program that doesn't allocate dynamic memory, or that quickly stabilizes around a finite `ArrayPool`. You're still pulling in all the runtime GC machinery. Further, the minute someone _else_ contributes code, you run the risk of allocating again. As much as I love C#, _this isn't its niche_.

Const-me 6y ago
> vast majority of extant .NET APIs encourage or require allocating memory dynamically A lot of APIs in modern .NET already supports spans. They can be backed by anything, not just GC-managed memory. For that project, some of these spans are backed by the memory mapped by V4L2 or ALSA API calls. Others are backed by unmanaged buffers allocated on startup with Marshal.AllocHGlobal. For small temporary stuff I use stackalloc, e.g. both mp4 and mkv use tons of variable-length encoded integers. > the minute someone _else_ contributes code, you run the risk of allocating again. Good point. On the other hand, someone else contributing code can introduce any bugs at all, not just GC-related performance issues. > As much as I love C#, _this isn't its niche_. A while ago some people were saying the same about C, and were instead coding assembly :-)

jayd16 6y ago

Relevant to the topic, annoyingly, you still can't cancel a task without a ton of garbage.

Const-me 6y ago
You can easily forget pending tasks. That’s a single line of code like this: task.ContinueWith( t => { }, TaskContinuationOptions.OnlyOnFaulted ); However, graceful cancellation is indeed hard. Doable in .NET but not easy, you gonna need to manually pass these cancellation tokens all the way down. Do you have an example of a language/runtime/etc where the cancellation's easy? It's easy to kill processes from the outside, but even for threads it's borderline impossible without horrible side effects.
- jayd16 6y ago
  I don't. I don't use Rust but I'm quite sad I can't use this system in C# without paying for a stacktrace/exception. Cancellation tokens sure...but many libraries will still throw the cancellation exception.