Hacker News new | comments | ask | show | jobs | submit login
What Makes .NET Core So Special? (jamesmichaelhickey.com)
238 points by jamesmh 3 months ago | hide | past | web | favorite | 231 comments

I’m in the process of porting a bunch of go code to dotnet core 2.1 on AWS lambda. I’m on a Mac using vscode. I never installed mono, just the dotnet sdk.

Honestly, I’ve been amazed at how good the tools have been. For cli and serverless dev, it’s been surprisingly great. It’s fast. C# is decent. The cold starts are not as fast as go, but not terrible. Memory usage is low.

It’s been a legitimately positive experience. When I started the port I was skeptical, but it is legit cross-platform. I would consider starting a project in it for lambda... I never thought I’d say that about a MS product.

Something over there is different, and I suppose it has been for awhile. I think it could get a lot more popular as non-ms devs realize that MS has built dotnet to work really well on Mac/Linux cli, far away from the weird tightly-coupled Windows/VisualStudio-hit-f5-to-do-the-magic-with-the-15-billion-auto-generated-magical-xml-files world. It feels well engineered instead of thrown together, which is nice.

Also, So far, I’ve pulled in no external libs other than the AWS sdk for the port either. C# with linq is a pretty complete toolset. I’m sure I’ll pull in more as I get more familiar, but it’s been solid on its own. Really nice surprise.

I'm a huge C# advocate but we actually went the other way. Regardless of the tooling etc. we still have to use Golang for mission critical stuff. This is mainly due to the cold start times you mentioned - mainly the "first request" problem C# has with web related requests.

I've been keeping up with the latest developments, and it seems that they're finally starting to address the problem with tiered compilation stuff, which is fantastic. However, for now, waiting for 5+ seconds for a simple controller method to fully complete on a first post - with no way of auto-warming up (without using major hacks) on startup is just not acceptable.

Again, I really love .net, and contribute a fair bit to Signalr (core) myself, but feel this would really need to be addressed in an easy-to-integrate manner before it can be an absolute top tier language. They're addressing the other elephant in the room and providing a single-execuatable runtime-agnostic deployment option soon as well...which is amazing!

Overall though, for a language, you can't beat C#/core in my opinion and would 100% recommend it.

You can usually cut the cold start performance in half by enabling Tiered Compilation. It's just one parameter in your project file, or via an environment variable.

Disclaimer: I work on performance in the ASP.NET team.

I should say (since i've got your attention) that i'm almost 100% sure that all of your customers would be more than willing to sacrifice a startup time for a well-coordinated callback when everything is warmed up, as a toggleable option of course.

To explain this a bit better, i'd definitely be happy even waiting 10+ minutes for all of my controllers/hub methods to be instant response. I could then subscribe to an event when it is ready and let haproxy/nginx or whatever else know that the server is "good to go". This way, the server goes into the pool, and everyone is happy. I remember seeing that the Bing guys did something like this, but again it was majorly hacky.

Thanks for all the great work you're doing on C#/.NET Core in general by the way.

Tiered Compilation is tweaked in a way that it provides a very good balance between startup time and throughput, which is what a majority of users would need. If you want to privilege throughput and don't care about startup time, then you should try COMPlus_ReadyToRun=0 as an environment variable. This will force to use non-crossgened code so the JIT can better optimize your code.

How about using native compilation?

Said that in the post above :) however it doesnt seem to impact HTTP requests or requests to a signalr hub for the first time after boot.

We've had tiered compilation enabled since it came out as an option, but the first requests are still dog slow

What are you disclaiming?

None of those definitions mean "disclosure," which is certainly what was meant.

Yea, this project is mostly batch processing of things, so cold starts don’t matter. There is one api endpoint that we left in go for quick responses. I thought about doing a C# to js transpile, but have not had time to look into it. That being said, our cold starts are < 2 seconds with dotnet core 2.1, which isn’t great, but isn’t too bad.

I actually find the "f5-to-do-the-magic" experience in Visual Studio Code to be preferable (TypeScipt project with Mocha tests) to the Visual Studio experience :-)

As someone eager to start (properly) learning C#, is doing so on Mac actually viable? It sounds like it from your post but would be eager to hear your thoughts (I only have a Mac at home to practice on).

I've been doing C# on a Mac w/ Rider and it's been a delight. There's a few rough edges (using Windows/DOS style paths in the csproj breaks my muscle memory) but it's great.

Yes. VS Code is probably the easy button to get started. With a few plugins, it's ready to write, build, and debug C# projects.

I haven't built any production code in VS Code or .Net Core yet, but have started analysis for converting legacy .Net applications. I've also had interns doing some prototype work in .Net Core using VS Code, both on Macs and PCs. So far, so good.

I also used VS Code to do some React development. That worked out well also.

At this point, I'm hoping to get the legacy solutions converted in the next year or two, ditch my MSDN subscription, and move to VS Code full-time. Right now, I'm on a Mac, and running VS in VMWare.

Mac + VSCode is my daily driver.

Totally. .NET Core SDK, VS Code and the C# VS Code plugin are enough.

Yes, Unity3d developers have been developing in C# on Mac for over a decade. Visual Studio for Mac (aka Xamarin Studio aka MonoDevelop) is better than Xcode in some respects.

I'm using a 2015 Macbook Air + vscode. Builds are fast, easy to debug code, even spinning up a local webserver to test my .NET MVC web app goes fast enough.

.NET Core on Mac with Rider has been great here.

Devdiv (org that builds .NET, C#, VC++, VS etc) has always been one of the top notch organizations within Microsoft with great engineers (although from what I hear, some of them have left recently). Nonetheless, as someone who now works at a company with an open source tech stack, I sorely miss the tooling I had when I worked at Microsoft.

C++ belongs to WinDev, hence the whole politics WinDev vs DevTools, the torpedoing of Longhorn and WinRT.

I'm complete new to C# and Java but I'm looking into them to choose a new language to learn. I'm mostly worried about memory consumption since I often use a cheap $5 VPS. Would you happen to know which one would be a better fit for my use case? Thank you.

If your end game is working professionally just check what is more in demand in your geographic location.

Personal opinion

C# is a lot better than Java. You have less boilerplate code (getter and setter in 2018, really?) and lambdas are great.

But really both are similar so you can pretty much just start with one and still find your way in the other.

Java is the most popular language of the JVM ecosystem, but not the only one. If I were to restart from scratch, I would seriously look into Kotlin, which is how Java should have been.

Honestly, people still using the getter and setter argument in 2018 as a reason to pick a language should not be taken seriously.

Indeed Java has more boilerplate, but honestly I've never been bothered by it (as you can generate most within your IDE) and because its explicitly written down it can make code more readable.

And Java also has lambda's.

> because its explicitly written down it can make code more readable.

more text to read does not means "more readable", it means more effort to do

unless that text validates hidden assumptions, or conveys important information to the user.

not always the case, but you can't argue that "less text is more readable" any more than you can argue "more text is more readable". what you want is, "just the right amount of text" which will depend on your tastes.

Java is much heavier to read because of all the boilerplate. And it may have lambda but for example the stream implementation sucks compared to the elegance of LINQ. They had 8 years to make it right and I’m still amazed how did they manage to implement it so badly...

Yeah... the bigger reason to move away from Java isn't Getters and Setters...

The bigger reason is one word: Oracle

Whether you go towards C# or other companies... Oracle is a horrible company.

Oracle is only one player in the Java ecosystem. OpenJDK owns just about everything now, and most organizations are going to get support somewhere besides Oracle. There's been some good recent innovation with Java, and I think it'll continue due to the new accelerated release schedule.

That reminds me, I want to experiment some with AOT compilation and also the new GC plugins.

lambda's are much more limited in flexibility when compared with linq. Because of the way java lambda's work, I imagine there are some scenarios where they are more performant, but it probably comes down to the specific problem/usage.

If you want to be on the JVM I highly recommend giving Kotlin a look before Java. Great language and excellent tooling.

I would go so far as to argue that Kotlin is the JVM's real equivalent to C#. The syntax is different, but language semantics are much more similar.

I would like to learn Kotlin, but I've no prior knowledge about Java... That's a real impediment?

If it isn't, do you know (by chance) about some resource(s) for a total newbie/newcomer to the language?

thanks in advance.

I'd say a rudimentary knowledge of the Java ecosystem is required, Maven or Gradle are the preferred deps management and build tools. It's a bit of a bummer as quite a bit of 3rd party docs assume you have already written things in Java, and gloss over things like, importing a library. For someone who doesn't have a magic importer (or worse yet, someone who is not using an IDE), you'll literally have to dig around in API docs just to figure out what comes from where (I'm looking RIGHT AT YOU Vertx!!)

Overall, the language feels pretty nice though.

I don't think lack of other JVM knowledge will be a big impediment, but it might be a small annoyance bootstrapping a project (e.g. how to do dep mgmt) and debugging (how to read a stack trace).

jetbrains is doing a very good job of creating good error messages, but just like any other jvm language, you can run into huge, messy, jvm stacktraces. In my experience, Java/jvm proficiency is useful

We're using .NET Core 2.1 in prod on Linux Docker containers. One of our production services that gets 2-3 requests per second on average (not a ton of traffic, but a legit prod workload) uses between 78 and 90 MB of RAM.

If you're worried about memory usage, then neither is great (C# is a little better than Java), you may want to look into Go or Rust.

In this list we also have D and Swift. Good on yr mem, general purpose-y (Go is not a GP lang), quite popular.

> quite popular

Disagree, especially on the same level as the others with D, and especially concerning cross-platform ecosystem with Swift.

I'm curious: what was the problem with Go?

The domain experts all write C#, and I don’t have strong language preferences, so it’s easier for me to switch to C# than it is for them to switch to Go. There isn’t a real technology reason, it’s just team ergonomics.

And that is very smart decision making. Professional!

I'd be curious too, but one place might be cross-platform easy runtime shared library use. Go with non-Windows "plugins", or poor c-shared support w/ crappy Cgo that doesn't even work with MSVC, is very bad in this area. Of course I watch all the GitHub issues addressing these with hope, but it's clear this story in Go is terrible.

I want to like .Net Core, I really do. But in my opinion its just not yet ready for serious use.

An example. If you want to use .Net Core you can't use entity framework, you have to use EF Core, which doesn't yet support mapping to views or stored procs, only tables.

Now you might think that's fine, maybe you only want to map to tables. But it's the same story all over the ecosystem. Many major projects have a separate netfx and core package, and many times the core package has restricted functionality. You will almost certainly find a whole host of things you need are missing.

And then you get the fact that ASP.Net Core is dropping support for .Netfx in the next release, so if you want to use ASP.net Core you are now limited to EF core too, which means you are making a full jump and can't just go halfway first. And .netfx is now not going to support .net standard 2.1.

The list of incompatibilities and restrictions just goes on and on. I certainly can't keep the full list in my head. So right now I'm not really willing to commit to a new project of any significance on .net core because I know there will be dozens of missing dependencies or features.

You could argue this is just want it's like at the cutting edge, and the gaps will be filled in time. But .netfx is clearly already going into maintenance mode, so the push to move to .net core has already started.

We use .NET core in production and are very happy. A mixture of EF Core (for ad-hoc queries) and Dapper (for stored procs) works just fine. Also, new in EF Core 2.1, you can map views and stored procs just fine: https://docs.microsoft.com/en-us/ef/core/modeling/query-type....

That's your only specific example - what other functionality are you missing?

You're not willing to commit to .NET core but you admit that NetFx is going into maintenance mode?

Yes, totally agree- I worked on a project that wasn't Core but regular MVC + EF and Dapper which surprisingly worked out well. Actually so well I started mentioning it as a feature but really was just too lazy to redo all the dapper stuff since it worked so well.

Because it is cross platform and isn't really used cross platform it is a pain in the arse.

SQL Aliases don't work. So people have to put in registry hacks into C# code (YAY back to 2002).

Loads of missing functionality (e.g. GeneratePassword is missing in aspnet core).

It is just incomplete. .NET 1.0 was more together than ASP.NET core and that was in 2002.

We've lost loads of functionality in the spurious benefit of it running on multiple platforms. I was developing ASP.NET on Linux 5 years ago.

It is more churn and burn for the small amount of devs that use dotnet without Windows.

I'm working on a fairly complex e-commerce platform built on .Net Core, I'm really happy with it. We use EF core too.

It's a pretty serious project, and for us, the benefits of our developers being able to natively develop on Macbooks and being able to deploy to Linux containers outweighs missing features.

Swings and roundabouts...

Which IDE are you guys using?

The Windows guys are using VS Professional, I'm mostly using VS Community, though I've dabbled with Rider a bit. If I was starting out with zero VS experience I'd probably go for Rider, but I'm so used to VS I use that, even though Community isn't as good as Professional.

Maybe you will find that rolling a little of your own code instead of depending on libraries as much is less hard than you imagined and has some nice benefits?

EF isn't a necessity, many shops prefer not to use it at all.

Core is the future so if one wants to keep using .NET at all they should find a way or switch to something else.

.NET Core is the future just like moving on from COBOL and FORTRAN was the move 30+ years ago, eh?

> you have to use EF Core, which doesn't yet support mapping to views or stored procs, only tables.

At least this one is not true: https://docs.microsoft.com/en-us/ef/core/modeling/query-type...

You said it better (and nicer) than I could have. You can extend this to .NET Standard. I mean, I love .NET. You can have Rust and functional programming and whatever else. .NET gets the job done pretty much all of the time for me. But when you reach for simple file system access or System.Drawing and they aren't available it makes you wonder how they are on version 2. That's pre-alpha if you ask me.

Again, I think C# is a great language. I just feel a bit decieved about what .NET Core and .NET Standard are capable of. If the version number matched the capability I would probably be excited.

We utilize EF Core on a fairly large project and have had zero issues mapping to views. I doubt there are issues at this point with SPs either though I haven't personally done that.

EF Core has a lot of work that needs to be done (and features brought over) but for a lot of use cases, it works just dandy. I don't disagree with your comments about incompatibilities and restrictions - just wanted to set the record straight.

We've been a .net house for a decade, but we're moving away from .net and Core is a large part of it.

Everything is so low level and so unproductive it's silly, and the only redeeming features was how well it integrated into the windows setting. But now with 3.0 they're removing every non-core library, meaning, it's really not a good choice.

I'm sure it's fast, but if it takes longer to build and deploy, then it really doesn't matter to me. We can buy more iron a lot cheaper than we can buy more development hours after all.

And I agree that it's not ready, I wanted to do a quick hobby thing on my Mac, and despite the development environment working well with VSC (as good as regular visual studio really) it's just terrible to run. .net watch breaks on Mojave, and despite issues on the GitHub there isn't a real fix in sight.

Needing to reboot every-time you stop your development server for it to free the .net resource correctly is just silly.

And that's not to speak on entity. If you've ever tried Django and migrations you'll probably never work with entity again and not hate it. In face, entity is unproductive we've stuck with LinqToSql for a long while, yes I know it's slower, but who cares if I save enough development hours to pay for a thousand years of server time?

EF will be available in netcore 3.

The word you are missing is partially.

It is still not clear if the design tooling will be migrated and DB drivers also need to run on .NET Core.

Isn't that (EF6, I mean) only on Windows, though?

Funny, I tried .NET Core with EF at a Hackathon and thought EF really went a long way. Had no idea about the restrictions, thanks for the heads up.

Btw, we use .NET core in prod, but we have weird DB access through a third party API, so I didn't need to think about data mapping.

I don't think I can express exactly how wrong you are.

.NET Core and F# are the only reasons why I still develop .NET. I really hope the platform can break out of the Microsoft silo and attract talent from other dev communities, because the biggest problem with .NET Core, despite the whole OSS move, is still that the majority of C# developers let themselves happily trap by the Microsoft marketing machinery. The average .NET developer never even tries different things like AWS or the Google Cloud, TravisCI or AppVeyor, etc. They just swallow anything which so-called MVPs and conference presenters force them down the throat, primarily Azure which is by all measures inferior to the other two and they don't even know.

Visual Studio is littered with SQL server and Azure tools which doesn't even make sense. Either offer equal tools for all major tech or none, but this subconscious constant selling of their own tools sickens me slowly.

I'm not sure I agree that AWS and GCP are clearly better than Azure - but I'm not been neck deep in all three so I cannot definitively say so. But Azure is moving fast.

> Visual Studio is littered with SQL server and Azure tools which doesn't even make sense. Either offer equal tools for all major tech or none, but this subconscious constant selling of their own tools sickens me slowly.

Of course they support their own tools, but you don't have to use Visual Studio, you can use VS Code if you like. But I can understand why people like Visual Studio - live unit testing alone is reason enough to use it.

Just have to point out that I live by 'dotnet watch test' (F# FTW) along with VSCode's built-in console window, and while it does not include the line-by-line indication of lines affected by loading or failing tests, it does work out of the box, for free, and is cross-platform. (running dotnet core, to be clear)

Live unit testing is great, assuming your company pay for the Enterprise edition which is the only one which has it.

(Mine doesn't).

Resharper has it for a fraction of the price.

I really like ReSharper, and I've bought it for my team, but it often makes VS crawl like the PC was a budget model from 2000. They must address this sooner or later.

I just cut out the middleman and use their Rider IDE. It doesn't seem to bring my whole PC to grinding halt and is built on top of ReSharper. It's worth a try if you haven't checked it out already.

I'd be surprised if many organisations pay the full price for Visual Studio Enterprise - certainly a former employer of mine (a pretty large company) didn't pay anything like the list price for any of the MS development tools.

Let's say they get it at an 80% discount. VS Enterprise apparently is now available only though a cloud subscription worth ~$3000 per year so it would still be ~$600. Resharper is $299/$239/$179 (1st/2nd/3rd year).

And this is a scenario where your company can get an 80% discount (not sure this is doable) plus Resharper has a perpetual license you can keep after 1 year, just without updates.

It was a big multinational - that kind of money was literally a rounding error.

It might be a rounding error, but none the less, if they negotiate a reduced price, that would literally pay the cost of hiring a person whose only job is to do just that.

You get a little more than just VS with that subscription... Access to dev/test pricing in azure and all the software to test on is huge. Plus whatever else...

Check out NCrunch. It's an inexpensive add-on which does this specifically.

We're Silver Partners for that reason alone, granted it only provides 5 licenses, but one license cost more than the fee of being Silver Partner.

> The average .NET developer never even tries different things like AWS or the Google Cloud, TravisCI or AppVeyor, etc. They just swallow anything which so-called MVPs and conference presenters force them down the throat, primarily Azure which is by all measures inferior to the other two and they don't even know.

I've made an account because this attitude irritates me.

1. This is patently untrue. The real reason is that a large number of developers simply have more important things to do (friends / family / children etc) than learning whatever is considered in fashion. Scott Hanselman even has a name for these developers "Dark Matter Developers".


If you have 10 years of experience working with .NET and all the parts that normally come with it, it makes more sense to keep within the ecosystem and keep up with the changes in the tooling if you want to stay up to date. There isn't much benefit for most people to look outside of it.

I've personally got sick of things changing every 3 months and build almost everything exclusively using full fat .NET because I know it isn't going to be gutted and changed in 6 months time unlike .NET core. It has also 16 years worth of development and documentation behind it. I don't need to spend half a day trawling through stack overflow posts.

2. Most software that is built in .NET is intranet software that will never be seen by the public. It is most likely hosted in a server rack in the basement. Almost 90% of the problems when developing in these places is internal politics, poor IT infrastructure spending and abhorrent legacy code. I could probably list another hundred common problems.

> Visual Studio is littered with SQL server and Azure tools which doesn't even make sense. Either offer equal tools for all major tech or none, but this subconscious constant selling of their own tools sickens me slowly.

The whole point of VS is that you shouldn't have to go outside of the IDE very often. Thus why wouldn't Microsoft offer tight integration. If you don't want to see the tooling, remove it from your VS installation or use one of the many alternatives now (Rider, VS Code or setup your editor with Omnisharp).

I do agree that the person you replied to was unnecessarily cynical (and quite irrational -- there is nothing surprising that Microsoft pitches Microsoft services in their own products), but your reply is contradictory.

I've worked in a variety of shops, both "Microsoft" shops and non-Microsoft shops, and I would most certainly agree with the GP That Microsoft shops tend to be dominated by developers who like the comfort of just eating whatever pablum Microsoft is serving, often even if that pablum will take years longer to digest than competitive alternatives. There is, in general, a tunnel vision that profoundly limits the options available to build solutions, at substantial project cost.

And it's understandable. If you're at a Microsoft shop you aren't going to challenge the norm if your first choice is SQL Server and BizTalk and Azure, etc. It's the easy, laziest option. Occasionally it might be the best option, but that's just accidental given that the choice was predetermined.

For what value of "best?" In the majority of cases, "best" is what gets the product shipping fastest. Not memory usage, not performance, not coolness. Just getting in the hands of the guys in the warehouse who are wasting time using spreadsheets, etc. The "easy, laziest option" is what gets you from 0 to full speed first.

That's what Microsoft's core customer base cares about.

> I've worked in a variety of shops, both "Microsoft" shops and non-Microsoft shops, and I would most certainly agree with the GP That Microsoft shops tend to be dominated by developers who like the comfort of just eating whatever pablum Microsoft is serving, often even if that pablum will take years longer to digest than competitive alternatives. There is, in general, a tunnel vision that profoundly limits the options available to build solutions, at substantial project cost.

I dunno about this. The vast majority of costs in any project is contractors / staff rather than licenses.

I added up the cost of hiring 3 contractors for a month versus just buying a piece of software that did 90% of what the business needed. We were much more expensive.

> And it's understandable. If you're at a Microsoft shop you aren't going to challenge the norm if your first choice is SQL Server and BizTalk and Azure, etc. It's the easy, laziest option. Occasionally it might be the best option, but that's just accidental given that the choice was predetermined.

It is also kinda counter-productive for everyone else. If everyone knows how to do something in a particular language + IDE it makes things easy because knowledge can be shared without a steep learning curve.

e.g. I write lots of scripts using python, I mainly work in .NET shops.

I left instructions for the whole process on how to get the script to run for an adhoc support job I wrote 5 or 6 years ago. For whatever reason it broke (the db structure changed slightly). I have been in a lot of contracts since that job and it was just cheaper for them to call me up and pay me to fix the script than have one of their devs look at it.

The only reason I wrote it in python at the time was because I didn't know Powershell at the time and they said I could use what I wanted as long as it was documented.

This is a bit off-topic, but on another occasion, Scott Hanselman infamously used the term "5:01 developers" targetted at many of the same people ;)

Do you have a reference for that?

Here: https://www.hanselman.com/blog/501DevelopersFamilyAndExcitem...

I'm not sure if that is the original post.

There was a bit of backlash against it, someone even published a 5:01 Manifesto, but that site is not maintained any more :D

Scott Hanselman is a workaholic. He is also very evasive at answering questions directly if it isn't politically expedient. I have noticed this both in a few email correspondences I've personally had with him and through his comments on his website. I quite like how he explains things and I do think he is a good dude.

Hanselman is also one of those developers that can bang code out 24/7. I've met them. They can get a lot of stuff done, however there is usually someone like me that is picking up the pieces left behind.

Recently I worked with one and he banged out an MVC project, commented out all the tests I wrote after he changed the API I wrote and then went on holiday to Greece for several weeks and then was moved onto another project. Guess who had to clean up the mess ...

TBH I worked in high stress environments (gambling and finance). Management didn't care that I would work to 7-8pm most evenings (9pm start) and do a few all nighters. A few times I was like 30 minutes late twice in a row I would get called in for a talk about "tardiness". I was younger at the time and I thought they would cut me a bit of slack after delivering the impossible on time!!

After a while you realise that it isn't worth the effort and just get a contract job where you earn twice as much and have none of the bullshit.

If you deliver the impossible on time, they'll just ask for the even more impossible next time...

I think that's unnecessarily angry at Microsoft. Of course they have to sell something. They offer some great tools for free (as in free speech) and you still complain that their MVPs promote their own paid services at their conferences?

IMO the issue isn't MS, really (though parts of the org are still worthy of strong skepticism), it's the cultural phenomenon of a certain generation of developers who essentially eat, breathe, and die by Microsofts product cycles...

There are those argued that any innovation is unneccesary until MS launches a product for it, when it becomes a "must", ad nauseum. I'm talking about the developers who never discovered ORMs until MS pushed theirs, who let their products languish for years waiting for MS to address issues, and move lock-step with them on all fronts.... You've seen major motion with "Alt.NET" groups, and some pretty major internal revolutions based on the displeasure of community technical leaders (and their willingness/needs to hop off of MS solutions), that stem from this dissonence.

It can create some cross-purposes in their tooling when they're aiming at conservative C#'ers who want a unified MS experience and look at no other technical sources... Especially for the Enterprise devs, cloud-native architect, and cross-platform engineers who have clear needs that don't jive with those assumptions.

F# and .Net Core are the only reasons I'm still on their stack. It's a dream to work with, and addresses critical issues of cloud and distributed engineering that previously would have excluded MS and .Net from the discussion. Particularly with scalable cloud systems, OS licensing fees are often show stoppers for NGOs, non-profits, academics, and researchers

> IMO the issue isn't MS, really (though parts of the org are still worthy of strong skepticism), it's the cultural phenomenon of a certain generation of developers who essentially eat, breathe, and die by Microsofts product cycles...

Although to be fair, they were taught this by Microsoft. Before Microsoft saw the writing on the wall and changed approach not that many years ago, the strategy was to provide a Microsoft solution for everything. Useful stuff from outside Microsoft would be either be cloned, or MS would simply not implement compatibility or integration.

The .NET ecosystem was, and still is, utter dominated by Microsoft at every level, unlike Java where multiple vendors provide implementations, innovations, certification etc. It's a bit unfair to blame the developers in the ecosystem for not pushing back hard enough against the organization that provided literally everything, from the software licenses to the professional certifications.

I'm talking about the developers who never discovered ORMs until MS pushed theirs

Because every ORM sucks outside of the ones built on top of Linq.

Linq is great because it makes a query language a first class citizen and it decouples writing the query and the implementation.

In all fairness, you should consider Entity Framework, not Linq, when speaking about ORMs. And the first versions of EF sucked compared to the others frameworks that were available at the time.

It’s not just about EF. The beauty of C# and Linq is:

Linq => expression trees => provider => native query language of data source => data source.

Written correctly, you can pass expressions around like:

repo.Find(c => c.age > 65 && c.gender == “male”)

And the expression can be interpreted at runtime by either EF creating native sql or the Mongo driver creating a native MongoQuery or even an in memory List for unit testing.

No matter how good another ORM may be for another language, what made C#s implementation better was Linq + expression trees.

Except EF is basically the only provider that works 100% robustly. I have some pretty bad memories of getting NHibernate's Linq provider to work correctly, since it would just randomly mistranslate queries or flat-out throw exceptions.

As someone who has switched almost entirely away from .net to go, this is absolutely untrue. I'm fairly certain the issue was PEBKAC

The Mongo Linq driver is excellent. It’s not exactly an ORM, but it does let you work with strongly type collections and the queries it produces are pretty good.

There was also another Linq/ORM I used back in the day for Postgres. I can’t remember the name of it.

Well Visual Studio is certainly not free (maybe the community edition) and therefore I don't think I deserve to be littered with Azure ads all over a tool which costs already a lot of money.

However, my main complaint is not that they advertise their own products, which is absolutely fine, but the way how it is done is starving the .NET community from anything else but Microsoft. The way how all their .NET products are extremely tightly linked to a point where wanting to use something else but Azure or VSTS becomes almost unnaturally difficult, which is what I really dislike. For example, if I look at a nodejs product then I see documentation for all various integration points, with AWS, GC, Azure, etc., but when I look at a Microsoft library there is no documentation or integration points out of the box but Azure and that has a ripple effect on the rest of the community. Every library author only builds their tools optimised for Azure and don't even think about what else there is, which is quite upsetting.

I don't think this issue is unique to MS, but thanks to their historical business markets (Office, small-to-medium businesses), and product portfolio the sense is that many Azure services are spider-webs of related products. That feeling that you can't just use a component in isolation, but that other tightly bound products are often the only way to serve reasonable services.

They've made substantial efforts and improvements, so credit where credit is due. I think the broader .Net community needs to pull their thumbs out and take a hard look at why C# OSS has struggled the way it has, and how the ecosystem should be maturing.

The cross-platform, OSS-friendly, orientation of the F# community has been much more reflective of my technical concerns, platforms, desires, and predelictions.

Github was one of the best integrated services in VS even before ms bought it. But that's beside the point- the point is this: it's on Google and Amazon to make the development story good for their platforms.

So Google and Amazon should be scrambling to perfect the deployment plugins for VS. True, microsoft is SELLING (some editions of) VS - but there I'm sure they weigh both demand from customers AND the potential earnings. If AWS and Azure features are equally in demand, of course they will focus on their Azure features first because they have benfits for Ms.

Why look at Microsoft documentation then? AWS provides excellent documentation and plug ins for Visual Studio.

I use git inside VS, it's fine, I've a few minor quibbles, but all the GUI git tools I've used are a bit shit (tortoisegit, GitHub for Windows).

The built in support for GitHub is fine, so you can stop moaning about VSTS.

Also, you don't have to use azure or SQL server. You can close those tools and, poof, it's done.

One of the more ironic things is that there's a growing dissatisfaction with MS precisely because they're making it more flexible.

Lots of people just want stuff that works with no config, no mucking around with command line tools.

That MS are proudly going 'run dotnet blah' is actually, in a lot of ways, a bad thing. Why can't I just click a button, and why clutter tutorials with lots of pointless command lines?

The 'no hassle, no fucking around with shitty console tools' programming alternative is going away.

So you want other cloud providers to be a checkbox in the installation rather than a checkbox under extensions and you want to copy the documentation from other cloud providers onto msdn?

That's a pretty easy ask.

> I really hope the platform can break out of the Microsoft silo and attract talent from other dev communities

The problem is often trust. Like so many Microsoft projects, to me the goal of .Net Core seems to be to get as much people as possible on to a proprietary language and/or get as many devs as possible onto developing stuff that doesn't hurt Microsoft. There's no guarantee that MS will not pull the plug at some point, and then soon after that .Net and .Net Core will start to diverge, and MS will lure in as much devs as possible with proprietary functionality that everybody wants but is only in .Net, not in Core. Or they'll just pull the plug because of whatever reason, like they did with Silverlight and Xamarin.

Don't get me wrong, I kinda like C#. But right now .Net Core feels like it's been developed by Microsoft, not like it's open source. I'm not entirely sure but is looks like the community developing .Net Core is made up almost exclusively of MS people.

If you listen to some of the DotNet Rocks podcasts around when they started open sourceing so many things, some of the higher ups like ScottGu and Scott Hanselman talk about this issue of trust. They said to the effect that they understood the lack of trust and intended to earn it. I really believe the old guard is gone and there is a core group there that is 100% dedicated to open source.

I looked for the stat to back this up, but I believe either AspCore or NetCore was one of the most active in terms of community pull requests for a while. I mean first, there is the sense that it _is_ open. If they do anything too evil, take it and fork it. You may say that is a huge undertaking, which leads to my second point:

In my day to day I don’t have time to contribute much to such a large project. Having the backing of a large company does present some issues, but it also lends some stability you need for a large project. This isn’t some mall pet project that takes off and fizzles. I feel the same way about Angular- I don’t like some of what they do- I prefer Vue- but can be confident it’s not _going away_ soon because Google backs it. In the case of .NET Core, though, even more so since it’s such a large part of core operations. So while even more community support would be nice, from a standpoint of trusting the product, it’s enough that it’s open source and the process is transparent even if dev hours are paid for by MS.

In the end, I think some distrust is valid, but some of it is kneejerk reaction to old MICROSOFT that is gone now.

> But right now .Net Core feels like it's been developed by Microsoft, not like it's open source

This is my biggest reason for losing enthusiasm for .Net Core. Despite all the noise about open sourcing the development on GitHub, it still feels like Microsoft treats .Net like a Microsoft platform, not an open platform. And I'm not talking about Windows vs Linux. More that the design direction for .Net seems to be largely set by internal Microsoft politics. For example, the recent ASP.NET Core running on .Net Core vs .Net Standard decision seems to be driven by how tightly tied the .Net Core runtime is to its underlying OS.

Compare to Java with the JCP (because Java is often compared to C#). The JCP is far from perfect (e.g. all the drama with modules). But, regardless of my views of Oracle, when I'm using Java I don't worry as much that I'm tying the long-term stability of my tech stack to the whims of a single company (even with the new JDK licensing snafu).

On a side note, I'm really confused when I see people talk about how great the new tooling is. Sure, the dotnet CLI tool does more out of the box. But it still can get hairy very fast because of all the design baggage it inherited and shoved under the covers with the fancy new SDK abstraction. And Microsoft keeps cramming more and more complexity into NuGet which makes it a pain to integrate with third-party tooling.

Lastly, for the record, this isn't an anti-Microsoft rant. I think they've done a lot of great work with .Net Core---the standard library updates, cross-platform runtime, Roslyn---and I still am very productive writing .Net for my day job. Like I said, I've just lost my enthusiasm.

Also why I don't see .NET Core going anywhere, it's controlled by the same old Microsoft who have a massive conflict of interest for directing everyone to use their preferred libraries and services. Unlike every other popular language which is typically developed with a transparent independent governance model whose direction benefit all libraries and services equally, instead of giving their own preferential treatment.

A good language is only part of what makes it appealing, having a large diverse open community is often more important as it ensures mature bindings are quickly available for new technologies and 3rd party API's, it influences whether the language will be used to create new technologies (instead of just playing catch up and making clones of what's in other languages), whether libraries are able to succeed on merit so it doesn't discourage the community to invest in developing a variety of competitive options and whether there will be an active community available to quickly answer questions and resolve issues.

.NET Core will never have the community of other popular languages, unless you're happy to use Azure and want to be locked into using Microsoft technologies there are much better platforms to risk your business on instead of committing to one whose future is controlled by self-serving interests.

Using .net core, or even framework on other cloud providers is easy enough. .NET Framework is tied to a Windows environment, but core isn't.

I don't get all this hate against Microsoft because they suggest or prefer things they worked on as solutions, without actually tieing you to them. Do you work on software for years and then tell everyone to use something else?

If it was actually tied to their other services then I could see the reason to avoid it, but if using .net core without windows, azure, or sql server then I dony see how you are actually tied to it

They still could have created a runtime where all libraries and services are able to compete and succeed on merit and basically how every other popular language evolves. If they want to give special first-class treatment to their libraries and services that's their prerogative, just don't expect for others to be investing in a biased runtime with conflicting interests where alternatives exist as 2nd class citizens limiting them to smaller niche communities and why it will never have the community of other popular languages.

Unless you want to be locked into a future centred around using Azure and Microsoft technologies, there are better, more open vendor-neutral languages with more diverse and mature libraries you could be building on.

I see that as a very negative viewpoint. For many, it's an easily embraced negativity because it's Microsoft.

Objectively, MS simply has done more work to create a comprehensive package. It would be a disservice to their customers to not increase integration between it all. For the longest time, this was Active Directory. Today it's Azure and .Net. Amazon doesn't control one of the most popular programming platforms to do tighter integration than already exists. Oracle does, but I've never really heard much about their cloud offering.

Microsoft has all the pieces, either it's appreciated or you can resent it. But they are no longer forcing you to use it, it's being sold on merit and I like what I see.

Microsoft just announced that .Net Framework is in maintenance mode. The future is .Net Core.

Over half of the VMs running on Azure are Linux. Microsoft knows that the future is not selling Windows licenses.

Sorry, could you please link to the announcement?

Agree about the Windows licenses.

> to get as much people as possible on to a proprietary language

The C# compiler (Roslyn) is completely free and open source, as are a number of .NET components: CoreFX - Core foundational libraries, CoreCLR - runtime.

As well as PowerShell, VS Code, Typescript, ASP.NET Core, MVC, Blazor, F#, Z3 Theorem Prover, etc.

And that's from just the first few pages of their Open Source page: https://opensource.microsoft.com/

Microsoft just recently commited them selfs more to .Net Core and it looks like it will replace .Net Framework in a not to distant future https://github.com/aspnet/AspNetCore/issues/3753

Yes, .Net Framework itself will evolve very slow. New features will be added to .Net Core Only.

It isn't a proprietary language. Anyone can implement the language spec.

Do you people do any basic research, you know just googling or reading the license?

> Anyone can implement the language spec.

No. So far, only Microsoft has implemented the language spec and as long as no one else does it, no one can. Prove to me that "anyone can implement it" by pointing to someone who has done it, instead of relying on some theoretical "it could be done" fantasy.

The amount of effort, time, energy needed is just not something anybody else outside of MS is able or willing to put into implementing the language spec.

You mean, google it for you? Ok


At least 3 serious, large scale long term non-Microsoft implementations.

Or something like https://github.com/SandipKumar05/C-sharp-Compiler and then you can argue that if it only implements a tiny part of the spec it doesn’t count and that proves it’s a Microsoft conspiracy?

Okay, let's go through that list:

Visual C# is Microsoft.

Visual C# Express is Microsoft.

Mono -> Xamarin is now Microsoft.

Portable.NET -> Dot Gnu Project, has been decommissioned 11 years ago.

SharpDevelop -> IC#Code Team, project will be/has already been decommissioned, see [0].

Roslyn -> .NET Foundation, which was written by Microsoft, and is currently maintained (according to [1]) primarily by people working at Microsoft.

That last repo you posted is of course nice but like you said, it's tiny, doesn't even support arrays and is undocumented. Seems more like a assignment for a compiler building course. Like it though.

So, thanks for making me do some googling on this, but it just proved my point.

[0] https://github.com/icsharpcode/SharpDevelop/issues/799#issue...

[1] https://github.com/dotnet/roslyn/pulse

I think he proved you wrong, while there were many, the only example necessary is Mono. That lived alone, untouched by MS legal action or any other conspiracy theories about evil Microsoft, for many years. It was a great implementation, so great that Microsoft wanted it and those who built it received some good coin when they were brought onboard. Microsoft clearly has a track record of encouraging innovation on their (open) language spec.

Ximian and then Xamarin implemented it with Mono.

Yes I am sure that it takes a lot of time, but anyone who is willing and able can do it there is no-one stopping anyone from doing it.

The spec is open, the source code for pretty much everything is now open and is sitting on github, it has been ported to MacOS, iOS and Linux and it runs on both x86 and ARM what more do you people want?

Why should I try AWS and pay twice the price I pay in any traditional hosting provider? Don't drink the HN koolaid and thing that trying the latest and greatest will give you any real benefit. The good thing about .NET or Java or any of these seemingly uncool technologies is that they're tried and tested and work just fine.

The real problem with developing in .NET is Windows. Everything else is stellar. Hopefully at some point in the not so distant future Visual Studio will run on Linux and then we will all move to greener pastures.

1st million calls on lambda are free... then ~$1.80/million calls/month after that. No ops once you deploy... like none. Dotnet runs on it fine after being written on a Mac, with code completion and linq hints etc. No visual studio in site. I didn’t even install mono.

Your uncool technologies might be cooler than you think. ;)

Are you forgetting the API gateway charges? API gateway add’s $3.50 per million requests to the price.

Egress data as well?

You can already run VS Code on Linux. Or use emacs or vim and command line tools.

JetBrains have brought out a x-plat C# IDE also, called Rider. It's very nice.

> Visual Studio is littered with SQL server and Azure tools which doesn't even make sense. Either offer equal tools for all major tech or none.

It makes sense for them to offer tooling for their own services but that doesn’t mean they don't support other software / services as well as their own.

I can still use MariaDB with Entity Framework and push changes to the schema with update-database.

Visual Studio has extension support so 3rd party devs can add to it because MS might not be the best people to build the tool for a 3rd party, the 3rd party might just well be.

AWS provide an extension for managing AWS though Visual Studio called [0]AWS Toolkit which makes pushing code to lambda a breeze.

[0] https://aws.amazon.com/visualstudio/

primarily Azure which is by all measures inferior to the other two and they don't even know.

That's a really weird thing to say, by what measures do you mean? In terms of market share, they are AWS, then Azure, then a big gap, then Google. In terms of maturity of the managed services, it's Azure, then AWS, then Google. Google in particular has a lot of "tickbox" features just to say they have them but when you drill down they are far more basic than either Azure or AWS.

Visual Studio is littered with SQL server and Azure tools which doesn't even make sense

Why doesn't it make sense? I use those tools regularly! The VS team, using their own product to develop their product, is generally super responsive to the user community.

I would not call Azure managed services mature across the board. Some of them are excellent, others are broken in weird little ways.

The web portal is the best example, you can't use that with just one browser. Some things only works in Chrome, others are only broken in Chrome.

AWS offers excellent plugins for Visual Studio.


> Visual Studio is littered with SQL server and Azure tools which doesn't even make sense. Either offer equal tools for all major tech or none, but this subconscious constant selling of their own tools sickens me slowly.

VS works great with other tools (i.e Oracle Db tools) with the same level of integration ! The misconception is the problem, and MS should work on that ...

> Visual Studio is littered with SQL server and Azure tools which doesn't even make sense.

That's the reason I'm phasing out Visual Studio and phase in VSCode. I mess some features but it's a much more open and leaner tool.

> is still that the majority of C# developers let themselves happily trap by the Microsoft marketing machinery.

Or people choose what works for them? Or they have to deal with sunk costs?

> They just swallow anything which so-called MVPs and conference presenters force them down the throat, primarily Azure which is by all measures inferior to the other two and they don't even know.

Please get off that high horse of yours before you hurt yourself. Nobody is forcing anything down anyone's throat. Your argument is so petty. People go to microsoft-centric conferences and listen to MVPs for microsoft-centric products and talks. It's like you complaining that a linux conference or talk doesn't talk about windows products and hence are forcing inferior linux products down their throats. What do you expect when you go to a mysql conference? Talks about SQL Server?

> Visual Studio is littered with SQL server and Azure tools which doesn't even make sense.

A significant portion of windows development involves SQL Server and Azure interaction? You do realize that much of what is in Visual Studio is a result of customer surveys and usage data ( telemetrics )?

This is why I cringe at fanboyism. Whether it is F#, Ruby, Rust, etc. People get so irrational and consume by zealotry.

> This is why I cringe at fanboyism. Whether it is F#, Ruby, Rust, etc. People get so irrational and consume by zealotry.

Amen brother.

The post only mentions .NET Core, but should actually be mostly talking about ASP.NET Core that runs on top of .NET Core. The features such as dependency injection and Razor Pages are ASP.NET Core specific.

Microsoft have announced that they will be porting WinForms and WPF over to .NET Core so that they no longer need the heavyweight .NET Framework. However, this DOES NOT make WinForms/WPF cross-platform. They will still be restricted to Windows but will allow you the benefits of .NET Core, such as allowing side-by-side versioning.

Microsoft.Extensions.DependencyInjection is developed as a ASP.NET Core extension but has no dependency on it.


Indeed. It's possible and quite easy to use it in a console app for example

> ASP.NET Core that runs on top of .NET Core

Confusing, ASP.NET Core can actually also run on top of the Full .NET Framework right now, although it was announced this won't be a trend which will continue.

> features such as dependency injection

And DI isn't actually a feature limited to ASP.NET Core, .NET Core itself has DI "built-in".

> Microsoft have announced that they will be porting WinForms and WPF over to .NET Core so that they no longer need the heavyweight .NET Framework. However, this DOES NOT make WinForms/WPF cross-platform. They will still be restricted to Windows but will allow you the benefits of .NET Core, such as allowing side-by-side versioning.

They've come back full circle to forking Java for Windows only usage. .NET is the closest competitor to Java as it gets in terms of similar ideas, a VM, a bytecode for your VM, a C-like language to be compiled to said bytecode, and so on. .NET IMHO is the only serious alternative to Java and a damn good one at that, and I would dare say vice versa though I will always prefer .NET personally, I wouldn't mind Java at least.

What in the world ever happened to Xamarin? Weren't they acquired by Microsoft two years ago? I felt sure we'd have a nice cross-platform desktop GUI by now. . .

I'm feeling more fearful that they acquired Xamarin just to destroy it.

It's actively developed but there's no mature cross-platform UI (Xamarin.Forms is mostly mobile and has many issues). Using something like MvvmCross combined with native UIs on each platform is the best option for now.

The only use I ever saw of it by others was to make mobile apps for both Android and iOS so I think it will stay there worse case.

You can use the DI stuff without ASP.Net Core though?

Yes, you can. If you don't need anything fancy (in that case you are better off with autofac), then you can just add the nuget to your console app and start using it with a few lines of code.

to be fair autofac is not really needed in most projects.

you can even write a bunch of lines that will automatically register all your controller dependencies. (of course autofac makes this more simple). but I actually prefer explicit registration (i had the implicit variant on guice and as soon as the project was big, implicit is a mess).

There's also Scrutor (https://github.com/khellang/Scrutor) which makes assembly scanning and registering dependencies really easy too

One thing that makes .NET Core makes me special for me is PowerShell Core.

I have been coding quite a bit of PowerShell Cmdlet in C# lately, on Windows and Linux, and it's very nice that I can pass around .NET datatypes interactively, and in a script.

Powershell Core has allowed me to do 90% of the Office 365 administration I need to do from MacOS and has reduced my time in a Windows VM substantially.

Very happy that Microsoft is making this effort.

I just inherited a .Net core app that was a proof of concept. It's a real pot luck of glued together functionality. I remember working in MS ASP land almost 2 decades ago and I swore I wouldn't invest a single minute learning another proprietary MS technology.

I by and large held to that but here I sit, banging away at some C# code. This is day 3. Did you know if you specify a path in JSON and apply it to Use app.UseStaticFiles with a single trailing slash, instead of a double, it'll bring down the .Net kernel in flames.

Not confidence inspiring in the least.

You could replace .NET core in this comment with any $framework and see plenty examples of developers misusing a tool.

by and large, btw

Besides Node.js the main competitor is is Java/JVM. C# is a bit nicer than Java, but you can use Kotlin or Scala on the JVM. All in all I see no real advantage over the JVM/Java world - more of the other way around, since the .Net ecoystem is not as big as the JVM ecosystem. However competition is always good.

I've worked a lot with both C# and Java, and C# is so superior I never want to touch Java again. Especially since around C# 3.5, the distance between Java and C# has grown enormous. The two benefits I can see with Java is that it's a smaller language (easier to train junior engineers), and yes, the huge amounts of libraries.

Kotlin/Scala/Clojure are nice, but my experience is that just because an organization is working with Java, you shouldn't count on being able to work with some other JVM language. At my current job, we've been forced to give up on Clojure (a language I love) because the higher-ups have decided we should stick to Java.

I really hope especially Kotlin will gain more traction in the coming years, but in the meanwhile there is at least an order of magnitude more jobs in C# (where I live).

I hate dealing with checked exceptions in java.

> C# is a bit nicer than Java, but you can use Kotlin or Scala on the JVM.

With .Net you get F#

This needs to be brought up more. It's a huge bonus. F# is fantastic.

I recently scraped some job sites in various major metropolis areas in the US and aggregated the keywords I found. There was about 5 Java jobs for every one .NET job.

.NET and C#/F# are pleasant and I wouldn't be opposed to going back to them, but job-wise it seems safer to stick with tried and true Java.

It depends on how much better you think C# is but I think of this the other way around. You don't have to use Java anymore to get cross platform support, good performance and a stable and statically typed language.

Regarding things that might be better I think the linq support in dotnets collections is better than the streams support in java since java has kept more old collection libraries.

On an entirely superficial point, in case the author is reading:

> It offers developers modern tooling that can scaffold projects, build, run, test and deploy using incredibly easy-to-use CLI tools.

I think this is one place where the abbreviation CLI should be avoided, since it means two completely different things both of which are somewhat plausible here at first glance. "Command line interface" -- even though this is a Microsoft-derived thing, you can do everything using the command-line tools you're used to from Unix, node.js, etc.; "Common Language Infrastructure" -- even though this is happening on Mac and Linux as well as Windows, you can do everything using the Microsoft .NET tools you're used to from Windows. I'm pretty sure the first of these is the intended meaning, but I had to think about it.

Personally the biggest advantage .NET core has for my situation is that it creates a pool of programming talent and mindshare that I'd now be open to hiring and working with on projects that can now be made with open source tools in a sane environment.

I don't think it would be my go to choice for projects currently, but its an option I would happily consider and I give Microsoft a lot of credit for moving in this direction.

That being said so far the reasons I've had to look at it were modernizing older .NET projects and last I looked there were so many incompatibilities be between .NET core and .NET standard that the projects would have been almost complete re-writes, somewhat of nullifying its advantages against other choices, but that was a while ago.

For us, hiring .NET core developers is very hard. The pool of programming talent is gigantic, but it's also full of ultra-low quality developers. It has taken us almost half a year to find a decent C# .NET developer, with an average of 2 interviews per week on the best developers we could find. Meanwhile the previous developer had time to construct a behemonth of Java overengineering (Enterprise code they call it) that is taking us several months to tear down. We couldn't fire him because we didn't have a replacement, but in hindsight, firing him soon would have been better.

@alexmuro: best of luck finding quality in the pool of programming talent.

this seems odd. The main advantage other than going faster than Node ( which you'd expect ) is that it's cross platform and can run in containers and has libraries.....like MOST other languages.

Not knocking .NET Core, I use it a lot... but this just doesn't seem like it tells you what's special about it

I agree, they can do a better job articulating what is “awesome”.

For me personally, there are 3 main reasons that I have been super excited about .Net core:

1. It is C#, in my opinion the best statically typed language. The easiest way I have described it to other folks is it is Java++. Combine it with really good intelligence, and it is like the code “flows out of you”. Part of the reason for that is the effort put into the language itself (getters/setters, lambda functions, etc), but equally and possibly more important is the support of Microsoft, so this is a language/toolset that is being used daily to make itself better. (In my opinion this is why Jetbrains is so good, the developers use their own tools constantly).

2. It is cross platform from the ground up. I can’t understate how great it is to have an alternative to java

3. Rosleyn: being able to compile and potentially be as fast as C++

Just my 2 cents

> 3. Rosleyn: being able to compile and potentially be as fast as C++

Roslyn is the C#/VB compiler and analysis tool. Yes, that allows you to compile C#. No, it doesn't have anything to do with performance. That's where other things come in, like RyuJIT, or .NET Native.

For someone who is not well versed in MS world, what is the C# equivalent of the Java Streams API?

I had no idea what Java Streams was (a long time since I wrote much Java) and it appears to be the Java version of LINQ:


Java streams is the awful copy of LINQ, written something like 7 years later.

LINQ, the IEnumerable extension methods, and IQueryable extension methods.

I'd like to point out that the extension method feature of C# is one big reason why I like this whole story much better than the Streams API in Java. There are often methods I wish were part of the IEnumerable interface, and with extension methods, I can add them myself! (if they are not already provided in, say, MoreLinq [1]). Very convenient, and a big boost in productivity.


I would say IEnumerable<T> interface.

having a look at it, it seems like LINQ?

linq, kind of, but it has more run time overhead and is more flexible.

Sanely designed/mature libraries I might add. I went through an exercise to build a simple web app with Rust and ASP.NET/Core - I was mind boggled how mature the .NET Core stack/ASP.NET felt compared to pulling in 3rd party crates that are constantly in flux. Even after you're done fighting them the code still looks daunting compared to C# - there is a certain cleanliness to it.

Not criticizing Rust which is a very new and different language - I am just comparing it's current state to something as established as .NET now that it's cross platform.

The .NET ecosystem is a lot more mature than Rust's, there is no arguing that. As for code cleanliness, though, it's debatable. Rust has ADTs, Option, exhaustive pattern matching, Option and Result. C# doesn't.

C# has a 3rd party Option lib that works well. I use it heavily.

F# is probably a better competitor to Rust than C# though.

Which Option lib is that?

.net is not equal to c#. f# has all of that and a much cleaner syntax than rust.

isn’t f# a second class citizen in .net core ? last time i checked you still needed to install mono to get some sort of autocompletion on vscode. And all the official tutorials were still in C# only.

F# is a "second class citizen" for all .Net tooling from MS, as C# is more popular. Luckily it is a first class citizen in language capabilities, and is years ahead of C# on that front ;)

Ionide doesn't seem to require mono, ATM, for tooling in VS Code. VS Community Edition on the mac has autocomplete, full F# support (better than VS2017 in some areas), I think that might be cross-platform too (it might want Mono installed for other reasons, though).

The transition to .Net core has had some start-n-stop moments, and delays in core components that couldn't start until the framework was relatively mature. So on the fringes of tooling there have been some issues that had to wait for multiple dependencies to resolve. A delivers to B delivers to C delivers to D, and then we get a nice IDE.

Most MSDN documentation has parallel examples in C# and F#. There were offical F# tutorials, examples, demos, and templates at RTM, though the editor situation was grim due to the .Net Core project format wars. Those have since been resolved.

In general, though, the C# code from early tutorials will be relevant and easy to port as F# code is highly code-compatible with most normal C# code.

Ionide, the F# plugin for VSCode, added autocomplete via .NET Core about a year ago. Only thing you need mono for is the REPL, and that's being worked on.

If you're after Option or ADTs (Unions) for C#, I can heartily recommend https://github.com/mcintyre321/OneOf , it's brilliant.

But then I would say that ;)

C# 8 will introduce nullable reference types, which will effectively be equivalent to Options. And they are working on pattern matching (some simple, partial implementation is already in place AFAIK), though I don't know what will come of that.

There are a lot of .NET engineers who assume they can't use docker or run on Linux, and simultaneously a lot of other engineers who think if they build on .NET they'll be married to Windows or Azure. So I can see why the cross platform nature of it gets harped on a lot. Personally I think the strongest case for .NET is the C# language and associated tooling, but the only way to really appreciate that is to dive in.

I think it's because C# and (most of) its ecosystem is a joy to use compared to many languages that are popular with large corporations. Having that ecosystem and that particularly delightful language become cross platform is a welcome change, and also a welcome sign that Microsoft is willing to open up a bit more than many of us were expecting.

With the right kind of cross-compiler I believe that C# and shim libraries are a near-ideal way to handle javascript development...

You've got a strongly typed OOP langauge on top that is also pleasantly dynamic and anonymous when it wants to be, available through one of the best IDEs on the market, and it can compile to javascript that is remarkably similar to the original source. You preserve the well-optimized JS runtime for execution, but preserve a primo development experience that eliminates a lot of the pain of larger JS code-bases.

IMO "Typescript" should have just been a compiler variant for C# that was more scripting oriented with associated tooling.

That would have been/would be fantastic. I'd be all in on that.

Well.. I think some people might think "well I need to go faster than Node... so do I need to go to C? Java is slow too. But the C library ecosystem is _rough_...."

Nice infrastructure around the language + speed +... not being Rust (with all the difficulties that come with the language)? Is pretty interesting

>>some people might think "well I need to go faster than Node... so do I need to go to C? Java is slow too. But the C library ecosystem is _rough_...."<<

They would be utterly mistaken on all accounts.

That "all" makes for a bold claim.

"well I need to go faster than Node..."

.NET is generally faster than Node.js, at least based on most benchmarks I've seen.

" so do I need to go to C?"

Is there any other official/stable extension mechanism for Node?

"Java is slow too."

That one, I agree, is false. Java is at least as fast as .NET.

"But the C library ecosystem is _rough_...."

The C library ecosystem is very rough. The lack of memory management and the overall creakiness of C showing its age are easily apparent.

That would be a weird thing to think, because there's a long, long list of languages and platforms which are faster than Node but friendlier than C. Java and C#, two of the most popular languages in corporate development, being very much at the top of it (not necessarily in that order).

I wonder if it is the garbage collected language with the highest performance ceiling now?

Java might still be faster, and that's deliberate.

The goal of RyuJIT is understandable code and predictable machine code. HotSpot aims for performance at all costs. Many HotSpot features have been moving over to RyuJIT, even more are planned. I've always been envious of HotSpot. The main feature I've been envious of is its namesake: it aggressively optimizes hot spots. .Net now has this (tiered compilation), but it's still ultimately as-conservative as the compiler a few years back.

The hill that Java has to climb over is the extreme degree of "enterprise code." ASP.Net core is designed with the predictable performance profile of .Net in mind. Java has, well, this[1].

[1]: https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstac...

As of the latest versions of .net core, it's definitely faster than Java and it's not even a contest. Oracle is asleep at the while and the new version of Microsoft is pushing C# and .net much harder.


.NET Core now has a ton of memory/data layout control with ref, ref returns, span<t> and also has support for hardware intrinsics as well.

Even without the intrinsics C# is beating the JVM on the benchmark game already. Though I think those benchmarks may not all alllow hotspot to do its thing.

We are replacing out homegrown PHP ERP system with ASP.NET Core MVC since Version 1.0.

It is a blast to work with LINQ and Lambdas and I really miss it in other languages. EF Core also matures quickly and we sucesssfully connected it to mysql and sql server. So far there hasn't been a problem we couldn't solve in .Net Core.

For a small side project I used .Net Core Razor Pages very productively. Only needed the SDK and visual studio code. Planning on moving more small stuff away from python to .net core based on that.

Really looking forward to Version 3.0 and Kestrel replacing IIS for good.

If you intend to learn ASP.NET Core, check out my micro samples https://github.com/dodyg/practical-aspnetcore (171 samples so far).

.NET Core is special because it increases the portability of your .NET code in case your cloud provider decides to jack up costs by 15% for no reason other than you are locked in. cough cough

What about client-side apps? Is it possible to write a cross platform client app with .NET Core, a la Electron way? That would be my dream framework. I've been waiting for it for decades, seriously.

(I looked at Avalonia UI and mono/xwt. Not sure how stable/reliable they are.)

Check Lazarus, it's not c# but Object Pascal, but it's a decent IDE for developing cross-platform GUI programs, it's concept is from Delphi which was from Visual Basic.

Code editor, GUI designer, UI framework, runtime library, debugger, everything is included and it's being developed actively for nearly 2 decades.

At the moment there is Xamarin.Forms which actually can target osx,gdk and uwp or wpf. which means you actually can have a cross plat gui on all platforms, stability differs for each platform and I also did not like the mono runtime that much, a lot of stuff is not as good as it is in the .net core runtime.

This is the Electron demo using Blazor by Steve Sanderson. https://github.com/SteveSandersonMS/BlazorElectronExperiment...

Electron.NET does exactly that https://github.com/ElectronNET/Electron.NET

When I try to run a random .Net exe file with dotnet core it will complain about libhostpolicy.so dependency missing.

I understand that it is not supposed to run .exe files (no idea why, okay), but overall it sounds like awful usability.

I would say not being actually free and open source is a show stopper but I'm glad there's finally some progress. https://github.com/dotnet/source-build/issues/782

I don't get it. They rewrite the whole think from scratch and there's still code they can't show the source for... I have a feeling there is still push back inside Microsoft against Scott Guttrie and the open everything crowd.

Many of the features (Dependency injection, etc) seem only to be available for ASP.Net Core. What about cross platform desktop applications? Do we have a GUI layer that is cross platform as well?

Microsoft's offering here is Xamarin Forms. If you're an application developer that's probably enough and useful. Otherwise, given that Microsoft is now a cloud and services company there doesn't seem to be much of a push for cross-platform desktop applications. Personally I'm still hoping for Avalonia to be picked up officially, but perhaps that's just me liking WPF too much and hoping in vain.

Xamarin.Forms is cross platform (not only mobile, also desktop) while native look&feel. Don't use Electron.NET, that's a waste of CPU cycles.

My personal opinion is that people are sleeping on local HTML apps.

Local files, if you want, make everything lightning fast. Hosting your own web-browser lets you hook into whatever you want, and handle it however you want. A local server makes hosting whatever you want simple, too. There's a pre-existing plugin and component model for serving rich content... Every knows HTML and CSS, and sharding off chunks of the app to a genuine web app is straightforward...

A well factored, MVVM, WPF should be relatively easy to port to this model, and there are mature databinding libraries to handle the plumbing...

Maybe it's just me, but I'd rather take the pain points of a known technology than another 10 years of uncertainty and no cross-platform story.

It's probably less secure by default. Make sure to reject all HTTP requests where the Origin header doesn't match the local server host, or just all request with an Origin header.

What you really need is a shared secret between (embedded) browser and (local) server.

IP, host header, origin header can be checked as defense in depth, but can't prevent local privilege escalation from non browser clients and are quite fragile even in browsers.

(or use a secure non TCP/IP based communication channel)

> but can't prevent local privilege escalation from non browser clients

That is such a different threat model though. A native app has a lot more permissions than a web page. Trying to protect one native app from another is not really done much. Like, are MS Word documents encrypted so Slack can't read them from disk?

You can have multiple OS users on the same computer.

Oh, the dependency injection definitely works independently of ASP.NET Core - it's just something frequently talked about in tandem with it. Just wrote a console app that used it a couple of days ago.

I don't know about the current status of the GUI layer, other than that I've heard plans for WPF to be ported over to .NET Core. I don't know if or when that will actually happen.

Both WPF and WinForms will be part of .NET Core 3.0. They've done a few demos of it already, and were able to port over existing apps without any changes to the code. This even worked when using third party controls like the ones you can get from Telerik. They just added references to the Telerik .dll's they already had, and everything just worked.

They'll still only run on Windows, but it's a nice option for teams that want to move their existing apps over to .NET Core and take advantage of the quicker update cycle and improved performance.

Awesome, glad to hear it!

There are plans to bring WPF to .NET Core but it will still be windows only. It is being done because Microsoft wants to move all development to be on top of .NET Core.

Electron.NET should allow you to do that: https://github.com/ElectronNET/Electron.NET

Reads like an overenthusiastic sales piece posted here by the author to sell their own product.

I moved all my indie projects from .net to .net core, so i get the same development model i know and love, but can host on linux.

how hard is it to port an existing mono application to .net core for linux? does .net core run stable on linux ? I am thinking of a particular open source server application written for .net/mono: opensimulator.

> does .net core run stable on linux

it's probably more stable on linux than if you host in inside iis. hosting in iis is a pita btw. it's easier on windows to create a service and proxy it inside iis (if you need multiple different applications). however compared to just systemd+dotnet+nginx it's way harder to debug if something goes bogus.

> does .net core run stable on linux

Can't say that I've used in production on Linux, but everything I've seen so far for .NET Core on Linux seemed fine and .NET overall as a platform has been historically pretty solid. It would be strange if it would be really flaky in production with all the engineering resources Microsoft is pouring into it.

And despite all the hate, Microsoft does have great engineers and great engineering processes in most core teams (Windows, Office, .NET, Visual Studio). They're held down most of the time by legacy stuff, management and marketing, but that's a bigger discussion.

It's one of the few halfway modern "lightweight" languages with static typing and other full fledged OOP features.

I was working for a company that was making the switch from Nodejs to C#/.NET Core.

Having taught and worked 4 years professionally with Java I believed I'd make the switch to C# easily.

This was not the case. But not by lack of understanding C# or .NET Core.

Mainly .NET Core and C# felt like a few years back in time. A lot of boilerplate, configuration, and a lack of libraries/alternatives.

I don't necessarily need or want a full-bodied UoW ORM when designing a microservice. It felt like I was trying to practice DDD designed for a monolith; while many of the programmer practices of DDD feel cumbersome when designing a more minimal microservice. Even the concept of a "Controller" feels misplaced for a microservice; request handler functions seem more appropriate.

Some findings I had when I tried it:

- Model validation is very optimistic; casting JSON numbers to strings automatically and vice-versa. To me this feels completely unacceptable. I've never seen something as surprising with regards to validation. While there are ways around this that requires a lot of work and code. In the end I worked around this by parsing the JSON input using JSON Schemas and ignore .NET Core model validation completely.

- The JSON deserialization is a separate step before the model validation; throwing 500 errors if JSON is formatted improperly. If you want consistent error handling and more than just the basic error output across your entire application (deserialization, model validation, business rules, app errors, etc...); good luck. .NET Core makes it difficult to achieve that goal. Same here I used a JSON Schema parsing library to overcome most of my problems and completely ignore .NET Core out-of-the-box features.

- Entity Framework feels as defacto standard; where basic SQL would do in Node or Go. It's a difficult sell to your colleagues if you'd argue EF is redundant and overly complex for the task at hand.

- I first tried to write .NET Core in VS Code like I do Nodejs, Python and Golang. It worked, but I would recommend anyone to use either Visual Studio or Rider instead. The auto highlighting, code hints and refactor tools are just so much better using those tools. Also I frequently ended up deleting the *.sln files and recalculate them using the CLI tool using VS Code. VS Code support for C# + .NET Core is just not mature yet.

- To set an environment variable in Linux the convention is UPPER_CASE. C# / .NET Core uses UpperCase__Double__UnderScore. I know it's minor, but it just feels weird and out-of-touch with linux devops, probably due to a windows-first approach.

- Lack of a popular alternatives like Kotlin or Groovy that provide a more lean & mean approach to tackle simple tasks or build basic microservices. (I don't count F# which is more in the functional domain)

- No out-of-the-box support for measuring test coverage in Linux. Community alternatives are lacking.

- ...

I'm convinced .NET Core is a step forward for the C# community. I'm not convinced it's a step forward for others.

I had a very similar reaction. People complaining all the time about verbosity in Java and then when I look at C# there seems even more boilerplate ... it seems like even the most simple piece of code ends up nested 3 or 4 layers deep and preceeded by 3 qualifiers to declare a simple variable. As a completely random example:


And like you say, all the cited advantages of .NET Core just seem to be fixing things that were broken compared to Java.

Yet I completely acknowledge that there seem to be a huge number of people who really love it, and there are some clear technical advantages. And now that Microsoft seems to be genuinely (for now) no longer hostile to open source and mostly out of the patent-trolling business, I would be open to adopting it. But when I actually do try it, I don't experience the advantages that I thought I was going to.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact