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.
> 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.
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.
Thank you for the excellent and critical questions. You've pointed out the biggest flaw in my first article: it failed to properly connect the proposed concepts to the broader "myriad of problems" in the microservice ecosystem.
I have written a new, much more detailed manifesto that is almost entirely dedicated to explaining that connection and the architectural vision. I believe it addresses your first point directly.
But I also want to be transparent with you in particular. You asked about the low-level details—the "how" of C# in a non-managed world, memory management, and how it compares to Rust. You are right to ask for this. That new manifesto is still the philosophical 'why', but I want to assure you that I have already completed a full technical whitepaper that covers the 'how'.
The challenge is that the whitepaper is currently in my native language (Vietnamese), is quite long (around 150k characters), and I am still revising it before I can begin the translation.
So, I would like to propose a path forward. First, I would be grateful if you could read the new manifesto and give me your honest critique there. It lays out the complete architectural argument.
https://news.ycombinator.com/item?id=45477324
If, after reading it, you trust the vision a bit more, I hope you'll be patient for a short while longer until I can properly translate the technical whitepaper which addresses your remaining concerns.
Alternatively, if you're curious to see the raw draft now, you can likely find it by searching my username plus the keyword "Viblo". You could then use an LLM for a preview translation, but I must give a strong disclaimer that I cannot promise the quality of an automated translation of an unrevised draft.
Thank you again for the sharp feedback. It's exactly the kind of critique that is needed.
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.
kaibutsu|5 months ago
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.
kikimora|5 months ago
Genbox|5 months ago
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.
Rohansi|5 months ago
guiriduro|5 months ago
Which is better handled by existing mature and simpler abstractions from the actor model, like Akka.net, or maybe Orleans.
HeavyStorm|5 months ago
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.
axx83|4 months ago
Thank you for the excellent and critical questions. You've pointed out the biggest flaw in my first article: it failed to properly connect the proposed concepts to the broader "myriad of problems" in the microservice ecosystem.
I have written a new, much more detailed manifesto that is almost entirely dedicated to explaining that connection and the architectural vision. I believe it addresses your first point directly.
But I also want to be transparent with you in particular. You asked about the low-level details—the "how" of C# in a non-managed world, memory management, and how it compares to Rust. You are right to ask for this. That new manifesto is still the philosophical 'why', but I want to assure you that I have already completed a full technical whitepaper that covers the 'how'.
The challenge is that the whitepaper is currently in my native language (Vietnamese), is quite long (around 150k characters), and I am still revising it before I can begin the translation.
So, I would like to propose a path forward. First, I would be grateful if you could read the new manifesto and give me your honest critique there. It lays out the complete architectural argument. https://news.ycombinator.com/item?id=45477324
If, after reading it, you trust the vision a bit more, I hope you'll be patient for a short while longer until I can properly translate the technical whitepaper which addresses your remaining concerns.
Alternatively, if you're curious to see the raw draft now, you can likely find it by searching my username plus the keyword "Viblo". You could then use an LLM for a preview translation, but I must give a strong disclaimer that I cannot promise the quality of an automated translation of an unrevised draft.
Thank you again for the sharp feedback. It's exactly the kind of critique that is needed.
bob1029|5 months ago
There are also other implementations of GC for C# with very interesting properties:
https://docs.unity3d.com/6000.2/Documentation/Manual/perform...
mgh95|5 months ago
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.
pjmlp|5 months ago
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.
asabla|5 months ago
Either way, a more fine grained control over the GC is probably preferred over something like this.
shiomiru|5 months ago
> It is the conductor [emoji] that directs the symphony of independent Spaces.
this pattern is a meme by now.