I used .NET Core for a backend API relatively recently (3.1) with no background in .NET prior (mostly javascript/typescript, php, and ruby). I found it incredibly productive and to be an enjoyable developer experience. Entity framework is one of the best ORMs I've ever worked with. Solutions and projects took some getting used to but I like it in retrospect. I now use IntelliJ products as a consequence of having used Rider for that project (developing on a mac) and enjoying the experience. C# as a language is now one of my favourites. I find it hard to convince colleagues and peers to give it a chance (mostly ruby and javascript devs) which is a shame.
Extremely similar background here, similar feelings after working with .NET / modern C#. I even, semi- subconsciously perhaps, wanted to dislike it -- because I thought it was MS-ish, and ASP-ish. But really, it's a first class citizen and especially so the last few years as it's become very fast & received a ton of cross-platform support.
Once over the [quite low IMO] initial 'hurdle', it's easily amongst the most productive & best-supported "platforms" I've ever worked within.
I am returning to Java ( Spring Boot, Spring Cloud and IntellJ ) after a long period with C# and .NET core. What a step backward it is! Really the .NET platform is leaps and bounds better than anything offered by Java today (at least when speaking about Spring).
Yes, I think it is the best ORM in terms of productivity, but it is very, very slow. This is usually not a concern for internal enterprise applications that only have a few people using them at a time though. I guess the other issue is just an issue with ORMs in general - you lose a lot of the in-built features of your sql database, which as projects progress, can ultimately result in you writing the same amount of code as if you didn't use the ORM.
You also can't switch programming languages without rewriting the entire database section. Personally, I stopped using ORMs altogether because I find that they make easy things a little easier, and hard things harder, which isn't a very good value proposition overall. They don't really save me time anymore.
Interesting! I’ve recently made a switch from C# to TypeScript and I’ve found prisma to be such a relief from working with entity framework.
Not that entity is bad in any way, it’s just not as productive. Which is sort of how I have it with most of the journey into TypeScript. It’s just a really great environment especially in Azure Function apps, and a massive cadeau to Microsoft for making the node in docker such a first class citizen in their Azure environment!
In many ways I feel like TypeScript is a mix of the best of Python and C# and that’s just wonderful, for me.
But writing things like Odata APIs in .Net sure has some benefits from the massive work Microsoft has done with the .net and C# environment since moving core into the main .net or however you describe it.
So now I’m not sure where I am going with this, I’m probably just very appreciative of the work Microsoft has done for us enterprise developers in non-tech enterprise in the past few years.
> Entity framework is one of the best ORMs I've ever worked with.
It is good, but it's just better to learn TSQL/SQL Server if you are on a windows stack. Shouldn't use it as a crutch especially if you working on the back-end side. Entity framework was created to make data access easier for the front-end people.
I'm using ASP.Net Core for a couple personal projects for the first time, and it's pretty decent. I'm using nginx as a proxy, and I'm able to develop and test everything on Windows, and publish directly to a Linux test server. I have a lot to learn, especially for handling some web requests at a lower level, but I've been pretty impressed so far.
Interesting. I’m a rails developer, and to me one of the core strength of rails is active record (altho some might disagree). How would you compare it with rails active record, and which part do you say it’s much better?
Btw, I know this is superfluous and very shallow, but for some reason, I can’t get over the C# syntax because of how enterprisey it is. I much prefer ruby, but I guess it’s a matter of preferences and taste
I have worked with .NET for a long time and recently did some work with Java, node and python. .NET has a lot going for it but i feel MS is making things more complicated than they have to be. When I need to achieve something a little off the beaten path in the non .NET technologies this is often pretty straightforward to achieve whereas in .NET I have to find some obscure interface and overrides to implement and then deal with weird side effects. I think .NET has become too big for its own good to be maintained by one party. The documentation also has a lot of volume but almost no structure. When .NET started out it was pretty coherent but in the last few years it felt very disjointed without a central design philosophy. Don’t even mention desktop development which is a complete mess since Windows 8.
Maybe I am too negative on .NET but personally find the open source alternatives easier to work with and more fun.
I have used it since 2001, though Friday (and continuing next week and for the forseaable future). My biggest problems are:
* OOP is celebrated in the ecosystem. It's time to face the truth: the mainstream (i.e. not smalltalk) implementation of OOP is fundamentally flawed. I have done some pretty fancy stuff with aspnetcore and, OH BOY, does it take a while to unravel and understand that decoupled OOP wet dream.
* Nobody does the high performance stuff in the real world. DDD (which has several valid merits) has many idioms in netcore that are fundamentally incompatible with writing high performance code. You might be able to dilute DDD to achieve tighter code, but if you value explicit clarity above all else then you have limits. Modern procedural languages suffer from fewer opinions when approaching the best of both worlds.
Really this is a rant about OOP and, disagree with me about OOP being broken or not, OOP and OOP idioms are deeply entrenched in netcore (F# included).
- In later versions of .NET, struct enregistrering is very powerful, it promotes struct's contents to CPU registers. You can write high-performance and allocation-free implementations for value objects, monads and wrappers of all kinds without much issues nowadays.
- Guarded devirtualization helps a lot if you heavily rely on interfaces because it allows further inlining and reduces method calls cost.
- Unfortunately LINQ is no match to Rust iterators which get easily vectorized. However, there are low-allocations and simd-ified implementations which might help with your goals. See https://github.com/asc-community/HonkPerf.NET
After all, DDD requires special care when describing its domain definitions in code but you really don't have to go OOP route nowadays for the core logic of your applications. Also records and record structs make it very easy to define contracts and state on the go without having to go with tons of boilerplate I keep seeing in a very much DDD-oriented project my team is responsible for.
I think this is a valid critique. But then, most of the development (C aside) has been a victim to OOP.
I have begun to think that OOP creates more problems than it solves. Added complexity and performance loss being the biggest. It's insane if you peek into a big projects where many developers came and went and each of them read an article about what it seemed an interesting design pattern and tried to implement them.
You can have some kind of procedural programming if you use classes just to store data and use static methods. But the frameworks are OOP and there is no way around that unless you write your own frameworks.
I am a big fan of Mike Acton's Data Oriented Architecture speeches, but I didn't find a way to implement something similar in C#.
For those interested in something better than OOP, here's a few links:
.NET now has a lot of functional stuff. It has a whole functional language (F#), that can natively interop with .NET libraries (even if they are written in C#)
C# itself has many functional constructs.
With the modern minimal APIs, you can create a single file web application servers, without ever creating any objects.
OOP is the bread and butter of .NET, just like Java.
I left OOP when I left Ruby back in 2015. I won't be going back to OOP ever. I use Elixir now.
How much C# is functional these days? I know linq had the beginnings of it waaaay back in 2010 but do you see a shift in more c# devs going functional instead of OOP? Or is it just another JavaEnterpriseFactoryFactory.cs
How, in your opinion, does “mainstream” OOP differ from what Smalltalk OOP was/is?
I tell people Alan Kay’s 97 OOPSLA keynote “I invented the term object oriented, and this is not what I had in mind”, but I find it difficult to articulate to people who are doing “mainstream” OOP, what they’re missing. It’s like trying to explain the taste of salt.
Just curious if you have any better way of explaining it.
Oddly, I’ve been learning Elixir/Erlang for the last year, and though it’s definitely not OOP, there’s something oddly resonant about it with my Smalltalk past from 10 years ago.
> OH BOY, does it take a while to unravel and understand that decoupled OOP wet dream.
If you are referring to ASP.NET then I think you might be describing DI and IoC more than OOP in general.
The evolution of ASP.NET has definitely be one of embracing DI and IoC design patterns.
With ASP.Net Core the conversion is complete as the foundations of that framework are built on DI and IoC design principles.
However, the trouble with DI for newcomers is it can be very hard to understanding what's going, only because of much of the action happens in code that is not visible.
It also means anyone using the framework really has little choice but to also adopt DI and IoC design principles, otherwise they'll just find themselves fighting the framework.
I love .NET. It is highly productive, reasonably performant and you can competently write any kind of software using it beside systems programming. It is an excellent jack of all trades, and you can move with ease from game programming, to web applications, to desktop software, to small glue programs and utilities, to mobile apps, to web frontend and what not.
In the future even systems programming might be possible with push towards native apps and direct memory access. If at some point it will be possible to disable the garbage collector and manually manage memory, .NET could be used for everything.
For a company investing in .NET is a good idea since you can move with ease a developer from one role to another. And even if you don't move the developer, having a mobile developer who can read and understand the code for the backend APIs can be quite beneficial.
For me, personally, working with .NET was quite a win. I moved from desktop apps to web, then, when I got bored I moved to the gaming industry as a game developer and now I am again a happy web developer writing microservice based web apps. Meanwhile I also developed a few mobile apps for myself.
> (Note: there’s some debate on whether it’s 20 or 21 years, but Microsoft’s Professional Developers Conference in October, 2001 definitely already referenced .NET in production systems)
I can clear this one up.
I was lead on a .Net production system launched in August, 2001. It's 21 years.
I guess apples-to-apples benchmarks are so hard to agree on that any statement of the form "A is slower than B" is always to some degree a myth. If that's the author's position, fair enough. But if we actually want to make comparisons, "C# is faster than Rust" is a bold claim.
I don’t have any problem with the idea that .net is a fast, capable, modern language suitable for many purposes.
But I had to laugh at their example that “crushes” (why the embarrassing phrasing?) node.js.
Why, returning plain text is as simple as declaring a private “PlainTextActionResult” class that implements the IActionResult and the IActionResult method ExecuteResultAsync, creates an HttpContext.Result, sets the status code symbolically and the content type textually, manually calculates the content length, and returns an asyc Task object!
Try building a serious app with node. Its a pain to build and maintain. In .net, you can have teams of people working on business logic DLLs, Data Access DLLs and have a few person team tie them all up in a web app. I hardly think that is possible in node.
All the enterprisey things in .NET are a god send in a 10k loc web app with solid debug and profiling capabilities.
And all that will save you time and money.
So many developers try to compare the structures of different stacks based on "hello worlds", whereas, the actual issues crop up in actual web development.
Whoever wrote that code either doesn't know the framework or perhaps is doing a custom implementation for some performance optimization. All you need to do to return a plain text response from an action method is `return Content("text goes here")`
I kinda had the opposite myth, that .NET core is cross platform, in my head. Then one day someone handed us something to actually run on Linux so off I went to try and install .NET on our linux box and run it. That's when I found it was anything but trivial and in fact, nearly impossible to install it without root permissions on the server we were using (HPC compute cluster where admin access is forbidden). Then we ran into all sorts of problems with having the wrong version so about 3 or 4 random attempts at different versions later and after emulating the install in a VirtualBox clone of the OS so we could manually fetch out dependencies, we finally got a version of it that ran.
So yeah, maybe it's technically cross platform but it's a far cry from the portability and deployment story that other languages like Java or even Python offer.
This feels disingenuous. The author uses this heading for proof that ASP.net performs faster than similar frameworks in Node/Python. I could be convinced C# is faster than Go, but absolutely not for Rust. The simplicity modern C# provides (look at those code samples) comes at the cost of runtime performance optimizations.
Benchmarks would be required to prove it, but I could actually see .NET outperforming Rust in a few scenarios. First, C# can be written in a way that stack allocates almost everything (much like Rust) and second, the runtime information and JIT compilation may allow it to make better optimisations.
Hard disagree on the tooling costs. VS Enterprise is $250/month per seat. VS Code is way too limited for most .Net projects.
…and that’s if you can even figure out how to manage your VS licensing within the deep abomination that is the MS sign-on and management. Most frustrating experience of my life entire professional life was dealing with O365, Visual Studio, and Azure subscriptions.
I love C# and working with it is often a great fit for a lot of use case, and most of those points are valid.
But point #5 - "Myth 5: .NET Isn’t Open Source Friendly" is unfortunately still not good enough. It's not enough that Microsoft is no longer actively hostile to open source (especially in .NET), the ecosystem needs to be too, and right now the ecosystem is dominated by first-party offerings and have little serious third party involvement, even when they do exists a lot of them are not open source.
I agree .NET is fantastic technology. I think a lot of the hesitancy in adopting it is from the historical churn described in the article. It’s normal for languages/runtimes to have churn in their features, performance, and library. .NET has that in spades, plus continual churn in its very reason for existence. The corporate and cultural forces behind .NET may be aligned with your situation right now, but five years from now, who knows? There’s not yet historical evidence that it will remain stable.
The switch from full fat .nets support life cycle to the current dot net cores totally confusing life cycle is currently pissing me off and the higher ups in my firm. Which should be worry for ms. I want stability , not breaking changes.
That’s the problem. They don’t have a steady design approach. They do something here, something there, then abandon the first, then go back to it. Desktop is a complete mess. Core looks quite good but who knows what they will do in a few years?
I've been a .NET dev for almost 8 years now and I agree with the general positivity sentiment in the comments, but...
As many senior devs I also want to retire early from tech. But unlike many, even if I spend hundreds of hours in leetcode, mock interviews, etc. I'm not sure if my work experience would be even considered for an interview at FAANG. Of course I could interview at Microsoft, but it's the only one. Google, Amazon, Facebook, they don't use/hire C# devs at all.
I'm guessing the only path is to learn some Java and sell myself as a C#/Java dev in order to be able to at least get an interview. Any former dotnet dev here that has successfully transitioned into a FAANG position that wants to share advices/experience?
I've worked with .NET in the past few years and I've been pretty happy with it. The syntactic sugar is great, and it seems like we get interesting new features every release. My favorite from .NET 6.0 has to be the integration of dotnet-format as a subcommand. I regularly use vim so being able to format code without opening an IDE has been really helpful.
Unfortunately Nuget package management is abysmal, and a development environment lives and dies by that nowadays. There's also the legacy reliance on XML that shows itself everywhere in C# development. It's easy to forget that the reason Node took off exponentially when it did is not really because it was that great itself, but because NPM (and its' small package philosophy, in combination with JSON based config) was a bit of a revolution in package management that led to network effects of adoption.
The language runtime might technically be open source, but it’s got a huge number of closed-source packages and the ecosystem appears to be only begrudgingly open source.
> It’s slower than Node/Python/Go/Rust
One of 2 of these things, aren’t like the others. I’d believe modern .net can outpace Python, but matching or outpacing Rust is something I’d have a hard time believing, especially in the “vast majority of code” sense-I’m aware that .net can be written to stack allocate everything. I’m also aware that basically no .net code I’ve ever seen in business world has ever done that (precluding games here, because I’ve not worked with them).
> It’s for boomer enterprise development
Yes. Uncharitable presentation and framing, but yes. Every single place I’ve worked at that has used .Net has had the same attitude and approach to solving problems and writing code. Use Kafka for our events like every other company in industry? Nah, use some bizarre MS thing that nobody outside of .Net has heard of or can use. Use websockees or SSE? Nah, use some bizarre .Net version instead. Use Postgres because it’s more than good enough and other teams might need to use the database? Nah MSSQL, and all the tables are named and optimised according to EntityFramework and if you have to suffer through ODBC issues that’s a you problem!
Never mind the obtuse naming and the dogged insistence on dependency injection at every possible turn.
Am I not a fan of .Net? Correct. Is it because every time I’ve had to touch it, it’s a painful and frustrating experience.
The author has nothing to offer for either of the main arguments against .Net:
1. It remains a walled-garden language, subject to Microsoft whims. The only reason Java ever took off was that it offered people freedom from Microsoft sharecropping. It is deeply foolish to yoke yourself and your career to Microsoft again: Microsoft will always ensure they get the major benefits on the platform, not you.
2. It is still almost as badly designed, as a language, as Java.
Can you produce a stand alone executable with ASP.NET these days?
I had a look at how to deploy a modern ASP.NET thingee the other day and it was super enterprisey. It doesn't produce a single file, it produces a 'publish' folder, and you need something called a "kestrel" server...
Say what you will about node.js but you just run the script and slap caddy or nginx in-front of it.
[+] [-] lucidone|4 years ago|reply
[+] [-] adanto6840|4 years ago|reply
Once over the [quite low IMO] initial 'hurdle', it's easily amongst the most productive & best-supported "platforms" I've ever worked within.
[+] [-] manigandham|4 years ago|reply
That's the best summary of the .NET stack, unfortunately it requires first-hand experience to figure it out.
[+] [-] register|4 years ago|reply
[+] [-] pinetlk|4 years ago|reply
Yes, I think it is the best ORM in terms of productivity, but it is very, very slow. This is usually not a concern for internal enterprise applications that only have a few people using them at a time though. I guess the other issue is just an issue with ORMs in general - you lose a lot of the in-built features of your sql database, which as projects progress, can ultimately result in you writing the same amount of code as if you didn't use the ORM.
You also can't switch programming languages without rewriting the entire database section. Personally, I stopped using ORMs altogether because I find that they make easy things a little easier, and hard things harder, which isn't a very good value proposition overall. They don't really save me time anymore.
[+] [-] christophilus|4 years ago|reply
[+] [-] EnKopVand|4 years ago|reply
Not that entity is bad in any way, it’s just not as productive. Which is sort of how I have it with most of the journey into TypeScript. It’s just a really great environment especially in Azure Function apps, and a massive cadeau to Microsoft for making the node in docker such a first class citizen in their Azure environment!
In many ways I feel like TypeScript is a mix of the best of Python and C# and that’s just wonderful, for me.
But writing things like Odata APIs in .Net sure has some benefits from the massive work Microsoft has done with the .net and C# environment since moving core into the main .net or however you describe it.
So now I’m not sure where I am going with this, I’m probably just very appreciative of the work Microsoft has done for us enterprise developers in non-tech enterprise in the past few years.
[+] [-] qiskit|4 years ago|reply
It is good, but it's just better to learn TSQL/SQL Server if you are on a windows stack. Shouldn't use it as a crutch especially if you working on the back-end side. Entity framework was created to make data access easier for the front-end people.
[+] [-] tehlike|4 years ago|reply
[+] [-] rootw0rm|4 years ago|reply
[+] [-] dnndev|4 years ago|reply
Push they’re buttons all the time calling them Microsoft fanboys… that will get them going. Secretly they like it.
[+] [-] acmecorps|4 years ago|reply
Btw, I know this is superfluous and very shallow, but for some reason, I can’t get over the C# syntax because of how enterprisey it is. I much prefer ruby, but I guess it’s a matter of preferences and taste
[+] [-] spaetzleesser|4 years ago|reply
Maybe I am too negative on .NET but personally find the open source alternatives easier to work with and more fun.
[+] [-] zamalek|4 years ago|reply
* OOP is celebrated in the ecosystem. It's time to face the truth: the mainstream (i.e. not smalltalk) implementation of OOP is fundamentally flawed. I have done some pretty fancy stuff with aspnetcore and, OH BOY, does it take a while to unravel and understand that decoupled OOP wet dream.
* Nobody does the high performance stuff in the real world. DDD (which has several valid merits) has many idioms in netcore that are fundamentally incompatible with writing high performance code. You might be able to dilute DDD to achieve tighter code, but if you value explicit clarity above all else then you have limits. Modern procedural languages suffer from fewer opinions when approaching the best of both worlds.
Really this is a rant about OOP and, disagree with me about OOP being broken or not, OOP and OOP idioms are deeply entrenched in netcore (F# included).
[+] [-] neonsunset|4 years ago|reply
- In later versions of .NET, struct enregistrering is very powerful, it promotes struct's contents to CPU registers. You can write high-performance and allocation-free implementations for value objects, monads and wrappers of all kinds without much issues nowadays.
- Guarded devirtualization helps a lot if you heavily rely on interfaces because it allows further inlining and reduces method calls cost.
- Unfortunately LINQ is no match to Rust iterators which get easily vectorized. However, there are low-allocations and simd-ified implementations which might help with your goals. See https://github.com/asc-community/HonkPerf.NET
After all, DDD requires special care when describing its domain definitions in code but you really don't have to go OOP route nowadays for the core logic of your applications. Also records and record structs make it very easy to define contracts and state on the go without having to go with tons of boilerplate I keep seeing in a very much DDD-oriented project my team is responsible for.
[+] [-] DeathArrow|4 years ago|reply
I have begun to think that OOP creates more problems than it solves. Added complexity and performance loss being the biggest. It's insane if you peek into a big projects where many developers came and went and each of them read an article about what it seemed an interesting design pattern and tried to implement them.
You can have some kind of procedural programming if you use classes just to store data and use static methods. But the frameworks are OOP and there is no way around that unless you write your own frameworks.
I am a big fan of Mike Acton's Data Oriented Architecture speeches, but I didn't find a way to implement something similar in C#.
For those interested in something better than OOP, here's a few links:
https://youtu.be/rX0ItVEVjHc
https://youtu.be/QM1iUe6IofM
https://youtu.be/pgoetgxecw8
[+] [-] kumarvvr|4 years ago|reply
C# itself has many functional constructs.
With the modern minimal APIs, you can create a single file web application servers, without ever creating any objects.
OOP is the bread and butter of .NET, just like Java.
[+] [-] sergiotapia|4 years ago|reply
How much C# is functional these days? I know linq had the beginnings of it waaaay back in 2010 but do you see a shift in more c# devs going functional instead of OOP? Or is it just another JavaEnterpriseFactoryFactory.cs
[+] [-] travisgriggs|4 years ago|reply
I tell people Alan Kay’s 97 OOPSLA keynote “I invented the term object oriented, and this is not what I had in mind”, but I find it difficult to articulate to people who are doing “mainstream” OOP, what they’re missing. It’s like trying to explain the taste of salt.
Just curious if you have any better way of explaining it.
Oddly, I’ve been learning Elixir/Erlang for the last year, and though it’s definitely not OOP, there’s something oddly resonant about it with my Smalltalk past from 10 years ago.
[+] [-] jussij|4 years ago|reply
If you are referring to ASP.NET then I think you might be describing DI and IoC more than OOP in general.
The evolution of ASP.NET has definitely be one of embracing DI and IoC design patterns.
With ASP.Net Core the conversion is complete as the foundations of that framework are built on DI and IoC design principles.
However, the trouble with DI for newcomers is it can be very hard to understanding what's going, only because of much of the action happens in code that is not visible.
It also means anyone using the framework really has little choice but to also adopt DI and IoC design principles, otherwise they'll just find themselves fighting the framework.
[+] [-] slugart|4 years ago|reply
We run an high performance, allocation free automated trading platform on .NET. I guess we are nobody…?
[+] [-] spyremeown|4 years ago|reply
Any nice readings you could link me about this view? Thank you!
[+] [-] DeathArrow|4 years ago|reply
In the future even systems programming might be possible with push towards native apps and direct memory access. If at some point it will be possible to disable the garbage collector and manually manage memory, .NET could be used for everything.
For a company investing in .NET is a good idea since you can move with ease a developer from one role to another. And even if you don't move the developer, having a mobile developer who can read and understand the code for the backend APIs can be quite beneficial.
For me, personally, working with .NET was quite a win. I moved from desktop apps to web, then, when I got bored I moved to the gaming industry as a game developer and now I am again a happy web developer writing microservice based web apps. Meanwhile I also developed a few mobile apps for myself.
[+] [-] EMM_386|4 years ago|reply
I can clear this one up.
I was lead on a .Net production system launched in August, 2001. It's 21 years.
[+] [-] Yoric|4 years ago|reply
[+] [-] hackerfromthefu|4 years ago|reply
[+] [-] sandreas|4 years ago|reply
You can build for:
The only thing I'm missing atm is BSD, although it might work with Mono, it is not officially targeted. More: https://docs.microsoft.com/en-us/dotnet/core/rid-catalogSome libraries / frameworks I came across that are definetely worth checking out:
- https://github.com/gnaeus/OperationResult - Rust style error handling for .net
- https://github.com/Tyrrrz/CliFx - Command Line Parser library
- https://github.com/Tyrrrz/CliWrap - Shell exec for c#
- https://github.com/Zeugma440/atldotnet - Audio tagging
- https://avaloniaui.net/ - Cross Plattform UI (WPF Style)
- https://github.com/quozd/awesome-dotnet - Other awesome stuff
- VS Code and JetBrains Rider - alternative IDE for c# development
[+] [-] ourmandave|4 years ago|reply
And they forgot 2...
Myth 7: The .NET branding dept sucks.
Myth 8: The .NET desktop strategy has sucked since Build 2011.
Oh wait, both of those are still true.
[+] [-] oconnor663|4 years ago|reply
I guess apples-to-apples benchmarks are so hard to agree on that any statement of the form "A is slower than B" is always to some degree a myth. If that's the author's position, fair enough. But if we actually want to make comparisons, "C# is faster than Rust" is a bold claim.
[+] [-] jmull|4 years ago|reply
But I had to laugh at their example that “crushes” (why the embarrassing phrasing?) node.js.
Why, returning plain text is as simple as declaring a private “PlainTextActionResult” class that implements the IActionResult and the IActionResult method ExecuteResultAsync, creates an HttpContext.Result, sets the status code symbolically and the content type textually, manually calculates the content length, and returns an asyc Task object!
“Crushed it!” (with Enterprise-y code).
[+] [-] kumarvvr|4 years ago|reply
All the enterprisey things in .NET are a god send in a 10k loc web app with solid debug and profiling capabilities.
And all that will save you time and money.
So many developers try to compare the structures of different stacks based on "hello worlds", whereas, the actual issues crop up in actual web development.
[+] [-] keithnz|4 years ago|reply
[+] [-] Merad|4 years ago|reply
[+] [-] draw_down|4 years ago|reply
[deleted]
[+] [-] zmmmmm|4 years ago|reply
I kinda had the opposite myth, that .NET core is cross platform, in my head. Then one day someone handed us something to actually run on Linux so off I went to try and install .NET on our linux box and run it. That's when I found it was anything but trivial and in fact, nearly impossible to install it without root permissions on the server we were using (HPC compute cluster where admin access is forbidden). Then we ran into all sorts of problems with having the wrong version so about 3 or 4 random attempts at different versions later and after emulating the install in a VirtualBox clone of the OS so we could manually fetch out dependencies, we finally got a version of it that ran.
So yeah, maybe it's technically cross platform but it's a far cry from the portability and deployment story that other languages like Java or even Python offer.
[+] [-] DoctorOW|4 years ago|reply
This feels disingenuous. The author uses this heading for proof that ASP.net performs faster than similar frameworks in Node/Python. I could be convinced C# is faster than Go, but absolutely not for Rust. The simplicity modern C# provides (look at those code samples) comes at the cost of runtime performance optimizations.
[+] [-] pharmakom|4 years ago|reply
[+] [-] parkingrift|4 years ago|reply
…and that’s if you can even figure out how to manage your VS licensing within the deep abomination that is the MS sign-on and management. Most frustrating experience of my life entire professional life was dealing with O365, Visual Studio, and Azure subscriptions.
[+] [-] Illniyar|4 years ago|reply
But point #5 - "Myth 5: .NET Isn’t Open Source Friendly" is unfortunately still not good enough. It's not enough that Microsoft is no longer actively hostile to open source (especially in .NET), the ecosystem needs to be too, and right now the ecosystem is dominated by first-party offerings and have little serious third party involvement, even when they do exists a lot of them are not open source.
[+] [-] wrs|4 years ago|reply
[+] [-] bennysomething|4 years ago|reply
[+] [-] spaetzleesser|4 years ago|reply
[+] [-] Volrath89|4 years ago|reply
As many senior devs I also want to retire early from tech. But unlike many, even if I spend hundreds of hours in leetcode, mock interviews, etc. I'm not sure if my work experience would be even considered for an interview at FAANG. Of course I could interview at Microsoft, but it's the only one. Google, Amazon, Facebook, they don't use/hire C# devs at all.
I'm guessing the only path is to learn some Java and sell myself as a C#/Java dev in order to be able to at least get an interview. Any former dotnet dev here that has successfully transitioned into a FAANG position that wants to share advices/experience?
[+] [-] cjvirtucio|4 years ago|reply
[+] [-] hackerfromthefu|4 years ago|reply
[+] [-] ramesh31|4 years ago|reply
[+] [-] FridgeSeal|4 years ago|reply
The language runtime might technically be open source, but it’s got a huge number of closed-source packages and the ecosystem appears to be only begrudgingly open source.
> It’s slower than Node/Python/Go/Rust
One of 2 of these things, aren’t like the others. I’d believe modern .net can outpace Python, but matching or outpacing Rust is something I’d have a hard time believing, especially in the “vast majority of code” sense-I’m aware that .net can be written to stack allocate everything. I’m also aware that basically no .net code I’ve ever seen in business world has ever done that (precluding games here, because I’ve not worked with them).
> It’s for boomer enterprise development
Yes. Uncharitable presentation and framing, but yes. Every single place I’ve worked at that has used .Net has had the same attitude and approach to solving problems and writing code. Use Kafka for our events like every other company in industry? Nah, use some bizarre MS thing that nobody outside of .Net has heard of or can use. Use websockees or SSE? Nah, use some bizarre .Net version instead. Use Postgres because it’s more than good enough and other teams might need to use the database? Nah MSSQL, and all the tables are named and optimised according to EntityFramework and if you have to suffer through ODBC issues that’s a you problem!
Never mind the obtuse naming and the dogged insistence on dependency injection at every possible turn.
Am I not a fan of .Net? Correct. Is it because every time I’ve had to touch it, it’s a painful and frustrating experience.
[+] [-] ncmncm|4 years ago|reply
1. It remains a walled-garden language, subject to Microsoft whims. The only reason Java ever took off was that it offered people freedom from Microsoft sharecropping. It is deeply foolish to yoke yourself and your career to Microsoft again: Microsoft will always ensure they get the major benefits on the platform, not you.
2. It is still almost as badly designed, as a language, as Java.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] LAC-Tech|4 years ago|reply
I had a look at how to deploy a modern ASP.NET thingee the other day and it was super enterprisey. It doesn't produce a single file, it produces a 'publish' folder, and you need something called a "kestrel" server...
Say what you will about node.js but you just run the script and slap caddy or nginx in-front of it.