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.
I tried .NET and liked C# as a language. But even though the language and runtime are now open source, it seemed like a lot of the recommended libraries were still commercially licensed, which was an immediate nope from me. I've never encountered that in any other ecosystem.
I 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".
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.
Are you looking at older materials?
And in 20 years I've personally never needed a paid library. Maybe one company had bought Telerik back in the day? I've now built up multiple startups, some with millions of users.
The only thing I ever plugin that's not a MS library really are serilog, validation with FluentValidation, and a job server, usually Hangfire just because it's easy. Other than that, most people have good C# API clients. Oh and OAuth, though the popular one got baited and switched like you said.
The key difference is that the core libraries cover much more for .Net than most other languages. I'm constantly adding npm modules, but rarely nuget packages.
But the opensource/closed source bait and switch has happened a lot recently it does seem. Someone was blaming it on some failure of an open source initiative MS were running.
But one of the big frustrations sometimes is dealing with some American Koolaid company who thinks Erlang support is a priority but .Net isn't. No code examples, no officially supported library. Most recent example, IBM of all people (C-level insisting we use their cloud, ugh).
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.
What are free PDF generation/handling libraries in Java ecosystem what is their performance are they up to date and which licenses?
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.
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.
[0] I actually think VB.NET is the superior .Net language, but it lost support at MS and died. I think the code is vastly more readable (to me) than C-style code, and I've coded in every C, Java, C#, whatever variant.
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.
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.
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)
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.
> It's just the amount of money spent on Windows/Microsoft for small companies is rather large, compared to other alternatives that are just as good.
We have a full team using C# at a series-C, YC startup with every developer on Macs (some on Beelinks and Linux). The team is using a mix of VS Code, Cursor, and Rider. We deploy to Linux container instances in GKE on Google Cloud running Postgres.
There is no more tie in to Microsoft licensing than there is say for TypeScript. Yes, C# DevKit is licensed like VS, but if you don't need the features, then you can also use DotRush or just use the free C# Extension.
"I am using Java. Need a database - should it be Oracle?"
.NET Core 1.0 was released almost a _decade_ ago.
> To the uneducated, C# is linked to Visual Studio.. the IDE.. and the Community edition if free as long as you are a student, open-source, and individuals. Professional and Enterprise are paid.
> Need a database - should it be SQL Server? Should it be Windows Servers? etc.
> there are many smaller companies (and startups) that may have concern paying for such tools.
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.
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.
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.
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".
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.
Genuinely curious, why?
Hmm...there appears to be an interesting story and/or reason there...care to share?
Then there's Django. Rarely changes, only for the better. Upgrading Django versions is usually painless too. The ORM is fine enough.
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?
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.
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.
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.
Stackexchange famously is a dotnet application that runs on a handful of fairly (but not unreasonably) large computers. 10k containers is either "you are Facebook", or you're wasting a lot of that in some other way.
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.
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.
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#.
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.
Why?
Go and Rust produce native binaries, I wish C# had an official native compiler without the big runtime needs of .Net.
It's a force multiplier when you have a small team of strong developers.
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.
And when the front-end is C#, it only makes sense to do the backend in .NET too so you can share classes easily.
C# is extremely popular in Western/Northern Europe. (Sweden/Denmark/Germany ironically in particular).
These are real Microsoft strongholds.
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.
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.
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.
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.
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.
Running TypeScript on the server is a well trodden path. It can be pretty fast too. Python on the client, not so much.
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/ (replacing part of my Lua code) and I expect 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?
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.
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.
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.
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.
.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.
I personally won't be using it, given the choice, again. I don't like exceptions, but can live with them. I don't like null, but can live with it. Nuget is complete and utter garbage. You still have to resort to all forms of unreliable hacks in order to redirect it to a locally clone (and if you do use a feed to avoid that, good luck with getting the local cache to not be completely moronic).
(Look, it certainly didn't help that the project itself was heavily enterprisey because the developers hadn't kicked those habits)
What exactly does this mean? I haven't touched .NET in earnest in over 10 years. I know the ecosystem has evolved a lot since then, but I don't know how or in what ways
Or, if you're trying to temporarily use a local source tree, swap out <PackageReference> for <ProjectReference>.
> 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.
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.
No, really, I'm facing more issues from Cursor based based on a year-old upstream version of VSCode than from this, heh...
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.
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.
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.
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
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.
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.
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.
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
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?
Although the EF team has made huge progress towards keeping your entities persistence-unaware, it's still not enough and eventually you wind up building your project in Entity Framework just as much as in C#.
New features are often more likely to be semantic sugar instead of some new big thing.
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...
If you take it in the context of the industry, I think async/await is the more imperative friendly option. It let's you write code sequentially without callbacks. And the performance gains are definitely worth it. I'll have to respectfully disagree
It helps that now most (if not all) parts of the stack are open source and run on Linux.
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?
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.
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.
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.
Could you please elaborate? Are you referring to most .NET shops not straying away from Windowsland?
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?
.net462 baby!
More like 4.6.2
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.
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.
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...
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-c...
In a world obsessed with AI and web tech, this is a refreshing read!
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.
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 :) )
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.
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.
What fragmentation? Honest question
var pixels = new uint[renderers.width * renderers.height];
var pixels2 = MemoryMarshal.Cast<uint, ulong>(pixels);
pixels2[idx] = ...
Spans is such a fundamental tool for low level programming. It is really unfortunate they were added relatively late to the language. Now every new version includes a slew of improvements related to them but they will never be as good as if they were there from the start or at least as early as generics were.
We force to use this workaround for now.
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
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.
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.
Don't know how trustworthy is this but it seems like it never was on top30: https://hnrankings.info/45888620/
This has 74 upvotes and posted 16hrs ago.. @dang?
I've restored it to the front page and wound back the clock so it gets its rightful dose of front page time.
https://hackernews.life/?s=top&id=45888620&t=1762939537
It arrived at rank 86:
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?
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
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"
I wish CPP development was as robust as C# development is
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.
With C++ it's a whole different thing.
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.
Yup.
It looks like they got someone from Apple to write their press release.
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.
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.
[1]: https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
dotnet tool install --global dotnet-ef --version 8.0.8
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.
Edit. I was not aware that the gap between System.Text.Json and Newtonsoft narrowed, take my comment with a grain of salt, please!
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.
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).
Yes, a lot of great features have been added over the years. But it also introduces some amount of cognitive load and confusion. Take the first new feature in the example:
> Field-backed properties simplify property declarations by eliminating the need for explicit backing fields. The compiler generates the backing field automatically, making your code cleaner and more maintainable.
Huh, I thought we have had this for years, what were they called, ah Auto-Implemented Properties- so why is there a need for this? In this example:
// Automatic backing field with custom logic
public string Name
{
get => field;
set => field = value?.Trim() ?? string.Empty;
}
get;
I feel like the documentation is always somewhat lacking in explaining the reasoning behind new features and how it evolves the language from earlier versions.
You could have:
public string Name { get;set; }
private string name;
public string Name {
get;
set { this.name = value?.Trim() ?? string.Empty; }
}
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
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!