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:

https://www.foreach.be/blog/java-and-net-comparing-streams-l...

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.

https://github.com/morelinq/MoreLINQ

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.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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