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

Re:How Microsoft rewrote its C# compiler in C# and made it o... by jaked89 on Tuesday February 11, 2020 @04:50PM (#22303294)

> the overall size of your code has increased a lot over time, causing performance issues due to issues that have existed for a long time, but weren't being felt yet.

Not really. A simple empty project displays the same problems. You can try going back to 2017 right now with any project you're working on, you'll feel the difference instantly.

Intellisense simply takes longer to respond, and likewqise other editor functions.

Their feedback forums have hundreds of similar reports.

[ Parent | on HN ]

Re:How Microsoft rewrote its C# compiler in C# and made it o... by phillipcarter on Tuesday February 11, 2020 @05:09PM (#22303467)

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.

[ Parent | on HN ]

Re:How Microsoft rewrote its C# compiler in C# and made it o... by Const-me on Wednesday February 12, 2020 @04:51AM (#22307453)

> 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.

[ Parent | on HN ]

Re:How Microsoft rewrote its C# compiler in C# and made it o... by phillipcarter on Wednesday February 12, 2020 @01:50PM (#22311531)

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).

[ Parent | on HN ]

Re:How Microsoft rewrote its C# compiler in C# and made it o... by Const-me on Thursday February 13, 2020 @04:56AM (#22316529)

My experience might be irrelevant to Roslyn, I experienced these things when reporting Visual Studio bugs in general. Examples:

https://developercommunity.visualstudio.com/content/problem/... (BTW, people have been reporting that bug for years now)

https://developercommunity.visualstudio.com/content/problem/...

[ Parent | on HN ]

Re:How Microsoft rewrote its C# compiler in C# and made it o... by fultonfaknem42 on Tuesday February 11, 2020 @05:23PM (#22303602)

That is interesting and counter to my experience. Consider looking in to alternative causes (uninstalling plugins that may not be playing nicely with your particular version, background updates, etc.)

[ Parent | on HN ]

Re:How Microsoft rewrote its C# compiler in C# and made it o... by mycall on Tuesday February 11, 2020 @10:24PM (#22305455)

Have you replicated this issue on multiple machines?

[ Parent | on HN ]