5 ms·
Disregarding popularity, why should I switch to C#/dotnet from PHP/Go/Ruby?
by bovermyer 6y ago
Disregarding popularity, why should I switch to C#/dotnet from PHP/Go/Ruby?
- manigandham 6y agoVery fast, statically typed, clean language design with features like LINQ for data operations and fantastic async support, cross-platform, comprehensive standard library, advanced ORMs like EntityFramework and NHibernate, easy deployment including docker/self-contained/single-file, build anything from web/mobile/desktop apps, best-in-class IDE and tooling, Blazor UI component framework running .NET in the browser, solid gaming support with Unity, etc. 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.
- mattferderer 6y agoI think the web front end could be a huge multiplier for them. 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.
- manigandham 6y agoWe're already building with Blazor using the server-side model and it's pretty incredible. We can get massive amounts of functionality built in minutes because it's just .NET, especially with all the existing backend logic easily shared and used by those components (via signalr). 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.
- TheRealDunkirk 6y ago> LINQ for data operations > advanced ORMs like EntityFramework and NHibernate I've used all of these. Rails' ActiveRecord blows all of them clean out of the water.
- manigandham 6y agoHow so? 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.
- cutler 6y agoActiveRecord surpasses all other ORMs in memory usage and slow execution, that's for sure.
- nullsense 6y agoI like the ergonomics of it though. 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.
- TheRealDunkirk 6y agoIf its memory usage and execution speed are deal-breaking bottlenecks for you, then you're working at a scale few people actually work at. Here in the line-of-business web app electron mines, I get to optimize for developer productivity and simplicity.
- aliswe 6y agoI suspect you haven't yet seen tge power of LINQ, it's not the chaining that is its point - it's the lazy evaluation. It's not at all limited to DB operations.
- nullsense 6y agoThe ecosystem let's it down a little I reckon. I came over from the Java world and have dipped my toes into Rails and found the Java ecosystem far richer. 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.
- tasogare 6y agoYou can stay on PHP and run it on dotnet using the PeachPie compiler.
- dodyg 6y ago- Super fast - 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 https://github.com/dodyg/practical-aspnetcore) - It's really a fun framework to develop in.
- FridgeSeal 6y ago> - Super fast 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?
- dodyg 6y agoJust Google around for techempower benchmarks for speed. You don't have to rely on some random opinion on the web. 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/ https://devblogs.microsoft.com/dotnet/f-5-update-for-august/)
- sparkie 6y ago> 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.
- u7u7h 6y agoI've switched from PHP/Node.js to .NET/C#. And that's awesome!