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

71–80 of 136 posts

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

#71

Post by fsloth »

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.

To my understanding commercial software licenses can effectively enforced globally as long as you have reach of the local justice system. So need lawyers to represent you and so on.

If the financial loss isn’t big enough to warrant a global license compliance scheme then I don’t see the source code would be that valuable (in a general commercial contex).

But I don’t think any form of software that is distributed to end users can be fully secured from unlicensed use. You always need a legal recourse if you actually want to stop unlicensed use.

The very-small niche where you can’t afford lawyers but want to force license compliance maybe isn’t a niche you can actually serve through a sound business.

So, rather than seek for automated technical compliance solutions (they don’t really exist without the physical lawyer component) maybe you should find the biggest market you can serve, use the most productive tool for the job and try to make sure unlicensed use can be noticed.

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

#72

Post by phillipcarter »

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…

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.

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

#73

Post by wvenable »

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.

I say it's a mess but it isn't a hassle. Targeting .NET standard or .NET core is pretty straight forward and easy.

But the fact that all this exists is a mess and thankfully MS finally has a good plan to clean it up.

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

#74

Post by wvenable »

kick wrote: post #51
oconnor0 wrote: post #43

Earlier quoted context omitted.

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.

Apple releases code under free licenses because they are required to and do exactly that minimum required.

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

#75

Post by fultonfaknem42 »

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…

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

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

#76

Post by WorldMaker »

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.

.NET Core 3.1 is a good LTS release and no time like the present to start migrating to it. Unlike .NET Framework, there's a lot less emphasis in .NET Core on machine-wide installs and a lot more capabilities for application-specific framework deployments. .NET Core even has tools to bundle all of your framework dependencies into a single "EXE", and tree-shaking that down to at least something of a minimal bundle size. There's a small but growing world of "go-like" small utilities that are entirely self-contained .NET Core dependencies.

https://www.hanselman.com/blog/MakingATinyNETCore30EntirelyS...

There's even fun experiments of AOT compiling to get interesting in "EXE golf" results from .NET Core applications such as getting them below 8 KB or running on Windows 3.1 (because why not):

https://www.hanselman.com/blog/NETEverywhereApparentlyAlsoMe...

.NET 5 will integrate further AOT capabilities as the Mono world is merging in, in addition to the raw marketing advantage that 5 > 4 for anyone still struggling to convince non-technical managers that .NET Core is a better investment in 2020 than .NET Framework.

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

#77

Post by romwell »

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.

Well, it's the EEE I'm comfortable with. I hope it stays this way.

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

#78

Post by kick »

wvenable wrote: post #74
kick wrote: post #51

Earlier quoted context omitted.

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.

Apple releases code under free licenses because they are required to and do exactly that minimum required.

That's not entirely true. launchd was released under a free license, and it was one of the most interesting innovations in software in a long while, for example.

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

#79

Post by to11mtm »

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.

> A lot of what they are doing now looks like EEE when you peel back a couple of layers.

Doesn't look like; they are doing EEE, just of a more 'benevolent' nature.

.NET between around 2010-2016 was a pretty boring/dire time for the community. Things were so bad that the Community started solving their own problems. This wound up giving us a bunch of great projects that the community stepped up and provided.

But now, when we fast forward to Today, .NET Core (Or, to put not too fine a point on it, ASP.NET Core) is doing a whole lot of what is at best steering developers away from good practices, at worst (un?)intentional EEE:

- EF Core: EF6 was terrible for a lot of reasons. EF Core tries to get people to access relational and nonrelational databases via the same API. Why? (Of course, with Cosmos the answer becomes obvious...)

- MS DI: Microsoft looked at the best examples of DI the community provided, and wound up deciding that breaking a number of established paradigms made it easier to build ASP.NET Core, even if folks who have written the best libraries/literature on DI in .NET explain why it's a bad idea.

- Serialization: 'System.Text.Json will be better than the other libraries out there' I heard that from multiple voices. It's still not really that good, but people try anyway because MS Stack.

And that's a bit of the problem. Many of these things _are_ needed for the 'safe shops'. I've been at places where deviating from MS Stack was specifically discouraged because they were worried about longer term support. Broadly speaking, if it had a big backer/sponsor (i.e. StackOverflow's Dapper) it was a non-issue, and it wasn't a -bad- way to make sure developers weren't just using $"{blogToolOfTheWeek}". Later on however, we shoved that mindset aside as much as we could. Instead we made it our goal to find the best libraries to solve or problems... and our productivity went way up.

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

#80

Post by Karliss »

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.

There is reason AST is called abstract syntax tree not just syntax tree. Many syntax details like parentheses or choice between alternative syntax forms are there only to avoid syntactic ambiguity, improve readability or historical reasons and don't affect the semantics or even error messages. It's not surprising for compiler authors to choose discarding some of the unnecessary information as early as possible to save memory.
Post reply on HN