[HN Gopher] .NET 10
___________________________________________________________________
.NET 10
Author : runesoerensen
Score : 476 points
Date : 2025-11-11 15:44 UTC (1 days ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| jitbit wrote:
| For us, every .NET upgrade since .NET 5 has gone surprisingly
| smoothly and reduced CPU/RAM usage by 10-15%.
|
| 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.
| oaiey wrote:
| Can only confirm that. Such a smooth platform overall for web
| and API development. We use it with several 100 devs on it and
| the choice never failed us, neither in technology or hiring.
| And it is not that we have .NET gurus or anything.
| balamatom wrote:
| I'm sorry, I just remembered the few .NET maxis I've shared
| hours with and tried to extrapolate a whole company full of
| them. I'm sure they must work great with each other.
|
| 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.
| LandR wrote:
| > Apropos, what do they do for fun?
|
| 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 ?
| recursive wrote:
| > what do they do for fun?
|
| Play in a band, ride bikes, play video games. Sample size
| of one.
| larrik wrote:
| As a counter-point, my company was original purely .NET, then
| added Python (and later JS).
|
| 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)
| zerr wrote:
| Do you measure that standard by leetcode?
| catlover76 wrote:
| > 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.
| mrsmrtss wrote:
| You can run .NET natively on Mac, if you wish. I would also
| recommend JetBrains Rider over VSCode; it works on Linux,
| Mac, and Windows and, in my opinion, is better than Visual
| Studio anyway.
| nozzlegear wrote:
| I use Rider+ daily to write F# and C# on my Mac. It works
| great, I have no issues with it. It even handles the .NET
| Framework 4.8 code++ that I maintain without any issues
| thanks to Mono.
|
| + And Neovim occasionally, but I mostly use it for
| Typescript or anything that isn't F#/C#.
|
| ++ https://github.com/nozzlegear/shopifysharp
| phillipcarter wrote:
| Rider is your option there, it's better than Visual Studio (I
| used to work on VS).
| starvar wrote:
| How is it so different than Visual Studio that you think it
| is "better"?
| Deukhoofd wrote:
| I switched over entirely to Rider as well, in my
| experience it's far more performant, has a far smoother
| UX, has a lot more functionality for power users, and
| includes Resharper by default, giving you access to a
| bunch more powerful inspections and refactoring.
| Semaphor wrote:
| Offers essentially everything VS does + everything
| ReSharper does. I switched after years of using VS + R#,
| and have never looked back.
| cyptus wrote:
| performance!
| throwuxiytayq wrote:
| Pick literally any Visual Studio feature. Rider does it
| better.
| SparkBomb wrote:
| I've used Rider for several years now on and off.
| Generally I would put these at the top of the list.
|
| - 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.
| dahauns wrote:
| >- Less bugs (Visual Studio has been progressively
| getting worse).
|
| 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.
| SparkBomb wrote:
| > Eeeeeeh...it's not quite roses and rainbows on the
| Rider side either, and that's coming from a Jetbrains
| fanboy
|
| 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).
| zigzag312 wrote:
| Much better UX and integrated ReSharper.
| whstl wrote:
| Yep.
|
| VSCode gets you 90% there.
|
| But IMO Rider gets you over 100%.
| jitbit wrote:
| I'm founder of a 100% .NET based company (15 years, 1mil
| LOC), all development happens on Macs, production servers run
| linux. No issues so far.
|
| No, really, I'm facing more issues from Cursor based based on
| a year-old upstream version of VSCode than from this, heh...
| clintmcmahon wrote:
| There used to be a Visual Studio for Mac (since retired) but
| they never could get it right in comparison to the Windows
| version.
|
| 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.
| debugnik wrote:
| They couldn't get it right because Visual Studio for Mac
| was actually a rebranded MonoDevelop, an entirely different
| IDE than Visual Studio.
| phito wrote:
| I have a much better dev experience on Linux/Rider than on
| Windows/VS.
| aryonoco wrote:
| I work at a large enterprise where most of our backend js
| .NET and I can tell you that the dev team is nearly half and
| half split between Linux and Mac, and nearly half and half
| split on using VS Code and Rider.
|
| 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.
| leetharris wrote:
| > I wish .NET was more popular among startups, if only C# could
| get rid of the "enterpisey" stigma.
|
| 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.
| phillipcarter wrote:
| Is it though? Backends can be any language and there's a lot
| more variety there -- TS+node, Go, Python, Java. It's just
| .NET that's largely ignored for no real technical basis.
| cebert wrote:
| You can easily use the same types and libraries in your
| backend and frontend with TypeScript. It's not at easy with
| dotnet.
| phito wrote:
| OpenAPI and client generators solve this issue easily.
| robertlagrant wrote:
| No, that's not true. If you share code like this then you
| can do things like put the same validation code in the
| frontend and the backend: frontend to give a nice user
| experience, and backend to protect the endpoint.
| littlecranky67 wrote:
| OpenAPI does support patterns for fields and
| nullables/non-nullables - that already gets you very far
| regarding validation. A decently sophisticated generator
| (which don't exist IMHO) would generate the validation
| code for your respective language.
| robertlagrant wrote:
| True, but you can get all the way to zero duplication if
| you write it directly and share that code.
| cies wrote:
| Or GraphQL.
|
| Still one lang on both ends is nice: there are some bits
| of code you want to run on both ends (like templating for
| SSR/SEO/caching; but also using them in the browser).
| josephg wrote:
| Still more work than just running the same code
| everywhere.
| littlecranky67 wrote:
| I would love this to be true, but it isn't. I've done
| generating types for the frontend multiple times,
| sometimes from C# (around 2016, using typelite), Java
| (openapi template generator) and most recently straight
| from OpenAPI spec files (.yaml) using Orval.
|
| 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.
| pjmlp wrote:
| While suffering the performance loss of V8 versus CLR,
| JVM or any compiled language.
|
| 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.
| petesergeant wrote:
| > While suffering the performance loss of V8 versus CLR,
| JVM or any compiled language
|
| The number of startups for whom that performance
| differential matters more than developer output is tiny.
| pjmlp wrote:
| Yeah, except plenty of them are probably using Kubernetes
| and NoSQL, because everyone dreams to be Google.
| DeathArrow wrote:
| >You can easily use the same types and libraries in your
| backend and frontend with TypeScript. It's not at easy
| with dotnet.
|
| You can do that in .NET, too if you use Blazor for
| frontend.
| SparkBomb wrote:
| It really depends where you are. In the UK half the places
| seem to use .NET in some form or another.
|
| 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.
| mrsmrtss wrote:
| Why would they insist on using Visual Studio? At least
| you can run SQL Server easily on Linux using docker.
| SparkBomb wrote:
| > Why would they insist on using Visual Studio?
|
| 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.
| hshdhdhj4444 wrote:
| > It's just .NET that's largely ignored for no real
| technical basis.
|
| 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.
| phillipcarter wrote:
| By recently you mean a decade ago yeah? I mean it's fair
| that it was only a half-decade (.NET 5) when it was
| genuinely complete enough, but lots of stuff was in good
| shape when it was called .NET Core.
|
| 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.
| pier25 wrote:
| > _Backends can be any language_
|
| In +90% of cases you will still need a frontend for that
| backend.
|
| TS full stack is _by far_ the best option for this.
| phillipcarter wrote:
| Not really? Having come deom a TS + Go startup it's
| pretty trivial to wire up domain objects across each
| language and define a clean API boundary with some
| enforcement at build time. And Go was a far better choice
| for the backend than TS for some lower-level memory
| considerations.
| pif wrote:
| I wish people stopped conflating web programming with the
| whole realm of software development.
| charcircuit wrote:
| If you ignore Android / iPhone, where language choice is
| limited, practically all other development is web.
| forrestthewoods wrote:
| > practically all
|
| 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.
| adastra22 wrote:
| The majority of software is probably Excel macros.
| egeozcan wrote:
| This probably isn't true but I want to read a super geeky
| dark sci-fi novel that explores this topic.
| charcircuit wrote:
| >I mean the hot new areas for funding right now are AI
| and robotics
|
| 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.
| johannes1234321 wrote:
| That is software with a web interface. Only a small part
| of OpenAI's work deals with web related things.
| defraudbah wrote:
| how dare you, i summon 10 js engineers from openai to
| downvote you (they have 6 only)
| gishh wrote:
| Sure isn't.
| adastra22 wrote:
| Get out of your bubble.
| fuy wrote:
| It's web in a (limited) sense that there's probably a web
| frontend somewhere, but this "somewhere" is usually
| pretty far away from where most of the code is developed.
|
| 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.
| egeozcan wrote:
| Most of your electronic devices work with embedded
| software. Production lines, transport gates, cranes,
| computer hardware, ships, planes, rockets, cars, e-bikes,
| smart lights...
|
| 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".
| hshdhdhj4444 wrote:
| I really doubt you're using .NET (it literally is named
| in the dotcom style and refers to the interNET) in
| embedded software.
|
| In an article about .Net its fair to talk primarily about
| creating APIs and other internet focused uses.
| master-lincoln wrote:
| And you just deduct that from the name? Was .NET created
| with a focus on web? It seems to me like a generic
| application framework.
|
| ASP.NET is the web part, no?
| delta_p_delta_x wrote:
| > practically all other development is web
|
| This is a pretty ignorant take.
| greener_grass wrote:
| What are the cross-stack gains of Python?
|
| Running TypeScript on the server is a well trodden path. It
| can be pretty fast too. Python on the client, not so much.
| vintagedave wrote:
| .Net is also good as a platform for other languages. I recently
| started working with RemObjects, and you can compile languages
| like Java, Swift, Go and more (VB, Pascal) to .Net. Then, the
| whole framework and ecosystem is available. I'm liking it a
| lot.
|
| 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.
| sfn42 wrote:
| > they can onboard people who know anything-not-C# and
| benefit from the .Net library
|
| 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.
| netdevphoenix wrote:
| > People love to talk about the right tool for the job,
| it's all BS
|
| 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
| mhfu wrote:
| If your organization has one API written in Node, another
| in Java and third in Python without any reason, then yes,
| all the problems are nails. And sadly, I've seen this a
| lot.
| sfn42 wrote:
| If you can justify with good reasons why you absolutely
| need this other tool then that's fair game - hence the
| data science example where I allow for specialists to use
| specialized languages for specialized tasks.
|
| 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.
| skeeter2020 wrote:
| >> And there is literally no reason for any of these
| choices
|
| 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.
| sfn42 wrote:
| Some of my coworkers are awesome. Super talented, super
| smart people.
|
| 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.
| Razengan wrote:
| Do you also make everyone wear the same clothes, drive the
| same vehicle, order the same food
| SideburnsOfDoom wrote:
| > Do you also make everyone drive the same vehicle
|
| 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.
| Razengan wrote:
| But different tasks require cars, other tasks require
| trucks, vans, bicycles, motorcycles..
| sfn42 wrote:
| Yeah, .NET is a truck and React is a bicycle. Nobody sad
| you can't use different tools for different tasks.
|
| 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.
| SideburnsOfDoom wrote:
| > Just don't let every dev choose their own because
| you're gonna have a hell of a time maintaining that
| fleet.
|
| 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.
| SideburnsOfDoom wrote:
| > Yeah, .NET is a truck
|
| 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.
| skeeter2020 wrote:
| >> Yeah, .NET is a truck and React is a bicycle
|
| 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.
| pixl97 wrote:
| Eh, no, you don't hire those employees. You're stretching
| this analogy in some odd ways.
| SideburnsOfDoom wrote:
| Well, they clearly all know how to ride bikes, so you
| offer to hire them to deliver using company bikes as a
| day job. And let them ride whatever they want on
| weekends.
|
| 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.
| locknitpicker wrote:
| > But different tasks require cars, other tasks require
| trucks, vans, bicycles, motorcycles..
|
| 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.
| SideburnsOfDoom wrote:
| I think that question is more "how many different makes
| of van can your delivery company afford to maintain?"
|
| 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.
| skeeter2020 wrote:
| Car models get maybe refreshed annually, bigger changes a
| couple of times a decade, if that. Vehicle fleets are
| often aging out with these timelines.
|
| 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?
| SideburnsOfDoom wrote:
| > Car models get maybe refreshed annually, bigger changes
| a couple of times a decade, if that.
|
| .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.
| stevefan1999 wrote:
| but they all _delivers_ , just that they don't suit your
| taste doesn't mean it can't
| locknitpicker wrote:
| > Do you also make everyone wear the same clothes, drive
| the same vehicle, order the same food
|
| 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.
| ourmandave wrote:
| It's bad enough when you've got constantly changing "best
| practices" from MS so the thing you wrote last year doesn't
| look anything structurally like what you're doing now.
|
| And all the 6-month-old on-line docs and tutorials aren't
| only useless, but time wasting.
| sfn42 wrote:
| So you don't like .NET, that's fine. I'm not saying
| everyone needs to use .NET. I'm saying pick one thing and
| stick with it.
|
| 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.
| SideburnsOfDoom wrote:
| > the thing you wrote last year doesn't look anything
| structurally like what you're doing now... all the
| 6-month-old on-line docs and tutorials aren't only
| useless, but time wasting.
|
| This is indeed a complete exaggeration.
| ourmandave wrote:
| Sorry, I love .NET and have used it from it's rollout
| back in 2002.
|
| I'm just fondly remembering the ASP.NET MVC churn or more
| recently, Azure API whiplash.
| SideburnsOfDoom wrote:
| Online forums often have people asking "hey I found this
| tutorial for learning c# but it's way way back for .NET 7
| will it even work in .NET 9?"
|
| 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.
| to11mtm wrote:
| I get you actually.
|
| MVC churn was real, EF Churn was real, heck NETCORE
| itself was a (at least warned about) churn, 3.1->6.0 was
| minor but still definitely a thing [0].
|
| [0] - Now that I'm thinking it out loud, maybe that's why
| they changed the branding from .NET CORE to just .NET;
| The churn was more or less 'done'...
| jelder wrote:
| Using the right language for the problem domain is a good
| thing, but what I can't stand is when people self-identify
| as the one language they are proficient in. Like, "I'm
| Staff JavaScript developer" no buddy, you aren't "Staff"
| anything if you only know one language.
| skeeter2020 wrote:
| >> we use .NET for backend and React for frontend. You
| don't need anything else
|
| ...
|
| >> 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.
| sfn42 wrote:
| > This is how it happens though
|
| 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.
| randyburden wrote:
| For what it's worth, the startup I currently work for is built
| entirely in C# and .NET, as was my previous employer. Both
| startups are based in the Dallas, TX area. Across both
| companies, applications were hosted on Azure and AWS using a
| mix of PaaS services and virtual machines running Windows and
| Linux. We've consistently found this stack to enable strong
| productivity and high-velocity release cadences.
| DeathArrow wrote:
| At my current workplace we use a mix of on premise servers
| and Azure but at former workplaces we deployed to Google
| Cloud and AWS.
| miki123211 wrote:
| > Both startups are based in the Dallas, TX area.
|
| 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.
| cheschire wrote:
| The Dallas area _is_ a major tech hub. It's just an older
| hub of major enterprisey type companies with major tech
| divisions there like Texas Instruments, AT &T, Bank of
| America, defense contractors like Lockheed, etc.
|
| Office Space took place there before the dotcom bust.
|
| Less enterprisey, but John Carmack and id Software also
| started there.
| raw_anon_1111 wrote:
| I lived and worked in Atlanta from 1996-2020. Those
| aren't anymore tech companies than Delta, Home Depot or
| Coke by modern definitions. In all of the companies you
| named, software development is a cost center, not a
| profit center - follow the money. Who gets paid the most
| as a group at those companies? Those are enterprise
| companies.
| cheschire wrote:
| You're saying the same thing I did yet somehow you're
| trying to argue with me about it.
| tinyspacewizard wrote:
| Start-ups should strongly consider F#.
|
| It's a force multiplier when you have a small team of strong
| developers.
| Xelbair wrote:
| >startups should consider niche language with extremely
| limited hiring pool.
|
| 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.
| dude250711 wrote:
| It's good for, and I am not being sarcastic or snarky,
| justifying high pay and gate-keeping. Developers should set
| up more barriers for entry - look at doctors and lawyers.
| stiiv wrote:
| I think I agree with you. When I was part of a growing F#
| team a number of years ago, everyone we hired was an
| enthusiast who just loved coding in F# and wanted an
| opportunity to do it professionally. It turned out that
| this love, combined with the constraints of the language,
| led to a super-clean and legible code base. The quality
| was (in my estimation) outstanding, and I was sad to
| leave it.
| z500 wrote:
| As an F# lover my heart sank at that "it turned out" at
| first. I'm glad someone got to live the dream somewhere
| haha
| banashark wrote:
| I'm at my current company (actually writing mostly
| typescript and node services now) because of a YC "who's
| hiring" post that mentioned F# positions (bait and switch
| /s, but my experience lined up heavily with the team I
| ended up joining which didn't use F#).
| Xelbair wrote:
| Sure, but that's a 'need' from programmers side - not
| from business side.
| bonesss wrote:
| F# is less popular, but it's a first class .Net language
| with full MS support and integration onto .Net (VM and
| ecosystem). C# has been tracking F# and aiming for language
| parity for years (ie all your modern C# devs should be
| learning the same language facilities). F# is multi-
| paradigm so C# devs can write idiomatic C# with minor
| forced changes. And as a .Net language you can always
| decompile it into C# and keep going from there.
|
| 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.
| Xelbair wrote:
| don't get me wrong - i want F# features in C#! I like the
| ecosystem and both languages.
|
| 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.
| omcnoe wrote:
| I've worked with a lot of junior devs/graduates on a
| large F# project, in that context hiring/onboarding for
| F# hasn't at all been a limiting factor. Ultimately F# is
| not a particularly difficult language to learn.
| stiiv wrote:
| Last I knew, Rider was pretty much the only IDE available
| for a large codebase when you weren't on Windows. Much
| love for Ionide, but it was a serious struggle.
|
| Is this any better now?
| aryonoco wrote:
| No still the same.
|
| 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!
| ikety wrote:
| F# seems really awesome. Used it briefly for an internal
| tool. Are you at a startup working with it?
| xerxes249 wrote:
| I am working at a 2k fte company and we use F# for a lot,
| its very nice to work with, prefer Rider over Visual Studio
| though.
| banashark wrote:
| Are you on (or would you mind adding your company to) the
| F# companies list?
|
| https://github.com/fsprojects/fsharp-companies
| raw_anon_1111 wrote:
| Seeing that any startup is more likely than not to fail, why
| would I work for a company that is using a niche technology
| that isn't going to be in demand when I look for my n+1 job?
| omcnoe wrote:
| How important is being a language expert in x vs all your
| other skills as a Software Engineer? My opinion is that
| "higher level" skills (like system design/architecture,
| product thinking/planning etc.) are so much more important
| than language minutia (outside of specialized fields).
|
| If a business is turning away candidates because they
| "don't have n years of experience in x" that doesn't sound
| like a very dynamic/interesting place to work, it sounds
| like a code monkey job. AI is going to eat code monkey
| jobs.
| olavgg wrote:
| As a startup, what is it in for me to switch from Java, Spring
| Boot, Hibernate, Beam, Flink, Pulsar, Vault, KeyCloak ecosystem
| to C#.Net? Is the documentation better? Do I get better
| performance? Is the community larger and more stable?
| littlecranky67 wrote:
| Yes.
| Xelbair wrote:
| Vault, Keycloak, Flink are language agnostic or there exist
| bindings for most popular languages.
|
| 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.
| mrsmrtss wrote:
| >If i remember right Java's webserver beats ASP.NET in
| performance benchmarks
|
| That's not the case anymore. Kestrel is one of the fastest
| servers there is, and it beats every Java server out there.
| hans0l074 wrote:
| I do not have any benchmarks other than this[1] to refer
| to, but I work with Quarkus[2] and Java 25 LTS (just
| recently released) services deployed on AWS EKS and we
| are very happy with the performance (for mobile game
| backends)
|
| [1]: https://sharkbench.dev/web [2]: https://quarkus.io/
| Xelbair wrote:
| the famous benchmark that put ASP.NET in #1 spot was
| hyperoptimzied to hell while competing with normal
| implementations of other systems. https://web.archive.org
| /web/20250330225652/https://dusted.co...
|
| 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
| mrsmrtss wrote:
| Look at plaintext results if you want to compare just
| servers. Fortunes benchmark has too many variables
| (including db queries etc) to say anything about server
| performance. As for fortunes benchmark, for more
| realistick Java performance numbers I would look at
| Spring. Also there are many shady things on those Java
| bencmarks.
| banashark wrote:
| I think saying that Spring is the representative of Java
| metrics is somewhat equivalent to saying that full aspnet
| mvc is the representative of dotnet metrics.
|
| 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).
| dustedcodes wrote:
| > archived version becasue original one gives 404
|
| Thanks, fixed now. I literally just migrated from GCP to
| Hetzner over the weekend and was about to finish the
| migration today :)
| achandlerwhite wrote:
| It's no longer so hyper optimized and performs very well
| today in the metric compared to any other comparable
| framework.
| dustedcodes wrote:
| That's not what Microsoft's own sponsored benchmarks say:
|
| https://www.techempower.com/benchmarks/#section=data-r23
| mrsmrtss wrote:
| Look at plaintext benchmark, if you want to compare just
| servers. Also look at Spring score in fortunes, which is
| the more common Java stack and I think a more suitable
| comparison.
| haspok wrote:
| > but i haven't used java in a very long time
|
| 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!
| gf000 wrote:
| > Documentation is vastly better compared to Java ones,
| it's like day and night
|
| 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.
| Xelbair wrote:
| well you can't judge 3rd party libraries, can you? by
| that metric js/ts would be the worst thing in existence.
|
| I've seen some great, some horrible 3rd party docs on
| .net side - same with java.
| troupo wrote:
| Most of that ecosystem is language agnostic, or offer much
| more ergonomically sane APIs in dotnet. This is _especially_
| true for anything coming out of Google (e.g. Dataflow which
| runs on top of Apache Beam).
|
| 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.
| stanac wrote:
| I sometimes miss Spring magic when working with ASP.NET,
| and I worked 12+ years with C# and only a year with Spring.
| Not saying one is better than the other, it's always a
| choice, less magic = more boilerplate and less boilerplate
| = more magic.
| gf000 wrote:
| > and most language features don't feel bolted on like with
| Java (anything from functional programming to extension
| methods to whatever)
|
| 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.
| troupo wrote:
| > while Java takes a while to design a bigger feature
| that will replace several smaller ones' use cases.
|
| 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"
| gf000 wrote:
| > Java is quite busy also implementing features that are
| small in other languages like text blocks.
|
| It's a small feature which is immediately understandable
| by anyone coming straight from Java 1.2, it doesn't
| materially increase the complexity of the language and is
| arguably one of the best implementation among different
| languages. So not really sure if it's a good
| counterpoint.
|
| Meanwhile records arrived several versions ago with
| sealed interfaces/classes on the horizon already, so now
| they together form a complete ADT feature. Pattern
| matching builds on top. And sure, these are no novel
| features, MLs had this decades ago, but the
| implementation is very nice, with minimal additional
| developer complexity and some small DX improvement
| (records replace the majority of Bean usages). In the
| future, withers may come that would help with both object
| initialization AND record "mutation". Where Java spends
| more development budget is on the runtime side, e.g.
| virtual threads can replace async code in many cases, so
| the language doesn't have to get all the complexity of an
| async feature.
|
| Meanwhile C# has many many "one-off" features and they
| really can have unexpected interactions and make the
| language quite a bit harder to understand. Some of them
| are absolutely wonderful, but I am on a "the-smaller-the-
| merrier" language team.
| vips7L wrote:
| > Java is quite busy also implementing features that are
| small in other languages like text blocks.
|
| Or named parameters or compile time null safety. Everyday
| I inch closer to moving over to C# from Java.
| griffiths wrote:
| As others have mentioned Vault, Keycloak, Flink are language
| agnostic. Regarding the switch from Java to .NET, I would
| rather recommend switching to Kotlin instead of .NET for a
| developer experience similar to C#, while still keeping your
| existing expertise in Java and its ecosystem. And this comes
| from someone in a .NET shop currently, but have worked with
| Java before. IMHO both languages and surrounding ecosystems
| are good. Both have their pros and cons and quirks.
| jgilias wrote:
| Startups typically have the tech stack that the one man army
| tech co-founder set up on no budget. Apparently then .NET isn't
| too popular for that!
| thewebguyd wrote:
| That's part of it, but is also weird because C# & .NET is
| probably one of the most productive single-developer stack
| you can choose. Modern ASP.NET handles so much for you it's a
| lot like Rails in that regard, you can get a lot done in it
| solo.
| defraudbah wrote:
| agree, but it lost the battle when windows was an exclusive
| platform for it, even when mono was rising in popularity
| netol wrote:
| The XML/config side of things just isn't for everyone.
| Sometimes Go's simplicity wins out.
| neonsunset wrote:
| It is as simple as what you get with Cargo, and possibly even
| more readable.
|
| .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.
| loldot_ wrote:
| One of the big features in .net 10 is the ability to do
| `dotnet file.cs` to run an application, with package import
| and assembly attributes directly in the file.
| brainzap wrote:
| too much microsoft
| masfoobar wrote:
| I think the "confusing" aspect with C#, being part of the
| Microsoft eco-system, is that there are many smaller companies
| (and startups) that may have concern paying for such tools.
|
| 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.
| CharlieDigital wrote:
| > 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.
|
| This is a complete mis-perception about the modern ecosystem.
|
| 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.
| martinald wrote:
| Totally agree.
|
| 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.
| masfoobar wrote:
| > 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.
|
| 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.
| masfoobar wrote:
| My last comment, which you referenced... focused not just
| on C# or .NET.. but the focus of "you need Microsoft" in
| general.. this includes Windows, SQL Server, etc.
|
| 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.
| CharlieDigital wrote:
| Yes, I am very aware of this and have spent a lot of
| time/effort trying to dispel some of these myths and mis-
| understandings through writing.
|
| - 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
| lou1306 wrote:
| > Need a database - should it be SQL Server?
|
| "I am using Java. Need a database - should it be Oracle?"
|
| .NET Core 1.0 was released almost a _decade_ ago.
| masfoobar wrote:
| ???
|
| 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.
| stevefan1999 wrote:
| > That is an example of C# + Sql Server.
|
| I'm sorry but most of us use Npgsql now
| jve wrote:
| > To the uneducated, C# is linked to Visual Studio.. the
| IDE..
|
| 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.
| masfoobar wrote:
| > 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.
|
| 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.
| atraac wrote:
| > 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.
|
| No it's not. What? Visual Studio is a shitty MS product that
| most decent C# devs already moved away from to
| JetBrains/vscode. > Need a database - should
| it be SQL Server? Should it be Windows Servers? etc.
|
| .NET runs on Linux just fine, there's also zero issues using
| Postgres or any other popular DB of your choice.
| > there are many smaller companies (and startups) that may
| have concern paying for such tools.
|
| There's literally nothing you would need to pay to work in
| .NET ecosystem. If a company rules out a language based on
| thoughts like yours, I genuinely believe they deserve to
| fail. Literally none of those things is true and it takes a
| minute or two to find all of that out.
| masfoobar wrote:
| > most decent C# devs already moved away from to
| JetBrains/vscode.
|
| 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.
| aryonoco wrote:
| What are you talking about C# being tied to Visual Studio?
| This is 2025 not 1995.
|
| 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.
| tracker1 wrote:
| Silly me, using Rider (and VS Code) on Linux with C#
| (FastEndpoints and Dapper) with PostgreSQL...
|
| 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.
| CharlieDigital wrote:
| I'm at a series-C, YC startup. We made a switch from TypeScript
| to C# two months back. Now we have a team of over a dozen
| backend engineers working on C# transitioning from TypeScript.
| 90% are working with C# for the first time. (We are still
| hiring backend C# engs!)
|
| 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.
|
| [0] https://typescript-is-like-csharp.chrlschn.dev/
| fud101 wrote:
| So should I learn C# by learning Typescript? Does that make
| sense?
| stanac wrote:
| Not really, you should learn Typescript by learning
| JavaScript first. Then consider learning C#. Or if you want
| to focus on the back end side learn C# and skip TS/JS.
|
| 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.
| CharlieDigital wrote:
| As much as I think C# at a platform level is a better tool
| for building backends, you'll get the better bang for the
| buck learning TypeScript if you don't already know
| TypeScript.
|
| 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.
| loldot_ wrote:
| It is no coincidence that C# and TS are similar. They are
| created by the same person, Anders Hejlsberg. The C# language
| may have some baggage from back in the day, but at least it
| has a very good, non-fragmented ecosystem. While Typescript
| may have learned from some of C#'s mistakes, the js/ts
| ecosystem is a dumpster fire imho.
| christophilus wrote:
| I really liked working with C#. I spent 15 years or so with it
| and found it very productive. But no; I don't miss the culture
| of C# / Microsoft shops at all.
| mexicocitinluez wrote:
| > culture of C# / Microsoft shops at al
|
| What do you mean?
| array_key_first wrote:
| I worked at a Microsoft shop, and this was my experience.
|
| 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.
| atraac wrote:
| Those things have nothing to do with C# though, rather
| than your personal experience with companies that were
| using it.
|
| 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.
| UK-Al05 wrote:
| The problem is thats how a lot of .net shop operate. I
| say this as .net developer.
|
| .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.
| mexicocitinluez wrote:
| Imo, you're criticizing "enterprise" development, not
| .NET/C#.
| UK-Al05 wrote:
| And .NET is the language of choice for "Enterprise". So
| that's what the majority of jobs are.
|
| Where as large 'tech' companies don't tend to be like
| this.
| stevefan1999 wrote:
| > And .NET is the language of choice for "Enterprise". So
| that's what the majority of jobs are.
|
| 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.
| tracker1 wrote:
| It is mostly an Enterprise Development complaint... that
| said, it's how most .Net shops are in my experience. I
| really like C#, I've been working on a project with
| FastEndpoints and the .Net 10 RC since April and been
| pretty happy with it. That said, I don't have to
| implement 10 layers of indirection/interfaces/patterns to
| get the job done either. I have in other places.
|
| But I would levy the same complaint with most Java[1]
| usage as well.
|
| 1. https://github.com/EnterpriseQualityCoding/FizzBuzzEnt
| erpris...
| toyg wrote:
| _> I would argue Java is more of a choice for
| "Enterprise"._
|
| .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.
| mexicocitinluez wrote:
| > And .NET is the language of choice for "Enterprise".
|
| 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.
| Lumping6371 wrote:
| What's skills? Pumping out code ala startup? Sounds like
| a stable environment. Someone with a good eye will still
| be able to pick out flaws in the processes/architecture
| and learn a thing or two.
|
| "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.
| duxup wrote:
| That just sounds like management issues and less tech.
| Granted maybe people who are bad at that select C#, or
| it's just size of company?
|
| https://youtu.be/s4Cz49MLh4o?t=142
| jiggawatts wrote:
| Size of the company, combined with wanting "vendor
| support" instead of going at it alone like a FAANG would.
| GiorgioG wrote:
| Congratulations, you worked at a huge company. Nothing to
| do with the tech stack.
| mexicocitinluez wrote:
| Yea, this is "enterprise" development 101.
|
| 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.
| thewebguyd wrote:
| And from the company's perspective, that's the right way
| to operate. Sure, it sucks for the individual hacker-
| type, but a big enterprise doesn't want "move fast, break
| things" they want the opposite. Rigidity, proven
| processes, stability and backwards compatibility.
|
| 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.
| mexicocitinluez wrote:
| > And from the company's perspective, that's the right
| way to operate.
|
| 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.
| Lumping6371 wrote:
| This is just the run of the mill politics you see at
| every big company (or mid sized one).
|
| 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?
| tracker1 wrote:
| Don't forget all the $PATTERNS ... I mean, you can't
| possibly live without 15 layers of abstraction and
| indirection.
| mohaine wrote:
| Been awhile since I've worked at one but it is usually
| grounded in trying to achieve 100% MS usage.
|
| 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.
| GiorgioG wrote:
| Not that rare, I work in one now and we use: .NET, Mongo,
| Postgres, SQL Server, Node, Python, etc.
| oaiey wrote:
| There is no way a reasonable person would not deploy to
| Linux and postgres for cost reasons alone. No one wants
| to pay Microsoft or Oracle money for databases, operating
| systems or frameworks nowadays.
| omcnoe wrote:
| My biggest complaint would be a tendency to blindly use a
| "Microsoft first" approach to selecting tech rather than
| evaluating things on their own merits in the context of
| their own use cases.
|
| Some Microsoft stuff is really good but it's not
| universally true. And in the worst cases you end up locked
| into some hard to migrate off platform that is withering on
| the vine.
| theshrike79 wrote:
| C# is massive in (mobile) gaming because of Unity.
|
| And when the front-end is C#, it only makes sense to do the
| backend in .NET too so you can share classes easily.
| tracker1 wrote:
| I only partly agree with you... if you're talking a web api,
| then code generation can go a long way with an OpenAPI doc
| file.
| parliament32 wrote:
| I think the key problem is that a large number of startups are
| shipping software in containers, and dotnet requiring a CLR is
| not particularly well-suited for containerization. It's like
| the old school Java JVM model. You have to ship a copy of the
| runtime with every container, and if you're doing proper
| microservices it's an awful lot of overhead.
|
| 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.
| paride5745 wrote:
| Exactly this point.
|
| Go and Rust produce native binaries, I wish C# had an
| official native compiler without the big runtime needs of
| .Net.
| cachius wrote:
| You might want to read https://learn.microsoft.com/en-
| us/dotnet/core/deploying/nati...
|
| _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._
| 4rt wrote:
| They're self contained and native, but they're still
| massive.
|
| 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.
| greener_grass wrote:
| Smaller is better, of course, but I've never found the
| size of .NET binaries to be an issue.
|
| What problems does this cause?
| 4rt wrote:
| If you're trying to pack hundreds of microservices into a
| cluster, having containers using 80MB of ram minimum
| instead of 500KB can become a big deal.
| skeeter2020 wrote:
| There are quite a few gotchas for this, especially web
| apps. THis is understandable because it was added after
| the fact, vs. a first-party design requirement. It's cool
| and might work for you, but taking a non-trivial .net
| codebase to native AOT can be tough, and if you're
| starting greenfield, why go .net?
| whizzter wrote:
| Sure, legacy applications won't be easy to move over but
| Microsoft has been quite consistent in working towards
| making microservice applications easy to build and run
| with AOT by moving more and more components over to using
| source-generators and promoting minimal-API's.
|
| 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.
| el_benhameen wrote:
| FWIW, the .net folks seem to have put a lot of effort
| into the native AOT pipeline in the last few releases. We
| have a large, non-trivial application with a fair amount
| of legacy code, and getting it AOT'd in .net 10
| (targeting wasm, even!) was not an insane lift.
| leobuskin wrote:
| How is the WASM target looking nowadays? I tried it in
| 2023 and early 2024, and it was far from complete (JS
| interop, poor documentation scattered across GitHub
| issues, and so on). I still can't find a single
| trustworthy source of documentation on how to proceed. C#
| would look great at the edge (Cloudflare Workers).
| parliament32 wrote:
| And this sounds great until you get to the laundry list
| of restrictions. For us the showstopper was you can't use
| reflection.
| oblio wrote:
| You can't use reflection with AOT compilation. That's
| what AOT compilation is. Java has the same limitation for
| AOT compilation, for example.
| alexandrehtrb wrote:
| Most reflection usage is for JSON (de)serialization and
| for that you can use source generators, which also offer
| better performance.
|
| https://learn.microsoft.com/en-
| us/dotnet/standard/serializat...
| midnitewarrior wrote:
| Not every library is capable of building to Native AOT,
| which means any app that depends on those libraries run
| into the same problem. If the library or app uses
| reflection, it likely isn't capable of Native AOT
| compilation.
| synergy20 wrote:
| rust and go are only good at single binary. when you need a
| few their size adds up quickly, because they don't really
| do shared libs.
| oblio wrote:
| Meh. Probably 100x more startups use Python and JavaScript
| than anything else combined.
| thiago_fm wrote:
| Nowadays it's very common to have .NET apps being
| containerized and running them on K8s or whatever you like in
| production -- I think you are relying on outdated
| information.
|
| 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.
| greener_grass wrote:
| > dotnet requiring a CLR is not particularly well-suited for
| containerization
|
| 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.
| parliament32 wrote:
| Create a hello world dotnet container, then do the same in
| a modern language. Then compare image size and resource
| consumption. Then imagine you're running tens of thousands
| of containers in a proper SaaS microservices model, and
| it'll make sense :)
| maximilianburke wrote:
| Sounds like a problem with the "proper SaaS microservices
| model" more than .NET
| M4R5H4LL wrote:
| Enterprise doesn't spawn 10,000 containers to perform a
| simple "hello world" operation. That's not how it
| operates. You'd be amazed at how many concurrent requests
| a single service can handle. This capacity must align
| with the actual requirements of the companies involved,
| not some unrealistic scenario like "we need to emulate
| Google."
| hvb2 wrote:
| If you have that many containers, you should be having
| the revenue to pay for that.
| orphea wrote:
| > Create a hello world dotnet container
|
| The container image is 10.9 MiB. The binary is 1.2 MiB.
| GiorgioG wrote:
| Just say you don't want to use .NET. It's fine, but how many
| startups ever get to over 10k containers? You can use AOT to
| further reduce the footprint. It's totally fine to hate
| Microsoft, but this is as weak an argument as I've ever seen.
| petershinners wrote:
| A million different Javascript and Python services in
| delivered as Docker images would like a chance to disagree
| with you.
| stevefan1999 wrote:
| > dotnet requiring a CLR is not particularly well-suited for
| containerization
|
| 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.
| tracker1 wrote:
| If you use the same base image, is it really as bad as you're
| making it out to be?
|
| 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#.
| parliament32 wrote:
| The runtime alone is a bit over 200mb, and that doesn't
| include additional packages you'll most likely need.
|
| That being said, I'd much prefer to deploy a C# application
| over Node or Java, no argument there. But saying "I wish
| more startups were using C#" makes me wince. C# seems well-
| suited for the monolith-architected VM-image-deployed
| strategy of the early 2000s, but it's pretty close to being
| the exact opposite of modern best practices. And
| unfortunately it's kinda unfixable in a language that
| depends on a VM execution environment.
|
| I'm sure all this is short-lived however -- I'm relatively
| confident we'll see deployment best practices converge down
| to "use whatever language you want but you must compile to
| WASM" in the next decade, so the warts of devs' chosen
| language aren't an ops problem anymore.
| jiggawatts wrote:
| You're making the classic logical error of "your thing
| doesn't have the workaround needed for an issue that only
| happens with my thing".
|
| 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.
| dijit wrote:
| > I wish .NET was more popular among startups
|
| C# is extremely popular in Western/Northern Europe.
| (Sweden/Denmark/Germany ironically in particular).
|
| These are real Microsoft strongholds.
| thewebguyd wrote:
| Australia too.
|
| 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.
| nicoburns wrote:
| > I wish .NET was more popular among startups, if only C# could
| get rid of the "enterpisey" stigma.
|
| 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.
| GiorgioG wrote:
| Recommended by whom? I've been doing .NET for 23 years (since
| the first beta) and I've never paid for a single library in
| any commercial project I've been part of.
| runjake wrote:
| Not OP but I still run into paid libraries (eg Telerik) all
| over the place in projects.
| tracker1 wrote:
| I never liked their stuff myself, and generally avoided
| them.
| whizzter wrote:
| Moq, lots of PDF libraries, Avalonia, Automapper, MediatR,
| MassTransit,Telerik stuff,etc.
|
| 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.
| majora2007 wrote:
| There are a few non-paid PDF libraries, but that is the
| biggest pain point in .NET, anytime you need advanced
| features for PDF, you're better off paying for a license
| (it's just insanely expensive unless you're a large
| company).
|
| 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.
| jasomill wrote:
| I've used libqpdf extensively from C++/CLI with excellent
| results, but since C++/CLI is deprecated-ish and Windows-
| only, I wouldn't disagree with PDF being a pain point,
| and if I get the time, a cross-platform open source .NET
| wrapper for libqpdf is at the top of my list of potential
| projects.
|
| 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).
| tracker1 wrote:
| AFAIK pinvoke (DllImport) works today just like it always
| has if you want to create FFI calls to C libraries. It's
| not windows only for sure.
| whizzter wrote:
| That brings you back to managing memory though, C++/CLI
| having access to managed C# handles/references for GC'd
| objects (and finalization) would greatly simplify any
| memory management at the same time as having first class
| access to native libaries.
|
| 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.
| to11mtm wrote:
| IDK, for certain cases those fancy libraries are just
| handling the ugly marshal calls for you.
|
| 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.
| paxcoder wrote:
| I can confirm that (several years ago at least) free PDF
| libraries were lacking, and Telerik was always non-free.
|
| 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.
| whizzter wrote:
| Yeah pdf libraries are a bit of a mess, I work with a
| product that handles lots of PDF documents and I think we
| just recently added another PDF library dependency (I'm
| certain it's at least 3 now, but could be 4 or even 5
| libraries loaded at startup).
|
| 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.
| to11mtm wrote:
| > Moq has the appearance of free software but bundled
| some spyware stuff (seemingly "benign" "Sponsorlink" for
| getting donations).
|
| Well they pulled back but the trust was broken in a lot
| of cases. I am still fine with it 'for now' but IDK
| NSubstitute always feels weird to me, maybe that's just
| how I was taught to use it tho.
|
| > Masstransit went commercial recently
|
| I mean good for them but thankfully it's also giving
| attention to other projects that are FOSS or Open Core...
|
| As far as the other stuff, I've never seen AutoMapper
| used in a way that couldn't literally be handled with a
| static/extension method in 'real' code. Yes it can be
| useful but it is often grossly overused.
|
| MediatR is cool but TBH I'd rather just reach for
| Akka.NET or MessagePipe instead; If you're abstracting
| out to keep processing backend 'swappable' you should be
| able to handle any of the above for the choice you make
| anyway.
| paulirwin wrote:
| Avalonia is FOSS (MIT licensed). You only need Avalonia
| XPF if you are migrating legacy stuff.
|
| 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.
| Kwpolska wrote:
| I agree with almost all of this, especially MediatR being
| nonsense, but I would recommend against using a LLM to
| generate a mock. That's just more code that you need to
| maintain and update on every interface change.
| NSubstitute is a fine library.
|
| Another popular library that went commercial is
| FluentAssertions, Shouldly is a good open-source
| alternative.
| AshleyGrant wrote:
| Any recommendation of good alternatives to Telerik? We've
| been using it for years, but I'm open to considering
| alternatives even though it doesn't cost me anything to
| pay for the license.
| to11mtm wrote:
| Depends on what layer of Telerik [0]. Honestly of late
| since I'm extra rusty on frontend I just get Copilot with
| Claude to help generate UI widgets since that's allowed.
|
| Before that, years ago, I just YOLOed with WebSharper and
| built composition helpers to make 'spartan but correct'
| UIs that could be prettied up with bootstrap if needed.
|
| That said, alas, Bolero (what replaced WebSharper) is F#
| specific rather than also supporting C#.
|
| I mostly bring those up because they have various
| libraries out there to work with different JS bits.
|
| [0] - Cries in webforms
| AshleyGrant wrote:
| We're planning on using Blazor, so any Blazor UI
| components that you recommend?
| piskov wrote:
| For pdfs render the, in html with razor and then print
| as;df with puppeteer. If you need custom headers/footers,
| add something like
| https://github.com/PejmanNik/puppeteer-report-csharp
| electroly wrote:
| Easy to avoid depending on the area; I'd urge you not to be
| discouraged by the presence of commercial libraries. They
| aren't as vital as it may seem from the outside. I've been a
| full-time C# developer since the first open beta and I have
| only one (1) instance where I used a commercial library. That
| was 2002 and if we were doing it today, we wouldn't have
| needed that commercial library. I have never used a
| commercial C# library other than that one time. We have a
| tremendous supply of open source libraries in NuGet, just
| like every other language, and much more functionality built
| into the standard library than most languages have. We just
| _also_ have commercial UI libraries and such. That commercial
| library we used was a docking /tabbing UI library; you can
| get that from open source packages now (and my later projects
| do).
| throwaway7356 wrote:
| > I've been a full-time C# developer since the first open
| beta and I have only one (1) instance where I used a
| commercial library. That was 2002
|
| 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.
| toyg wrote:
| Come on, it's clear he meant "commercial libraries not in
| the default Microsoft SDK".
| whizzter wrote:
| Remember when people were selling COM objects in Dr Dobbs
| journal ads for Visual Basic in the 90s? I think it's the
| same culture (and partially people) that has been bought over
| to the .NET world via VB.NET as it was always touted as the
| stepping stone.
|
| 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.
| DarkNova6 wrote:
| Silly question. If you want the C# experience but more
| community/OSS driven... why not Java?
| wvenable wrote:
| C# and Java might be similar technologies at some level but
| they not similar developer experiences _at all_.
| bradford wrote:
| I haven't kept aware of changes to Java in the last decade,
| but the things I didn't like about it then were:
|
| 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).
| Kwpolska wrote:
| C# 1.0 was pretty much Microsoft Java, but since then, C#
| has evolved into its own, more powerful thing, while Java
| has stayed much more conservative over the years.
| osigurdson wrote:
| I'm not sure it is more powerful but it might be more
| ergonomic. The strange part about both (today - it made
| sense 20 years ago) is the whole bytecode thing. That
| should go away imo.
| Kwpolska wrote:
| What's wrong with bytecode? Using something abstract
| helps with porting between OSes and architectures. .NET
| supports compiling to native executables, but only a
| limited subset of projects is supported, because
| reflection is not available in native AoT mode.
| osigurdson wrote:
| I think cross compilation has gotten a lot better so
| there is basically no need for it today. Obviously
| nothing is for free and would be hard for .NET to
| completely get rid of it at this point but I don't think
| a greenfield project would take the bytecode approach.
| Bytecode still makes sense in something like WASM as it
| is a sandboxed environment but otherwise skip the VM
| abstraction if you can imo.
| raddan wrote:
| I wouldn't call this a silly question at all. But having
| recently converted my intro data structures course from
| Java to C#, I can talk about why C# might be better. I have
| programmed regularly in both languages for the last 15 or
| so years (in addition to regularly programming in
| TypeScript, Scala, and F#).
|
| 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.
| Yhippa wrote:
| This is interesting. I've been away from the high-code
| world for a while and instead of going back to Java, I
| might try out c#. Thanks for the writeup.
| to11mtm wrote:
| > Generics work as you would expect with very few weird
| corner cases. No boxed types because... everything is an
| object!
|
| Took me a moment to realize you meant that 'Java has
| corner cases because everything is an object' but yes.
|
| Will also add the 'advantage' that for value types (i.e.
| struct) the generics are 'specialized' for the type, in
| certain cases you can use that for performance
| optimizations. (although it can have downsides.)
|
| > 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)
|
| And, fun side note, the generic arrays actually existed
| before real generics (and we get fun hacks in the VM as a
| result!)
|
| .NET does still have funkiness around Array Covariance
| tho, which sometimes can be a pain.
|
| > By default, reference types are not nullable.
|
| This is a newer feature and great, however it requires
| people to (1) use libraries that properly do it and (2)
| requires you to have the right tag in the csproj to flag
| the NRT warnings as errors. I've yet to see a shop that
| has adopted (2) as a default.
|
| > 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>
|
| Yes and also the sugar around yield syntax to do
| generators.
|
| > Properties are really nice, and the shorthand syntax
| for property getters/setters saves a lot of time.
|
| I still remember getting called into a Dev Manager's
| office, he's a JVM guy and he's goes into this overview
| of Lombok and how the JVM folks want to use it and he
| asks what I think and I'm like "Gee wow give me a moment
| I thought Java had AutoProps by now". (I think it was the
| first time he was impressed with C# as a language lmao,
| He and later I were disappointed in .NET's lack of a good
| set of thread pool abstractions...)
|
| > .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.
|
| That is so freaking cool and I love it. Profs like you
| made college fun back in the day.
|
| > NuGet is a million times easier to use than Maven.
|
| Truth; every time I have to do a thing in JVM dealing
| with maven feels like I need a goat or chicken to make
| anything work right.
|
| > 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.
|
| We have AOT and R2R nowadays, I'm not sure if it's 'JVM
| Fast' for something like a webservice but unless you're
| pulling in something like an ORM it's typically fast
| enough I can't observe a difference as a user for utility
| apps/etc... Curious what examples you have in mind?
| wvenable wrote:
| I will pile on that I don't use any commercial libraries in
| .NET at all. Ironically, I do purchase a commercial library
| for front-end JavaScript.
|
| 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".
| osigurdson wrote:
| Every company should give developers $100 per year to
| donate to the open source project of their choosing. Right
| now the conditions are such that maintainers are
| incentivized to rug pull.
| dlahoda wrote:
| every company must pay enough to allow developer to
| donate from his own pocket (and each state to allow vat
| free donations without paper work).
| ablob wrote:
| Surely you don't expect someonoe that uses a particular
| piece of software only during work to donate to that from
| their own salary.
| hakanderyal wrote:
| This one was weird to me at first too, coming from Python.
|
| 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.
| tracker1 wrote:
| What libraries are you referring to? I really haven't used
| any commercial libraries at all since the .Net Core
| transition (and .Net 5+ as a result).
|
| Are you looking at older materials?
| eitally wrote:
| Just one example, but when I was running a .Net dev team we
| licensed the Telerik UI components. We ended up dropping
| them, but not until we had initiated a migration to Java/PG
| instead of C#/MSSQL. After we moved to Java everything
| standardized of a set of FOSS libraries for various things.
| AshleyGrant wrote:
| We use Telerik components at my current job. They're a
| solid library, IMO. I'm sure there's better out there,
| but we've been using them for nearly 15 years at this
| point and I feel like we get decent value for the money,
| and their developers get to draw a salary.
| SegfaultSeagull wrote:
| What is wrong with paying for something that is useful?
| to11mtm wrote:
| In the last 12-15 years, outside of imaging and PDF (and some
| office documents [0]) the only commercial .NET library I
| found worth it's salt was the the Devart Oracle client, if
| only because it sucked WAY less than the official one [1].
|
| Yes, that includes UI frameworks. Honestly nowadays I'd just
| have an LLM help build my UI components, because every
| commercial UI component lib I've seen is never quite right to
| a shop I've worked at anyway and you see a bunch of kludges
| bolted on to make it work the way they want [2].
|
| I guess maybe a list of the recommended libraries would help
| cause I'm a bit lost.
|
| [0] - You can totally do Excel output from .NET without a
| commercial library, I know you used to be able to hack
| together a PDF output flow, Word docs well good luck dealing
| with that format...
|
| [1] - Devart's lib was both x86 and x64. Oracle's you had to
| pick the right arch on build. And then make sure everything
| on the deployment chain was configured the same way, or deal
| with people forgetting and then burning cycles with broken
| stuff. That ROI on that alone was worth it to the org.
|
| [2] - To be clear I try to avoid touching such UIs
| encountered, when I do I at least try to clean things up if
| possible... but often it's not which is why I have to bring
| it up.
| mbesto wrote:
| > I wish .NET was more popular among startups
|
| 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".
| Lumping6371 wrote:
| Yeah, but it's very likely you won't be working like a mule,
| or creating a bicycle with three wheels. How could oneself be
| innovative and top talent under such conditions?
| dzonga wrote:
| I tried so many times to get into the .net ecosystem. I
| actually like f# have written a few toy things with it. but
| never could built anything substantial with it - as I would
| starting my own cement factory.
|
| 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.
| thiago_fm wrote:
| I'm a Ruby dev of almost 2 decades now doing C# and it's
| extremely fast to get a API with Swagger running from C#, a
| few mins tops. And this is if you spend just a little bit to
| learn it!
|
| 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.
| zamalek wrote:
| I was somewhat recently attempting to help my manager get a C#
| dev environment set up. He was used to doing everything the
| C/Java/JavaScript/Python/almost-every-language-under-the-sun
| way, and avoiding the "Microsoft way" of doing things created
| so many roadblocks. I had no idea that over the previous ~20
| years I had been practicing a C# compiler summoning ritual and
| had become incredibly good at it. From the start I recommended
| installing Rider, VS, or VSCode, and that's eventually what
| worked - but having to drink the kool aid to that extent is
| fucking absurd.
|
| 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)_
| stusmall wrote:
| >He was used to doing everything the
| C/Java/JavaScript/Python/almost-every-language-under-the-sun
| way, and avoiding the "Microsoft way" of doing things created
| so many roadblocks.
|
| 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
| achandlerwhite wrote:
| Isn't it just a single file installation?
| zamalek wrote:
| No. It's a tar + some config envars if you need to do it
| manually.
| delaconcha wrote:
| Just install the .NET SDK, and you're ready to go.
|
| > 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.
| zamalek wrote:
| "Just" is an incredibly obnoxious word when used in the way
| that you have.
|
| > 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...
| pier25 wrote:
| > _I wish .NET was more popular among startups, if only C#
| could get rid of the "enterpisey" stigma_
|
| 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.
| hvb2 wrote:
| > That said, I regret that decision and won't be using it
| again for any new projects.
|
| Genuinely curious, why?
| shortrounddev2 wrote:
| Just stick with the classic frameworks. Razor works great as
| does MVC WebAPI
| pier25 wrote:
| I tried Razor. It's mature, has tons of features, and it's
| very fast. But it only really solves rendering HTML.
|
| 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.
| shortrounddev2 wrote:
| If youre intent on writing everything on the frontend in
| javascript then you can just have a frontend app and use
| webapi MVC on the backend. Personally, in my personal
| projects, I find I iterate faster if I dont't write any
| javascript. Every page is just static HTML and any
| interaction is done via CSS (which you _can_ do perfectly
| well in razor pages) or html forms. Managing page state
| is a huge time sink and IMO not worth it, but it 's what
| pays the bills lol
| mpweiher wrote:
| > 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.
|
| Hmm...there appears to be an interesting story and/or reason
| there...care to share?
| giancarlostoro wrote:
| I'm the same. I'm both a Python and C# developer. I use
| Python for all my personal projects, and given the choice,
| for MOST projects I'll always pitch Python first, Django
| gives me the strengths of something like ASP .NET / EF Core,
| but without feeling like they're building more abandonware. I
| really love Blazor and heck even MAUI, but will they still be
| there in 10 years? Probably, will Microsoft have some new
| project that replaces them? probably.
|
| Then there's Django. Rarely changes, only for the better.
| Upgrading Django versions is usually painless too. The ORM is
| fine enough.
| toyg wrote:
| It is ironic when companies like Microsoft and Google end
| up showing the sort of "permanent reimplentation" behaviour
| that used to be typical of opensource, whereas certain
| opensource projects persist seemingly forever. Python,
| Django, Emacs - these things will likely see the end of the
| galaxy; meanwhile, big companies now build and discard key
| projects every other year.
| mrsmrtss wrote:
| >Everywhere you look there are tons of half baked projects
| like Blazor
|
| 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?
| wvenable wrote:
| I had high hopes for Blazor but it didn't really materialize.
| Instead I'm just sticking with Angular.
|
| 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.
| rblatz wrote:
| I avoided Blazor, despite multiple people on my teams
| pushing for it. It always felt like it fit in the same
| space as web forms and silverlight. A product created to
| fill a gap of developers that wrote desktop apps and don't
| want to learn how to write front end code for the web. Plus
| it binds you to the product lifecycle of a .net side
| project that likely will be abandoned.
|
| While Blazor has some cool stuff built in, the cool stuff
| never felt worth the risk of building a product around it.
| wvenable wrote:
| Honestly, I was wishing that Blazor was in the same space
| as web forms.
|
| There is a market for front-end development that isn't
| steeped in the hell of actual front-end development.
| Blazor is almost the right idea but I think this
| incarnation is a dead end. Somebody needs to gather up
| all the pieces and figure it out for real.
| to11mtm wrote:
| Blazor honestly is _great_ for 'I need to write a simple
| backend control plane for whatever'. I.e. internal only
| stuff where you care about just shipping something
| functional and don't care too much how it all looks/etc.
|
| Further you go away from that circle, the less enticing it
| is.
| AshleyGrant wrote:
| Why is that? Do you speak from real-world experience?
|
| Not trying to push back. We're planning to use it for
| some new projects we have coming up on our team of .NET
| devs who can't seem to grok Angular or React and the
| entire ecosystem of tooling required, so I'm looking for
| reasons we shouldn't use it aside from Blazor being
| rather unpopular compared to Angular/React/other JS libs
| tracker1 wrote:
| Agreed... 2 -> 3 was probably the most cumbersome for me, and 3
| -> 5 had a few hiccups. But since 6, I haven't seen any huge
| issues.
| damieng wrote:
| If you use LINQ and have ever used areay Contains youre about
| to find out it's not going to be smooth. They knew about this
| for a year but decided coercing to span in an expression tree
| despite it being invalid wasn't worth fixing.
| HumanOstrich wrote:
| That's pretty vague. Do you have links to any articles or bug
| reports explaining the issue clearly?
| vielite1310 wrote:
| As much as I love .NET. I would like to see the whole libraries
| ecosystem being sustainable again. A recent license changes
| from all my favorite libraries just made me hesitant using .NET
| for actually build a startup TBH
| nu11ptr wrote:
| IMO, C# is just a somewhat better version of Java (low bar) w/
| first class Windows API support. I can't see myself ever
| adopting it for any real work. F# on the other hand seems a
| pretty awesome, terse and expressive language. Unfortunately,
| it is very unpopular (yet still hangs around).
| nozzlegear wrote:
| As a daily user of F#, I'm most looking forward to the support
| for "and!" in computation expressions. There are a few
| performance-critical pieces of code I can think of that are
| currently wrapped up in "Task.WhenAll" / "Parallel.ForEachAsync"
| that I'd like to extract back into "native" F# task computations.
| cies wrote:
| I really like F# (as I like OCaml, Elm and Haskell); but I'm
| always afraid MS will kill it one day.
|
| It helps that now most (if not all) parts of the stack are open
| source and run on Linux.
| vintermann wrote:
| C# Dev Kit, which VSCode pressures you to install, is a core
| very non-free component.
| madarcho wrote:
| Where is this worry coming from? (I'm curious, not shutting
| it down)
|
| 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?
| azertify wrote:
| Doesn't it feel like the functional stuff is coming into C#
| so that F# can disappear? Pure speculation on my part but
| doesn't seem unreasonable.
| pizza-wizard wrote:
| Microsoft is still supporting VB.NET, Windows Forms/WPF,
| and to a lesser extent VBA. I doubt F# is going away
| anytime soon.
| debugnik wrote:
| Supporting as in maintenance mode, at least VB.NET.
| Thankfully F# is more community driven, but the CLR
| ecosystem is definitely getting C#-centric in the use of
| idioms and features from newer C# versions, which
| increasingly affects F# interop while they catch up.
| aryonoco wrote:
| .NET has always been both the biggest blessing and the
| biggest curse for F#.
|
| 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.
| banashark wrote:
| Although you inevitably end up writing some OOP code in
| F# when interacting with the dotnet ecosystem, F# is a
| really good OOP language. It's also concise, so I don't
| spend as much time jumping around files switching my
| visual context. Feels closer to writing python.
| bonesss wrote:
| C# has incomplete and often compromised versions of the
| constructs F# mostly took from OCaml, and as you extend
| those exhaustive guarantees towards formal verification
| you bump into F*.
|
| 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.
| WorldMaker wrote:
| The C# team admits to looking at how F# features work,
| but also keeps trying to make it clear that C# doesn't
| have a goal of entire eating F#.
|
| 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.
| banashark wrote:
| They killed off VB, which if I recall the announcement
| correctly, noted that it statistically had a larger user
| base (by Microsoft metrics) than F#. There are a number of
| companies relying on F# for critical operations and MS has
| some use of F# internally which I understand has no plans
| of replacement, which helps balance out the fear.
| nu11ptr wrote:
| I was curious so I googled. Best I can tell it is still
| supported, but perhaps stagnant?
| jve wrote:
| How come this quickly fell off main page and is ranked 395 right
| now?
|
| 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?
| tomhow wrote:
| It looks like it was hit by some software penalties that
| lowered it in the rankings more than it should have been, then
| it just continued dropping.
|
| I've restored it to the front page and wound back the clock so
| it gets its rightful dose of front page time.
| aeonfox wrote:
| Literally just got yoinked up from rank 199 to 2.
|
| https://hackernews.life/?s=top&id=45888620&t=1762939537
|
| It arrived at rank 86:
|
| https://hackernews.life/?s=top&id=45888620&t=1762876085
| DeathArrow wrote:
| >I wish .NET was more popular among startups, if only C# could
| get rid of the "enterpisey" stigma.
|
| 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
| thiago_fm wrote:
| There's F# if you want to go fully functional.
|
| 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.
| high_na_euv wrote:
| C# has the best ecosystem out there.
|
| I wish CPP development was as robust as C# development is
| bilekas wrote:
| They are very different beasts.. What problems are you having
| with CPP that you're not with C# ? Funny enough a lot of the
| 'ecosystem' is on the back of cpp..
| high_na_euv wrote:
| Evaluating complex expressions during debugging.
|
| 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.
| bilekas wrote:
| Ah okay, yes, debugging tools are a bit more friendly with
| C# but it's again the nature of the beast of cpp, but to
| nitpick this is a compiler area moreso than a tooling issue
| . CPP will compile direct to binary, whereas C# will
| compile to machine Lang iirc, an intermediary step anyway,
| so you can imagine it makes debugging much easier.
| maccard wrote:
| > to nitpick this is a compiler area more so than a
| tooling issue
|
| 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.
| theshrike79 wrote:
| With C# (.NET) I can click on "install package" in my editor
| and within seconds it's downloaded and in my project.
|
| With C++ it's a whole different thing.
| cies wrote:
| That's a lot of goodies in a new release! It seems it is
| outpacing the JVM's development...
| lolive wrote:
| Apart from [the equivalent of] records, I see nothing big.
|
| 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.
| JaggerJo wrote:
| The code snippet is in F#. And F# has so called "computation
| expressions".
| codeulike wrote:
| I think thats F# not C#
| greener_grass wrote:
| Here `a` and `b` can have different types:
| let! a = fetchA() and! b = fetchB()
|
| Whereas `Promise.all` usually requires all promises to have
| the same type (returning a `List<T>` or even a `List<obj>`) .
|
| See https://learn.microsoft.com/en-us/dotnet/fsharp/whats-
| new/fs...
| ajifurai wrote:
| Actually, TypeScript's `Promise.all` can handle different
| types too. const [a, b] = await
| Promise.all([fetchA(), fetchB()]); // => a: A, b: B
| greener_grass wrote:
| I am talking about C# / F# context where the lists must
| have homogeneous types.
|
| That TypeScript supports this is yet more complexity
| introduced to cover usages of an API not designed around
| types.
| adgjlsfhk1 wrote:
| The inlining and escape analysis changes are fairly big from
| a performance perspective.
|
| 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).
| whoisthemachine wrote:
| As others point out, that's F#, but yes C# has
| `async`/`await`, and has all the `Promise` methods, just
| under the `Task` class instead (and with slightly different
| names/calling conventions through out).
| kurokawad wrote:
| To me, it's pretty much unbelievable that Microsoft introduces an
| agent framework while for JSON serializing third-party Newtonsoft
| is still the go-to.
|
| Edit. I was not aware that the gap between System.Text.Json and
| Newtonsoft narrowed, take my comment with a grain of salt,
| please!
| vintermann wrote:
| What's wrong with System.Text.Json?
| anonymars wrote:
| Last I checked they stubbornly insisted on reinventing the
| wheel and ignoring everything in System.Runtime.Serialization
| so you had to redecorate everything with their new
| attributes. For example
| https://github.com/dotnet/runtime/issues/29975. So we stuck
| with Newtonsoft for the time being.
| WorldMaker wrote:
| There is a 3rd Party library for that now:
| https://github.com/zcsizmadia/ZCS.DataContractResolver
|
| 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.
| Deukhoofd wrote:
| Is it? We've switched over to System.Text.Json entirely.
| monerofglory wrote:
| The go-to nowadays is System.Text.Json, developed by the same
| person as Newtonsoft.Json, built in to .NET.
|
| 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.
| kurokawad wrote:
| Uh okay! I was not aware of this. Thanks for pointing that
| out. Why is there so much difference in the NuGet downloads
| between both libraries tho?
| Hawxy wrote:
| > Why is there so much difference in the NuGet downloads
| between both libraries tho?
|
| 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.
| akoeplinger wrote:
| System.Text.Json ships as part of the shared framework in
| recent versions of .NET so for most users it won't be
| restored from nuget.org
| xnorswap wrote:
| System.Text.Json isn't needed as a nuget library for newer
| development, the library is only needed for older stuff.
|
| Those older stuff are likely running newtonsoft.Json
| anyway.
|
| There's also a load of .NET Framework applications still
| running Newstonsoft.
| WorldMaker wrote:
| System.Text.Json is out-of-the-box in .NET > 5. The NuGet
| package is primarily a compatibility layer for people still
| supporting .NET 4.x for whatever reason.
| gf000 wrote:
| Doesn't Text.Json have a much narrower scope and plenty of
| features supported by Newtonsoft not available?
| orphea wrote:
| No, not _plenty_ : https://learn.microsoft.com/en-
| us/dotnet/standard/serializat...
| BatteryMountain wrote:
| Haven't touched the newtonsoft package since .net core 3 / or
| about 5 years go? Something like that. Its not really getting
| updates and its huge/slow compare to built in one. The built in
| one is much better these days and plays well with other
| subsystems in aspnet.
| pier25 wrote:
| There's so much stuff they could be working on instead like a
| first party Postgres driver, better OpenAPI, improving Minimal
| APIs, etc.
| EdNutting wrote:
| It's exciting to see so much deep computer science that's gone
| into optimising the language / JIT / GC / etc (inc. utilising
| hardware advances).
|
| In a world obsessed with AI and web tech, this is a refreshing
| read!
| bob1029 wrote:
| These improvements are really making me look forward to Unity
| finishing their CoreCLR conversion. I think this will be one of
| the more disruptive announcements once it's complete.
| frenzcan wrote:
| At last, extension properties in C#. I've been waiting for these
| for years.
| vswaroop04 wrote:
| I hope .NET will become more popular
| thiago_fm wrote:
| Changed from Ruby to .NET and loving it.
|
| 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.
| dahauns wrote:
| >and has the best parts of Typescript
|
| 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 :) )
| thiago_fm wrote:
| Might be my own taste, but except a few of the common and
| easy to understand structural typing code, I find it
| sometimes actually make things needlessly complex.
|
| 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.
| Timon3 wrote:
| I've come to really appreciate Typescripts structural
| typing, because it reduces some of the overhead & prevents
| the unnecessarily tight coupling that has often annoyed me
| in other languages.
|
| 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!
| vips7L wrote:
| I hope once they introduce unions, they also introduce some
| sort of error union.
| mrsmrtss wrote:
| >And so has Hejlsberg, apparently, seeing his reasoning for
| choosing go over C# for tsc
|
| 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.
| gf000 wrote:
| > It also doesn't have the fragmentation that Java or JVM langs
| has
|
| What fragmentation? Honest question
| ralferoo wrote:
| > Today, we are excited to announce the launch of .NET 10, the
| most productive, modern, secure, intelligent, and performant
| release of .NET yet.
|
| It looks like they got someone from Apple to write their press
| release.
| Arisaka1 wrote:
| Every time I read about new .NET version improvements I always
| remember my attempt to get a job using this stack in my local job
| market (Greece), where .NET Framework is super prevalent, majorly
| used by classic companies that don't even give you a fair
| technical chance if you lack a degree, and the devs are
| considered to be a cost center.
|
| 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.
| netdevphoenix wrote:
| > 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.
|
| Could you please elaborate? Are you referring to most .NET
| shops not straying away from Windowsland?
| Arisaka1 wrote:
| It's not about what the company uses, but how informed the
| technical people responsible for hiring candidates are around
| the ecosystem they claim they work with.
|
| 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?
| whoisthemachine wrote:
| There's still a lot of folks who consider themselves .Net
| experts who don't know how to program with async/await, so
| knowing about a niche IDE (which I also exclusively use) is
| asking a lot for those people.
| metadata wrote:
| A bit off-topic, bit hiring exceptional .NET developers is like
| searching for a needle in a haystack. Way more people have a
| ton of experience with JS and marginal experience with .NET,
| just writing very basic API endpoints - yet claiming serious
| experience.
|
| 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.
| stby wrote:
| Somehow, .NET jobs seem be tied to waterfall processes ("but we
| are still agile, because we release two times a year"),
| requirements in OneNote, and a 5 kg Windows laptop.
| mvdtnz wrote:
| What an absolute load of bullshit.
| willio58 wrote:
| > don't even give you a fair technical chance if you lack a
| degree, and the devs are considered to be a cost center.
|
| 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.
| kopirgan wrote:
| Does this version improve or streamline the numerous options for
| web dev like Razor, Blazor etc? Anyone can comment on which is
| actually being popular
| WorldMaker wrote:
| Same number of options.
|
| 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.
| kfuse wrote:
| Updated a pet project of mine and got a minor break:
| var pixels = new uint[renderers.width * renderers.height];
| var pixels2 = MemoryMarshal.Cast<uint, ulong>(pixels);
| pixels2[idx] = ...
|
| In NET9.0 pixels2 were Span<ulong>, but in NET10.0 a different
| MemoryMarshal.Cast overload is used and it is ReadOnlySpan<ulong>
| now, so the assignment fails.
|
| 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.
| thw_9a83c wrote:
| Related and useful (work in progress): Breaking changes in .NET
| 10 [1]
|
| [1]: https://learn.microsoft.com/en-
| us/dotnet/core/compatibility/...
| lol768 wrote:
| What is the deal with Ubuntu and this version of .NET?
|
| 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?
| jcon321 wrote:
| Microsoft's Ubuntu image seems to be ready. I guess I could see
| a reason to use regular Ubuntu 24 and then install dotnet
| manually, but these images have served us well.
|
| 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"
|
| https://github.com/dotnet/dotnet-docker/discussions/6801
| bouke wrote:
| See the docs[1] where it mentions that 10 is supported, but not
| available in the built-in Ubuntu feed. It however is/should
| become available in the backports feed.
|
| To make matters even more interesting the GitHub / Azure DevOps
| CI agent image Ubuntu 24.04 doesn't provide .NET 9, whereas
| 22.04 does[2]. .NET 10 appears to become available in both
| though[3].
|
| [1]: https://learn.microsoft.com/en-
| gb/dotnet/core/install/linux-... [2]:
| https://github.com/actions/runner-images/issues/12697 [3]:
| https://github.com/actions/runner-images/pull/13295
| martijn_himself wrote:
| I usually feel ambivalence with announcements of new C# versions.
|
| 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;
| }
|
| Ah so it's a way to access the backing field of Auto-Implemented
| Properties if you need more logic. And in the above can we just
| say: get;
|
| or do you need to refer to the field keyword explicitly in the
| getter if we use it in the setter?
|
| 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.
| xnorswap wrote:
| Previously, if you wanted to add that Trim in, you needed to
| define the field behind.
|
| You could have: public string Name { get;set;
| }
|
| Or you could have: private string name;
| public string Name { get; set { this.name =
| value?.Trim() ?? string.Empty; } }
|
| So you needed in the second case to also declare name as a
| field. The new syntax avoids having to do that "double"
| declaration.
| martijn_himself wrote:
| > The new syntax avoids having to do that "double"
| declaration.
|
| 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.
| xnorswap wrote:
| They provide a bit more context around changes in their
| "What's new in C# 14" page:
|
| https://learn.microsoft.com/en-us/dotnet/csharp/whats-
| new/cs...
| martijn_himself wrote:
| This is great thank you.
| anonymars wrote:
| Agreed. I feel like we're getting diminishing returns out of
| the language as they try to squeeze out every last keystroke
| (as though the challenge of software development is in the
| typing)
|
| 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
| wvenable wrote:
| I love this feature. I have avoided doing some stuff in
| properties because I don't want the noise of a private backing
| field.
| ethin wrote:
| How is .NET debugging on the command line? I don't use IDEs that
| often and last time I tried making something serious with .NET I
| couldn't find any kind of reliable debugger that I could just
| spin up and get to grips with. And I wasn't exactly very keen on
| switching from VS build tools to full VS just to debug .NET apps.
| formerly_proven wrote:
| Isn't the official .NET debugger only allowed to be used from
| Visual Studio and VSC? I recall Jetbrains had to remove
| debugging support from their IDE for a while due to that
| license. Also the whole kerfuffle around hot reloading first
| being added to .NET (Core) and then the code being deleted
| because it was supposed to be a VS-only feature.
|
| 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.
| jve wrote:
| There is WinDbg which can debug CLR code, but that is Windows
| only.
| trelane wrote:
| > that is Windows only.
|
| There are _so many things_ that are like this in the .Net
| ecosystem.
|
| Yeah, it runs on Linux. Kind of. Mostly.
|
| As long as Microsoft is at the helm, I don't expect that to
| change.
| MarkSweep wrote:
| The .NET debugging extension (SOS) is not Windows only, it
| supports LLDB on Linux in addition to WinDbg:
|
| https://learn.microsoft.com/en-
| us/dotnet/core/diagnostics/de...
| formerly_proven wrote:
| License: https://www.nuget.org/packages/dotnet-debugger-
| extensions/9....
|
| > 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 Microsofts 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.
| MarkSweep wrote:
| Yes, the restrictive license they place on their
| debugging components is frankly bizarre.
| Nelkins wrote:
| There's an open source one by Samsung that is excellent, never
| had any issues with it: https://github.com/Samsung/netcoredbg
| ethin wrote:
| I think I tried that (or a derivative of it, didn't know
| Samsung was the primary developer) that broke in some very
| very weird ways. Will try this version, thanks!
| jcmontx wrote:
| I've worked with .NET for over 10 years and we built our startup
| on top of it. Here are my thoughts:
|
| 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.
| duxup wrote:
| Anecdotal opinion , but as someone who works in Node and JS
| land a lot of the time. I think .NET is pretty cool.
| davey48016 wrote:
| .NET Core and ASP.NET Core (especially the minimal APIs) seem
| to have taken a lot of influence from Node API libraries like
| Express.
| theshrike79 wrote:
| > * Culturally, it feels like .NET devs are less "passionate"
| about their work
|
| 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.
| 999900000999 wrote:
| Unity C# is arguably its own thing.
|
| The way you use C# is much different than anywhere else. The
| Unity implementation lags by a few versions. It's an awesome
| language though
| threetonesun wrote:
| It's funny, I came up in my career working in places mixed with
| .NET and PHP/JavaScript devs and the .NET developers all felt
| the PHP/JS teams were clown cars. IMO had .NET Core come out a
| few years earlier it would have a much bigger marketshare
| today, but when you had Ruby/PHP/Node/Python devs primarily
| using Macs, no one wanted to touch the thing.
| deburo wrote:
| * C# has way to many features, it feels bloated
|
| 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.
| jcmontx wrote:
| Sometimes less is more. It very easy for devs to use the
| language in completely different ways. I lean towards Go
| style in that regard. My ideal language would be like Go +
| Linq.
| danielbarla wrote:
| I've heard this argument before from the perspective of C#
| having more keywords and language features to be aware of
| than something else (in my particular argument, the other
| side was Java).
|
| 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.
| maccard wrote:
| I use rider on Mac (and windows to be fair) and i think the
| experience is better than visual studio on windows.
|
| 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
| stetrain wrote:
| I've personally found Rider to be a great IDE for .NET
| development outside of Windows.
| Kwpolska wrote:
| It's also a great IDE for .NET development on Windows.
| denismenace wrote:
| Why is EF regarded as such a good ORM? I've encountered
| countless bugs in different repos related to its stateful
| nature after many years in .NET. Personally I found it
| completely illogical for my ORM to maintain state. I just want
| it to hold my schema and build queries.
| achandlerwhite wrote:
| EF or EFCore? Specifically EFCore is highly regarded whereas
| legacy EF not so much.
| htgb wrote:
| Are you referring to the change tracker? FYI you can have it
| skip tracking as the default (or per query), but when you
| actually want to make changes you better opt in with
| `.AsTracking()`.
|
| 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?
| wvenable wrote:
| EF Core is amazing -- in it's default setup it works for 99%
| of situation. For the 1%, you can basically turn off
| everything you don't want.
| jerhewet wrote:
| > C# has way to many features, it feels bloated
|
| Could not agree more. Too many -- WAY too many -- "features"
| from Javascript and functional languages have been jammed into
| C#, and the language has suffered for it. Every time I see "var
| blah" in C# code I cringe at how lazy you must be to not use
| strong typing when declaring a variable.
|
| Same goes for "astink / await". If you need asynchronous multi-
| threaded code, use the damned Thread Parallel Libraries that
| Microsoft provided over a decade ago. Being forced to have
| every damned thing you write in C# wrapped with astink is just
| one giant code smell.
|
| Yes, I'm old. Thank ghod I'll be retiring _very_ soon, because
| as far as I 'm concerned the tooling and languages I've used
| over the past 50 years have taken one step forward and at least
| three steps back in the past five years...
| igravious wrote:
| Anybody remember IronPython, IronRuby, etc?
| OkGoDoIt wrote:
| I do! Pretty sad that IronPython isn't a thing anymore,
| especially now that I've actually had to learn Python for
| machine-learning related reasons. At least .net did get the
| dynamic data type out of its brief interest in these.
| orphea wrote:
| > Pretty sad that IronPython isn't a thing anymore
|
| Why? It seems the latest release is quite recent (9 months
| ago)
| Zambyte wrote:
| IronScheme[0]! I was pretty happy to be able to expose async-
| await in a neat little library[1]. I wonder if it's in use
| anywhere. I didn't get to use it in the project I was working
| on at the time.
|
| [0] https://github.com/IronScheme/IronScheme
|
| [1] https://github.com/IronScheme/IronScheme/pull/141
| ta12653421 wrote:
| I HAVE FOUR WORDS FOR YOU: "I ... LOVE .. THIS .. COMPANY ...
| yeeeaaaahhhhhh1111"
|
| 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!
| AbraKdabra wrote:
| Some days ago I helped migrate a service in .NET Framework 2 to
| 4.8.
|
| Yup.
| piskov wrote:
| Copilpt will migrate it to .net 10 -- there is upgrade agent
| catapart wrote:
| Literally just started building a game engine with .NET 9, so
| naturally there's an update within a week. -_-
|
| 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.
| sumnole wrote:
| I wouldn't worry. Updating .NET rarely breaks anything.
| pixl97 wrote:
| 9 isn't an LTS version... always go with an LTS version.
| orphea wrote:
| That's... a strong statement. There is absolutely nothing
| wrong with going with a non-LTS version. You just have to
| update a little bit sooner, and that's it.
| htgb wrote:
| Especially with the recent extension of STS release support
| from 18 to 24 months [1]. Previously, upgrading from an LTS
| version to the next major (STS) version meant the support
| window _decreased_ by half a year, while now it would stay
| the same.
|
| [1] https://devblogs.microsoft.com/dotnet/dotnet-sts-
| releases-su...
| Kwpolska wrote:
| For most projects, upgrading between .NET version is quick and
| painless, usually just updating the TargetFramework and NuGet
| packages in your .csproj file.
| truekonrads wrote:
| It's all about the libraries in the end.
| hakanderyal wrote:
| Also first time in a long time Rider is supporting it from day
| one. I was ready to wait for a month plus to enjoy the goodies.
| achandlerwhite wrote:
| If the US had universal healthcare I bet there would be a lot
| more .NET startups as corp devs would have the freedom to pursue
| their dreams.
| 1970-01-01 wrote:
| .NET has to win the title for worst naming. If you didn't know
| what it was, this announcement makes no sense whatsoever. All you
| would guess is there are probably 9 others that were just like
| it.
| lpribis wrote:
| > All you would guess is there are probably 9 others that were
| just like it.
|
| Lol, even this is not true. For the current runtime/stdlib
| package known as ".NET", they started numbering at 5. The
| actual sequence (only counting major version numbers) is: .net
| framework 1, 2, 3, 4, .net core 1, 2, 3, .net 5, 6, 7, 8, 9,
| 10. Easily the worst naming/version history for any product
| (worse than Windows).
___________________________________________________________________
(page generated 2025-11-12 23:00 UTC)