Comment by pjmlp
2 years ago
C# has a uphill battle against those that don't believe in systems programming languages with GC, despite several graphical workstations have been done in the past in such languages.
Unfortunately freebie UNIX, and security was yet decades away to be relevant to governmental regulators, thus they never managed to gain enough mindshare to keep going.
Additionally even with all the .NET team efforts, the technology remains mostly relevant to Microsoft shops.
I seldom see RFPs from UNIX first culture companies, that quote .NET as possible delivery technology.
GC still has the downside of higher memory overhead. While I’m not particularly a fan of Swift, this is a relevant argument for a general-purpose browser implementation.
Reference counting is also a GC algorithm, even though people pretend otherwise, as they seldom learn from CS literature.
Plus all systems languages with GC, including C#, can do C and C++ style memory management.
This is an old argument, and it’s well understood that “GC” by default refers to tracing GC and delayed collection. (Without delayed collection, there arguably isn’t any “garbage” in the first place.)
“Can do C++ style memory management” is very different from what happens when coding in the default idiomatic style of the language and when using existing libraries written in the language. What happens by default is a relevant consideration.
4 replies →
The degree to which GC issues in the context of deterministic memory management apply to C# is incomparably lower to pretty much every other language that offers GC (especially JVM family) or a similar automatic memory management capability (except Swift or D).
However, D's GC is very rudimentary, and Swift pays very hefty performance price imposed by ARC for lower memory footprint and somewhat more predictable memory behavior.
In the context of writing something like a browser engine, both Swift and C# offer strong if different capabilities to control or avoid allocations, with Swift introducing Rust-like lifetime annotations for affine-like memory management, while C# relying on improving escape analysis in compiler and much better integration of plain structs and byreflike structs (they can hold GC-aware pointers called byrefs (`ref` keyword) to arbitrary memory) with generics for zero-cost abstractions.
Note that today, if I ever dared to even think about writing a browser engine, then the choice would have been Rust. But if not Rust, then C# would have been the next on the list. Some may suggest Zig but I have only brief knowledge of it so cannot comment further.
Until Zig has a good story for use after free, I wouldn't be considering it.
Regarding C#, there was some research work at MSR for improving escape analysis and IDispose usage via lifetime analysis, but seems to never have moved beyond proof of concept.
By the way, Midori internal presentation from 2013 is doing the rounds on twittersphere.
3 replies →