Why would you use C# if starting a company/project today? I know C# fans love it, but seriously why not choose a community driven language over one controlled by microsoft?
And for writing C# on the server, the major benefit is that Microsoft has a batteries included web framework that’s very battle tested. There’s at least one good first party answer for every problem (auth, database connections, caching, etc) which is very nice as compared to finding 30 npm packages to try to put stuff together. And C# is a pretty nice type-safe language that’s as fast if not faster than Java.
As for the front-end scene? Yuck. That’s a big ol mess in .NET right now.
(And, oh man, that batteries included battle tested framework is a stinky pile of trash. The language itself is ok, but the framework uses every misguided trend somebody at MS thought as cool, has no documentation of them, and implements half of them in some way that only that person thought about. There is a passable "web framework" inside it, but you have to ignore the MS recommendations and know what tons of pieces to discard, also, it's not very batteries included, because the batteries are almost all poisonous.)
I've never used C# or dotnet core but I know from word of mouth that it is a relatively well put together framework of tools for doing a lot of the things organizations with a lot of backend services to write might need. Many of those orgs are already very locked in with Microsoft, so the greater support by the open source community that comes with typescript is mostly irrelevant. Whatever the officially supported version of something is is what you will be required to use, and the typescript ecosystem provides very little if you want some big company to declare one particular thing to be the blessed solution.
Java is “controlled” by Oracle. Kotlin by JetBrains. Scala is “controlled” by… no one knows. Go is “controlled” by Google. C++ is “controlled” through representatives of a consortium of blue chip corps, including MSFT and GOOG. They also “control” Linux to a significant extent. Their employees contribute to many OSS projects.
There’s no perfect governance structure. .NET has the .NET Foundation, like Haskell (also “controlled” by Microsoft until recently) and Python; but who “controls” Python? Did you ever bother to wonder or was it ever important at all?
And the language alone is insignificant, you need a community and an ecosystem that you and your project fit best in and you can rely upon for the lifetime of you project.
As for the frontend, you have to have so JavaScript somewhere, it’s unavoidable, so typescript is just a way to make the inevitable more palatable.
And there are other frontend options that go without any JS on your side, so it’s quite avoidable. In most cases it’s impractical to avoid JS for the browser target. But the browser is not the only UI target for many apps.
For embedded Linux, .NET runtime delivers memory safety for high-level pieces, great support for networking and multithreading, combined with simple unmanaged interop for low-level pieces. The lower-level parts of the software I made were in C++ to consume OS APIs not exposed to C# like drm/kms/egl, also to implement a few performance-critical functions in C++ with NEON SIMD.
For a web service running on Linux: the same binary runs on my development amd64 Windows and the target aarch64 Linux which makes it easy to develop and test stuff. Asp.net framework is first party, stable, and mature. The runtime is relatively small and is trivial to deploy. That project didn’t use C++ at all; the complete server is implemented in memory-safe managed code, good for security.
C# has best tooling on the market, by far.
Btw. C# has huge oss community
Huge cultural difference.
But for some reasons ppl that argue for fragmentation under umbrella of innovation never talk about sane experience, especially for newbies
It's basically Java without most of the bad parts. It's a very well designed language that fits most niches (fast, compiled, familiar syntax, feature rich, adopts recent PL concepts, etc.)
And every new praised feature comes with many caveats because the OpenJDK folks want to keep it backwards compatible and carry on all that dangerous garbage resulting from the many bad design decision made in the past. Virtual threads come with many caveats. Pattern matching too. The Panama FFI has been underwhelming. The value types proposal is kinda weird. GraalVM is great on paper but have you met someone satisfied with it in production? It’s nice you can, in principle, embed an R, JS, Python, Ruby and Java runtime on it in the same app, but does it actually work in production? It’s all praised to the infinity but it just doesn’t work right in production. And what’s dangerous - the caveats are not advertised at all, you really need to be very cautious and follow all the relevant Oracle talks and discussions here and on Reddit just to not endanger your software. Do you really believe that an average Java developer can cope with all that sheer complexity?
For example, pron might tell you virtual threads are fine but do you have the budget to even invite him on your team? Yes, obviously, you don’t have to be one of the developers of the Virtual Threads to use them appropriately, and they gave their best to make the APIs as user friendly as they could, which few really appreciate. My point is that it’s only the tip of the iceberg that many people talk about when they discuss languages. This may come as an unpopular opinion but that’s just my experience.
So, no, C# is not “basically Java”—it began as such and perhaps a decade ago that would be a good assessment. But today, C# is a robust language in its own right. You can also choose F# or VB if you like, they all run on the same CLR, like the JVM languages. And .NET is a full-fledged robust and comprehensive framework. There’s much less variability in the correctness and cohesion of the implementations across the .NET ecosystem—already because there’s much fewer moving parts and knobs to control. And .NET apps use much less memory for the same throughput and latency than JVM apps. In addition, as for DX, EF Core is much more efficient and straightforward than Hibernate and Spring Data JPA, and so on.
It just works.
That makes it easier to get started than say Python where you have to depend on multiple third party libraries with different support cycles, API styles, or even async programming models (e.g. gevent vs async/await in Python). And you can still swap components out if needed.
Not saying Rust or Python etc. are bad for writing startup software. Given the ecosystems I personally find it faster to get started with .NET because of the reasons above.
https://i.kym-cdn.com/photos/images/newsfeed/001/079/173/ed2...
You can go with dynamic languages if you're flying fast and loose, or native languages like Go/Rust if you are worried about performance but you miss out on the "enterprise" integrations of something like Java or .Net.
Speaking of Java, it's great too but the ecosystem is a jungle. It's more flexible, but that flexibility has a cost too and you'll spend a lot of time frustrated trying to figure out the right combination of configs in xml, toml, yaml, json, env, properties, etc files.
They don't always get this right but if you are careful you can get a codebase to survive 10-15 years under Microsoft without too much suffering. If you latch on to every shiny new thing they release (cough MAUI cough), then you will find yourself despising Microsoft.
Stick to the basics and a vendor like Microsoft can take you to the moon with zero drama.
If you're not, then I'm not sure what the appeal would be.
I work for a company in the former space. We have no intention of supporting nonWindows clients or nonWindows servers or even nonSQLServer DBs. It's not worth doing from a commercial perspective in our particular market. Consequently, it's C# and .NET.
Tradeoffs:
- You'll have to use Rider if you want a full IDE
- Or get used to VS Code and know its gaps
- Some workloads aren't as well supported in VSC (e.g. MAUI, desktop apps); as long as you don't need these, VSC is fine
- I know at least the CosmosDB emulator straight up does not work in ARM, even with the x64 emulation on the Docker image. Has been that way since M1 released.
- Occasionally, you'll run into issues where there are dependencies on x64 binaries like with Google OR-Tools which has a .NET wrapper around a C++ library.
- Have to get used to configuring cross-platform builds for .NET and Docker (not hard) since you'll often still be running in x64 environments in upstream cloud deploy targets.
- Terrible multi-monitor support; you'll need a $250+ DisplayLink capable dock for more than 2 screens.
- And the text doesn't render quite as crisp as Windows; might be that it would if I were using Apple monitors, but the same monitors are notably more crisp with Windows 11.
- PHENOMENAL battery life; for this alone, it was worth the switch. It's insane how good the battery life is for the performance. I've previously used top-of-the-line Dell Precision mobile workstations and the performance for the battery life on ARM64 is just unmatched. I can run Postgres (in Docker), a handful of Docker images, VS Code, and code on a cross-country flight
- The form factor is phenomenal. The same size as a Microsoft Surface 13.5" laptop but has 3 USB-C ports and an HDMI port. Of course, the phenomenal performance and battery life listed above
- The laptop is absolutely silent; never hear the fan kick on. I can be compiling away, running a Node-powered front-end dev runtime, a .NET web API, Docker containers -- never hear a damn thing. Coding in complete silence is kind of crazy.
- Stays relatively cool and never reaches the same temps as a Windows Intel laptop
- It takes a while to remap your brain for KB shortcuts; get Karabiner to save your sanity
- Download iTerm; it's like Windows Terminal
- If you switch to VSC, you need to commit to it and get used to the CLIWhat risk do you see here?
https://news.ycombinator.com/item?id=37470318
That might be a place to start looking.
It basically comes down to:b they could take development in any direction and the community of users is powerless.
There's a distinction to be made between doing something in public and something being done by the public.
- this year's correct way to access your database is...
- this year's correct way to serve dynamic web pages is...
- this year's correct way to make a Windows GUI is...Except in the case of languages/tools like python, node, neovim etc. Everytime I touch one of these there is always a new better way of accessing DBs, making a web server, making a client side render, no a server side render, async library, configuration system, build system, runtime, GUI patterns etc.
The only difference I see between both is that there is an authoritative opinion when it comes to .NET (Microsoft) while there is no authority figure when it comes to node/Javascript. Even the actual runtime, package manager, module resolution, build tools etc get forked and replaced but since there is no authority, everyone is like "lets wait and see who wins". While with a language like .NET (or Go for that matter) you know that whatever comes from Microsoft (or Google) is the authoritative answer and people are more likely to jump to it right away.
Don’t get me wrong, the naming sucks. Microsoft is far more likely to recycle names for marketing reasons than just introduce a new name for plethora of stupid reasons.
But Active Server Pages means nothing anymore. It stopped meaning anything since 2003 but they use it as a brand name than anything. It’s no less stupid than gulp, bower, webpack, bun, deno, express, koa, next, vite, etc.
It sounds like your argument is "because Microsoft".
If you are using VS Code, GitHub, or TypeScript -- well, all those are also controlled by Microsoft, aren't they? Microsoft is the biggest investor in OpenAI and in fact offers their own Azure labeled OpenAI -- are you going to give up on OpenAI because it's Microsoft controlled? React is controlled by Facebook. Go is controlled by Google. So what?
Why use C#?
- It's a very small step from TypeScript to C# if a team needs higher throughput on the backend[1][2]
- `System.Linq` provides a superset of JS Array methods and is easy to map from one to the other.
- It's performance is on par or superior to Go[3] and competitive with Rust[4] while being much easier to adopt because of the language similarity to JS and TS.
- It is an object-functional hybrid language owing to its influence from F#[5]; discriminated unions are on the roadmap and available today with packages like Dunet and OneOf, it has pattern matching like Rust, extension methods provide flexibility in modelling, named tuples in C# 12 converge even more with TS, it supports destructuring record types and classes, it has immutable record types
- Minimal APIs are very familiar for teams using Express but need more performance. I'd actually say that it's a bit simpler than Express on Node for common use cases since there's nothing to import when setting up minimal APIs since it's all first-party Microsoft.
- Platform support for source generators are a revelation; it removes a lot of boilerplate code while actually improving performance over reflection.
- Many of the things teams love about modern JS actually have influence from C#. Lambda expressions in JavaScript, `async/await`, and more. In fact, C# and JS/TS have been converging (see the linked repo).
- It's relatively easy to write high throughput code in C# with support for both concurrency (Tasks + Channels) and high level abstractions for parallelism (Task Parallel Library) as well as full access to threading.
- C# allows easy access to underlying low-level primitives; you can program with high level abstractions for productivity but still have access to call `unsafe` code if needed.
- EF Core is possibly the best ORM on the market right now in terms of performance, ease of use, maturity, and database engine support.
- A benefit of a language and runtime backed by Microsoft and used in the enterprise is that security issues get addressed by a team of professional engineers; you don't see the same types of security issues that pop up in the Node/NPM ecosystem.
- This is a big boon particularly because of the broad standard libraries and first-party libraries for many use cases. Rather than importing unknown dependencies for common use cases, you end up with a baseline of professionally maintained, OSS code.
- GitHub's State of the Octoverse report in 2020[6] showed that C# had the least Dependabot alerts and has the least transitive dependencies (less prone to security issues via package managers).
- As a general purpose language, it can be used in many domains from desktop to devices to web to gaming (both Godot and Unity; RyujinX).
- It's also quite mature and stable while languages like Rust are still ironing out async and Go just released generics. C# has been there; done that.
Besides, if a team is already using VS Code, GitHub, and TypeScript, they're already in the Microsoft controlled ecosystem.
[0] https://spectrum.ieee.org/the-top-programming-languages-2023
[1] https://github.com/CharlieDigital/playwright-scrape-api
[2] https://github.com/CharlieDigital/js-ts-csharp
[3] https://medium.com/servicetitan-engineering/go-vs-c-part-3-compiler-runtime-type-system-modules-and-everything-else-faa423dddb34
[4] https://www.techempower.com/benchmarks/#section=data-r21&test=composite&hw=cl
[5] https://itnext.io/getting-functional-with-c-6c74bf279616
[6] https://arxiv.org/ftp/arxiv/papers/2110/2110.10246.pdfAnyway, I favor productivity way over ergonomics. And my .NET apps are very robust and very easily deployed. Everything is perfectly well integrated. No surprises. Almost no sharp corners left. The DX is superb. The performance is great. It’s so easy to run. Time to delivery is good. And the most important bit - I don’t need to keep all the hidden Java traps in mind. JVM with its many implementations is an amazing piece of tech, but in my experience it appears as something overengineered and requires too much maintenance and fine tuning. Just like Spring, Hibernate, and many other components of a typical Java app.