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

91–100 of 136 posts

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

#91

Post by moron4hire »

qes wrote: post #33
moron4hire wrote: post #14

Earlier quoted context omitted.

DLL Hell doesn't refer to "lots of DLLs", it refers to conflicting versions of DLLs not being easily manageable across multiple applications. Outside of putting assemblies in the GAC (which was always a hack of last resort anyway), .NET has never had "DLL Hell".

> .NET has never had "DLL Hell" I take it you've never worked on a .Net solution with projects targeting both full framework and Core framework. Core v1.x stuff was a nightmare - haven't had so many issues with versioning in 20 years. Core v2.0 was still pretty bad but each v2 point release made decent strides - and specific packages would get updated out of band at times to fix issues. But to say .Net has never had…

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 Hell

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

#92

Post by JamesBarney »

kqr wrote: post #38
m0xte wrote: post #27

Earlier quoted context omitted.

Their intent is still entirely market share. We need to be vigilant on how they get there. History has taught us a lot of lessons we seem to have forgotten because shiny and new layer of marketing. There is still a massive cultural and technical impedance mismatch.

I agree. A lot of what they are doing now looks like EEE when you peel back a couple of layers. I say this as someone who happily uses a lot of the stuff they produce in the process. I really, really, intensely hope I'm wrong and my fears aren't realised.

It's the same corporate entity, but Microsofts incentives and the majority of executives have turned over. So I don't see any reasons why Microsoft would be any more likely to EEE than another company. In fact I think they would be less likely because they they have more to risk reputationally.

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

#93

Post by phillipcarter »

mhh__ wrote: post #82
jaked89 wrote: post #50

While the rewrite enabled faster development of the language as a whole, it also gradually destroyed the IDE's performance. The editor in VS 2019 is simply unworkable. I blame this directly on the immutable AST. While a nice concept in theory, it causes too many allocations, and is cumbersome to work with. I predict another rewrite in 2 or 3 years.

If an immutable datastructure causes to many allocations surely that's an issue with the allocator rather than immutability? I'm not familiar with this compiler but I'm currently writing a mostly immutable structure so I'm curious as to whether it's an issue.

It's not an issue. See here: https://news.ycombinator.com/item?id=22303220

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

#94

Post by mycall »

nudpiedo wrote: post #8

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

Their Azure platform is very closed.

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

#95

Post by mycall »

jaked89 wrote: post #50

While the rewrite enabled faster development of the language as a whole, it also gradually destroyed the IDE's performance. The editor in VS 2019 is simply unworkable. I blame this directly on the immutable AST. While a nice concept in theory, it causes too many allocations, and is cumbersome to work with. I predict another rewrite in 2 or 3 years.

VS2019 runs fast for me O.o

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

#96

Post by mycall »

to11mtm wrote: post #61
alkonaut wrote: post #56

Earlier quoted context omitted.

I had to ditch ReSharper to get to 2019 because together with the performance of the IDE itself, it just wasn't usable. R# ate gigs of Ram and Roslyn does the same. It's not surprising since they basically do the same thing, in managed code! But I can't pay the CPU time and memory to analyze my code TWICE on every edit. I also suspect things like switching build configuration offers thousands of opportunities to have…

> I had to ditch ReSharper to get to 2019 because together with the performance of the IDE itself, it just wasn't usable. R# ate gigs of Ram and Roslyn does the same. It's not surprising since they basically do the same thing, in managed code! But I can't pay the CPU time and memory to analyze my code TWICE on every edit. I'm holding off on 2019 as much as I can. Between 'forcing' an upgrade for .NET Core 3.0 and the…

Is Rider 64-bit?

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

#97

Post by mycall »

jaked89 wrote: post #67
phillipcarter wrote: post #65

Earlier quoted context omitted.

> I blame this directly on the immutable AST. While a nice concept in theory, it causes too many allocations, and is cumbersome to work with. This isn't a cause of performance problems you're seeing. What's most likely happening is that 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. The issue that's m…

> 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 fun…

Have you replicated this issue on multiple machines?

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

#98

Post by throwaway8941 »

_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…

>Or imagine syntax reformatting but purely locally.

You don't have to imagine it, this has been supported by IDEA for about a decade now at least for some languages (it works for Kotlin at least, I just re-checked before posting this).

> Or semantically aware git diffs that can actually compare the underlying parse trees instead of just raw text.

http://semanticmerge.com/

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

#99

Post by jaked89 »

mhh__ wrote: post #82
jaked89 wrote: post #50

While the rewrite enabled faster development of the language as a whole, it also gradually destroyed the IDE's performance. The editor in VS 2019 is simply unworkable. I blame this directly on the immutable AST. While a nice concept in theory, it causes too many allocations, and is cumbersome to work with. I predict another rewrite in 2 or 3 years.

If an immutable datastructure causes to many allocations surely that's an issue with the allocator rather than immutability? I'm not familiar with this compiler but I'm currently writing a mostly immutable structure so I'm curious as to whether it's an issue.

The problem with immutability in a rapidly mutating environment is that the theory clashes with reality.

Anytime a leaf node changes, all its ancestors have to be replaced, instead of just updating the leaf in place. (I'm aware of the red-black node separation, but I believe that in practice most of the tree is constantly regenerated all the time).

I realized it when trying to write a complex analyzer. I had to replace the tree all the way up to the project level. If you combine different chunks of the tree, each with a slight change, you're forced to recreate each of those chunks.

This is extremely wasteful, and no wonder the IDE behaves so poorly.

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

#100

Post by jaked89 »

jaked89 wrote: post #99
mhh__ wrote: post #82

Earlier quoted context omitted.

If an immutable datastructure causes to many allocations surely that's an issue with the allocator rather than immutability? I'm not familiar with this compiler but I'm currently writing a mostly immutable structure so I'm curious as to whether it's an issue.

The problem with immutability in a rapidly mutating environment is that the theory clashes with reality. Anytime a leaf node changes, all its ancestors have to be replaced, instead of just updating the leaf in place. (I'm aware of the red-black node separation, but I believe that in practice most of the tree is constantly regenerated all the time). I realized it when trying to write a complex analyzer. I had to repla…

Also, forgot to mention, that in some analyzers, even if you have no actual code change, the symbols change meaning, and then you're forced to recreate the tree regardless, because you can't change the node-symbol association.
Post reply on HN