I just jumped on the .NET Core gravy train after 6+ years of Ruby on Rails development. I feel so productive and confident working with .NET. Ill be riding this rollercoaster with you for a while!
C# is such a cozy language, anyone familiar with C++ or Java can instantly bang out half-decent code, and there's a ton of great features to gradually learn and use. And the performance is about as good as it gets for a language with garbage collection. Big fan.
And ASP.Net Core is an insanely fast web framework. It beats every other major framework written in a managed language by a mile. There's no way your backend will outgrow it if your workload isn't RAM-limited.
Would you call TechEmpower benchmarks synthetic? I think they're a pretty useful data source and indeed support the claim that the performance of .NET is rather good.
Personally I think that some of their tests are pretty close to what web applications might actually do a lot of the time (fetching the data, processing it, saving it), for example, see here: https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...
Sure, sometimes the code you see in benchmarks can be a bit more clever than the code you'd see normally, but for the most part TechEmpower seems close enough to be a vague indicator towards what frameworks/languages/stacks have decent performance.
It also helps you get a feel for how big the differences are between any two given platforms, like using something like Java + Spring and Python + Django, which may or may not be relevant in actual business conditions, since you might also want to iterate quickly.
It produces best performance OOB with minimal API way of registering your endpoints. Which is expected to be the default way for many newcomers to the framework. On 5800X, hello world with some logic and cached JSON output (not raw bytes but actual response object so no cheating) produces over 4GB/sec when benchmarked over localhost on .NET 7.
The only other real way is to write two programs that do the same thing in both. You need to put in the same degree of runtime/environment-specific optimizations (which, notably, will result in different code), but except for in trivially simple applications (eg: "TODO app") which are arguably also "synthetic", the optimizations are always going to leave room for debate.
I'm glad for you, but ActiveRecord is still the best ORM of all time. OF ALL TIME. I rewrote one of my main Rails applications in .NET, and trying to use Entity Framework was like pulling teeth for me, in comparison.
I'm glad it works for you. It gave my team years of headache while we ported it all to jOOQ.
Also our Ruby engineers liked the flexibility so much that they exposed our entire database as a service to customers, which we had to emulate and support.
Amen to that. We had a high-level engineer who sincerely believed that Rails and Postgres were the right tools for Everything. Consequently he shipped a mission-critical query engine whose API is - you guessed it - just ActiveRecord!
It's great if your users are disciplined and experienced Rails engineers who understand how the system works, but we don't live in fantasy land and a year later, we are so very constrained by the unlimited DB access that we're rewriting it all and leaving ActiveRecord out of the equation.
I'll always maintain that Rails is the first tool I'd reach for in a new web startup, and the first one I'd discard after growing past ~20 engineers.
> It's great if your users are disciplined and experienced Rails engineers who understand how the system works.
I'm continuously shocked at how much bad ActiveRecord code there is lying around given that it's so easy to just look at the SQL it generates and be like "yeah this looks reasonable".
WHY SPONGEBOB WHY!?! Why do you pass around your relations making all of ActiveRecord part of your external API? It's so hard to do stupid things with AR if you pretend that AR objects can't leave the scope they were fetched in.
You shouldn't blame Ruby (or ActiveRecord) for infrastructure decisions that are inherently bad, irrespective of platform or technology. I mean, this is HN, and you WILL, but you shouldn't. ;-)
Unfortunately we were a tiny Lisbon startup with our own in-house clone of AOL Server and Tcl was never a hyped language, otherwise I don't really see what it does better.
Our Tcl ORM was doing Sybase, SQL Server, DB2, Informix, Oracle and even Access, across Windows 2000/NT, AIX, HP-UX, Solaris, Linux, in 1999 - 2002.
But we never went big into US, so Rails gets the credits.
And we were not alone in this regard, there was Vignette, Cold Fusion, Zope,...
I'm just glad the number-space has been sorted out. It was annoying to learn that ".NET 2", ".NET Standard 2" and ".NET Core 2" are very different things.
It's really too bad the naming/versioning has gotten so confused. I used to be a heavy .Net user, then stepped away for a while when I changed jobs. Every time I try and come back, I get so confused. Am I looking at the right docs? Is this API available for the platform I'm on? It's bad enough with .Net, itself, but what about GUI libs? What's even supported anymore? What's actually stable and not in pre-release? It's a shame, because .Net is damn good, but the messaging around it has been awful in my experience.
Christ, the mess that are the docs. And the complexity. Just lost well over an hour trying to get a non-trivial regex working (that would have taken me 30 secs in emacs). Gave up and just used split() and it just worked. Never again, I swear.
Might want to check out RegexStorm [1]. It's a .NET regex tester in your browser. Yeah the docs are great but there's nothing like instant feedback to test your regex.
Yes, big poop show on naming convention changes done terribly. Eventually the dirt will settle and become easier to navigate if it hasn’t started already.
Old .NET was always ".NET Framework". Microsoft had many years of branding advice early in .NET history that it was never to be called just .NET because their branding teams were using that as a wider initiative that included other things. Most of those other things died or were rebranded and .NET Framework was the last one standing. .NET 5 was the first ever "just .NET", technically from a historical perspective.
My friend works at an F# consultancy - from what I’ve heard it’s definitely growing in popularity! I used it for some windows profiling in 2020 which was pretty cool too, albeit only really a single script.
I have been a long time "enterprise languages" developer. First Java/J2EE then .NET in the last 10+ years. I already felt that moving to .NET was a jump forward with respect to J2EE but have always been curios about startup languages/stacks like Ruby and Clojure. Lately I was much tempted to do some side project on Rails because I find the Hotwire/Nojavascript trend very reasonable for a lot of real use cases . How do you compare modern Rails with modern .NET?
I haven't worked with Rails since Rails 5 so I dont know if I could do a fair comparison of how they are as it stands today. Check one of the comment replies above where I outlined some of my thoughts in a similar question.
Any interest in doing a short comparison? As in, why are you in no rush to switch back to rails? Any features you miss from rails? (edit: register beat me to it. I'll leave my post as a +1)
For the most part, I think there is a lot of feature parity between the .NET and Ruby on Rails frameworks when it comes to developer tooling.
As I grow older I guess I am growing more fond of statically typed languages. It's easier for my decaying/distracted brain to reason about. There is less mental overhead I suppose [might be a good blog post?]
They both have a good database migration system and various generators for scaffolding views, controllers, etc. To be fair I believe Entity Framework does most of the work for the .NET side on the database developer tooling but I just consider it part of the .NET ecosystem since it seems to be the go-to ORM/database tooling library. I want to be fair to Rails -- I really think they set the bar very high for other frameworks. Productivity w/ Rails was unprecedented when it first came out. I started during the Rails 3 to 4 upgrade.
Both ecosystems have easy access to outside libraries using Nuget/Gemfile. So pulling in a background processor like Sidekiq [Ruby] or Hangfire [C#] is fairly easy.
Cross platform support is acceptable across both frameworks as well. I can setup an EC2 instance and run both Rails and .NET applications side-by-side. So deployments are going to be similar but I would argue that .NET has the upper-hand because it can deploy do a self-contained deploy so you don't have to worry about installing dotnet in the deployment environment.
I am using Blazor Server and I am not going to say something drastic like it will kill React but it is pretty awesome. I can build my entire web experience with C# but with Rails I have to introduce React when I sometimes dont want to. Blazor prevents me from having to write HTTP code from my front to backend systems and as an indie developer that is a godsend.
Both have gorgeous documentation -- I thought Rails was good and thorough but .NET ate their lunch.
> As I grow older I guess I am growing more fond of statically typed languages. It's easier for my decaying/distracted brain to reason about. There is less mental overhead I suppose
I'm not even sure it's an "older" thing -- it's nice just to have less mental overhead.
The things that used to turn me off from static languages (eg: most of the benefits dynamic languages have) have disappeared. Generics allows creation of some powerful re-usable code (eg, List<T> or RunningAverage<T>). Tools to easily convert any random JSON or XML to concrete classes make it a simple extra step to consume any API.
The benefits are massive. Code-completion just frees your brain from having to remember or deeply think about what's available. Type-safety giving compile-time (or even coding-time) errors prevents so many stupid problems that, in a dynamic language, take a runtime check to find.
I would advise against Blazor Server. In contrast to standard frontend SPA frameworks, Blazor Server requires a peristent websocket connection to each client to execute the C# code you write on the client and maintain state. I found that connection is easily/fequently disrupted resulting in an app reset, lost state, and poor user experience, to say nothing of the scalability implications.
Though, for a purely back-office app with minimal state, that might be OK
> Blazor Server requires a peristent websocket connection to each client to execute the C# code you write on the client and maintain state
Blazor Server retains the circuit for up to 3 minutes if the connection is lost, so you do not loose the connection even if the websocket connection is interrupted.
It is also not correct that it needs a websocket connection. It builds on SignalR which will use websockets if available but will fall back to other methods such as long polling to emulate a persistent connection.
Blazor Server absolutely has it's place, but you need to know when that is. You can even scale it out on multiple servers, but at least until .NET 7 you'll need to ensure "sticky" connections (the client must connect to the same server based on e.g. IP address, cookie or similar).
It sounds like you have been using Blazor a lot more than I have so I’ll take your word for it. I haven’t any massive traffic yet. Is this something I can reproduce with a benchmarking tool?
But your comment comparing Blazor to Rails seems to be about the current state of Blazor and Rails. So currently Hotwire for Rails is production ready. So with Rails, you don't necessarily have to introduce React as you comment claims.