We were even able to downgrade our cloud servers to smaller instances, literally.
I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.
There's that, but there's also the developer experience and functionality for people to run it on Mac and Linux.
We have a small C# service that we run locally via Docker (which I think is usually the optimal setup anyways) and develop with VSCode. Since it's small, it has worked well. Would it work well if that was our main backend? Not sure.
Wish I had the option of full Visual Studio on Mac for it regardless.
Too hard to ignore the benefits of cross-stack gains in Typescript/Python. The C# native phone, Blazor, etc just isn't quite there yet. Tried it at the last company, and full stack TS was just so much easier to do.
The reality is that the vast majority of startups don't make it. The #1 thing startups should be focusing on is hiring the right people and product velocity. TS just makes that easier in my experience.
† And Neovim occasionally, but I mostly use it for Typescript or anything that isn't F#/C#.
No, really, I'm facing more issues from Cursor based based on a year-old upstream version of VSCode than from this, heh...
They have customers who are startups and the 'got to have tools' folk like having lots of languages since they can onboard people who know anything-not-C# and benefit from the .Net library.
VS Code on a Mac works great and with the ability to run SQL Server in Docker you can have the old stack right there on your Mac.
Don't know how trustworthy is this but it seems like it never was on top30: https://hnrankings.info/45888620/
This has 74 upvotes and posted 16hrs ago.. @dang?
I've restored it to the front page and wound back the clock so it gets its rightful dose of front page time.
I love C# and .NET and I use them extensively but I dislike the fact that the framework still kind of forces you into OOP.
If you like to have a more functional workflow you have to roll your own stuff or wrap objects in functional constructs.
But .NET is excellent for startups because:
-it is very fast to develop in
-has excellent tooling
-it is batteries included
-generally you have ONE way to do things that is accepted by most developers
-documentation is very good
-it supports large codebases with ease
-community is large enough
-you can use it for many areas, from embedded, to high performance computing, to desktop, mobile, web backend and web frontend
-it is performant
https://hackernews.life/?s=top&id=45888620&t=1762939537
It arrived at rank 86:
I wish CPP development was as robust as C# development is
One of the reasons I am back to writing more C++ code is C++ addons for node.js, as several SaaS products now only care about Next.js as extension SDK.
Edit. I was not aware that the gap between System.Text.Json and Newtonsoft narrowed, take my comment with a grain of salt, please!
I don't get this mindset. I'd much rather have the new guy spend a few months getting used to a new language, than have an organization where everyone uses different languages. It's a nightmare a few years down the road when you have 20 different projects in 15 different languages and the people who built them are mostly gone.
People are way too lenient with this stuff IMO. The goal of an organization should be to have one solution to each problem. For example we use .NET for backend and React for frontend. You don't need anything else. People love to talk about the right tool for the job, it's all BS. You can make pretty much any kind of website using react and pretty much any kind of backend using C#. The only reason to choose anything else is preference.
And sure maybe you have some data science people who need python, thats fine. Just don't have one guy using Py, another using R and yet others using Matlab. That's just asking for trouble. Pick one, stick to it. If you're going to make a change then migrate everything. If it's not worth that then the new tool probably isn't such a big deal after all.
You can do that in .NET, too if you use Blazor for frontend.
It's a force multiplier when you have a small team of strong developers.
Newtonsoft.Json as the primary JSON serializer (at least in every place I've worked) has NOT been the case versus System.Text.Json for years. Though it certainly used to be the case.
Define “practically all”. I would accept “clear majority”.
But practically all? Nah. I mean the hot new areas for funding right now are AI and robotics neither of which are web!
I’m coming up on 20 years professional experience. Exactly none of it has been mobile or web! The programming field is so much bigger than HN likes to pretend.
I might be biased from having worked with production F#, but it feels more like functional is making its way into C#, as the general industry sees value in functional principles. So F# feels like its more here to stay?
Aah that explains it.
For some reason, .NET is extremely popular outside of major tech hubs (notably in Europe), where you're much more likely to work for (without loss of generality) Ikea than for Google.
Which I guess was the whole premise of the .NET ecosystem, so score one for Redmond, I guess!
Apropos, what do they do for fun? I'll probably never meet 100 .NET devs in my life so honest question.
The number of startups for whom that performance differential matters more than developer output is tiny.
Except...
this '''let! a = fetchA() and! b = fetchB()''' really puzzles me. Does C# have a high-level syntax for concurrency timing? [something that Java is strongly lacking, and that Typescript did solve with Promise.all(), which is an ugly syntax, from my perspective]
Any elaboration on this is very welcome.
Because there's a boatload of older .NET apps that have been using Newtonsoft for over a decade already and aren't in a rush to switch. Anything built on .NET Framework is likely to still use Newtonsoft.
Running TypeScript on the server is a well trodden path. It can be pretty fast too. Python on the client, not so much.
C# is a great language, it's now very modern and has the best parts of Typescript, while leaving out the bad ones.
It's also extremely fast and multi-platform.
It also doesn't have the fragmentation that Java or JVM langs has.
And it's also open source nowadays. I think Sillicon Valley hasn't caught up with those recent changes, I bet more startups would be using C# if they knew.
sure, but only if you're doing something that actually demands it - and actual innovation - instead of usual 'lets repackage XYZ as SaaS and growthhack' strategy.
It always has been a shitshow. It works well for the 90% cases, but in the 10% edge cases, things break. It becomes impossible to fix generation issues, you will often resort in working around issues in your backend/openapi code. Sometimes you report bugs upstream and hope it gets fixed. In the current project we are stuck on a ~2year old Orval version (a typescript generator from openapi) because some features broke or were removed in the latest version, and the entire monorepo (15+ LoB apps) wouldn't compile and would require major changes. This simply because a never version of the generator was broken/removed features previously present.
let! a = fetchA() and! b = fetchB()
See https://learn.microsoft.com/en-us/dotnet/fsharp/whats-new/fs...
Why C# doesn't have first class functions and can't go fully functional (and likely never will): Scala tried and its compiler is slow, even after so many iterations and new novel compiler ideas.
I like the way it is, and hope it doesn't change. Unless they could make this possible without making the compile process extremely slow.
Most of the backend logic is not related to serving data for the browsers, it's doing actual backend stuff - communicating to databases, APIs, etc.
Is Google search backend a web app? I think it's really stretching the term.
Most developers are not in such startups. There is a lot of boring software out there which is a website. Even for AI, the first company that comes to mind OpenAI is known for ChatGPT, a web product. Most of the AI companies are building web products.
There is also scientific programming, that feeds research and analysis. Weather reports? Statistics, etc.
And there is gaming.
Devops, infrastructure? Databases? Tools for artists? Most of those aren't web. And yes I've heard of Figma.
There are probably tens of categories I'm missing.
Web is still bigger probably, but I have a problem with the saying "practically all other development is web".
Documentation is vastly better compared to Java ones, it's like day and night, LINQ is vastly superior to anything that Java offered - but i haven't used java in a very long time. And every time i had to write java it felt like i went backwards in time by 5-10 years.
If i remember right Java's webserver beats ASP.NET in performance benchmarks but .net's one performance is good enough that it does not matter until you hit really big usercount - and at that point you usually have to rethink your architecture anyways.
But frankly .net is still mostly Microsoft Java but with better developer ergonomics in my opinion. It did shed a lot of overengineered OOP legacy from .net framework days though and we're seeing major performance improvements with every version.
I really, REALLY wish I was in another timeline where I could say in an interview "yes, I use Linux on my desktop and Rider for my IDE" without being seen as a traveler from outer space.
I enjoy working with modern C# way more than node.js but... that's it.
This is a pretty ignorant take.
Those older stuff are likely running newtonsoft.Json anyway.
There's also a load of .NET Framework applications still running Newstonsoft.
In c# I can evaluate complex linq data transformation in watch window in visual studio during debug, at fly.
In cpp I cannot. Not even nested evaluation is working.
I am pretty language agnostic and I am reasonably competent programming in C# (I worked with C# and VB.NET for about 15 years), Go, Python, TypeScript and C++ these days.
The issue with a lot of places that do C#/.NET stuff is that they will typically ignore new tech until it is officially blessed by Microsoft. You can have a piece of tech that everyone is using and works really well and it will be ignored if it isn't blessed by Microsoft.
The other issue with .NET is all the Microsoft gumpf that tends to come with it even with the newer versions of .NET.
I am also in the weird place of being a Linux user. I've had job interviews that wanted to do live coding exercise/take home code exercise and they expect you to do everything in Visual Studio with SQL Server.
Could you please elaborate? Are you referring to most .NET shops not straying away from Windowsland?
This sounds very close minded to me. It is certainly true that there exist tasks if not subdomains where some ecosystems are better than others. Using a hammer for everything might work for you if all your problems are nails. But that doesn't mean that all problems out there are nails
- Integrated ReSharper.
- Far better performance (it isn't even close)
- Doesn't take 30GB of disc space up. Visual Studio has been a massive disc space hog since forever. Rider is a few hundred megabytes IIRC.
- Less bugs (Visual Studio has been progressively getting worse).
- There was better tooling IMO around NuGET.
var pixels = new uint[renderers.width * renderers.height];
var pixels2 = MemoryMarshal.Cast<uint, ulong>(pixels);
pixels2[idx] = ...
Spans is such a fundamental tool for low level programming. It is really unfortunate they were added relatively late to the language. Now every new version includes a slew of improvements related to them but they will never be as good as if they were there from the start or at least as early as generics were.
In an article about .Net its fair to talk primarily about creating APIs and other internet focused uses.
Example:
Expected: "Oh, you're on Linux? I heard about Rider. We use Windows and Visual Studio here for parity. You're okay with that, right?" (me: Obviously, tools are tools)
Actual: "Does .NET run on Linux? What is Rider?"
I mean, .NET has been running on Linux since forever now (11 years according to https://news.ycombinator.com/item?id=9459513, let's say about 9 for stability because I feel generous). How do they not know about it?
They don't even know Rider exists a lot of the time. It is also quite different visually compared to Visual Studio code.
A lot of places have never used Linux at all and if they have they have it would be WSL or some RHEL box. So if you are screen sharing Gnome and with a totally different IDE and Terminal the person assessing you might not actually understand what you are doing.
> At least you can run SQL Server easily on Linux using docker.
1) They normally want you to use something like SQL Server Compact or SQL Server Express and a specific version. TBH I just don't bother anymore with these interviews because it takes like a couple of hours to get all this stuff working on Windows.
2) SQL Server Projects can only be used on Windows with Visual Studio. Some places do a lot of stuff "old school" and they want you to use that.
If you came to me for an interview, your story would have been a breath of fresh air. So maybe try to mention it anyway, someone will be interested.
As someone who has been developing primarily on .Net for the past decade this is absolute bullshit.
1. It’s only very recently that .Net became open source. Until then you would frequently hit issues where the only option was to rely on the few support calls you got with MS engineers with your $1000+ Visual Studio subscription to move forward. And believe me, this isn’t a pleasant way of debugging. 2. It’s only recently that .Net became cross platform. Until recently .Net meant you had to pay far more money for windows servers, get far less performance, and open your application to way more security issues. And when things broke they broke in highly inscrutable ways. 3. It’s still not a great platform. If you’re deploying on Windows, there are still things you will want to do that will require windows registry changes. 4. It’s only recently that the transition to an open source/cross platform framework has stabilized. Until now you had to deal with MS alphabet and naming goop, an absolutely muddy roadmap, and if you ever got thrown into a project you’d end up finding yourself in a mess of varying conventions, project types, incompatibilities, etc. 5. You know all those performance improvements they’re delivering with every release? There’s a reason for that. Until recently performance was so bad. Kestrel alone provider at least an order of magnitude of improvement. 6. Thank the lord for Jetbrains but other than them, to do proper .Net development you need to use Visual Studio. And Visual Studio is not a pleasant IDE or development environment at all.
There were a lot of technical reasons to not adopt .Net. Even today there’s the problem of MS losing interest or making the wrong choices and there being basically no alternative, because unlike even Java, the .NET ecosystem is completely dependent on what MS does.
Also, C# doesn't need nearly as many massive changes like project Valhalla because they got a lot of those design choices right from day 1 (mostly by looking at what Java did that was dumb and avoiding it).
[1]: https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
Good analogy. If, say, your organisation maintains a fleet of cars - it needs to keep them on the road, get them serviced, replace parts, refresh individual cars regularly etc.
How many different makes and models do you support? A small org might decide that it only makes sense to support one. A larger org might have the resources for 3 or 4, so that there is 1 or 2 "general purpose" models, and then other ones suited to specialised tasks.
.NET, unlike Go, has all needed management commands built into its CLI too: dotnet new {template}, dotnet add/remove package, dotnet sln add/remove, etc.
Eeeeeeh...it's not quite roses and rainbows on the Rider side either, and that's coming from a Jetbrains fanboy. (Although admittedly, I'm not really up-to-date on the current state of VS in day-to-day work)
But yeah, the coding/refactoring support (Resharper et al) and general quality and integration of tooling (database tools, package managers, version control, debugging (esp. multi-process) etc.) is the big one for me.
And all the 6-month-old on-line docs and tutorials aren't only useless, but time wasting.
I'm talking about general software development and web dev in particular. There's a trend where you'll see one org has or web app using .net ad react, another using next.js, another using Java and Vue, one djnago and htmx, and so on.
And there is literally no reason for any of these choices, they're all fairly basic web applications that could have all been made in literally any half decent web stack. So whether the devs who made these choices knew or not, they made them based on preference not any kind of reason or need, they're all nails and any hammer would have done the job just fine.
Every since they got rid of the Microsoft packages feed, it's just been a complete mess.
Ubuntu's own documentation states:
> .NET 10 will be available in the Ubuntu archive for Ubuntu 24.04+ and included in main upon its official release
But it isn't available?
That said I think you're exaggerating those complaints, the docs for C# are quite good imo and I've been working with ASP.NET web apps for half a decade so far and I'm not seeing any problems like you're describing.
Maybe you're miffed about the Framework to Core/.NET switch? That was a bit of a doozy but the ecosystem is so much better for it I'd say it was worth it.
I really like C#, but I wouldn't go that far - unions are at least on the horizon, but I've sometimes come to miss the power and flexibility of TS's structural typing...(And so has Hejlsberg, apparently, seeing his reasoning for choosing go over C# for tsc :) )
ASP.NET is the web part, no?
Yes, a lot of great features have been added over the years. But it also introduces some amount of cognitive load and confusion. Take the first new feature in the example:
> Field-backed properties simplify property declarations by eliminating the need for explicit backing fields. The compiler generates the backing field automatically, making your code cleaner and more maintainable.
Huh, I thought we have had this for years, what were they called, ah Auto-Implemented Properties- so why is there a need for this? In this example:
// Automatic backing field with custom logic
public string Name
{
get => field;
set => field = value?.Trim() ?? string.Empty;
}
get;
I feel like the documentation is always somewhat lacking in explaining the reasoning behind new features and how it evolves the language from earlier versions.
I'm saying use one tool for one task. One type of truck. One type of bicycle. Maybe some companies need both a small and a large truck. That's all fine as long as you actually need it.
Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.
This is indeed a complete exaggeration.
Obviously. IME it is better than Visual Studio.
> But yeah, the coding/refactoring support (Resharper et al) and general quality and integration of tooling (database tools, package managers, version control, debugging (esp. multi-process) etc.) is the big one for me.
I rarely use any of these tools tbh. I just want Resharper and something that works reliably on Linux. I would transition to using vim entirely but half the vim stuff I like using I can't use with Windows (work is never not going to use Windows).
These things to me seem like one faction in MSFT wants .NET to be an open platform and another faction wants it to be a sales funnel for Visual Studio.
That’s a radically different proposition than, say, raw OCaml and not particularly niche. It also impacts hiring pools differently since competent functional C# devs are viable, but it tends to appeal to a certain calibre of dev.
Moving faster with fewer errors and more talented candidate pool are relevant to repackaged SaaS startups too. Leaves more time for the other stuff and scales better.
Pros:
* Stability
* Very decent standard library
* Good balance between productivity and robustness
* Great package management
* Extremely easy to upgrade, so essentially free goodies (performance) every year or so
Cons:
* Very MSFT dominated (obviously)
* Subpar tooling outside of Windows (I'm looking at you C# Dev Kit)
* C# has way to many features, it feels bloated
* Culturally, it feels like .NET devs are less "passionate" about their work
* The freaking stigma of being a .NET dev: you will never be as cool as the guys who work with Node/Python/whatever
Edit: Also I'd like to add EFCore as one of the pros of the ecosystem. Hands down the best ORM. Others don't come close.
I'm just pointing out that no matter how cool the language is if it doesn't serve business needs(hiring, onboarding ,ease of replacing staff, target market) it won't be picked.
To the uneducated, C# is linked to Visual Studio.. the IDE.. and the Community edition if free as long as you are a student, open-source, and individuals. Professional and Enterprise are paid.
(Yes - there is Visual Studio Code)
Again, I am looking at this from the uneducated. With the above, as well as "going with other Microsoft products" things start to get more expensive. Need a database - should it be SQL Server? Should it be Windows Servers? etc.
Because of the above, I would not be surprised if Go is more popular especially for startups... alongside Linux, MySQL/Postgres, as well as other IDE or text editors. Sure.. I might agree that Visual Studio Code is suited for various programmers today.
Not suggesting you are wrong in any way. It's just the amount of money spent on Windows/Microsoft for small companies is rather large, compared to other alternatives that are just as good.
I can say that it has gone waaaaaay smoother than anyone would have thought. This is a decision (language switch) that the team has been putting off for a long time and simply suffering through some big time jank and complexity with TypeScript (yes, TS at scale becomes complex in a very different way from C# because it becomes complex at the tooling layer in an "unbounded" way whereas C#'s language complexity is "bounded").
Indeed, I think more teams should give C# a shot. My own experience is that C# and TypeScript at a language level are remarkably alike[0] that if you know one well, you can probably quickly learn the other. But the C# ecosystem tooling is more cohesive, easier to grok, and less fickle compared to JS/TS (as is the case with Go, Java, etc. as well).
There still remains a lot of mis-perceptions about C# and .NET in general and I think that many startups should spend the time to give EF Core a shot and realize how every option in JS-land ends up feeling like a toy. EF Core itself is worth the price of admission, IMO.
I don't think this is an valid comparison. There's a problem called technology sprawl, which is characterized by needlessly increasing maintenance needs and cognitive load and lower development speeds caused by the need to juggle multiple programming languages or frameworks. There is a fixed cost in maintaining each tech stack and even development environment, and you multiply that cost each time you think it's a good idea to introduce yet another programming language or framework.
> It's just the amount of money spent on Windows/Microsoft for small companies is rather large, compared to other alternatives that are just as good.
We have a full team using C# at a series-C, YC startup with every developer on Macs (some on Beelinks and Linux). The team is using a mix of VS Code, Cursor, and Rider. We deploy to Linux container instances in GKE on Google Cloud running Postgres.
There is no more tie in to Microsoft licensing than there is say for TypeScript. Yes, C# DevKit is licensed like VS, but if you don't need the features, then you can also use DotRush or just use the free C# Extension.
I'm just fondly remembering the ASP.NET MVC churn or more recently, Azure API whiplash.
No, they don't. You may believe that some frameworks or programming language are ideally suited for some particular tasks, but that is mainly dictated by your prior experience (or lack thereof). The truth of the matter is that a van can very well do the tasks you conceive for a car, trucks, bicycles, motorcycles, etc. If you go with a van, you avoid the problems of having to maintain car, trucks, bicycles, motorcycles, etc. This is called software engineering.
Ironically dotnet runs better on Linux/Mac systems in my experience. All our devs who use Windows for dotnet dev now use WSL2 as it matches production. We don't use any other 'commercial' Microsoft products like SQL Server or Azure. All postgres/redis/etc and deploy onto docker containers.
What do you mean?
And when the front-end is C#, it only makes sense to do the backend in .NET too so you can share classes easily.
Only in the "stove pipe industry" as we say here. Mobile gaming is massively C#-based for example and the people are really passionate about what they do.
And for a backend dev, the scale of stuff you get to work with is cool.
Odd question, but as a .NET developer myself
Mountaineering, climbing, bouldering, going to gigs, playing pool, running, music festivals, gaming, photography, watching F1, watching NBA, eating out with friends...
I'm not sure what the point of the question was ?
Yes I'm aware MS makes it easy to build containers and even single executables, but languages that compile down to an ELF are pretty much a requirement once your deployments are over the 10k containers mark.
With C++ it's a whole different thing.
Which is an analogy for "how many different programming languages for the same task of serving a web api can you company afford to support?"
The majority of programming languages (c# definitely included!) are "general purpose", i.e. they can be used well enough for almost all tasks. They're not so different as a truck vs. a bicycle.
The issue is not so much "we need firmware in Rust and statistical analysis in R" - that's fair! The issue is more, as others have said, web apps or similar in multiple equivalent languages. This is an overhead. If you take on that overhead, recognise that 1) it has definite drawbacks and 2) for mundane tasks, the advantages aren't large. and 3) chances are your organisation is like most orgs - you don't do all of firmware, statistical analysis and web apps, in house.
Yes, this.
> I'm saying use one tool for one task.
I saw an article ages ago arguing that the number of supported languages should scale with the size of the organisation. Which makes sense to me. The threshold was larger than we might expect though, it was something large like "one fully supported language per 500 devs". In other words, small-medium orgs will have a better time supporting 1 language only.
C#s adoption of language features shows their utility but they’re not a replacement, per se. Without a clear functional answer in certain language and parallel computing scenarios MS would be ignored. Scala and Kotlin are comparable answers to comparable pressures on the JVM, and even keeping pace there with new and exciting tools/libraries requires some proper functional representation on the .Net platform.
F# will disappear when/if those other languages do, and already has lots of what C# is chasing with a more elegant syntax. It inherits VM and project improvements from C#, so the biggest threat to long term investment is something like the crippling changes made to FSharp Interactive (FSI), during the .Net Core transition. Otherwise it seems to be in a safe place for the foreseeable future.
Go and Rust produce native binaries, I wish C# had an official native compiler without the big runtime needs of .Net.
Office Space took place there before the dotcom bust.
Less enterprisey, but John Carmack and id Software also started there.
Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.
archived version becasue original one gives 404
currently according to techempower benchmarks ASP.net is 55th overall in minimal variant, while being 83 in normal one in Fortunes benchmark which is basically a normal usecase.
While most java framworks oscillate between 10-30
https://www.techempower.com/benchmarks/#section=data-r23
EDIT: there's also an entry for aspnetcore at 35th
That TypeScript supports this is yet more complexity introduced to cover usages of an API not designed around types.
C# itself has way better DX (object initializers alone are worth the switch), and most language features don't feel bolted on like with Java (anything from functional programming to extension methods to whatever).
And at least 6 years ago .net with default settings required significantly less resources (RAM, CPU) and yad significantly faster startup than comparable Java code.
C# is also significantly more consistent. You might not use LINQ, but since everything is IEnumerable, you will use the same set of methods on everything. None of the Lis.of...Collectors.collect idiocy from Java.
I also found Asp.net to have significantly less undebuggable magic than Spring.
Most of the newer features make C# less cumbersome to use. I can't imagine using the language from ten years ago, in fact the first thing I do when working on a legacy app is to set langVersion=latest.
My biggest gripe with dotnet tooling is dotnet format. It’s not quick enough to use on a pre commit hook, so people don’t run it regularly and we get failures for it.
It’s such a small nit, dotnet is a great environment to work in
I know one person who was good at python, and who looked at the "classic" .NET hello world app with usings, namespace, class, main method etc containing the "Console.Writeline" payload, and noped out immediately, saying "if it's that verbose that it takes 10 lines to do what's 1 line in python, imagine how terrible real code must be!"
Personally I think they were wrong about that - it was optimised for larger programs, not trivial ones.
But also it helps me understand the ongoing push towards the point now where "hello world" is is 1 line in 1 .cs file only. And `dotnet tool exec` means you don't even need to install a utility to use it, etc.
In other words, .NET started life as a truck, with many features to support large codebases - usings, namespace, class, method etc. but is also general purpose enough that you can now also write a "bicycle" program.
If there’s one thing c++ is good at it’s bikehsedding where the responsibility for fixing this stuff is. When I started programming in c++ 16 years ago, modules were “imminent” and reflection was coming soon.
Modules are still unusable because what we’ve standardised is insanity and the standards committee refuse to make a decision to support the backwards compatibility of tooling and code that will never be upgraded or even used in a modern setting.
The compiler vendors blame the standards committee, the committee say that tooling isn’t their problem,and standardise something that has no theoretical objections but in practice requires deep concessions to the spirit of the idea. At the same time, they’re perfectly content to assume that everything is developed the way they imagine - adding ranges to algorithm and forcing the compile time because modules technically exist.
1. Process, process, and more process. Doing anything required layers of management approval. Trivial tasks become month long, or even years long, processes.
2. You have no power or agency. Something is broken? You're a developer, you should be able to fix it right? No. Broken things stay broken. You swim in your lane and keep your head down. Mediocrity is the goal.
3. Optimization doesn't exist. If a process is manual and takes you, a developer, 10 hours, then that's what it is. Nobody gives a flying fuck about tooling. Nobody cares if you spend 50% of your dev time doing random stuff. And if you even dare try to fix it, you will be told it's impossible and you're wasting your time.
4. Management is king. You will have to lie to them. You will have to spend time re-entering the same data in 5 different places so they can read it conveniently. You will have to make Excel workbooks. You will have to dumb things down, and then dumb them down again, and again. Everything is about Jira... Unless they're a really high up manager, in which case you have to take whatever is in Jira and put it in a word doc and send it to them, because they don't know how to open Jira.
From this perspective, I can't say I disagree as such. If you look at the full set of language features, it sure is a lot of stuff to know about. The argument that it is too much, and that we should sacrifice expressiveness and signal to noise ratio in the code to keep the language simpler, I don't agree with.
Thanks, fixed now. I literally just migrated from GCP to Hetzner over the weekend and was about to finish the migration today :)
Since Nadella took over, MS made some substantial steps forward: On Azure, around 30% is Linux; MS went cross platform with some of its most successful apps/ecosystems. Its not that MS behaving like a friend today, but their Dev-tools are really great - at least they care for Devs, i wish they would care for Office users as well.
C# + .NET is from my perspective the most developed and most mature eco system when it comes to business applications.
I really like it!
It is rarish to find a partial MS shop. Most of this is how hard MS makes it to use other tools. Even in 2025 they have good interop with external tools hamstrung.
Example: SQL Servers JDBC driver will convert an entire table's of data from ASCII to UTF and a full table scan instead of convertering your UTF bind to ASCII and using the ASCII based index. This doesn't break interop but does make it painful to code and one more reason to just use .Net.
If I judged every single company i worked at/interacted with, that uses NodeJs, I'd think that every single Node dev is a 13 year old child with no real experience but who think's he's the hottest shit. That has nothing to do with Node and doesn't really describe _all_ the companies out there.
Yup.
They are created by the same person but they are very different in my opinion.
TypeScript is "a tool" for JS, it is possible to compile without errors but still fail in runtime (e.g. wrong object type returned from API), on the other hand parsing JSON with C# will give you correct object type, it may fail if some properties are missing but it will fail at parsing call, not further down when you try to use missing property. In other words typing is not glued on top of the language it's core of the language.
Not native English - does "to the uneducated" means you are directing this sentence that knows no better or you are uneducated?
Because if it is former, you need to re-educate yourself.
C# is not linked to IDE. You can do `dotnet build`? Can run on Linux if you will. Database choice? You are NOT limited to SQL Server or Windows server.
There's been some work on CoreRT and a general thrust to remove all dependencies on any reflection (so that all metadata can be stripped) and to get tree-shaking working (e.g. in Blazor WASM).
It seems like in general they're going in this direction.
> To the uneducated, C# is linked to Visual Studio.. the IDE.. and the Community edition if free as long as you are a student, open-source, and individuals. Professional and Enterprise are paid.
> Need a database - should it be SQL Server? Should it be Windows Servers? etc.
> there are many smaller companies (and startups) that may have concern paying for such tools.
...
>> sure maybe you have some data science people who need python,
This is how it happens though; it's not "let's form a company with 10 developers; don't worry what tools they use!". It's starting with a single problem using common tools, then adding specialized problems where you could still use the same tools but they are not optimized, then adding an acquisition product that uses different tech, then growing to 100 or 1000 developers and may all use React or C# (doubtful) but don't use it the same way...
>> If you're going to make a change then migrate everything
Have you ever worked for a software company before? THis is not how it goes.
I tried .NET and liked C# as a language. But even though the language and runtime are now open source, it seemed like a lot of the recommended libraries were still commercially licensed, which was an immediate nope from me. I've never encountered that in any other ecosystem.
I'm a manager now but definitely held a variation on this "people are idiots" view when an IC and younger. Question: are all your coworkers idiots? No? then why would all the work done before you be the product of idiots?
I found it really valuable to approach scenarios where the initial response is "how could this possibly happen?" as a cultural anthropology question. It turns out there were many rational decisions made, most that I would have gone along with that brought us to what we see today. My coworkers are actually really good, some of them who manifested what we see today are amazing. Many are crafting code, making thousands of microdecisions without perfect information or 100% clarity across a large organization, reacting to changing markets and directions, client needs, shifting priorities, executive decisions, technology changes... the list goes on.
This is all my way of saying there might be many reasons for any of these choices, and you'll help your own cause - and happinness - if you step back from your zealotry and take an empathetic approach that's less binary.
.NET gets selected because a lot of non tech companies need to do software things, and they pick the stack fits in with their current WinTel stack. The main concerns is having replaceable talent to reliably do x. They're not trying to innovate. They are often doing something like sending out insurance quotes by email. They do this by having strict processes, and having developers stay in their lane. Expect rigid scrum, using dependencies only supported by Microsoft etc, Locked down Dev machines with visual studio only, ask for microsoft dev certs, and expect pre-approved enterprise design patterns up the wazoo. They don't want innovative developers, they want you to fit into the pre existing framework designed by an architect. Your skills can die in such an environment.
There are companies that use .NET that aren't like this, but you have to go out your way to find them.
Again, my comment is focusing on someone on the outside looking in.. and WHY people end up making decisions away from C# in favour of (something like) Go.
I am aware of deploying to Linux containers, etc.
So if we either stretch the fleet management analogy to 50 years, or software applications only lasted 3-5 years maybe it IS fair to say the both have either a lot (former) or very little (later) inconsistnency?
My comment is NOT talking about 'decent C# devs'
It is a RESPONSE as to why more people are not using C# for startups. For those who are not familiar with C# MAY be put off using it for those reasons... and why another language might be used.
People who already are familiar with C# know this. To programmers that do not, may prefer to stick with another language to keep away from Microsoft in general.
Again - my comment is a response about why C# is not used more for startups. I am not suggesting it isn't, but there are plenty of reasons, and this is likely just one.
I'm not a car guy but I most certainly a bicycle lover, so I will jump on you and say you often need more than one type of bicycle. Joan commutes to work? she wants a city ebike. Dan rides at the bike park? He wants a DH bike. Randy ride centuries on the weekend on his TDF road bike and Sally rides with her kids on a mountain bike.
So yeah, we can pick one bike type and force everyone to ride it, and the results will suck & everyone hate it. Your job can be to continually force everyone to follow this policy or you can stop and we'll get a lot of variation. THis is how it happens.
In my experience .NET/C# dwarfs pretty much any other framework in the SMB and there are WAY more software companies that aren't considered "startups" than those tagged as "startups".
Java was originally Sun Microsystems.
However - if Java was Oracle to begin with (and as successful in the mid-90s) then might have done some marketing for the Java+Oracle mix.
Some people (ie Managers) if they decide on using Microsoft products will likely "encourage" the use of C# and .NET. -- That is an example of C# + Sql Server.
same as c# - seems asp.net comes with a lot of stuff - but to use that stuff a lot of ceremony is baked in.
with Ruby | Rails i'm one or two commands away from most things I need. I understand the language & the ecosystem.
VS Code with Ionide is okay but has many limitations for example in debugging or lack of support for F# fsi scripts.
If you’re serious about F#, investing in Rider or Visual Studio makes a lot of sense.
Having said that I wrote a Neo4J data extraction tool a few months ago and chose to write it in F#. At one point I observed how funny it was that I was developing in a Microsoft language and yet my dev workstation runs Fedora and my IDE comes from JetBrains and my code is running in kubernetes on a Linux cluster and there is not a sight of a windows machine in this whole pipeline.
I remember the days when the language, linker, compiler, IDE, the GUI components, everything was tied together. If you wanted the next version of VB you had to buy the new version of Visual Studio!
I am pushing for Linux containers in the workplace... away from Windows, IIS, etc. I totally agree with you 100%. I'm also trying to push us away from SQL Server where possible.
Seems like a good update, though! And I'm glad it's early enough that updating the framework probably shouldn't break anything. Really as long as there's no issues with the DearImGUI dependency (would be a surprise!), I'm pretty happy about the update.
.NET gets refreshed annually. The last bigger change was nearly a decade ago. So not all that different.
But I don't think that the analogy stretches, really. e.g. where I am all .NET apps are .NET 8 LTS or 9, and will be all be .NET 10 LTS by middle of 2026. You can upgrade an app to a new model year much more easily than a vehicle. The "software application, on a SDK major version" only lasts 1-2 years.
Of course, if you expect a full FE+BE 'omakase' framework like Rails there isn't anything with the same weight. I began to see this as a plus, you actually don't need it all, and nowadays it's very modern to delegate auth to a service etc. I know it isn't DHH's PoV, but it makes it much easier to maintain, so you focus on writing business logic and do the FE in a widely supported framework like React, or use Microsoft stuff, your choice.
The DTOs/DI and the typical .NET developer stuff isn't bad or hard to learn, most of it comes naturally when you think "What would a statically typed language need?"
It's what allows C# code be very clean and easy to follow, where you know exactly what is available unlike Ruby that a lot of things are implicit and can get very nasty. After so many years debugging and improving Rails apps performance, I got sick of it and C# feels fresh.
Then there's LINQ and a lot of language sugar that makes C# code really beautiful. I've done also some Java, and can easily vouch for C#. It's the Ruby of statically typed langs.
And the speed, don't get me started. It's so fast.
I do my hobby .NET development in Zed and my serious work in Rider. .NET is open source and MIT licences. I do most of my development on a ARM MacBook Pro, or using my workstation which runs Fedora.
We deploy our code on kubernetes clusters usually on AWS.
All of the tooling, compiler, libraries etc are open source and cross platform and free. Not a single one of the developers in my team uses Windows or Visual Studio.
It's also well-suited for that. Of course, you won't end up with a tiny Go docker image, but this doesn't matter.
Why? I routinely put compiled .NET programs into containers.
It's also easy (easier than Rust even) to build on Mac targeting a Linux image.
What problems does this cause?
https://learn.microsoft.com/en-us/dotnet/standard/serializat...
I also write lots of Typescript, and the furthest I go is to use 'Omit' and other utility types, but already feel like it's too much.
I'm not inherently against it, we have a problem with opensource being asymmetrically underfunded and if people going commercial is the cost perhaps we've failed.
Most of our code is deployed on Kubernetes and runs on AWS.
Developer experience means many things to different people. Personally for my most recent project, I used F# and the IDE was Rider and my OS was a form of immutable Fedora (Ublue OS) with devpod and devcontainers and the whole system was the most joyous developer experience I think I have ever had.
Having worked on some basic parsing of metadata from PDF spec, I would rather pay than have to code something myself. PDF is such a PIA.
What was the last Java version you used? There has been a huge momentum in adding new features lately, granted, it is slower than in C# (Java's top priority is backwards compatibility, so it does not have the luxury of shedding old stuff or changing them once they are in), but in the last couple of years it has improved tremendously. The JVM (especially in the garbage collection front) but also the language - half of an ML-style language is there (for example, ADTs and pattern matching), the other half is coming soon!
Then if you have the chance, you'll find C# an easy transition from TypeScript, IME. Learning C# first, on the other hand, will make you a better TS developer, in my opinion, because it will shape your approach to be more diligent about using types. This is something most JS/TS devs do very poorly and at scale, it's very hard to reason about code when it requires digging down several layers to find the actual types/shapes.
"Enterprise" frameworks like Nest.js are much more similar to ASP.NET or Spring Boot than they are to Express, Hono, or Elysia so once having experience with .NET Web APIs (or Spring Boot) will make Nest.js (for example) easier to pick up.
The "force everyone to ride it" on the weekend part is where I think the analogy has broken down irreparably. We're talking about cost of ownership of company equipment used during working hours for much more defined tasks. What flavour of bike you enjoy riding on weekends is not relevant.
Programming language are inherently flexible, especially those that aim to be "general purpose". Fine-grained distinction of road bike vs mountain bike apply more to the apps created than the coding tool.
However, aren't Moq, Avalonia and MassTransit free software?
As for Automapper and MediatR, their owner changed from a free software license to only an open source one (Reciprocal Public License), but these are probably the simplest libraries of the ones you mentioned and have either been forked (MagicMapper) or have alternatives.
We have access to millions of libraries. I look at BEAM languages and OCaml every once in a while but can’t quite drag myself over there, knowing that in .NET, just as an example, I can choose between a dozen JSON serialisation libraries that have been optimised and tuned comprehensively for decades.
But then, those libraries are also our curse. If you consume them, everything is OO so you either give up on functional purity and start writing imperative F# code, or you have to spend time writing and maintaining a F# idiomatic wrapper around it.
Similarly I was working recently on project to develop a library which was going to have downstream consumers. The problem lent itself really well to domain modelling in F#. But I knew that my downstream users would be C# devs. I could invest the time and write my library as “functional core, imperative shell”. But then I decided that since the interface would be OO anyway, I might as well just write it in C#.
Thankfully what keeps F# going is the wonderful community around it, not Microsoft. I know some people (outside of Microsoft) have worked on a standalone F# compiler but it’s still very early stages. Maybe one day.
- TypeScript is like C#: https://typescript-is-like-csharp.chrlschn.dev/
- 6 .NET Myths Dispelled: https://medium.com/dev-genius/6-net-myths-dispelled-celebrat...
- The Case for C# and .NET: https://itnext.io/the-case-for-c-and-net-72ee933da304
Moq is largely unnecessary today with LLMs being able to easily generate mock classes. I personally prefer to hand-roll my mocks, but if you prefer the Moq-like approach, there's NSubstitute (3-BSD).
Automapper and MediatR are both libraries I avoided prior to the license change anyways, because I don't like runtime "magic" and not being able to trace dependency calls through my code. But, there is Mapster and Wolverine to fill those needs (both MIT). Wolverine can also replace much of MassTransit.
Telerik stuff - there are many good FOSS alternatives to these UI components; too many to list since it depends on which stack you're using.
PDF is indeed a sore spot. PdfPig is good, but limited in capability. I've started offloading PDF processing to a separate Python container with a simple, stateless Flask API with PyMuPdf.
> we have a problem with opensource being asymmetrically underfunded and if people going commercial is the cost perhaps we've failed.
Completely agree with this, though. My company and myself personally contribute a lot of time back to OSS, and I feel like that is part of the social contract of OSS. To have these libraries rug-pulled feels like a slap in the face as a OSS contributor and maintainer.
You could have:
public string Name { get;set; }
private string name;
public string Name {
get;
set { this.name = value?.Trim() ?? string.Empty; }
}
Nothing has ever forced anyone to depend on commercial libraries, there has been some upsets as people has closed-source previously popular opensource libraries.
But in the end, sometimes it feels like open-source in general is just waiting for a Jin-Tia moments everywhere, if people go commercial to prevent that happening that's just an indication that we've failed to create alternative ways of _living_ that can support open-source (this is probably most damning on companies that prides themselves on building on-top of opensource).
Heck, remember that tjholowaychuk created tons of (some popularly still used) npm packages early in the Node.JS lifecycle before first moving to go and then abandoning open source altogether.
The fact that large companies pick an established tech over newer ones isn't about .NET/C# per se, it's about large companies and the way they work.
Yes, that's right. It is in other words a way to access the compile-time generated backing field for auto-implemented properties. It is quite nice to be honest, I just wish they presented a bit of context in their announcements.
https://learn.microsoft.com/en-us/dotnet/core/diagnostics/de...
Moq has the appearance of free software but bundled some spyware stuff (seemingly "benign" "Sponsorlink" for getting donations).
Masstransit went commercial recently, https://masstransit.io/introduction/v9-announcement
Avalonia itself is opensource, but i'd put in in a fremium/shareware category since if you need to add an WebView or Media player you need to buy their commercial Accelarate additions.
libqpdf also intentionally limits its scope to PDF structure, so doesn't address nontrivial content creation or manipulation (page content handling is pretty much limited to compressing/decompressing and parsing/unparsing the content stream).
Their target is probably not entirely greenfield projects (although I wouldn't mind it myself), but rather those with existing investments that start new projects that still want to share some parts.
https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
But most developers are pretty bad. I see a lot of developers who hardly do any work at all, and many who do lots of work but it's all trash. Buggy, overcomplicated, untested, dumb pointless decisions.
Like my current project. Two guys started it - .NET backend, React frontend. Sure, fine. But let's use Azure functions for the backend instead of a regular web api. What. We asked them why, no reason. And their whole codebase was trash, I've deleted about 90% of the code that they had written and I'll delete the rest too.
I've also been in a team that had the problem I highlighted in the OP. 20 different apps, 10 different JS frameworks etc. Speaking as someone who worked on these apps, there was absolutely no reason to choose one JS framework over another. I could have made them all in React no problem, they're just websites, not much more than glorified PDFs. How you generate the html is irrelevant. And the code was mostly trash. Overcomplicated, buggy, untested etc.
I did struggle with this early in my career - am I just a narcissist? Everywhere I turn the code is just trash, maybe I'm the problem? But now I've worked with people who do good work. I've seen my own ideas work in practice. I know for a fact my judgement is good.
In university I was the one who helped everyone else. I was always ahead, while my peers could hardly keep up. When we graduated a lot of them would have struggled to solve fizzbuzz in 20 minutes, yet we all have the same degree. No wonder there's so much trash code around.
This is absolutely not my experience, especially when it comes to the ecosystem and third-party libraries. Like Java is pretty much the best in this category.
Java doesn't have extension methods and while both are decent languages, C# is the one that likes implementing every conceivable language feature immediately, while Java takes a while to design a bigger feature that will replace several smaller ones' use cases.
> a. Data Collection. The software may collect information about you and your use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may opt-out of many of these scenarios, but not all, as described in the software documentation. There are also some features in the software that may enable you and Microsoft to collect data from users of your applications. If you use these features, you must comply with applicable law, including providing appropriate notices to users of your applications together with a copy of Microsoft�s privacy statement. Our privacy statement is located at https://aka.ms/privacy. You can learn more about data collection and its use in the software documentation and our privacy statement. Your use of the software operates as your consent to these practices.
> You may not work around any technical limitations in the software:
> * reverse engineer, decompile or disassemble the software, or otherwise to derive the source code for the software, except and only to the extent required by third party licensing terms governing use of certain open-source components that may be included with the software;
> ...
> * share, publish, rent, or lease the software; or
> * provide the software as a stand-alone offering or combine it with any of your applications for others to use, or transfer the software or this agreement to any third party.
So you are not, for example, allowed to ship this in your application's docker image, you are in fact not allowed to redistribute it at all. So if you wanted to get a .NET debugger into your staging environment, you are not actually allowed to, unless you directly install it then-and-there with nuget. (I'm assuming we're talking about any type of enterprise context, where any given application is touched by contractors or employees from n>1 legal entities, so you are always distributing/sharing/transferring/making available).
Ya ya, I know you shouldn't have debuggers near prod, chiseled images, living off the land, yaddayadda. Regardless, it's needed or at least the easiest way at times, to actually be able to debug an application in staging or similar scenarios.
Also I'm not sure if e.g. blocking outgoing connections of the telemetry (even if by blanket policy) would already technically violate the license.
I'm thankful I've been along for the ride so I know the "archaeology" but pity those freshly dunked into its increasingly complicated ocean
Disagree. I would argue Java is more of a choice for "Enterprise".
Also, would you please define the scope of "enterprise".
If you mean "enterprise" as someone who want consistent and predictable management and productivity, then sure .NET is "enterprisy", because instead of a dragon they want a fossil.
But if you mean "enterprise" as they want to sell their core product, and sometimes that pushes to high developmental velocity with multiple development team to tackle on a feature, then .NET is evolving fast enough that it is not so considered "enterprisy".
Heck, even Ruby on Rails would replace .NET for that, especially when you consider the e-commerce scene that is either Ruby or PHP (Wordpress).
Just look at C# and its incredible language revision every year.
I'm sorry but most of us use Npgsql now
This is a solved problem within csproj to do dotnet publish to OCI containers already. I even have some csproj override to magically add it to every console projects in the solution.
The biggest problem IMO is because of the JIT generated code not being able to be saved, so it will always be regenerated on the fly, and compound that with a not so state-of-the-art GC (wish we have ZGC someday), it will create brief moment of latency very easily and making the timing fat-tailed.
NativeAOT and ReadyToRun remedies this problem by compiling ahead of time, but you trade space with time.
The overhead argument seems fairly objective to me - clean code with low coupling in C# et al. requires separate definitions of interfaces and implementations, explicit conversion methods between compatible interfaces etc. This adds up over time and makes refactoring pretty annoying.
The tight coupling happens when people don't bother to define interfaces. Suddenly I have to couple class hierarchy to classes from unrelated modules, all so the compiler is happy when I pass structurally equivalent data. To keep my own modules clean I have to add yet more interfaces, conversion methods etc!
I personally won't be using it, given the choice, again. I don't like exceptions, but can live with them. I don't like null, but can live with it. Nuget is complete and utter garbage. You still have to resort to all forms of unreliable hacks in order to redirect it to a locally clone (and if you do use a feed to avoid that, good luck with getting the local cache to not be completely moronic).
(Look, it certainly didn't help that the project itself was heavily enterprisey because the developers hadn't kicked those habits)
What exactly does this mean? I haven't touched .NET in earnest in over 10 years. I know the ecosystem has evolved a lot since then, but I don't know how or in what ways
For us, hiring .NET is WAY harder than the other stacks. We get a lot more applicants in general, but almost zero that meet our standards. For Python roles we get way fewer applicants, but the average quality is much much higher than the .NET average. (JS is a whole other thing, and we frankly aren't as good at hiring there yet)
"The main concern is having replaceable talent to reliably do X" as in every other company?
I swear you guys make having a regular job sound like being under slavery. It's just a job. Some companies are boring, that's just part of the job, and being able to adapt to different environments is what makes a good sde imo.
No it isn't. This is not how you end up with 7 different frontend JS frameworks in 7 different web applications. Using python/matlab/r for data science is completely fair. These languages are standard in this field, they have the most tools and built-in functionality for this purpose.
I mean if you want to do ML and data science stuff in C# or whatever go right ahead. If you can make that work that's great. But I also think, as someone who aggressively promotes sticking to one language, that it's fair to use Python for data science.
What I don't condone, as I said, is using multiple tools for the same task. So for example, having one team/dev using Python while another uses Matlab and yet another uses R etc.
> Have you ever worked for a software company before? THis is not how it goes.
Yeah, I know. That's the problem. People just introduce new tech like it's nothing. That's why I'm saying it needs to be a big decision. So if it's really worth it okay let's go for it. But for the vast majority of cases it just isn't.
I worked at a PHP shop, it was pure mierda. Worst code I've ever seen in my life. Pure incompetency. Does that say anything about PHP shops as a whole?
I agree that the commercial library offerings seem much more "in your face" with .NET but I don't find the actual breadth and depth of the free and open source library situation to be that troubling. It certainly continues to get better every year.
.NET is very "batteries included" as well so you don't need a huge base-line of competing open source packages just to do "hello world".
On the dotnet side, both Oxpecker and Giraffe (Giraffe being written by the author of that post) perform very well with simple code and from what I see, no "tricks". It's all standard "how the docs say to write it" code (muuuuch different than those platform benchmarks that were rightfully scrutinized in the referenced blog post).
On the jvm side, I started looking for a reference near the top without any targeted non-default optimizations (which is really what I personally look for in these). The inverno implementation has a few things that I'd call non-standard (any time I see a byte buffer I imagine that's not how most people are utilizing the framework), but otherwise looks normal. I recall an earlier quarkus implementation that I read through a couple years ago (same repo) that wasn't as optimized with small things like that and performed very well, but it seems they've since added some of those types of optimizations as well.
All to say: If you venture outside the standard of either platform (full fatty aspnet/ef or spring/hibernate) you can make the tradeoff of framework convenience for performance. However when it comes to the cost/benefit ratio, you're either going to be joining a company using the former, or writing your own thing using the latter (most likely).
I've never considered how lucky I am to live in the U.S. and to work at a company that absolutely sees the dev team to be a huge asset rather than another cost. The amount of time, money, stress we've saved by not allowing bad code to enter the code base.. I wouldn't have it any other way.
Also, I've had such great success hiring people without degrees. Truly some of our best contributors came from entirely different career paths. Same applies for some designers I work with.
1. The overall architecture (with the JVM) made it slower than the equivalent C# code.
2. C# really started embracing modern language features at a time when Java was kind of languishing (lambda functions, async patterns). Java seems like it's been in perpetual catch-up since then.
(Not OP, disclaimer, I work for Microsoft and this is only my opinion).
Nowadays, the ones I use have reasonable licenses and pricing, like ImageSharp. Free until 1M gross revenue, cheap afterwards. I support this type of dual licensing wholeheartedly.
There are plenty of real issues that are not the enterprise stigma.
I built a backend web api this year with it and C# is fantastic. EF Core is truly one of the best ORMs I've ever used. That said, I regret that decision and won't be using it again for any new projects.
Honestly it looks like Microsoft is distracted and doesn't really know what to do with .NET. Everywhere you look there are tons of half baked projects like Blazor, Identity or Kiota and progress in .NET is super slow. It's probably going to get worse now with all the AI crap.
Working there you aren't building the next Google, you're probably maintaining a some 20 year old order-to-cash ERP process that's boring, but critically important to the business, and is exactly the software you don't want to move fast and break.
Just don't go work for big enterprises if you don't want that environment. It won't matter what language/tech stack, it's just big non-tech company things.
But there's plenty of us out there that don't mind those jobs. Pay can be good enough, and usually offer great work-life balance. I work IT ops for one. I'm remote, I put in my 9 to 5 and I'm done. I'm (thankfully) not on call, I get unlimited PTO, and my personal time is 100% my own to go do non tech things with.
You will still need to integrate Vite somehow to use modern CSS, TS, etc. And if you do that, why even use Razor to begin with?
Also, hot reload is garbage. C# will never get close in speed or features to something like Vite.
But I would levy the same complaint with most Java[1] usage as well.
1. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
But startups aside, pretty much any company of significant size outside of the bay area/silicon valley is a Microsoft stronghold. It's an anomaly, not the norm, that so many companies in SV are on other stacks. Even for the non-tech workers (Google Docs vs. MS Office, macOS vs Windows endpoints, Slack vs. Teams, Okta vs. Entra ID or Active Directory, etc.).
When the entire enterprise's IT runs on Microsoft, you might as well pick an MS tech for the dev stack too.
I understand that you're getting a roughly 100mb dist directory for a .Net web app, and that it uses quite a bit of ram.. but people also use Node and Java which have similar issues.
Don't get me wrong on this, I'd like to use Rust+Axum a lot more and C# a bit less.. but I don't dislike C#.
Now the above is personal preference, while my day job is on Windows (also FE/Dapper) but with MS-SQL, which is because another group does DBA. I'm using VS Code for the work stuff though.
So you used C# without any of the .Net runtime? I don't think Microsoft did open source in 2002...
Even Mono was only started in 2004.
It was more related to the fact that the existing TS code was more easily ported to Go, and also .NET AOT wasn't mature enough at that time. Structural typing has its own problems. I'm personally not a big fan of it.
Then there's Django. Rarely changes, only for the better. Upgrading Django versions is usually painless too. The ORM is fine enough.
You need 10K containers for Node and Python apps because they use a single threaded runtime! The best way to scale these is to deploy many small containers.
The .NET runtime is fully multithreaded and asynchronous and supports overlapped I/O. It scales to dozens of cores, maybe hundreds in a single process. The built in Kestrel server is full featured including HTTP/3 and TLS 1.3! You don’t even need NGINX in front of it.
Not to mention that unlike most Linux-centric programming languages, it deploys reliably and consistently without needing the crutch of containers. You can simply copy the files to a folder on the web server(s), and you’re done. I’ve actually never seen anyone bother with containers for an ASP.NET web app. There is very little actual benefit, unlike with other languages where it’s essentially the only way to avoid madness.
PS: Every Node app I’ve ever deployed has been many times slower to build and deploy than any ASP.NET app I’ve ever seen by an order of magnitude, containerised or not. Go is comparable to C# but is notably slower at runtime and a terrible language designed for beginners too inexperienced to grok how exceptions work.
C# still doesn't see itself as a functional programming language, even as it has added so many features. It may never get first-class currying or the broader ideas like generalized computation expressions, for instance. It certainly won't get F#'s cleaner syntax with fewer mandatory semicolons and whitespace nesting rather than curly brackets.
F# probably isn't going to disappear for a lot of similar reasons that GHC (the Glasgow Haskell Compiler) didn't disappear when F# was started (nor when key contributors left Microsoft). F# often already sees more outside open source contributors than contributions from Microsoft employees.
Java is quite busy also implementing features that are small in other languages like text blocks.
And I wish Java would design bigger features that would replace several "smaller ones", but that is almost never the case. It's almost always just a new big feature bolted on to the language that is almost there, but not quite
There are many reasons for that, none of them simple, and it doesn't help that there's also the attitude of "those lesser languages cannot compare to the greatness that is Java" [1]
If we're talking about Java, somehow you're still required to do builder patterns and manually create `.of` constructors for everything. Where C# has had object initialisers and pervasive IEnumerable with a very simple interface that nearly everything uses. And that is only scratching the surface of DX.
Almost every feature bolted onto Java seems to take several times more code, and doesn't really work with the rest of the language.
Don't get me wrong, I quite like working with modern Java. But I had the chance to work at a company where micro services where developed in both Java and C#, and the difference is still light and day.
[1] https://news.ycombinator.com/item?id=28985688 "our goal isn't to adopt the strategy of less successful products, but to forge our own"
Anyway, I've used EF at work for about a decade and I'm happy with it. I surely have blind spots since I haven't used other ORMs in that time, but some things I like are:
- Convenient definition of schema.
- Nice handling of migrations.
- LINQ integration
- Decent and improving support for interceptors, type converters and other things to tailor it to our use cases.
What ORM do you prefer, and how does it differ by being stateless? How does saving look like, for example?
> Nuget is complete and utter garbage. You still have to resort to all forms of unreliable hacks in order to redirect it to a locally clone
How so, you can use a nuget.config in your project and use your local packages fairly easy, seems in part with npm and the likes.
We used Blazor years ago and it worked flawlessly already then. Hard to believe it's worse today. And what's wrong with Identity?
>progress in .NET is super slow
Compared to what?
[1] https://devblogs.microsoft.com/dotnet/dotnet-sts-releases-su...
I haven't tried it because it has generally seemed easiest to use the new attributes. Though a large part of that is the shift from the WCF-era "opt-in" approach of DataContract/DataMember [0] versus the "opt-out" JsonIgnore approach where most of the transition is deleting lines because JsonIgnore is the exception rather than the rule. You could even keep DataContract/DataMember during the transition and just take an additive approach for JsonIgnore.
[0]: It was a good idea, in theory, but so annoying in practice.
I don't think Microsoft doesn't know what to do with .NET. I think it continues on a very logical and direct path. But they have no idea what to do with UI on any platform. Luckily they haven't even deprecated any of the existing options and on the web, at least, you have all the same options as every other platform.
Razor is still the "default" and "Razor Pages" has a different brand name, but just means "Razor with more things in the main .razor file and fewer code-behind .razor.cs files and less of an MVC approach".
Blazor mostly only matters if you want your frontend to also be Razor. At that point you've got the fork between Blazor using SignalR for HTML pipes from Razor files to the client versus Blazor running client-side in WASM with a Virtual DOM renderer based on Razor.
Blazor seems popular among some groups that want everything in C# rather than needing as much of a Typescript frontend. Blazor WASM bundles a full version of the CLR into WASM so mostly only popular in places where you don't need to optimize the initial web bundle.
Yes, again, you're criticizing the practices of enterprises not dotnet. It has nothing to do with how "dotnet shops operate".
I'm at a dotnet shop who doesn't work anything like that. I've been at multiple of them. It has nothing to do with dotnet itself.
Oh absolutely. It's a business decision. It just so happens that it's framework that has been around awhile and has a decent bit of support. Give Node another 10 years and that landscape might start to change.
Another popular library that went commercial is FluentAssertions, Shouldly is a good open-source alternative.
.NET was literally created to replace the Java enterprise ecosystem. It never managed to completely displace it, but effectively gained around half of the enterprise market - and it will take more and more, after Oracle started pulling their usual boa-constrictor moves. C# is as "enterprisey" as they come, and it went full-opensource only once it became a requirement even in the enterprise.
> Just install
Not on Debian? Have fun with that. You'll also need the Azure SDK. And what about openssl-dev? Oh no, you installed dotnet on Windows instead of within WSL? Start again.
No, you don't "just install" the SDK. There is a lot that the IDEs set up for you.
> Local nuget.config
I don't see how adding a nuget config improves anything. You have completely omitted what you place inside of it to make it build and use a local clone of the package source.
Look at all this nonsense that people have resorted to: https://stackoverflow.com/questions/32482746/how-to-temporar...
Java is fast and reasonably safe. It has a lot of software (especially OSS) software. Its package system (Maven and the like) is ok, but not great. The language occasionally gets new features, but change is slow.
To a first approximation, C# is a lot like Java, so it is relatively easy to switch. But C# is, hands down, a better language. The most obvious thing that a developer might notice that that C# does not force you to be extremely verbose like Java, although you can code in the Java style if you like.
Having switched my course from Java to C#, the most obvious "win" was the fact that, every lecture, I would delete some slides that explained painful Java corner cases to students. For example, Java's implementation of generics. Boxed types are necessary, and explaining them to students who have never seen any form of polymorphism before is difficult. After an entire semester of deleting a handful of slides each lecture, I have save _three entire lectures_ worth of corner cases!
Some C# niceties:
* Everything is an object, even value types! So our favorite `ToString` and `GetHashCode` methods, etc, are all there. * Generics work as you would expect with very few weird corner cases. No boxed types because... everything is an object! * The last two facts mean that you also get generic arrays, which are fantastic (and, incidentally, are also _implemented_ in C#, which is super cool). * By default, reference types are not nullable. This is a little bit of a pain for an intro data structures course (we turn them off), but it is a great idea for commercial programming. * switch statements work the way you would expect a modern switch to work, and in some cases they even do exhaustiveness checking like a functional language. * Speaking of... LINQ! * In general, the standard library is also better organized. Interfaces start with "I". Collections libraries have been carefully designed and learned many lessons from Java. A good example of an improvement over Java is the IEnumerable<T>/IEnumerator<T> class, which is simpler than Java's Iterator<T>. * Type inference is limited compared to a functional language, but it is dramatically better than Java. Being able to write `var` is wonderful. * Properties are really nice, and the shorthand syntax for property getters/setters saves a lot of time. * C# has a rich set of value types, including structs. Java may have added something like this, since I remember the Scala people hacking away on it, but it is used pervasively in C#, and you can make very fast data structures that take advantage of spatial locality. Rolling one's own hash table implementation in C# is actually kind of fun. * .NET's runtime reflection capabilities are amazing. All of my autograders make extensive use of reflection instead of forcing students to compile with interfaces; this gives them a degree of freedom in implementing things. * NuGet is a million times easier to use than Maven.
The downside is that C# is definitely not as fast as Java, in particular when the runtime is starting up. I remember how painful Java startup used to be, so I am optimistic that this will improve eventually.
Anecdotally, my students this semester are demonstrably more capable programmers after a semester of C# than a semester of Java. It might just be that I got lucky with this group, but I have been teaching this same course (except in Java) for the last 7 years, and this feels like a real effect.
While Blazor has some cool stuff built in, the cool stuff never felt worth the risk of building a product around it.
Granted, one could probably build some of the machinery memory management in a simple way but it'd still need to be done and probably not be coherent with other native interfaces.
The answer is always a variation of "yes, you'll be fine, but also look at a "what's new" summary for the new version.
It sounds like you’re projecting the problems of an existing .NET shop onto the shape of a startup without all that baggage. I can assure you, having worked with many customers running new business on newer .NET, it hasn’t been a legit technical concern since about .NET Core 3.
Wayyyy back in the day, before package managers were a thing, I had to write something to output a PDF via DLL calls and frankly it wasn't a bad experience. Possibly outside of what is in a 'modern' workflow but honestly wasn't too difficult. Just wrap it all in a class that only gives what you need and avoids potential footguns via validation.
Frankly it was easier than doing anything with Autocad's 'managed' libraries [0].
Maybe it's rose colored glasses for me, but .NET had fairly simple rules for most marshal bits so long as you knew them, although I will admit we didn't worry about 'performance' for the stuff I wrote and that can be a factor.
[0] - Microstation had a bunch of fancy COM hooks and exposed all of it to .NET in a nice way. AutoCAD 'managed' libs had all sorts of weird sorts of arcane rules and if you failed to follow them not only could you crash your .NET process but Autocad could remain unstable until you rebooted the PC... which is why I keep putting managed in air quotes.
docker pull mcr.microsoft.com/dotnet/sdk:10.0 - Refers to Ubuntu 24.04 "Noble Numbat"
docker pull mcr.microsoft.com/dotnet/sdk:10.0-noble - Refers to Ubuntu 24.04 "Noble Numbat"