Is Microsoft going to miss another C# opportunity?

[Ðаn]

IMO, 15-ish years ago, Microsoft had nearly "won" as Java was on life-support; had they open-sourced .NET/C# then (as well as porting it to MacOS/Linux, Xamarin, etc.) that might have been the end of Java. Certainly, the efforts over the past 10+ years have been wonderful, but it was too late to "kill" Java.

Now, "killing" Java isn't (necessarily) a goal, but keeping C# relevant in these days of Rust and Python would seem to be. And while stability isn't all bad, the amount of substantial change in C# has all-but-stopped since (say) dynamic.

Given the current chatter about the dangers of C (and C++) with a rewrite in Rust being one of the "solutions" proffered, it seems that C# is in a position to do something really radical: dramatically increase source-level compatibility with C.

This doesn't have to be anywhere near a 100% solution, certainly not at the beginning (if ever). And existing C code can be tweaked (slightly) to make it more amenable to C#, as long as it remains valid C code.

Yes, there are dozens of tiny corner-cases that are all-but-impossible to get right in C#; but there are also large swaths of existing C code that can "easily" be compiled as C# with a bit of creativity and small changes.

As but one example, memory management: the result of malloc() is almost always cast to Foo*, in C# malloc<Foo>() would allocate an array of Foos; pointer manipulation is just moving through the array. Speaking of pointers, a class like Pointer<T>(T[] array, int index=0) can be used to simulate much of a pointer.

As I said, none of would (ever) be 100% ... but if C# doesn't do something "radical" soon, all the air is going to be sucked up by Python and Rust.

 

[Skydiver]

Have you seen C++/CLI and IJW in action? It's not quite the same as what you seem to be asking for in terms of C code, but it does make a lot of C++ code ready to run in a managed .NET environment.

 

[Ðаn]

Have you seen C++/CLI and IJW in action? It's not quite the same as what you seem to be asking for in terms of C code, but it does make a lot of C++ code ready to run in a managed .NET environment.

C++/CLI is great! But it's Windows-only with no plans for Linux/MacOS; it also seems to have a hard time keeping up with a fairly fast-moving C++ standard.

Had C++/CLI (not managed C++) and/or C++11 existed back before C# 1.0 was released, C# might have never happened.

 

[Skydiver]

But that Windows-only dependency is not something due to the language. It's something that is due to the tooling (e.g. only the MSVC compiler supports it). So just need some people to pick up the gauntlet and implement it for the compilers on the other platforms.

I do see where you are coming from that there will likely be a bigger chance of a C# language change also being implemented on the other platforms, as opposed to trying to get people to update their already working C/C++ compilers.

Anyway, in my opinion, the key stumbling block for just dropping in C code to run as C# code is not the memory allocation (which is what everyone is talking about), but rather the cavalier method that C style code uses pointers. It lets pointers point of to nowhere or locations just before or after a buffer with the assumption that programmer writing the code will properly move the pointer to inside the buffer when it is actually time to access memory. I'm not quite sure how a C# language change (without having to use pointers and the unsafe keyword) is going to actually fix things like that without the programmer having to re-write the code. Even C++ code making of use of the standard library uses the concept of iterators and internally, those still follow the old C concept of being able to point outside the buffer to determine whether the iterator has reached the end or not.

 

[Ðаn]

But that Windows-only dependency is not something due to the language. It's something that is due to the tooling (e.g. only the MSVC compiler supports it). So just need some people to pick up the gauntlet and implement it for the compilers on the other platforms.

I do see where you are coming from that there will likely be a bigger chance of a C# language change also being implemented on the other platforms, as opposed to trying to get people to update their already working C/C++ compilers.

Anyway, in my opinion, the key stumbling block for just dropping in C code to run as C# code is not the memory allocation (which is what everyone is talking about), but rather the cavalier method that C style code uses pointers. It lets pointers point of to nowhere or locations just before or after a buffer with the assumption that programmer writing the code will properly move the pointer to inside the buffer when it is actually time to access memory. I'm not quite sure how a C# language change (without having to use pointers and the unsafe keyword) is going to actually fix things like that without the programmer having to re-write the code.

The "goal" is to preempt a Python or Rust rewrite (Rust seems to have a strong "marketing" department) by making vast swaths of C code "just work" on .NET (i.e., in a managed environment).

I'd suggest say 60% of a non-trivial "real world" C code with compile and run "as-is": if, for, while, etc. Another 10%-ish needs very light syntax change (e.g., switch/case), and maybe another 20% needs some helper utilities (e.g., the Pointer class I mentioned). Yes, 10% "not working" is still a hassle, but perhaps far less so than a total rewrite? (And I think with a bit of effort, that 10% can be cut down to just direct hardware access and the like.)

C++/CLI barely gets the time-of-day from Microsoft, why should "the community" try to make it work with GCC/CLang on Linux? Even the language itself is only "half implemented" (there's a long list of "could be done" in the original spec.)