How Microsoft rewrote its C# compiler in C# and made it open source (2017)
1–10 of 136 posts
Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)
#2Why isn't the native code compiler also now written in C#, like Java is doing?
Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)
#3I still can't believe more people aren't leveraging the Roslyn APIs to write compiler extensions or additional tools around C#. It's conceptually powerful.
Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)
#4Why isn't the native code compiler also now written in C#, like Java is doing?
I imagine it's on a roadmap somewhere. Having the code->IL layer be readily accessible from managed code will have bigger developer impact than the IL->machine code step, though.
Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)
#5I still can't believe more people aren't leveraging the Roslyn APIs to write compiler extensions or additional tools around C#. It's conceptually powerful.
Personally speaking, I'd love to, but I'd then have to figure out how to make them work with an IDE. I'm very tired of waiting for record classes to show up and I could have written a (to be clear: inferior) set of stuff around regular classes that magics one into "everything is readonly and we autogenerate a `copy` method", much like Kotlin does for its data classes...but my IDE isn't gonna understand it unless I do a lot more work, and so I never bothered.
Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)
#6I still can't believe more people aren't leveraging the Roslyn APIs to write compiler extensions or additional tools around C#. It's conceptually powerful.
I looked at bit when I was in preview. It’s indeed powerful but also quite verbose and it distinguish between a lot of concepts, so there is a steep learning curve. Then there was the lack of examples beyond a few blog posts.
Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)
#7I still can't believe more people aren't leveraging the Roslyn APIs to write compiler extensions or additional tools around C#. It's conceptually powerful.
I looked at bit when I was in preview. It’s indeed powerful but also quite verbose and it distinguish between a lot of concepts, so there is a steep learning curve. Then there was the lack of examples beyond a few blog posts.
Agreed. I have a few ideas and it would be nice to see more examples. Right now it’s hard to make sense of things without spending a lot of time on it.
Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)
#8I find amusing how microsoft moved from the closed source referent in the industry into such an open source player. Right now even allows to hook some of their tools and platforms to its competing platforms and tools.
Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)
#9I still can't believe more people aren't leveraging the Roslyn APIs to write compiler extensions or additional tools around C#. It's conceptually powerful.
At some point I wrote a barebones scripting system using roslyn for a project of mine. At runtime I got a piece of code compiled to a DLL in memory and then executed this DLL; Worked well; But at that time there was no support for destroying AppDomains or something, don't remember the exact name. Still pretty fun; But yeah, there's no real complete documentation anywhere; And the DLL hell was real. Dozens of DLL's just to support this; But now with .NET Core 3+ things must have improved a lot;
Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)
#10Why isn't the native code compiler also now written in C#, like Java is doing?
Depending on what you consider the runtime, a lot of it is already written in C#. And many new concepts are written in C# when they may have been written with C++ in the past, in part due to C# supporting more low-level concepts than before.
That said, large-scale rewrites don't happen just because engineers feel like doing them. In the case of Roslyn, there were multiple compilers (C# language compiler, VB language compiler, C# tooling compiler, VB tooling compiler, etc.), requiring an enormous cost to evolve C# and VB as languages while ensuring that end users of these languages had a good experience using tools like Visual Studio. Beyond that, there was a host of additional tooling to provide more advanced code analysis that was equally expensive to maintain and evolve as the languages evolved. This meant that the kinds of language and tooling innovations end users expected was more challenging to meet. A similar set of challenges - focused on problems centered around the end users - must exist to justify the enormous cost of rewriting a massive engineering system.