You can write an arena allocator referencing a pointer allocated via Marshal.AllocHGlobal and proxying it via Span<T> very easily in literally like 30 lines of code which will achieve whatever you're suggesting there, can also add where T: unmanaged if you don't want the ability to reference things which can be tracked by the GC, this is already possible right now and is fully enforced.
You can add 30 more lines of code to your arena with some PInvoking on windows calling AddVectoredExceptionHandler and VirtualAlloc, which will allow you to allocate whatever amount of memory you'd like without actually committing it, creating a very optimized and easy to use alternative to whatever you're suggesting.
The only problem I see with this approach is lack of standard data structures allocated in native memory. In GC memory you have collections and strings. In native memory you would have to create such data structures yourself. Plus figure out interoperability between the two.
It looks like a process model; isolation between programs with a system for inter-process communication, and running within a single process's memory.
If I understand correctly, instead of writing a c++ application to offload the computation of something, and then build a way of communicating the result between processes, you create a Space, define it as JIT/AOT, managed/unmanaged and execute it and use the built-in communication for transfering data.
It is an interesting approach. The author should check out Unity's Burst compiler. It takes a chunk of C# code, AOT compile it with LLVM and then the main application can invoke it. The concepts are adjacent.
Even something like Burst is, IMO, not really necessary in modern C#/.NET. It does well in benchmarks but they are almost always comparing Burst vs. normal C# in Unity. Problem is C# in Unity is stuck so far in the past that it makes Burst look amazing when it's usually not that much quicker. So if you are using modern .NET you're not restricted to a subset of C# and get good performance. And if you need even better performance there are plenty of new language features to get you there.
I generally agree. However, there are several important optimizations that Roslyn does not yet have. I love the improvements in newer versions of the compiler as much as the next guy, but historically, waiting 20 years on getting basic inlining, hoisting and SIMD accelerations has left many of us with the only option of not relying on C# for performance.
> It looks like a process model; isolation between programs with a system for inter-process communication, and running within a single process's memory.
Which is better handled by existing mature and simpler abstractions from the actor model, like Akka.net, or maybe Orleans.
For sure, but the author also proposed "unmanaged spaces" which would run in-process but with no GC. This seems to be the main goal and everything else is definitely better handled with existing solutions.
It does but the GC can still stop-the-world pause threads that aren't touching GC memory. The author's proposed isolation would provide a way to avoid that.
Don't really understand how this proposal connect to microservices, as it solves only one of the myriad of problems that architectual pattern addresses.
Second, why do we need the "spaces" concept for dealing with no GC work? And what does it really solves? Meanwhile, the proposal lacks explanation on how C# behaves on the non managed world, like better syntax for allocation and deallocation, etc. No ownership model would make it a hard sell over Rust.
C# has its own share of warts when it comes to AOT -- it doesn't yet support OpenBSD; it does not yet support all reflection oriented keywords; it requires significant changes to msbuild to work with in a standalone context.
But this article reads like someone with minimal background in software went on a LLM prompted delusion and lacks an understanding of the C# language architecture, associated build system, and philosophy. Additions of keywords like the proposed "overspace" attempting to shoe-horn both inappropriate approaches and ideas are a plague on the community.
Yeah, this doesn't look like something from .NET team.
For me what makes me angry on .NET is the selective support of what lands outside Windows, the way Xamarin went down, and the need to continuously add language features to justify the team size and new release cycles, how will C# look a decade from now with that velocity adding features.
You can write an arena allocator referencing a pointer allocated via Marshal.AllocHGlobal and proxying it via Span<T> very easily in literally like 30 lines of code which will achieve whatever you're suggesting there, can also add where T: unmanaged if you don't want the ability to reference things which can be tracked by the GC, this is already possible right now and is fully enforced.
You can add 30 more lines of code to your arena with some PInvoking on windows calling AddVectoredExceptionHandler and VirtualAlloc, which will allow you to allocate whatever amount of memory you'd like without actually committing it, creating a very optimized and easy to use alternative to whatever you're suggesting.
The only problem I see with this approach is lack of standard data structures allocated in native memory. In GC memory you have collections and strings. In native memory you would have to create such data structures yourself. Plus figure out interoperability between the two.
It looks like a process model; isolation between programs with a system for inter-process communication, and running within a single process's memory.
If I understand correctly, instead of writing a c++ application to offload the computation of something, and then build a way of communicating the result between processes, you create a Space, define it as JIT/AOT, managed/unmanaged and execute it and use the built-in communication for transfering data.
It is an interesting approach. The author should check out Unity's Burst compiler. It takes a chunk of C# code, AOT compile it with LLVM and then the main application can invoke it. The concepts are adjacent.
Even something like Burst is, IMO, not really necessary in modern C#/.NET. It does well in benchmarks but they are almost always comparing Burst vs. normal C# in Unity. Problem is C# in Unity is stuck so far in the past that it makes Burst look amazing when it's usually not that much quicker. So if you are using modern .NET you're not restricted to a subset of C# and get good performance. And if you need even better performance there are plenty of new language features to get you there.
I generally agree. However, there are several important optimizations that Roslyn does not yet have. I love the improvements in newer versions of the compiler as much as the next guy, but historically, waiting 20 years on getting basic inlining, hoisting and SIMD accelerations has left many of us with the only option of not relying on C# for performance.
> It looks like a process model; isolation between programs with a system for inter-process communication, and running within a single process's memory.
Which is better handled by existing mature and simpler abstractions from the actor model, like Akka.net, or maybe Orleans.
For sure, but the author also proposed "unmanaged spaces" which would run in-process but with no GC. This seems to be the main goal and everything else is definitely better handled with existing solutions.
Forgive my relative inexperience as a newcomer to C#, but doesn't it already provide things like stackalloc, Span and unsafe for these things?
It does but the GC can still stop-the-world pause threads that aren't touching GC memory. The author's proposed isolation would provide a way to avoid that.
I've learned to embrace the GC. In workstation mode, the latency can be so low that the pauses don't matter.
There are also other implementations of GC for C# with very interesting properties:
https://docs.unity3d.com/6000.2/Documentation/Manual/perform...
Don't really understand how this proposal connect to microservices, as it solves only one of the myriad of problems that architectual pattern addresses.
Second, why do we need the "spaces" concept for dealing with no GC work? And what does it really solves? Meanwhile, the proposal lacks explanation on how C# behaves on the non managed world, like better syntax for allocation and deallocation, etc. No ownership model would make it a hard sell over Rust.
Reading this makes me angry.
C# has its own share of warts when it comes to AOT -- it doesn't yet support OpenBSD; it does not yet support all reflection oriented keywords; it requires significant changes to msbuild to work with in a standalone context.
But this article reads like someone with minimal background in software went on a LLM prompted delusion and lacks an understanding of the C# language architecture, associated build system, and philosophy. Additions of keywords like the proposed "overspace" attempting to shoe-horn both inappropriate approaches and ideas are a plague on the community.
Yeah, this doesn't look like something from .NET team.
For me what makes me angry on .NET is the selective support of what lands outside Windows, the way Xamarin went down, and the need to continuously add language features to justify the team size and new release cycles, how will C# look a decade from now with that velocity adding features.
I can't tell if this is satire or not. And some parts read like it was written by AI.
Either way, a more fine grained control over the GC is probably preferred over something like this.
The whole post is obviously LLM spam. e.g.
> It is the conductor [emoji] that directs the symphony of independent Spaces.
this pattern is a meme by now.