5 ms·

C# isn't even remotely similar. A managed language running in a heavy VM runtime versus a direct-to-machine-code compiled language...

by chungy 3y ago

29athrowaway 3y ago
Have you heard of native AOT compilation?
- saagarjha 3y ago
  Still requires a substantial runtime.
  - pjmlp 3y ago
    Which in many cases has already been proven by making it part of the kernel, even if Xerox, DEC/Olivetti, ETHZ, MSR projects weren't made available to wider audiences. One can do a Google, and push it no matter what, or give up and take the adoption path that is easier to bring the safety luddites along for the ride.
    - saagarjha 3y ago
      I don’t fundamentally oppose such a thing, but I assume doing so would require very careful effort. It’s much harder than integrating Rust.
      - pjmlp 3y ago
        For me, Rust is a nicer Ada like effort, a kind of compromise. We can wait the usual progress rate of one funeral at a time until a new generation buys into fully managed OS, or another Google/Apple big spender forces them into developers no matter what, which most likely I will not live through. So we're left with the compromise of allowing only userspace for managed languages, while adopting something like Rust for the "only over my dead body folks" anti any form of automatic memory management languages. Given that even the success stories of bare metal deployments of managed runtimes doesn't change their minds anyway.
        saagarjha 3y ago
        Yeah idk why people are so against this, I guess old habits die hard.
- deleted 3y ago
  [deleted]
- stevefan1999 3y ago
  1. That still needs a GC, and thus heap space. Unless you make everything stackalloc which is impossible in kernel programming 2. It is heavily pinned by unnecessary metadata. Well, actually some maybe necesdary to facilitate GC but it is bloated anyway 3. RyuJIT is not as optimized as LLVM, and RyuJIT produced the AOT code. There in an abandoned project called LILAC attemping to use LLVM as a second AOT generator but it was never heard from again after 2019. 4. Native interoperability in .net requires JIT as well, to generate things like call sites and runtime thunks (function pointers to restore CLR context). Not only that wastes more resources but also that not all P/Invoke calls can be AOT compiled.
  - stevefan1999 3y ago
    oops here's some typo: 1. Well technically speaking, you need a unified heap space. Just like in Linux kernel you have vmalloc and kmalloc which does virtual memory and real, page-aligned physical memory. So this is technically means I will have to pre-allocate everything. But it is not gonna work, how do you save space? 2. "necessary". I should have enabled autocorrect on my phone, it does more good than harm this time if I had it on. 3. It's actually LLILC (https://github.com/dotnet/llilc https://github.com/dotnet/llilc). I just remembered how to pronounce it. But if the name is wrong, then you have to correct it.
  - pjmlp 3y ago
    - Singularity - Midori - Oberon - Mesa/Cedar - Topaz It is a matter of actually wanting to make it happen, or giving up to the voices that think otherwise.
    - omnicognate 3y ago
      That list just shows people have been experimenting with such things for decades, including in a major push with Midori: over 100 devs across Microsoft and Microsoft Research, and while things have been learned and fed into the development of runtimes and operating systems it hasn't changed the fact that all the major OS kernels are written in non-memory-safe languages. Rust, on the other hand, is starting to directly impact these kernels. Joe Duffy himself said with Midori they "started with C# and .NET [but] were forced to radically depart in the name of security, reliability, and performance" and that at one point they had 11 different garbage collectors. The jury is still out (and has been deliberating for an awfully long time) on whether you can build or even contribute to a successful, mainstream, general-purpose OS kernel in a garbage-collected language but a distinctive selling point of Rust is that you can start adding memory safety without having to. And the fact that this is actually starting to happen to more than one such kernel while Rust is still a fairly new language could be interpreted as evidence that maybe, just maybe, the GC really was the problem all along.
lostmsu 3y ago
I don't think runtime is that big. The classlib is.

C# isn't even remotely similar. A managed language running in a heavy VM runtime versus a direct-to-machine-code compiled language...

by chungy 3y ago

C# isn't even remotely similar. A managed language running in a heavy VM runtime versus a direct-to-machine-code compiled language...

29athrowaway 3y ago

Have you heard of native AOT compilation?

saagarjha 3y ago
Still requires a substantial runtime.
- pjmlp 3y ago
  Which in many cases has already been proven by making it part of the kernel, even if Xerox, DEC/Olivetti, ETHZ, MSR projects weren't made available to wider audiences. One can do a Google, and push it no matter what, or give up and take the adoption path that is easier to bring the safety luddites along for the ride.
  - saagarjha 3y ago
    I don’t fundamentally oppose such a thing, but I assume doing so would require very careful effort. It’s much harder than integrating Rust.
    - pjmlp 3y ago
      For me, Rust is a nicer Ada like effort, a kind of compromise. We can wait the usual progress rate of one funeral at a time until a new generation buys into fully managed OS, or another Google/Apple big spender forces them into developers no matter what, which most likely I will not live through. So we're left with the compromise of allowing only userspace for managed languages, while adopting something like Rust for the "only over my dead body folks" anti any form of automatic memory management languages. Given that even the success stories of bare metal deployments of managed runtimes doesn't change their minds anyway.
      - saagarjha 3y ago
        Yeah idk why people are so against this, I guess old habits die hard.
deleted 3y ago
[deleted]
stevefan1999 3y ago
1. That still needs a GC, and thus heap space. Unless you make everything stackalloc which is impossible in kernel programming 2. It is heavily pinned by unnecessary metadata. Well, actually some maybe necesdary to facilitate GC but it is bloated anyway 3. RyuJIT is not as optimized as LLVM, and RyuJIT produced the AOT code. There in an abandoned project called LILAC attemping to use LLVM as a second AOT generator but it was never heard from again after 2019. 4. Native interoperability in .net requires JIT as well, to generate things like call sites and runtime thunks (function pointers to restore CLR context). Not only that wastes more resources but also that not all P/Invoke calls can be AOT compiled.
- stevefan1999 3y ago
  oops here's some typo: 1. Well technically speaking, you need a unified heap space. Just like in Linux kernel you have vmalloc and kmalloc which does virtual memory and real, page-aligned physical memory. So this is technically means I will have to pre-allocate everything. But it is not gonna work, how do you save space? 2. "necessary". I should have enabled autocorrect on my phone, it does more good than harm this time if I had it on. 3. It's actually LLILC (https://github.com/dotnet/llilc https://github.com/dotnet/llilc). I just remembered how to pronounce it. But if the name is wrong, then you have to correct it.
- pjmlp 3y ago
  - Singularity - Midori - Oberon - Mesa/Cedar - Topaz It is a matter of actually wanting to make it happen, or giving up to the voices that think otherwise.
  - omnicognate 3y ago
    That list just shows people have been experimenting with such things for decades, including in a major push with Midori: over 100 devs across Microsoft and Microsoft Research, and while things have been learned and fed into the development of runtimes and operating systems it hasn't changed the fact that all the major OS kernels are written in non-memory-safe languages. Rust, on the other hand, is starting to directly impact these kernels. Joe Duffy himself said with Midori they "started with C# and .NET [but] were forced to radically depart in the name of security, reliability, and performance" and that at one point they had 11 different garbage collectors. The jury is still out (and has been deliberating for an awfully long time) on whether you can build or even contribute to a successful, mainstream, general-purpose OS kernel in a garbage-collected language but a distinctive selling point of Rust is that you can start adding memory safety without having to. And the fact that this is actually starting to happen to more than one such kernel while Rust is still a fairly new language could be interpreted as evidence that maybe, just maybe, the GC really was the problem all along.

lostmsu 3y ago

I don't think runtime is that big. The classlib is.