A Proposal to Add Gc-Less, Unmanaged Memory Spaces to C#

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.

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.

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.

Hi HeavyStorm,

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.

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.