33 ms·

.NET 10

• jitbit 11mo ago
  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 11mo ago
    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 11mo ago
      [flagged]
      • LandR 11mo ago
        > 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 ?
        • balamatom 11mo ago
          Ah, well, obviously the point of the question was to be odd for oddness's sake, as some form of bizarre, self-inflatory social ploy! I couldn't possibly have intended my question as a straightforward request for information about something, now could I? That would just be weirdy-weird, if people started asking each other questions for the purpose of receiving answers. Thanks for answering though.
          • LandR 11mo ago
            The reason I thought it was odd was that I've never seen any correlation between someones hobbies outside of work and what tech stack they use at work.
            • balamatom 11mo ago
              That's OK. I keep seeing a correlation between people's proneness to be like >The reason I thought it was odd was that I've never seen [it] and which tech stacks they feel more comfortable with.
      • recursive 11mo ago
        > what do they do for fun? Play in a band, ride bikes, play video games. Sample size of one.
        • balamatom 11mo ago
          >Play in a band Cool, what genre?
          • recursive 11mo ago
            Rock mostly covers. I play keyboard. Trying to learn to sing. Progress is mixed.
    • deleted 11mo ago
      [deleted]
    • larrik 11mo ago
      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 11mo ago
        Do you measure that standard by leetcode?
        • larrik 11mo ago
          No, we don't do any coding tests, just discussions of what you've done and how deep your knowledge of your tools goes. .NET folks are far less likely to understand much beyond the syntax, nevermind the "why" of things (even WHY you need StringBuilder) or what a database index is, etc.
          • zerr 11mo ago
            Interesting. One would thing, "script kiddies" would be more common among Pythonistas. On the other hand, .NET might be more user-friendly, so that devs are productive even without the knowledge of what's going on under the hood. Kudos for the interview practices, that's similar to how I conduct as well :)
  • catlover76 11mo ago
    > 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 11mo ago
      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 11mo ago
        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 https://github.com/nozzlegear/shopifysharp
    • phillipcarter 11mo ago
      Rider is your option there, it's better than Visual Studio (I used to work on VS).
      • starvar 11mo ago
        How is it so different than Visual Studio that you think it is "better"?
        • Deukhoofd 11mo ago
          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.
  • leetharris 11mo ago
    > 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 11mo ago
      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 11mo ago
        You can easily use the same types and libraries in your backend and frontend with TypeScript. It’s not at easy with dotnet.
        • phito 11mo ago
          OpenAPI and client generators solve this issue easily.
          • robertlagrant 11mo ago
            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 11mo ago
              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.
  • vintagedave 11mo ago
    .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 11mo ago
      > 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 11mo ago
        > 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 11mo ago
  • randyburden 11mo ago
    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 11mo ago
      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 11mo ago
      > 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 11mo ago
        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 11mo ago
          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.
          • 11mo ago
  • tinyspacewizard 11mo ago
    Start-ups should strongly consider F#. It's a force multiplier when you have a small team of strong developers.
    • Xelbair 11mo ago
      >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 11mo ago
        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 11mo ago
          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 11mo ago
            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 11mo ago
            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#).
  • olavgg 11mo ago
    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 11mo ago
      Yes.
    • Xelbair 11mo ago
      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 11mo ago
        >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 11mo ago
          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 https://sharkbench.dev/web [2]: https://quarkus.io/ https://quarkus.io/
  • jgilias 11mo ago
    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 11mo ago
      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 11mo ago
    agree, but it lost the battle when windows was an exclusive platform for it, even when mono was rising in popularity
  • netol 11mo ago
    The XML/config side of things just isn't for everyone. Sometimes Go's simplicity wins out.
    • neonsunset 11mo ago
      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_ 11mo ago
      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 11mo ago
    too much microsoft
  • masfoobar 11mo ago
    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 11mo ago
      > 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 11mo ago
        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.
        • 11mo ago
  • CharlieDigital 11mo ago
    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/ https://typescript-is-like-csharp.chrlschn.dev/
    • fud101 11mo ago
      So should I learn C# by learning Typescript? Does that make sense?
      • stanac 11mo ago
        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.
      • 11mo ago
  • christophilus 11mo ago
    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 11mo ago
      > culture of C# / Microsoft shops at al What do you mean?
      • array_key_first 11mo ago
        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 11mo ago
          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.
  • theshrike79 11mo ago
    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 11mo ago
      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.
      • theshrike79 11mo ago
        Yea, but then the other end has to serialise the HTTP API stuf to a typed object on their end. It's a lot easier when you have a single shared library you can just NuGet into both sides, client and server and then use the same correctly typed PlayerDTO for both.
        • tracker1 11mo ago
          I don't know about you, but when I code-gen from an OpenAPI doc, I get strongly typed object interfaces, so the serialization is in the box. No need to have a client distribution specifically, unless you want to wrap the generated client to make it easier to implement security layers. If I had to manually create a client, then I'd probably go back to WCF (CoreWCF) which, again makes it easy enough to publish a client. For WCF in particular, I used to have one project with all the interface definitions and a client-generator that would allow for an "easy" single connection string as opposed to the XML bloat that is typical for WCF defaults. All the same, you can definitely generate strongly typed clients to OpenAPI, provided the interfaces are well defined in the doc/generator/api.
  • parliament32 11mo ago
    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 11mo ago
      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 11mo ago
        You might want to read https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ 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 11mo ago
          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 11mo ago
            Smaller is better, of course, but I've never found the size of .NET binaries to be an issue. What problems does this cause?
  • dijit 11mo ago
    > 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 11mo ago
      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 11mo ago
    > 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 11mo ago
      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 11mo ago
        Not OP but I still run into paid libraries (eg Telerik) all over the place in projects.
        • tracker1 11mo ago
          I never liked their stuff myself, and generally avoided them.
          • runjake 11mo ago
            Same here, but "enterprise" dotnet developers generally seem to need "more help" and love this kind of stuff.
      • whizzter 11mo ago
        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 11mo ago
  • mbesto 11mo ago
    > 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 11mo ago
      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?
      • mbesto 11mo ago
        I've seen plenty of innovative .NET/C# shops. They just don't have the "hip" factor to them.
      • mardifoufs 11mo ago
        It's mostly about pay too. And yeah some people want more exciting jobs and maybe even outlandish stuff like the ones you listed (regardless of the sarcasm!). Yes at the end of the day most software isn't super exciting, but it doesn't make a tech stack or platform where most of your job prospects would approximate to "working on some run of the mill, mega enterprise or SMB software project" any more attractive for devs. Especially when even its advocates somehow use that as an "upside". It might very well be for a lot of people! But it's also a massive turn off for others. I have never worked in a startup or big tech, and work on very concrete and critical products yet I'd very much rather work on even outlandish SV stuff (at least the pay is usually great and the job environment could be good!) rather than on some SMB CRUD or some generic backend service. If I don't have a choice I could do it but it's not super enticing.
        • mbesto 11mo ago
          For all of the "SV startups" that are working on hard tech problems (new DBs, LLMs, etc.) there are thousands of SV startup CRUD apps. Most SV tech stacks are romanticized when in reality they are just are all mostly some flavor of a MEAN stack that is building a CRUD. The allure is the lottery payout and a clean slate tech stack, not that the specific tech itself is used.
  • dzonga 11mo ago
    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 11mo ago
      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 11mo ago
    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 11mo ago
      >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
      • zamalek 11mo ago
        As far as I remember, cloning the project, sprinkling in some printfs and running it. He didn't want to use an interactive debugger. He was used to using the likes of nvm, uv, rustup, etc.
    • neonsunset 11mo ago
      [dead]
    • achandlerwhite 11mo ago
      Isn't it just a single file installation?
  • pier25 11mo ago
    > 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 11mo ago
      > That said, I regret that decision and won't be using it again for any new projects. Genuinely curious, why?
    • shortrounddev2 11mo ago
      Just stick with the classic frameworks. Razor works great as does MVC WebAPI
      • pier25 11mo ago
        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 11mo ago
          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
  • tracker1 11mo ago
    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 11mo ago
    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 11mo ago
      That's pretty vague. Do you have links to any articles or bug reports explaining the issue clearly?
  • vielite1310 11mo ago
    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
    • sakesun 11mo ago
      I would also like to see the whole ecosystem being sustainable, financially :)
  • nu11ptr 11mo ago
    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).
    • koyote 11mo ago
      > I can't see myself ever adopting it for any real work Why not? I see a lot of people saying they don't like it or won't use it but few of them list any reasons to, the ones that do raise issues from 20 years ago that have since been resolved. Maybe you should give it a try, you'd be surprised how productive the language is and how comparatively unproductive all other languages and ecosystems are.
      • nu11ptr 11mo ago
        I have tried it recently. It felt like I was coding Java. I realize "feel" isn't very objective, but I don't really like C-like languages in general. I like Rust, but only because of it's heavier FP-influence. C# is one of those languages where you don't mean to, but you can't help just creating tons of files/boilerplate/etc., which feels just like Java. Just my perspective, others obviously feel differently.
  • ddmma 11mo ago
    Had the privilege to be consistent on C# development against the tide. NuGet was pretty generous during the years and VS26 is catching up with the small VS code frontend page cousin.
  • germandiago 11mo ago
    As a person who looks always at Java and C sharp with curiosity, I am a bit divided. For me C#'s value is obvious in the frontend and also games compared to Java (except for mobile, where Java can be used but Kotlin seems best). But for the backend I always wonder if I should invest more on C# or Java as I go. Also, it worries me that Java is a memory hog, which C# seems not to be. I like to have lean server-side software, to the point that my usual approach has been to use C++ paired with Capnproto, but if I had to go with something a bit more high-level for web work, I am not sure. Currently I am investigating Clojure for non-critically-fast backend. It seems to be a lot of fun and since I am using https://fennel-lang.org/ https://fennel-lang.org/ (replacing part of my Lua code) and I expect https://jank-lang.org/ https://jank-lang.org/ to become something at some point, maybe it is worth to stick to it? How would someone that has more data than me compare Java vs C# in terms of performance as-in "what machine you need in the cloud" to do useful stuff, mainly for backend work, asynchronous, in terms of CPU and memory for both?
  • Loxicon 11mo ago
    As a startup I tried .NET (it was .NET 8), and it was great. The problem was the education around .NET. So much DDD-this, Clean-that, CQRS-this, architecture-that. I get all that stuff is for enterprise with bigger teams. But there wasn't much content/guidance on how to build apps 'quickly' for startups. I am sure experienced .NET devs know this, but less experience .NET devs don't. I ended up dropping it because I could work faster in PHP.
  • glonq 11mo ago
    Yeah I've been using non-.Net languages this week, and lamenting how much they suck in regards to smooth version management
• nozzlegear 11mo ago
  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.
  • deleted 11mo ago
    [deleted]
  • cies 11mo ago
    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 11mo ago
      C# Dev Kit, which VSCode pressures you to install, is a core very non-free component.
      • ganzsz 11mo ago
        Removing free omnisharp was the worst
    • madarcho 11mo ago
      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 11mo ago
        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.
• jve 11mo ago
  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/ https://hnrankings.info/45888620/ This has 74 upvotes and posted 16hrs ago.. @dang?
  • tomhow 11mo ago
    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 11mo ago
    Literally just got yoinked up from rank 199 to 2. https://hackernews.life/?s=top&id=45888620&t=1762939537 https://hackernews.life/?s=top&id=45888620&t=1762939537 It arrived at rank 86: https://hackernews.life/?s=top&id=45888620&t=1762876085 https://hackernews.life/?s=top&id=45888620&t=1762876085
• DeathArrow 11mo ago
  >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 11mo ago
    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 11mo ago
  C# has the best ecosystem out there. I wish CPP development was as robust as C# development is
  • bilekas 11mo ago
    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 11mo ago
      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 11mo ago
        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 11mo ago
          > 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.
• cies 11mo ago
  That's a lot of goodies in a new release! It seems it is outpacing the JVM's development...
  • lolive 11mo ago
    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 11mo ago
      The code snippet is in F#. And F# has so called "computation expressions".
    • codeulike 11mo ago
      I think thats F# not C#
    • greener_grass 11mo ago
      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/fsharp-10#support-for-and-in-task-expressions https://learn.microsoft.com/en-us/dotnet/fsharp/whats-new/fs...
      • ajifurai 11mo ago
        Actually, TypeScript's `Promise.all` can handle different types too. const [a, b] = await Promise.all([fetchA(), fetchB()]); // => a: A, b: B
        • greener_grass 11mo ago
          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.
• kurokawad 11mo ago
  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 11mo ago
    What's wrong with System.Text.Json?
    • anonymars 11mo ago
      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 https://github.com/dotnet/runtime/issues/29975. So we stuck with Newtonsoft for the time being.
      • WorldMaker 11mo ago
        There is a 3rd Party library for that now: https://github.com/zcsizmadia/ZCS.DataContractResolver 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.
        • anonymars 11mo ago
          For me it was less not really about the opt-in part (after all, Newtonsoft works the same way) and more about stupid things like setting a name (DataMember), Enums, and in fact opting out (IgnoreDataMember) It's especially annoying in libraries because the consumer might not even be using System.Text.Json, but you have to pull in the library anyway to apply its own attributes if you want it to work right. Just an overall awful smell given the existence of first-class framework attributes to do the same thing to avoid just that problem Case in point: https://github.com/dotnet/efcore/pull/28084/files https://github.com/dotnet/efcore/pull/28084/files
• BitsAndObjects 11mo ago
  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 11mo ago
  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 11mo ago
  At last, extension properties in C#. I’ve been waiting for these for years.
  • Lord_Zero 11mo ago
    Why is it better than just using a method?
    • mrcsharp 11mo ago
      Think of it in terms of semantics. An object has certain properties that are immediately obvious and available: color, height, width and so on. Properties in C# are for such values that are immediately available or at least extremely cheap to retrieve or form. Seeing a property tells me that getting the value is a very small op and has no side effects. A method on the other hand is like asking/telling the object to do something that can take a bit of time and resources to do. So if the value you are trying to read is expensive to get and isn't immediately available then the method approach works and as a developer I'll avoid making multiple calls to it unless absolutely necessary because the method is also a possible indication that it might change state.
      • zbentley 11mo ago
        That’s a good argument. I had not considered properties in those terms before, and have historically been skeptical of them in many languages. I’m partly convinced now! I still worry a bit about property authors who don’t follow the “cheap, non-side-effectful, externally cacheable” rules, though. Perhaps there are linters in property-ful languages which would help with that.
        • mrcsharp 11mo ago
          > I still worry a bit about property authors who don’t follow the “cheap, non-side-effectful, externally cacheable” rules, though. Perhaps there are linters in property-ful languages which would help with that. Definitely a problem when a developer goes rogue and breaks this rule. I'm not sure if there are linters that helper with this. I don't think either VS, Rider, or the .NET Compiler include any analyzers that complain about this. If they do, I haven't seen the warnings before. I generally tend to enforce this during code reviews with my team.
• vswaroop04 11mo ago
  I hope .NET will become more popular
• thiago_fm 11mo ago
  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 11mo ago
    >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 11mo ago
      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 11mo ago
        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!
• ralferoo 11mo ago
  > 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 11mo ago
  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 11mo ago
    > 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 11mo ago
      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 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 11mo ago
        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.
• kopirgan 11mo ago
  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 11mo ago
    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.
    • kopirgan 11mo ago
      Thanks! Its clear..
    • Lord_Zero 11mo ago
      .razor is blazor, razor pages is .cshtml
      • WorldMaker 11mo ago
        In my brief testing just now, both extensions seem to be purely synonyms. Microsoft's documentation suggests that .razor is for Blazor components and .cshtml is for Pages, but even Microsoft's own templates are inconsistent on this and seem to use them interchangeably. The view engine doesn't seem to care what you call it and doesn't really seem to change its behavior. It really mostly just seems to underscore the difference between Razor Pages and Blazor "Server-Side Only" is real blurry to nonexistent. Obviously Blazor Hybrid and Blazor WASM have very different behavior from just Razor Pages.
• kfuse 11mo ago
  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.
  • AlfeG 11mo ago
    NHibernate project stumbled upon much bigger break: https://github.com/nhibernate/nhibernate-core/issues/3651#issuecomment-3426417796 https://github.com/nhibernate/nhibernate-core/issues/3651#is... We force to use this workaround for now.
    • qingcharles 11mo ago
      That workaround seems wild as hell.
• thw_9a83c 11mo ago
  Related and useful (work in progress): Breaking changes in .NET 10 [1] [1]: https://learn.microsoft.com/en-us/dotnet/core/compatibility/10.0 https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
• lol768 11mo ago
  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 11mo ago
    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 https://github.com/dotnet/dotnet-docker/discussions/6801
  • bouke 11mo ago
    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-ubuntu-install?tabs=dotnet10&pivots=os-linux-ubuntu-2404#ubuntu-2404 https://learn.microsoft.com/en-gb/dotnet/core/install/linux-... [2]: https://github.com/actions/runner-images/issues/12697 https://github.com/actions/runner-images/issues/12697 [3]: https://github.com/actions/runner-images/pull/13295 https://github.com/actions/runner-images/pull/13295
• ethin 11mo ago
  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 11mo ago
    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 11mo ago
      There is WinDbg which can debug CLR code, but that is Windows only.
      • trelane 11mo ago
        > 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 11mo ago
        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/debugger-extensions https://learn.microsoft.com/en-us/dotnet/core/diagnostics/de...
        • formerly_proven 11mo ago
          License: https://www.nuget.org/packages/dotnet-debugger-extensions/9.0.652701/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 Microsoft�s privacy statement. Our privacy statement is located at https://aka.ms/privacy 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.
• martijn_himself 11mo ago
  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 11mo ago
    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 11mo ago
      > 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 11mo ago
        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/csharp-14#the-field-keyword https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
• jcmontx 11mo ago
  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 11mo ago
    Anecdotal opinion , but as someone who works in Node and JS land a lot of the time. I think .NET is pretty cool.
    • davey48016 11mo ago
      .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 11mo ago
    > * 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 11mo ago
      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
  • 11mo ago
• igravious 11mo ago
  Anybody remember IronPython, IronRuby, etc?
  • OkGoDoIt 11mo ago
    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 11mo ago
      > Pretty sad that IronPython isn’t a thing anymore Why? It seems the latest release is quite recent (9 months ago)
  • Zambyte 11mo ago
    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 https://github.com/IronScheme/IronScheme [1] https://github.com/IronScheme/IronScheme/pull/141 https://github.com/IronScheme/IronScheme/pull/141
  • deleted 11mo ago
    [deleted]
• ta12653421 11mo ago
  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 11mo ago
  Some days ago I helped migrate a service in .NET Framework 2 to 4.8. Yup.
  • piskov 11mo ago
    Copilpt will migrate it to .net 10 — there is upgrade agent
    • mnau 11mo ago
      No, it won't. WebForms are .NET Framework only and are basically the key reason why any app stay on .NET Framework. A ton of internal apps used by few user with is built upon WebForms. It's just not worth it.
      • piskov 11mo ago
        Well, besides webforms there is a lot of other stuff. Rest web api will be migrated. Razor — also.
• catapart 11mo ago
  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 11mo ago
    I wouldn't worry. Updating .NET rarely breaks anything.
  • pixl97 11mo ago
    9 isn't an LTS version... always go with an LTS version.
    • orphea 11mo ago
      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 11mo ago
        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-supported-for-24-months/ https://devblogs.microsoft.com/dotnet/dotnet-sts-releases-su...
  • Kwpolska 11mo ago
    For most projects, upgrading between .NET version is quick and painless, usually just updating the TargetFramework and NuGet packages in your .csproj file.
• truekonrads 11mo ago
  It’s all about the libraries in the end.
• hakanderyal 11mo ago
  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 11mo ago
  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 11mo ago
  .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 11mo ago
    > 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).
    • taberiand 11mo ago
      I'm still reminding other devs that it's not ".NET Core" anymore (and hasn't been for years), it's just .NET.
• schneems 11mo ago
  Available on Heroku https://devcenter.heroku.com/changelog-items/3479 https://devcenter.heroku.com/changelog-items/3479
• whb07 11mo ago
  Meanwhile, I recently proposed doing the work of updating the runtime versions from .netframework over to even .net5+ to save $millions/quarter. I ran benchmarks, showing 2-10x+ improvements. Got told, “lol no, this service is unlike Bing”. For context, Bing has amazing blogs on this*. This, btw is inside networking for Azure… Not sure at what point I should stop caring. Could easily improve operating expenses to the tune of hundreds/billions per year if they applied this across Azure. https://devblogs.microsoft.com/dotnet/bing-com-runs-on-net-core-2-1/ https://devblogs.microsoft.com/dotnet/bing-com-runs-on-net-c...
• kkukshtel 11mo ago
  Something great about this release as well is the release of "file-based apps" https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/tutorials/file-based-programs https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals... Basically, you can now write scripts in C# without the ceremony of a solution or project file — writing some code in a cs file and running `dotnet run myFile.cs`will execute the file directly. You can also shebang to make it directly executable! Hoping this inspires more people to give C# a go — it's incredible these days. Come in, the water is fine.
  • qingcharles 11mo ago
    That's how I learned C in the 80s. Just compile the C file into an EXE. It's a good way to get started. That said, I'm certain you've always been able to simple compile a .cs to an .exe? When I ran guerilla C# programming classes in jail, I couldn't get anything from the outside, so I was stuck with the .Net v2 csc.exe which is squirreled away in a subfolder of Windows on a default install of Visa. What .Net 10 adds though is the ability to even scrap main() and just write code like it was Basic.
    • kkukshtel 11mo ago
      You've needed to have a project file in the past to compile .cs files, and this gets rid of that need. There are things that are part of more esoteric corners of Roslyn like .csx files that have allowed similar behavior in the past, but this fronts .cs directly as a scripting solution. Scraping main() has been a thing for a while in dotnet — so called "Top-level programs" have be in since C# 9/.NET 5, aka about 5 years ago. https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/program-structure/top-level-statements https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...
      • qingcharles 11mo ago
        Right, I think .Net 7 brought the top-level statements to Program.cs. The oldest version of .Net I could find on Windows 11 was .Net 4, but it still compiles just great without a project file since it has since v1: https://www.youtube.com/watch?v=KmIwGxcMOLg https://www.youtube.com/watch?v=KmIwGxcMOLg
• mikeyinternews 11mo ago
  If you have a build command that does not specify version for things like 'dontnet-ef', your build might fail because it is not compatible in .NET 10, so update to specify version, e.g. dotnet tool install --global dotnet-ef --version 8.0.8