Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Microsoft rewrote its C# compiler in C# and made it open source (2017)

medium.com

Post reply on HN
Print view View original

121–130 of 136 posts

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#121

Post by nudpiedo »

ablekh wrote: post #101

How would you compare special features, if any, as well as advantages (and disadvantages) of using C# for developing an embedded DSL versus using Julia macros for the same purpose versus using specialized toolsets (e.g., MPS) for developing an external DSL? Please note that I'm aware of the Modeling SDK for Visual Studio. However, since it only allows integration with / targets the Visual Studio environment, it is no…

Maybe you can look at F#, it will compile for Android, iOS, windows, Linux, MAC, javascript frontends and server side. The feature set is different than Julia’s but it is very powerful and versatile.

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#122

Post by moron4hire »

pjmlp wrote: post #112
moron4hire wrote: post #91

Earlier quoted context omitted.

DLL Hell had nothing to do with project development. It was a problem of application deployment and running applications with DLLs in shared locations. https://en.wikipedia.org/wiki/DLL_Hell The problem arises when the version of the DLL on the computer is different than the version that was used when the program was being created. Other than the GAC, which was never recommended for use anyway, .NET has never had DLL…

GAC was surely the recommended way until .NET 4.0, when the location changed.

No, the recommended way was to install your application with all dependency DLLs in the application install location.

And I've misspoken about GAC causing DLL Hell for .NET. It fixed DLL Hell, but introduced a new Strong Naming Hell.

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#123

Post by moogly »

pjmlp wrote: post #108
Kuinox wrote: post #81

Earlier quoted context omitted.

I found that VS 2019 is faster than VS 2017. But VS 2019 with Resharper is a lot more slower than VS 2017 with resharper. I would blame resharper there, not VS. VS never felt that fast than right now.

Every VS release is one reason less to use Resharper.

The biggest reason IMO not to use ReSharper is actually Rider (so I don't use VS anymore either). You get all the ReSharper goodies, but inside an editor that's more nimble than vanilla VS.

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#124

Post by moron4hire »

thrower123 wrote: post #29
moron4hire wrote: post #13

Earlier quoted context omitted.

I'm not sure that it would be that difficult with Roslyn and Visual Studio these days. There are Roslyn-based syntax-highlighters and linters and snippet-generators and code-transformers. I use one for making sure all of my code is not just formatted the way I want it, but auto-inserting "readonly" modifiers for fields that don't get re-written outside of the constructor, one that treats not implementing IDisposable…

What is the name of that IDisposable checking one? That sounds very, very useful.

I think the easiest way to set it all up is to manually edit your CSProj files, especially if you are still building .NET Framework projects. By default, Visual Studio will only create the new SDK Style project file format for .NET Standard and .NET Core projects, but it's still usable for .NET Framework projects if you manually change the format. Once you change it, it sticks, so you can use VS to edit the config after that, but it's still pretty easy to edit by hand now.

So here is my base project config: https://github.com/capnmidnight/Juniper/blob/master/Juniper....

The most important part is the first PropertyGroup sets values for all build configs, in particular is setting LangVersion to 8.0. Framework 4.8 taps out at C# 7.2, but you can use most of the C# 8.0 features, including fully async streams if you manually set the language version. Features that aren't available are some minor things like the array ranges and indexing: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

And here are my base project with the analyzers I use: https://github.com/capnmidnight/Juniper/blob/master/Juniper....

They're all ones provided directly from Microsoft, though there are a bunch more from other vendors: https://www.nuget.org/packages?q=analyzer

Then here is an example project using that targets file: https://github.com/capnmidnight/Juniper/blob/master/src/Juni...

You can see just how much the new SDK Style project file format simplifies things. There is no importing of any base Targets files hidden deep in Visual Studio's install directory anymore.

I manually import the .props and .targets file instead of using Directory.Build.props and Directory.Build.targets because I have other projects that use these configs, included via a git submodule.

Here is my .editorconfig file, where I set most of the rules related to Disposable types to errors: https://github.com/capnmidnight/Juniper/blob/master/.editorc...

And this Visual Studio extension makes .editorconfig files a lot nicer to work with: https://marketplace.visualstudio.com/items?itemName=MadsKris...

(BTW, I pretty much install all of Mads Kristensen's extensions)

And while I'm here, I'll give a shout-out to Viasfora for its syntax highlighting modifications that rainbow-highlight code blocks: https://marketplace.visualstudio.com/items?itemName=TomasRes...

And VSColorOutput for making the Output window in Visual Studio actually readable: https://marketplace.visualstudio.com/items?itemName=MikeWard...

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#125

Post by pjmlp »

moogly wrote: post #123
pjmlp wrote: post #108

Earlier quoted context omitted.

Every VS release is one reason less to use Resharper.

The biggest reason IMO not to use ReSharper is actually Rider (so I don't use VS anymore either). You get all the ReSharper goodies, but inside an editor that's more nimble than vanilla VS.

If I learned anything from my Borland days was to only get my IDE tooling from the same factory that does the sausage, instead of always playing catch-up with the OS vendor tooling.

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#126

Post by Rusky »

Sharlin wrote: post #64
_hardwaregeek wrote: post #44

Roslyn's parser and syntax tree is pretty amazing. You can recreate the precise source text from the parse tree up to whitespace. This sort of "bijective parsing" is truly incredible and probably one of the cooler innovations I've seen in parsing technology. I can see a bunch of really interesting ideas that you could do with bijective parsing. For instance, imagine Rails style boilerplate generation but done at a se…

Pardon me if I'm missing something, but doesn't just about any AST implementation allow recovering the source text up to whitespace – or indeed including whitespace, given that most real-world parsers have to retain lexical information in order to support reasonable diagnostic messages anyway.

Many (if not most) ASTs, especially in batch compilers, do not preserve comments, whitespace, or even all of the actual syntax. Even the diagnostics information you're referring to are insufficient to reproduce the whitespace.

Further, what Roslyn does is quite interesting even on top of preserving all of that. It does so in a way that lets it incrementally re-parse parts of the program without touching the rest- including position information for the rest of the file after the change, which has all shifted to match.

None of this was standard practice anywhere when Roslyn was designed, though it's starting to be picked up in other projects since.

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#127

Post by kevingadd »

chrisseaton wrote: post #106
kevingadd wrote: post #19

Earlier quoted context omitted.

People have done research before into having the C#->native JIT be written in C#, I recall seeing prototypes. There are a ton of barriers between a prototype and a shipping implementation though, so I'm not sure we'll ever see it. In particular you risk regressions in startup time or memory usage since the amount of infrastructure needed to run C# (pre-jitted?) to generate all your jitcode is much higher than a small…

The way Java does it is their JIT written in Java is optionally AOT compiled to native code, so it doesn't have a startup time or warmup time problem and it can be PGOd. We do know that the returns are worth it, because people are able to develop new optimisations in the Java version that people just won't attempt in the C++ version because the code is so much harder to work with (but possibly just due to the age of…

This is fascinating. Is the claim here that the C++ version could have never been as fast as the current Java one or just that people have been optimizing the Java one and getting improvements past the C++ one?

Also, it sounds like the old C++ JIT has to be maintained and shipped in the event that the Java-based JIT isn't available at startup, right? If so that makes sense as a stop-gap and it would be more of a tiered JIT, not a port. Tiered JITs are definitely proven, successful technology.

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#128

Post by pjmlp »

moron4hire wrote: post #122
pjmlp wrote: post #112

Earlier quoted context omitted.

GAC was surely the recommended way until .NET 4.0, when the location changed.

No, the recommended way was to install your application with all dependency DLLs in the application install location. And I've misspoken about GAC causing DLL Hell for .NET. It fixed DLL Hell, but introduced a new Strong Naming Hell.

Initially that recommendation only applied to native code DLLs, not managed ones, as far as I can remember.

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#129

Post by phillipcarter »

Const-me wrote: post #116
phillipcarter wrote: post #72

Earlier quoted context omitted.

Interesting. I've observed the opposite, with VS 2017 often being unbearably slow in comparison as the codebase gets large. But I can appreciate that you may be experiencing the opposite. I highly recommend filing issues, especially if you can do so with a specific, reproducible problems. Those tend to get resolved quite quickly.

> Those tend to get resolved quite quickly. The issues are getting resolved in the public bug trucker, pretty quickly indeed, typically saying "can't reproduce, won't fix", sometimes "not a bug, won't fix". I'm not sure the software problems are getting resolved.

You can look through GH milestones to see specific issues fixed in results. For example, here are the 230 tracked items done for the VS 16.4 public release: https://github.com/dotnet/roslyn/milestone/53?closed=1

You can also see that there are many more resolved issues in previews of that public release: https://github.com/dotnet/roslyn/milestones?state=closed

So there are a _lot_ of legitimate problems being fixed and enhancements being added over pretty short periods of time.

When something is resolved as "no reproduction" or "not a bug", that's because there was an earnest attempt to reproduce an issue with the latest bits set to go out to a release with no reproduction, or something is truly by design (e.g., user files an issue because they would prefer a feature to do something different than it does today).

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#130

Post by chrisseaton »

kevingadd wrote: post #127
chrisseaton wrote: post #106

Earlier quoted context omitted.

The way Java does it is their JIT written in Java is optionally AOT compiled to native code, so it doesn't have a startup time or warmup time problem and it can be PGOd. We do know that the returns are worth it, because people are able to develop new optimisations in the Java version that people just won't attempt in the C++ version because the code is so much harder to work with (but possibly just due to the age of…

This is fascinating. Is the claim here that the C++ version could have never been as fast as the current Java one or just that people have been optimizing the Java one and getting improvements past the C++ one? Also, it sounds like the old C++ JIT has to be maintained and shipped in the event that the Java-based JIT isn't available at startup, right? If so that makes sense as a stop-gap and it would be more of a tier…

> Is the claim here that the C++ version could have never been as fast as the current Java one

The claim is that the work to add new optimisations to the old C++ code is so difficult that people aren't prepared to do it. The Java code is easier to write and debug, enough so that people are managing to add new optimisations that they haven't added to the C++ code.

> the old C++ JIT has to be maintained and shipped in the event that the Java-based JIT isn't available at startup

Well only until the new Java JIT is mature. The AOT build of the Java JIT can be shipped in the binaries so it's always there.

> If so that makes sense as a stop-gap and it would be more of a tiered JIT, not a port. Tiered JITs are definitely proven, successful technology.

It's used as a new top-tier yes, replacing the C++ top tier. The C++ JIT is likely to go I think, in the medium-to-long term.

Post reply on HN