I also really like the Rails restful router which is strongly tied to its controllers.

I could go on. I really like that Rails gives me strong, opinionated conventions but also allows me to configure things to be liking if needed.

I want to love .net core - I really like F#. Any other rails dev out there make the transition to .net core?

They're worlds apart. Rails is optimized for day 1, .net core is optimized for day 1000.

Sure, that’s a standard argument for statically-typed kitchen-sink enterprise-marketed languages and platforms like Java/JVM and C#/.NET. But having come in to maintain things on day 1000 (or, in some cases 5000) for projects in such languages and, also, languages that are far less strict and have less features designed to require/support tooling, it's not been my experience that there's really that much of an advantage in practice.

Everything you mentioned can be done with some packages and a few lines of code, and the entire framework does have some opinionated conventions but with much more freedom than Rails. The fact that you can have MVC, Razor Pages, raw controllers, and Blazor all in the same app shows just how much freedom you have.

I think Microsoft is moving in the right direction though. Scott Hanselman has some .net core 101 videos out on Youtube that are good to get up and running.

ASP.NET MVC (which is now ASP.NET Core) is a fairly carbon copy ripoff of what rails was back then. Initially I was annoyed about this; there were efforts to run Ruby on .NET via IronRuby and thus get a nice rails-on-windows environment, and ASP.NET MVC came along and sucked all the wind out of that like a tent collapsing. Controllers, Views, Routing are all the same, and like rails can be reconfigured if you prefer.

Later on though, I’m happy with it. A new blank project doesn’t quite have all that stuff, but you can add the postgres driver, migrations, etc with a few lines of code.

You do lose out on all the more advanced Ruby meta-magic things that rails does like with_scope on ActiveRecord, but in exchange you get a 1000x performance boost, and static typing - especially now with null safety in C#8 is really helpful as your codebase grows. The productivity hit you take compared to rails is actually pretty minimal I think, and those other benefits outweigh that and some. I would chose ASP.NET core over rails for any web project at any time these days

Good luck!

I never got the point of Active Record amazement, having used similar teach like 5 years before Rails happened, we just weren't on Silicon Valley.

The default web template is far more spartan than what Rails provides out of the box. The workflow you're talking about can be done by installing packages and configuration (5-10min maximum for experienced .Net developers), and I'd wager good money on such a workflow being available as a "dotnet new" template.

What I found lacking (at the time) was specifically a better Webpack integration, similar to rails. Also I got used to having rspec, in net core world you have xUnit which is something like ruby TestUnit.

At the start I also found DependencyInjection a bit confusing and also the fact that in Aspnetcore the models/entities aren't like AR models where you have a bunch of validation/instance methods inside it. In .net you try to separate everything in repositories/validators/viewModels.

But yes, unlike Rails, .net won't have an opinionated way on how to do things.

All-in-all I'm quite satisfied with the experience. Though I will say that Rails is still a tad more "batteries included" type of thing.

Right now though, the dev ergonomics and productivity of .NET core are not actually very far behind rails at all, so you can serve your pages in 2ms instead of 200ms without suffering for it.

In some regards actually, perf helps a lot. Running a large bank of tests for example - those are going to complete a LOT more quickly in .NET which means you can iterate faster and have a better dev experience

The language stack is unmatched in terms of how quickly you can make a high-quality product across many different platforms.

I built an adtech platform doing millions of requests in 2010 in dotnet. Then I did it again doing billions of requests in 2012. Nothing else at the time other than java could come close with the same amount of effort.

But that is over with modern .NET Core. Nothing of above is valid anymore and the result is wicked fast as your link shows as evidence.

But yes, those tricks are now obsolete and the platform is incredibly fast.

I would recommend some early talks from Damian Edwards or David Fowler about ASP.NET Core. They are very explicit about that (in the end they build Katana replacing System.Web on .NET Framework to allow a better ASP.NET MVC performance, which lead to Project "K", which lead to (ASP).NET Core).

Speaking as one fanboy to another ;)

I always got the impression .net was never particularly performance focused: there were some bits you could use if you wanted to go a bit faster, but it doesn't seem designed from the ground up to be fast, and AoT compilation seems to be perpetually on the back-burner.

Compared to other languages like C++ or Rust, which have been built for speed...

Edit: changed my comment because it was a bit too argumentative.

AOT doesn't have anything to do with performance but helps with startup time and packaging. The .NET JIT now has tiered compilation with secondary passes that optimize hot methods with much more input about the environment, including knowing that it's a hot path. AOT can't do this.

C++ and Rust are faster because they don't have a managed runtime, and Rust's major innovation was moving as much of the memory management into a strong build-time analysis to ensure it's properly access. You can build low-allocation or more manual memory management with .NET and get very similar performance. RavenDB is an example of an fast document database built in .NET Core: https://ravendb.net/

Your comments are surprising since you seem to have experience F# and other languages and yet it sounds like you haven't used any modern .NET version.

Most of the stuff I've written in .net(core) has been in F# and C# (v8) and runtime v3.1. So much pain playing 20 questions with libs whose runtime requirements were thoroughly and widely distributed across all the runtime versions in a quest to get them to co-operate. I guess I'm just not a huge fan of the language in general, it's all a bit too enterprise-design-pattern-clunky-objects and implicit-mutation all the way down, not to mention verbose. I know it's finally, finally getting a half-decent implementation of pattern matching and immutable records, but there's nothing that stands out to me about it that makes me want to use it over literally any other language I know, which I guess is fine as it's primary target is being a "boring" enterprise language, which it excels at.

> AOT doesn't have anything to do with performance but helps with startup time and packaging.

Not sure I'd agree with this: putting code through an optimising compiler like LLVM ahead-of-time means you can apply more performance optimisations for runtime.

> The .NET JIT now has tiered compilation with secondary passes that optimize hot methods with much more input about the environment, including knowing that it's a hot path. AOT can't do this.

That's fair, but if you type-system and language design already tells you everything you need to know, you don't need to wait until code gets hot-enough to swap it in, you just pay the compile-time cost and have it go at peak speed the whole time, my argument here might be veering dangerously close to the 'sufficiently-advanced-compiler' argument hahaha.

> Saying "built for speed" doesn't really mean much. .NET created the async Task model that other languages adopted and has all kinds of performance related features from Span/Memory APIs to SIMD vector operations.

Sure, it's got some fast bits but in my experience very few libraries make any use of them and by default most things are heap allocated, with plenty of pointer-indirection right? Compare that to Rust where far more is stack-allocated and numerous other optimisations and shortcuts get applied so the things you're accessing on the heap still aren't too slow. The async-task model is just a model and has nothing to do with actual run-time performance though right? I had a go playing around with Span when I last wrote stuff in C#, but I found it difficult to do much with it as the compiler either wanted way more things to operate on Span-types (some of which was out of my control) or I needed to do things with iterators that required me to turn it right back into a 'heavyweight' IEnumerable class, which kind of defeated the purpose. Entirely plausible I was using it wrong though.

> RavenDB is an example of an fast document database built in .NET Core: https://ravendb.net/

Ok that's cool, I hadn't heard of this, I'll check it out.

Yet I don't see .NET getting on Java turf as much as many Internet thinks it can.

It remains mostly a Windows stack (so many enterprise third party are yet to release Core stuff that is actually cross platform), and there are plenty of platforms without any kind of .NET support, yet you will find a Java vendor on them.

Also ironically Microsoft is now a OpenJDK member and they are the ones doing the Apple Silicon support.

But I agree. .NET will not replace Java or any other serious language.

I think you have to specify a domain to make that statement reasonable. I think .NET is used more than Go for example. Maybe more than NodeJs also for server systems. Less than Java. If we compare to C++ it is very much down to domains. I don't hear about many enterprises using C++ for server backend code but of course they exist. And so on. .NET (or C#) may already be "leading" against a lot of other languages and then the question is if the others will replace C# or not. And if it will take some of the market from languages like Java which I think it will but not all.

Basically what everyone usually advocates as "Python" in performance critical stuff, but we get the the productivity and JIT/AOT tooling from Java/.NET eco-system as well.

SharePoint and Sitecore are .NET Framework only. Only CSOM is Core and Sitecore just released their first Core support last month, and most enterprise projects ends up plugging into them.

Forms, WPF still have issues running on top of core, UWP is stuck on Core 2.1 compatibility and .NET 5 is focused on desktop deployments with UWP future uncertain.

It’s pretty much as far away from “serious language” as it’s possible to get, but here you are happily using it anyway.

Take your Gatekeeping and get in the sea, thanks

The beauty of Java is that it is like C, plenty of implementations to choose from. :)

CoreRT was supposed to bring full AOT to C#, and that project is still in alpha with a disclaimer saying there are no plans to make it production-ready. LLILC, the compiler that targets LLVM, is also not production ready.

Anyone know what's going on?

As someone who isn't a .NET developer, the sheer proliferation of runtimes and platforms is super confusing, and I can never remember what's what between, .NET, .NET Native, .NET Framework, .NET Core, Mono, CoreRT, etc. If this is getting cleaned up, that's great news.

.NET windows/desktop framework stopped at version 4.8 and .NET Core has spent 4 years incrementing to version 3, so .NET 5 is a merger of everything into a single framework again. Mono will still exist since it's used by Xamarin for mobile and Unity for games.

AOT is mentioned in the article and comments, and there's also this big thread in the CoreRT repo if you want to see more discussions: https://github.com/dotnet/corert/issues/7200

Is it a merger or a replacement?

I won't be able to just take my huge legacy .NET 4.7.2 app and just change the runtime to .NET 5 and hit the go button right?

Seems for the app I work on at least the upgrade path is a full rewrite :/

You might be able to get pretty far with just a framework switch. The RC is already out so try it. You'll probably have to update the csproj/sln files at a minimum and fix some known API differences but it's unlikely you need an entire rewrite.

My EF 5, EDMX, ancient dependencies and the like probably beg to differ.

Libaries/Frameworks -> .NET core, .NET framework. Two different versions of the libraries, .NET Core is newer and cross platform but older technologies such as webforms can't run on it, .NET framework supports older technologies but isn't cross platform. Plenty of libraries are usable inside either framework.

Ahead of Time Compilation Technologies -> .Net Native, CoreRT, AOT

Most new devs don't have to know any of this to be productive. Just pick .NET core unless you need to use .NET Framework for backwards compatibility reasons.

So instead of a C++ with C# like tooling for doing UWP stuff, now one gets to edit IDL files without any kind of support (you could be using Notepad for what they care), and then you have to manually copy/merge C++ files after being generated.

And on the .NET side .NET Native was looking to be how version 1.0 should have been all along, and now has an uncertain future.

Finally with Reunion, when going regularly on their issues, it seems to be turning into a major reboot, porting what they can into Windows 7 like stack, leave UWP as an improved COM runtime, and pretend that everything else post Windows 8 outside Win32 never happened.

This is sadly totally true.

But Microsoft won't officially do any more since they have Blazor which lets you run C#/.NET in the browser with both client-side WASM and server-side SignalR/websocket running modes. It's much more advanced and functional than React already. [3]

1. https://channel9.msdn.com/Events/ASPNET-Events/ASPNET-Fall-S... 2. https://reactjs.net/ 3. https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

The browser runtime is trimmed down to the APIs actually used, has dynamic async loading now, and it's around the 1.5MB mark which is competitive with the big SPA payloads.

Here's a very old build: https://blazor-demo.github.io/

And a recent build: https://stevesandersonms.github.io/BlazorOnGitHubPages/

Yes you can be smaller with JS but not by much these days, and given the amount of functionality you get with Blazor it's hard to compare on file size alone. Also if you're just making internal apps with controlled usage then server-side is better anyway.

> It's much more advanced and functional than React already.

I’m sure this is true, but I can’t imagine there’s much of a community around it? The thing is with React you have a huuuuuuge community and ecosystem. You can share code with React Native. It’s so deep...

While React's ecosystem might be huge, the quality trails off quickly and it's pretty messy even with the popular stuff, much of which is to add functionality that every app needs but isn't included in React itself. Blazor already comes with everything included, but can also use the full power of C#, the massive standard library, plenty of 3rd-party packages, and the tight integration with the backend.

I suggest looking at some of the Blazor presentations (by Steven Sanderson the original creator) to get a sense of just how quickly you can build: 1. https://www.youtube.com/watch?v=Khn7sDUSEJM 2. https://www.youtube.com/watch?v=QnBYmTpugz0 3. https://www.youtube.com/watch?v=kLhoRyLxwAE

https://github.com/dotnet/aspnetcore/issues/12890

The closest community project is https://github.com/JeringTech/Javascript.NodeJS and should be a drop-in replacement for `INodeServices`

If you just want V8/JS scripting then there's https://github.com/microsoft/ClearScript

Yes a JS only developer is probably lacks certain experience but I am well versed in Java and have had solid exposure to C#, like they them both a lot, but today would prefer to use TS on backend and front end for any small project. The fact that I can share types and validation code (Joi) on both server and client is really powerful in my opinion. There’s only so much you have time to focus on when you’re working on a small project. Context switching two platforms is a big impediment in such cases.

There's nothing quite like it, and I find myself coming back to it and doing everything faster. The only downside would be a smaller open-source ecosystem (for many various reasons) so you don't get all the "cool" libraries, although you there are more than enough to solve any problem.

It's going to take a few years for Blazor to catch up & have a chance to surpass the Node ecosystem but they have a good shot.

They need more/better front-end specific tooling & a quicker feedback loop with hot reloading. There is some hope that hot reloading will make it in for next November's .NET 6 release.

As Wasm & Blazor improve, I think it has the potential to be what people like about TypeScript but with less setup required or worries about missing dependency support.

The WASM mode is still a little rough but it's rapidly improving. Hot reloading will definitely make a big difference there when it arrives.

> advanced ORMs like EntityFramework and NHibernate

I've used all of these. Rails' ActiveRecord blows all of them clean out of the water.

LINQ has nothing to do with ORMs, it's a generic querying/transform syntax that can operate on any kind of data structure, and it's expressiveness allows it to be seamlessly translated into SQL by EF and others.

Also it's hard to beat the static-typed nature of C#/EF and the fact that entities are just plain classes with no special needs or inheritance. They can be as "active" as you need them while the DbContext wraps everything nicely.

I'm dealing with some rather fun EF code inside triple nested for loops that runs several thousand queries before throwing a validation error. Now, I know that's the devs fault and not EF, but EF made it all just seem like harmless object oriented programming and not set operations.

I almost feel like I'd like EF for write operations, and Dapper for read operations. Strike a balance.

Ive seen so many awful queries with terrible performance out of EF.

LINQ is cool, and EF is alright if you have a decent team with good practices, but it takes a lot of discipline for it not to turn into a hot mess.

And for the record I hate LINQ to SQL.

    (#(1 2 3 4 5 6) select:[:e | x isPrime]) collect: [:e | 2 * e]

Though I do like it and think it's pretty good, it would really benefit from a bigger open source community. It's picking up, but it is on the backfoot due to starting out with a closed-source philosophy.

- C# and F# are constantly updated in coherently. They have been on a yearly improvement cadence for the past 5 years.

- It's easy to pick up. I wrote 300+ samples for ASP.NET Core (https://github.com/dodyg/practical-aspnetcore)

- It's really a fun framework to develop in.

For all it's other features, I'm really not sure I'd call .net fast. It's got half decent speed, but it's not "woah that's fast"

> - C# and F# are constantly updated in coherently

By which you mean C# gets new features every year, and F# gets thrown enough tidbits to keep it looking alive?

Every new C# version makes interoperability more of a pain. The C# team have no interest in compatibility with F# and will NIH stuff that could've been taken from F# libraries. One of the biggest pain points for interop is tasks, for which there are half a dozen libraries for F# and everyone uses a different one. There's been an open issue for F# to have native task support for years, but progress is slow.

C# gets more features every year than F# because C# is still trying to catch up to F# 1.0. F# 5 got good updates this round (https://devblogs.microsoft.com/dotnet/f-5-update-for-august/)

It's 2020 I can't name a single server side known application built in net core.

Bitwarden is a self-hosted lastpass/1password competitor in .NET

You've probably used oauth somewhere powered by IdentityServer, played a game built in Unity, and used a mobile app built with Xamarin.

In fact it remains to be announced what are their plans regarding .NET 5.

https://stackexchange.com/performance

https://hub.packtpub.com/stack-exchange-migrates-to-net-enti...

And there's definitely nobody can see the current state of their underlying technologies to know about their transitions https://github.com/StackExchange

So ... this all just sounds weird for a startup with a weird name?

/s

If you like F#, why not just reap all the functional benefits and write it in Haskell, or Rust which has (arguably) just as strong a functional influence (minus the syntax) as F# does, with the benefit of a stronger type system, and better performance, and these days, probably a bigger community than F# as well.

I'm a big fan of C# and the .Net platform as well. Being able to mix C# code in a project is compelling. If C# had a strong native SSH(I'm aware of netssh, but something a bit more official/active) implementation, and a WinRM/Remoting implementation that wasn't hidden inside the Powershell project, I think there would be a .Net OSS tools explosion..

There are plenty of enterprise stuff like SharePoint, Sitecore, GUI components based on commercial partners like Telerik and Component One, among many others that are still on an transition to Core.

And for those that already moved there, their stability is still at v1.0 level, better leave the "fun" to others.

EDIT: typos and grammar.

In the consulting business "I rewrote X in Y" blog posts only happen when someone takes the time to budget the project, because there is someone doing the math of developer time x cost per hour.

Then .NET Framework has been Windows specific for 20 years, there are lots of .NET libraries that are thin wrappers over Windows APIs, or interact with COM/UWP.

Porting them to Core means just rewriting everything from scratch, and if they are to remain anyway Windows specific, there is no advantage other than stay on reboot treadmill that Microsoft has started with the UWP/.NET Core (now backing off with Reunion), so they just keep doing .NET Framework as usual.

Spin up an Web API is at most one bullet point among many others.

I feel like a lot of what I see online fits into either SaaS web apps, or well known open source projects / core infrastructure used in building large-scale, distributed systems.

I'm sure there's a lot more out there, but it doesn't seem to get talked about much. Hence, the comment. Meaning if you're interested in coming over to the .NET Core world fr a different background then the things that are missing from full .NET Framework probably aren't of any interest to you.

The roadmap is to collapse both into '.NET Standard' at some point. MS are committed to full cross-platform compatibility.

MAUI (Xamarin rebranded) is only expected for .NET 6, if the stupidity of Blazor on Web Widgets doesn't end up replacing it.

https://datalust.co/seq https://github.com/PowerShell/PowerShell https://github.com/opserver/Opserver

Stackshare can be useful to track who is using what, although a lot of folks are not public about it: https://stackshare.io/dot-net-core

Really? I was of the impression that Unity C# is the old, established player in this space, while Godot (which supports C# but doesn’t force it at all) is growing among hobbyists and indies and may eventually pass the current popularity of Blender in VFX and go on to dominate the games industry in a few years or a decade.

LINQ? Clojure and Scala can offer you much more than LINQ. Java is on par.

dotNET Core libraries? I don't know, I have never heard people complaining much of the core libraries in the JVM world.

VS and VS Code integration? JavaScript and TypeScript has the best VSCode integration, other languages are just supported, including C#, F#, Java, Scala etc. JetBrains IDEs are much more powerful than what VSCode will ever offer. VS is not even cross-platform.

The C# used in game industry is a far cry from the one used in enterprise and I don't think C# is the longterm answer for scripting in game dev.

Example for bad parts: Handling checked exception in lambda, no extension method support, calling ".collect(Collectors.toList())" every time, no real closure support, complex lambda type due to primitive types.

I should mention async/await for C# feature compared to Java.

IMO Scala/Clojure is too much for me, C# is balanced option.

[1] https://www.cnet.com/news/sun-microsoft-settle-java-suit/ [2] https://en.m.wikipedia.org/wiki/Oracle_America,_Inc._v._Goog....

https://github.com/xamarin/java.interop

- Akka https://github.com/akka/akka - Lucene https://github.com/apache/lucene-solr - Aeron https://github.com/real-logic/aeron - Retrofit https://github.com/square/retrofit

Not to mention projects like Apache Spark, Cassandra, Elasticsearch, Druid - Java projects. Many projects (Foundation DB, Scylla DB, I could find more) will have in-house support for Java and not .NET.

The .NET equivalents to these libraries tend to be playing catch up. Xamarin Android will always be playing catch-up to Android's Java/Kotlin APIs for Android. Big machine learning projects like PyTorch and TensorFlow tend to give first-class support of some fashion to a Java API (mostly due to Android). Is there a .NET equivalent to Deeplearning4j? Hadoop? Hive? Kakfa?

In Java there is a proliferation of web projects: Spring, Vert.x, Quarkus, Micronaut, Play 2, Spark Java; Netty, Jetty, Apache. In .NET all you ever hear about is Microsoft projects ASP.NET core; Kestrel, IIS.

Working as a .NET dev, when there is an SDK, if it's not from Microsoft, it's clear the .NET SDK is a lower priority for bug fixes and new features compared to e.g. the Java/Python/etc.

TensorFlow can run on any JVM for building, training and running machine learning models. They have created recently https://github.com/tensorflow/java

PyTorch also supports inference on the JVM but you still need to train with Python. https://www.infoq.com/news/2020/02/pytorch-releases-java-bin...

I think something like Scala will be used in the future instead of Python even for prototyping.

Streaming is also big business on the JVM: Apache Kafka https://kafka.apache.org/ (80% of Fortune 100 companies use it) Apache Flink https://flink.apache.org/ Apache Storm https://storm.apache.org/

Hard to think that .NET ecosystem will ever reach the ecosystem of Java when it comes to open-source.