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

51–60 of 136 posts

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

#51

Post by kick »

oconnor0 wrote: post #43
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.

It is interesting to me that I read people criticizing Microsoft for their open sourcing code as doing it for marketing reasons---which seems accurate---but not criticizing Google or Apple or whoever else when they open source code.

Apple doesn't release code under Free licenses for marketing purposes: I'd be surprised if anyone in the marketing department of Apple even realized that they were doing so.

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

#52

Post by frandroid »

oconnor0 wrote: post #43
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.

It is interesting to me that I read people criticizing Microsoft for their open sourcing code as doing it for marketing reasons---which seems accurate---but not criticizing Google or Apple or whoever else when they open source code.

There are plenty of people on this very forum regularly criticizing Google and Apple's open source efforts...

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

#53

Post by dancek »

pcunite wrote: post #49

If .NET/C# could output native binaries for Windows Desktop apps, I could seriously think about switching to C# over C++. How do people deal with securing their source code otherwise? Quite trivial to get the source from a decompiled C# exe file.

You can reverse engineer native binaries, too. Many companies are happily publishing web apps where the actual source is available, in minified form. Why does your source code need to be so secure?

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

#54

Post by mads_ravn »

pcunite wrote: post #49

If .NET/C# could output native binaries for Windows Desktop apps, I could seriously think about switching to C# over C++. How do people deal with securing their source code otherwise? Quite trivial to get the source from a decompiled C# exe file.

You can use an obfuscator (see e.g. https://stackoverflow.com/questions/19163701/how-can-i-obfus...).

Note that you can still decompile the obfuscated code and look around (I’ve done so to attempt to debug a 3rd party library), but mangling all identifiers makes it quite hard to read.

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

#55

Post by LeifCarrotson »

pcunite wrote: post #49

If .NET/C# could output native binaries for Windows Desktop apps, I could seriously think about switching to C# over C++. How do people deal with securing their source code otherwise? Quite trivial to get the source from a decompiled C# exe file.

It's quite trivial to get the source from a C# exe file in the same way as a decompiler makes it trivial to get the source from a C++ exe file.

Obfuscators are common if you're concerned about the symbols leaking.

If you don't include the .PDB debugging symbol files it's much the same as native binary code. The .NET virtual machine code is a little more expressive but is superficially similar to x86 native code.

In my opinion, if you're concerned about people reading your compiled machine code, the only solution is to run your app on a server and give users an API.

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

#56

Post by alkonaut »

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.

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 some IDE widget hold references to old compilation data structures which are never garbage collected. On the bright side at least 2019 works pretty well without R#.

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

#57

Post by Wohlf »

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.

They kind of are already rewriting it, with VSCode + OmniSharp.

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

#58

Post by swasheck »

I've always loved C# but can't quite get past having to target specific .net frameworks and keeping the different frameworks in my different servers straight and targeting each of them differently. Maybe that'll change with .net core (and once I'm able to get that on my servers), but for now I've discovered a personal love for Go as a way around this for my small utilities.

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

#59

Post by hadrien01 »

alkonaut wrote: post #56
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.

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 did the exact opposite: I migrated to Rider, an IDE built around ReSharper. In my experience, it is much faster than VS2019 for my use case (including a huge monolith with hundreds of projects)

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

#60

Post by cpascal »

swasheck wrote: post #58

I've always loved C# but can't quite get past having to target specific .net frameworks and keeping the different frameworks in my different servers straight and targeting each of them differently. Maybe that'll change with .net core (and once I'm able to get that on my servers), but for now I've discovered a personal love for Go as a way around this for my small utilities.

The madness will hopefully be ending soon with .NET 5.

https://devblogs.microsoft.com/dotnet/introducing-net-5/

> There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.

Post reply on HN