19 ms·

I imagine it comes down to the handling of threads vs anything else. Technology is rapidly adopting the more cores strategy of technology since we are hitting s

I imagine it comes down to the handling of threads vs anything else. Technology is rapidly adopting the more cores strategy of technology since we are hitting some IPC limitations and in the server space more cores is better.

munchler 3y ago
.NET supports asynchronous code very well, so that hardly seems like a likely reason for rewriting in Rust.
- pdimitar 3y ago
  > .NET supports asynchronous code very well Work-stealing task schedulers?
  - neonsunset 3y ago
    Yes, and overall task-based code has been a basis for many APIs since .NET Framework 4.5 (2012), earlier async patterns existed before too. It is not in a frozen state either as each release sees improvements to asynchronous code execution (overall improving ThreadPool, reducing size of state machine boxes, experimenting with alternate underlying implementations like green threads experiment, the learnings of which have been carried over to runtime task handling experiment which will massively reduce the async overhead when it eventually finds its way into mainline runtime).
neonsunset 3y ago
Multi-core scaling (in particular within GC) is one of the strongest points of .NET (for example, Go used to have poor scaling on many-core systems (has this changed in 2024?) while in .NET the throughput would continue scaling linearly)).
- pdimitar 3y ago
  I really doubt that this is true, might be your bubble. Have you dabbled in Erlang/Elixir? Your standards would increase substantially if you did.
  - neonsunset 3y ago
    Wouldn't that be trying out something that is a strict downgrade? (bytecode interpreter based VM with weak JIT, GC is likely much weaker too) It really comes down to performing as much work on a core-local basis and .NET SRV GC does already a lot to avoid inter-core synchronization cost (per-core heaps, I'd expect JVM GCs do a similar, maybe better, job), and so does various thread-safe code in the standard library.
    - pdimitar 3y ago
      To answer your question: To see how far behind everything is in terms of parallelism and concurrency. It's not even funny how primitive 99.9% of everything out there is in this area.
      - neonsunset 3y ago
        Maybe compared to C++ or even Go (yes, Go is very rudimentary with examples expecting you to synchronize goroutines by hand), but unlikely compared to C#. While both parallelism and concurrency are not as central to it as to Erlang, it is a much more approachable language and achieving either or both is trivial: // Concurrency using var http = new HttpClient(); var req1 = http.GetStringAsync("https://example.org/"); var req2 = http.GetStringAsync("https://news.ycombinator.com/"); Console.WriteLine(string.Join('\n', await req1, await req2)); // Parallelism var user = Environment.GetFolderPath( Environment.SpecialFolder.UserProfile); var hashes = Directory .EnumerateFiles(Path.Combine(user, "Downloads")) .AsParallel() .Select(path => { using var file = File.OpenRead(path); return Convert.ToHexString(SHA256.HashData(file)); }) .ToArray(); Console.WriteLine(string.Join('\n', hashes)); For distributed computing, there are Orleans and Akka.net frameworks which allow to achieve it at scale and garden variety of other, simpler frameworks for job scheduling.

munchler 3y ago

.NET supports asynchronous code very well, so that hardly seems like a likely reason for rewriting in Rust.

pdimitar 3y ago
> .NET supports asynchronous code very well Work-stealing task schedulers?
- neonsunset 3y ago
  Yes, and overall task-based code has been a basis for many APIs since .NET Framework 4.5 (2012), earlier async patterns existed before too. It is not in a frozen state either as each release sees improvements to asynchronous code execution (overall improving ThreadPool, reducing size of state machine boxes, experimenting with alternate underlying implementations like green threads experiment, the learnings of which have been carried over to runtime task handling experiment which will massively reduce the async overhead when it eventually finds its way into mainline runtime).

neonsunset 3y ago

Multi-core scaling (in particular within GC) is one of the strongest points of .NET (for example, Go used to have poor scaling on many-core systems (has this changed in 2024?) while in .NET the throughput would continue scaling linearly)).

pdimitar 3y ago
I really doubt that this is true, might be your bubble. Have you dabbled in Erlang/Elixir? Your standards would increase substantially if you did.
- neonsunset 3y ago
  Wouldn't that be trying out something that is a strict downgrade? (bytecode interpreter based VM with weak JIT, GC is likely much weaker too) It really comes down to performing as much work on a core-local basis and .NET SRV GC does already a lot to avoid inter-core synchronization cost (per-core heaps, I'd expect JVM GCs do a similar, maybe better, job), and so does various thread-safe code in the standard library.
  - pdimitar 3y ago
    To answer your question: To see how far behind everything is in terms of parallelism and concurrency. It's not even funny how primitive 99.9% of everything out there is in this area.
    - neonsunset 3y ago
      Maybe compared to C++ or even Go (yes, Go is very rudimentary with examples expecting you to synchronize goroutines by hand), but unlikely compared to C#. While both parallelism and concurrency are not as central to it as to Erlang, it is a much more approachable language and achieving either or both is trivial: // Concurrency using var http = new HttpClient(); var req1 = http.GetStringAsync("https://example.org/"); var req2 = http.GetStringAsync("https://news.ycombinator.com/"); Console.WriteLine(string.Join('\n', await req1, await req2)); // Parallelism var user = Environment.GetFolderPath( Environment.SpecialFolder.UserProfile); var hashes = Directory .EnumerateFiles(Path.Combine(user, "Downloads")) .AsParallel() .Select(path => { using var file = File.OpenRead(path); return Convert.ToHexString(SHA256.HashData(file)); }) .ToArray(); Console.WriteLine(string.Join('\n', hashes)); For distributed computing, there are Orleans and Akka.net frameworks which allow to achieve it at scale and garden variety of other, simpler frameworks for job scheduling.