core

nc epic issue.

alenv or whatever, a container, or a global toolchain installed and you just ignore it. I’ve got containers that I wrote in 2019 that I built last week and they just worked out of the box, no faffing around with versions of anything. In my experience, the thing that’s most likely to fail or rot is external URLs that you grab the dependencies of the container from - which will happen with a shell script or virtualenv either Edit: https://github.com/dotnet/core/issues/9671 here’s a perfect example

the time spent in GC (DATAS targets up to 3% CPU time currently). You also have to remember that the average .NET application has much lower allocation traffic. In addition to that, without arguing on pros and cons of runtime simplicity (because I believe there is merit to Go's philosophy), .NET's CoreCLR implementation is anything but simple. So the statement does not correlate to reality at all - it makes different tradeoffs, sure, but together with CIL spec and C# design it makes historically better decisions than JVM and Java which lend themselves into more naturally achieving high performance - no interpreter stage, only intermediate compilations have to pay for OSR support, all method calls are non-virtual by default, true generics with struct monomorphization and so on and so forth. Another good example of the runtime doing truly heavy lifting on behalf of the user are byref pointers aka 'ref's - they can point to _any_ memory like stack, GC heap, unmanaged or even device mapped pages (all transparently wrapped into Span<T>!), and the runtime emits precise data for their tracking to update them if they happen to be pointers to object interiors without imposing any measurable performance loss - it takes quite a bit of compiler and GC infrastructure to make this work (exact register state for GC data for any safepoint for byrefs, brick tables for efficiently scanning referenced heap ranges, etc.). List of references (not exhaustive): High-level overview (it needs to be updated but is a good starting point): https://github.com/dotnet/runtime/blob/main/docs/design/core... Implementation (the 53612 line file): https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/g... .NET GC internals lectures by Konrad Kokosa (they are excellent even if you don't use .NET): https://www.youtube.com/watch?v=8i1Nv7wGsjk Articles on memory regions: https://devblogs.microsoft.com/dotnet/put-a-dpad-on-that-gc/ https://maoni0.medium.com/write-barrier-optimizations-in-reg... https://itnext.io/how-segments-and-regions-differ-in-decommi... Articles on DATAS: https://github.com/dotnet/core/blob/main/release-notes/9.0/p... (quick example of the kind of heap size reduction applications could see) https://maoni0.medium.com/dynamically-adapting-to-applicatio...

non-free stuff to run on Windows, is it ok to include in Debian? It looks like none of the non-free stuff (like WPF) gets distributed with the non-Windows SDK builds. Binaries created from your code only depend on MIT-licensed stuff on macOS and Linux, but might depend on something closed-source when targeting Windows - though it looks like almost all of that stuff is either WPF (so you wouldn't be able to develop on Linux/Mac anyway since those libraries wouldn't be in the SDK on those platforms) or were removed as a runtime dependency in .NET 7. It looks like `Microsoft.DiaSymReader.Native` might be the only thing left. Maybe that's what is holding it back? > also, does dotnet-core have a reasonable aot story for things like esp32 and ch32v003? "Reasonable" can be a lot of things to a lot of different people. People have been working on RISC-V support. Samsung seems interested in it. But I probably wouldn't recommend it at the moment - and Mono doesn't really have RISC-V support either.