I bet C# and F# are actually nice languages and I shortly considered adopting them together with Unity but at the end of the day I was still suspicious of Microsoft, and support for other platforms then windows. The article honestly sounds a bit like a straw man argument. Maybe bloomberg could have made another tech choice but then again I don't know the details.
Microsoft has first-party support for .NET on linux and it's open source. Their commitment to non-windows and non-.NET platforms has only increased over time.
any software project or language can die, but I honestly struggle to think of a company that has a better history of long term support than Microsoft. You can fault Microsoft for quite a few things but their ability to maintain software and provide stable interfaces for devs is second to none.
MS discontinues a UI library project and then hypes up a new one every few years. Today Blazor and Maui are hot, but there's a lot of abandonware that came before.
You can see it in Windows too, where you can burrow deeper and deeper into progressively older settings dialogs, because they reshuffle the Control Panel every few years.
To be fair. Creating a good cross UI framework is hard. Winforms wouldn’t cross over to OS X / linux. WPF was too heavily tied to Windows. Silver light was a compeditor to flash and both of those died. Now we are up to Maui and Avalion? Blazor is more silverlight replacement imo.
Also, Winforms and WPF were designed before Microsoft embraced Linux and started making .NET truly cross-platform. Starting over with a new cross-platform UI framework sounds like a reasonable thing to do.
OTOH even stuff as old as Windows Forms (which literally shipped with .NET 1.0 - that's 2001!) still works and it actually has maintainers. You don't have to chase the shiny new stuff.
Not with their core languages. For example, Windows still comes bundled with the old VB6 runtimes and Microsoft still supports the language even if they no longer add features to it. I'm not really sure of any major Microsoft languages that Microsoft has just dumped, unless you count their smaller more esoteric ones.
Also keep in mind that .NET Core is not only open source, but comes with complete protection from any patents Microsoft might have. The only thing Microsoft can sue people over is the .NET Core trademark itself.
> still supports the language even if they no longer add features to it
This is what I assumed the parent post was referring to. Mostly because it mirrors complaints I've heard (and maybe had) about the .net gui story. WinForms -> WPF -> whatever the windows store app framework was called -> I think MAUI now?
That's hardly a fault with Microsoft though. WinForms is fundamentally flawed and far better alternatives now exist, it'd be foolish to continue investing in WinForms. You can still use WinForms and .NET Framework on Windows 11, just don't expect new features, which is okay.
Wasn't J# designed to be a transitional language for Java devs migrating to .NET/C#? (Wikipedia calls it a transitional language, too) Sure it wouldn't last long.
Maybe, but the discussion itself was about Microsoft's commitment to open-source. Open-sourcing VS Professional, traditionally (and still) an enterprise tool, would be a bridge too far. The commenter that started this debate called the article a straw man, which is ironic.
Their support for VSCode is pretty considerable and reached the point where I'm comfortable working on non-GUI applications in C# in it a while ago, and from a UI perspective prefer it to Visual Studio.
If you’re a JavaScript dev, it’s worth noting that NPM is owned by Microsoft. The mistrust angle is real, but I think it’s moot when specifically talking .NET vs. JS.
I've been working in .NET for the last year using intel Mac for the first 6 months exclusively and recently switching between Windows desktop and Mac (performance of desktop machine mostly, not willing to be early adopter with M1/2)
I also use Rider exclusively and going to Visual Studio on Windows now and then I'm not missing much (visual studio did have some nice plugin for debugging compiler plugins, had to hack around than in Rider)
I can't comment on Unity part.
F# for me overpromises and underdelivers - it all sounds amazing in theory but it's been 3 times over the last decade where I've tried to use it (last time just a few months ago) and it never just works - I've spent diagnosing "why isn't this F# feature working as advertised" than solving my problem (from tooling like F# projects breaking autocomplete in VS solution - even for C# projects, to language features like type providers just being a nightmare to work with and integrate into CI/CD)
Honestly I've found F# pretty OK to use compared to some other languages, especially when not using Visual Studio on a non-Windows machine where F# IMO is the better choice. Given a cross-development experience in some of the more recent .NET teams I've been in (great that this is finally occurring btw) especially the Mac developers using VS Code prefer F#. After using it the feedback is that the experience on F#, especially since with F# Resharper is not necessary to function/develop, is preferable over C# (i.e. "its more of a scripting language").
My observation is that the ex JS/Ruby/etc devs learning curve's seem to favor F# over C# as it is more like these languages. There's just a lot less to learn, and the coding style (e.g. modules, function first, etc) is more synonymous with langs like JS than heavy OO languages. I've recently inherited a team that moved to .NET from JS, and getting them to try C# has been painful especially when using things like ASP.NET. There's a lot of knowledge I just took for granted - we don't realise how much knowledge is required to use standard Java/C# OO in a production like setting that many dev's stumbled on when they were junior but have long forgotten the learning curve they went through. They tend to be framework heavy/dependent and require much more experience. From patterns (what's a strategy, repository, etc etc), to dep injection frameworks, to which refactoring tools I need, etc, etc - where in F# in my recent experience the experience is more, but still not quite "just code and work it out as you go".
The pit of success favors F# over C# in my experience with these teams especially if you keep it simple with the features used.
My experience has been that F# appeals to coders who are using the .NET platform coming from languages like JS/Go/etc but also has static typing who usually at least in the jobs I've been in are often on a Mac. C# dev's typically come from Java/C# enterprise kind of shops. Not one is better than the other and I will work in whatever space has interesting problems to solve - I think the difference is more cultural than technical.
> For the front-end, JavaScript is unavoidable (for now)
Author really needs to give Blazor a try. I wrote some comments last week speculating that I'd use Dart or TypeScript with C# .NET on the client because WebAssembly doesn't do DOM manipulation, but turns out I should have waited to learn it better before making a comment.
I've learned I can add events and event handlers to elements without ever leaving C#. Then when I need to use a JavaScript library, I can load it just in time for my component. Once I got the hang of it I really felt like I've found the sweet spot for front end development.
Blazor is in development and will only get better. I believe it will eventually be recognized for what it is, but it's still early.
In theory, blazor is really neat. But last I checked you have to either go fully thin-client (server side blazor) or have an annoyingly large initial download (client side blazor). Which is probably fine if everyone's wired to the company network, but maybe less so if there's mobile involved or the general public needs access from the local coffee shop.
I'm currently playing around with server side Blazor and it works well. It's definitely not for general public applications but it seems great for internal corporate apps.
The issue that I have is since it is a thin-client re-deploys kick everyone off immediately. Where the web is totally stateless this is 100% state full. I'm used to being able to deploy production fixes rapidly without disturbing anyone's work but with Blazor server that's impossible. I've started to look into load-balancing solutions or something but not being able to roll out fixes throughout the day is almost a deal breaker for me.
Yeah, but F# is even worse than C# in the sense that you need really talented developers to get anywhere. Which is not a problem on personal projects, but can be for the majority of companies.
Building a company based on Fable/F# now. We're in process of taking folks with 2-3 years of react exp and teaching them Fable - it's a pretty quick transition. F# tends to attract some pretty talented developers as well.
Fable is pretty nice to work with.
Writing bindings is fairly trivial given typescripts influence on the front-end library landscape, and you can just yolo call things dynamically if you want.
Can confirm, we’re developing in Blazor now and it’s fine. Not as loosey goosey as js, but makes as much sense as any other js framework. And having such tight integration with Entity Framework makes development a breeze.
Server. From an ergonomic standpoint, the development is basically identical to WASM ASFAICT. This is all internal though, so ymmv if you're developing stuff for the open Internet. I guess it depends heavily on how married your org is or isn't to c#, which we very much are. I vastly prefer this to serving up a separate UI for what we do.
I'm a huge fan of C#, but I didn't really like Blazor when I tried it. I had expected to love it too. I found much of Blazor's boilerplate to be very ugly, I didn't like the complication involved in referencing npm libraries or backend code, and I couldn't figure out where several magical authentication related pages in the example app were coming from. I switched back to Typescript and Vue 3 (almost went with Svelte). I'm investigating the HotChocolate GraphQL library this week to see if I can marry the frontend and backend that way. I was hoping Blazor would give me a nice productivity boost, but native frontend development is hard to compete with. I'll likely try again in a few years.
> I found much of Blazor's boilerplate to be very ugly
I call that bureaucratic software because it reminds me of doing taxes. It's put me off from trying a lot of Microsoft tools, but with Blazor I decided to push through the pain. Once I did, I could see the logic of it and it became less of an annoyance
The thing is in .NET 7, they are going to decouple the WebAssembly toolchain from Blazor.
This will allow people to write competing frontend frameworks, or mix and match their JS framework of choice while calling into .NET app logic.
The latter already possible, though a bit hacky with the official tooling at the moment, since Mono can compile regular .NET code to WASM no problem (a fact already extensively used by game engines like Godot or Unity).
Blazor server was not executed on well. It's a poor react clone before react had hooks. The ecosystem is also small and not flexible. I would choose javascript over it, unless I already had a large investment in C#/.NET.
> Blazor is in development and will only get better.
How good can it get though?
Blazor WASM suffers from the huge initial, multi-megabyte download of the .NET runtime. How is that expected to come down to something in the range of 50-500kb what we have with most JS frameworks now? I just cannot do that on public-facing parts of an application. It is unusable when accessed from a slow mobile network. Company-internal stuff sure, who cares.
I really wanted to love Blazor, and evaluated replacing some of the complex frontend UIs at work which are a JS nightmare with either Blazor Serverside or WASM.
But serverside seems like an afterthought to me. I recently learned about Phoenix Liveview here on HN, and according to what I read, it seems like a much better option if you want that server-side rendering stream model. With Blazor-server, I get the feeling it is only a makeshift-solution until WASM takes off, and that makes me even more reluctant to use it.
I know that newer frameworks are slim but in practice bundles still seem pretty huge. Maybe that’s just asset bundling going on but I feel like people are still able to get away with.a lot
While the total download size is unlikely to go below 2MB with Blazor due to .NET Framework binaries, they are working hard on AOT and binary stripping, meaning your app could consist of a base framework download, served from a CDN, and subsequently cached, and a small app specific library that's comparable to a bundled JS lib in size.
Due to cache partioning in browsers now, this will still be a big issue for all clients. Don't also forget that many clients are in poor internet speed zones.
A 2MB "buy in" will be unacceptably high for lots of projects (but not all, obviously).
I know I'm coming across ad a blazor fanboy, but I'm curious what made you feel like server side was an afterthought?
The biggest way server side fucked us was originally db contexts are bound to scope via IOC in asp.net similar to MVC or razor pages.
Which is fine when your scope is a single request, but when the scope is a circuit you get so many weird fucking errors. We worked around this by disabling tracking. But the right fix is we should have used factories, but we didn't figure this out until it was too late and we had written a fuck ton of code.
This is such an obvious issue and should have been in the docs but wasn't.
The vast majority of complex JS SPAs are also multi-megabyte payloads. You can also prerender components the same was SSR is used to mitigate JS initialization.
As far server-side Blazor - it seems like an afterthought because you read about Phoenix Liveview? How is that a serious evaluation? Blazor is a core part of the framework now and the server-side model is always going to be a serious option because it enables functionality that can be done with the disconnected client/WASM mode (like direct DB access without the serialization + API overhead).
You can't look at some site that has 10MB of third party deps and compare that to what Blazor is doing. You'll still need third party deps with Blazor as well.
The sites that have a large 10MB bundle would have had 100's of 100KB scripts pre-spa days.
Have you actually tried Blazor ? Just the schism between WASM and Server and the feature matrix there, and generally shit quality of early stage Microsoft product - I wouldn't touch it with a 10 foot pole, likewise for MAUI - I've seen coworkers prototype both for some greenfield projects in last month or two and both projects gave up on it because it just isn't there yet for mainstream development.
I mean .NET core was pretty much in this boat pre v3, it took them years to move past the .NET standard mess, Xamarin never cleaned up and they are hoping MAUI will eventually just sweep it under the rug.
I wouldn't bet on any Microsoft stack that hasn't had 3+ years of successful use in the wild - I've been burned too many times. You might say the same is true for any other project/stack - but even when they moved to OSS .NET projects have this Microsoft level of complexity and boilerplate that makes diagnosing trivial things a slog. And Microsoft likes to put "stable" label on a lot of things these days with the pressure to ship. Good rule of thumb - not worth my time until v3.
I've tried Blazor. I built and deployed 3 apps for clients
over the last 3 years while consulting and was able to deliver the projects for 33% what it would have cost to deliver them with react or angular.
Clients have been very happy with the results.
Then I built my own startup with it, and we have a solution that 3 devs have been working on for 2 years.
I can't recommend Blazor enough. I love it.
I have run into a fuck ton of problems with MAUI though. It's a fucking dumpster fire of a technology.
* Blazor server side I have very limited experience with client side.
> was able to deliver the projects for 33% what it would have cost to deliver them with react or angular.
That’s a pretty extraordinary claim.
I know single stack can be more productive, but that sounds very impressive. Could you perhaps talk details of:
- styling blazor (eg. Bootstrap, tailwind); is it just drop in? How do you use it, eg. Without the tailwind preprocessor npm package?
- interactive front end components (eg drag and drop) that lag badly when using SS blazor in examples.
- bridging to native js (which is ultimately unavoidable in situations where you need integration like maps as far as I know)
- scaling load on concurrent users (one ws per user right? Are you using the signalr service & functions? I tried this and found the long running azure functions are quite expensive to run. Do you have advice?
Sorry I misspoke I meant a 33% reduction in the size of the projects. So projects that would have taken 6 weeks in React took 4 Blazor server side.
1. We just dropped in a wrapbootstrap template.
2. We wrote some javascript for interactive front end components like drag and drop or rich text editors. It was a little more work than it would have been in React but not much and everything else more than made up for it.
3. We found it wasn't particularly difficult. We'd just put JSRuntime.InvokeAsync in a C# method. Used it for things like popups and initializing some js libraries.
4. We're only using Azure App Service and Azure SQL database. Our long running functions we just run as a scheduled service on the app service. (though eventually we'll to do some refactoring when we need to scale horizontally). We're a B2B SaaS company so our revenue is quite high compared to our compute usage. By our back of the envelope calculations we won't have to add another server until we're somewhere between 5 and 15 million ARR. We think we'll need to do about 2-3 months of refactoring at that point to allow for horizontal scaling.
I wouldn't recommend Blazor-Server Side for B2C typical applications that have a low ARPU.
The big advantage in development speed is we got the functionality of a SPA but at the development cost of a classic multi-page application.
>* Blazor server side I have very limited experience with client side.
That's part of my problem with it - from what I see they are pushing two independent tech stacks (WASM and dynamic server rendering/JS updates) under the same name - but the APIs underneath and the architecture is very different.
The problem I have with Blazor Server side is that it requires a stable internet connection otherwise client socket connection drops and the browser issues a full page reload.
Or at least those were my findings last time I tried. I would be very happy if that isn't the case currently.
Man, I tried out Blazor over the last few days. I really wanted to love it (I love C#), and it looks like it might be good one day, but I found it sadly lacking. I couldn't even add a mouse event to a canvas element. I had to install an extension package to even use a canvas (BECanvas), and then that extension package didn't even have mouse events. I have to say, thats so absurdly basic of a thing to be missing that it made me call the entire library into question: what other extremely basic things could it be missing as well?
I was really excited for Blazor, until I tried developing for it. The DX is not really there yet and in the mean time I stumbled up HTMX (https://htmx.org/) and now I'm having an even harder time being excited for Blazor. And don't get me started on Blazor Server vs Blazor WASM...
The thing is, Blazor will become the lingua franca of (web) UI development for bigcorps, so I just need to suck it up and learn it (I'm a .NET consultant geared towards finance & insurance)
Its funny, after considering Blazor serverside and WASM, I also opted for HTMX + Alpine.js (when needed) + ViewComponents. Considering how nice server-side rendering story is in ASP.NET, I feel like this is a setup that really works well in a lot of situations, from low-interactivity pages to really complex UIs. It is lightweight on the client side (just load the small htmx and alpine scripts), lets me do much of rendering server-side in .cshtml views, and which needs no JS build pipeline of any kind.
With blazor you need to choose Client or Server Blazor. Client will give you 10MB+ page downloads, Server will require stable and low-latency internet connection. It's fine for intranet systems, but not for general webdev
There's no reason to discount front-end work from "programming languages". You choose python over typescript for machine learning because the ecosystem is there.
You choose typescript over python because Brython and JavaScripthon and Transcrypt have no ecosystem that makes more sense than using NPM, and the people who like to program in python prefer the challenges of other domains than what's in the web browser.
That just makes "most popular programming language" a silly metric. It doesn't mean that nobody uses the language because you ignore all the people who use it for things you aren't interested in.
IMO Python and C# are not comparable. Python is at best a simple scripting language, you really can't build anything globally scalable on it. No offense to people who use Python daily, just my own observations (probably wrong).
the biggest python codebase I'm personally aware of is JP Morgan's Athena and is about ~30 million LOC. Google, Youtube and Dropbox use Python extensively etc. Python being a scripting language stopped being a correct statement probably over a decade ago.
I am currently in the process of learning C#. I did a deep but brief dive into every language feature in C# 10. Being proficient in Python, absolutely nothing surprised me. All the same concepts, save for a handful, exist in either language, sometimes down to the exact keyword usage. LINQ is a big differentiator in favor of C#, but modern (that is, typed) Python looks very similar to C# (C# left, Python right):
ABCs -- ABCs
Interfaces -- Protocols/ABCs
LINQ -- ??
Enumerable/Enumerator -- Iterable/Iterator
class -- class
static -- staticmethod
foreach -- for
for -- for(range(...))
try/catch -- try/except
break/continue -- break/continue
enum -- Enum
struct -- dataclass, perhaps
namespace -- automatic on the file level
out -- pass by reference
switch/case -- match/case (both do structural pattern matching)
throw -- except
typeof -- type
overloaded methods -- singledispatch (only works for a single argument sadly, no stdlib multidispatch)
inheritance (single) -- inheritance (multiple)
object -- object (root of the type hierarchy)
generics -- generics as well (via typing, runtime never cared anyway of course)
lambda -- lambda
nullability -- None (C# can have nullable reference types, Python types are not nullable, None exists as a first-class type, not a subtype of all other types; similar ergonomics but different structurally)
extension methods -- just go wild in Python (although binding methods after class definition is cumbersome)
tuples -- tuples (both can do unpacking, multiple returns etc.)
operator overloading -- operator overloading
reflection -- reflection (arguably a Python strong-point)
async/await -- async/await
decorators (exist as a pattern) -- decorators (supported on the syntax level)
?? -- top-level/first-class-citizens functions
I probably got a couple wrong, but you get the idea: apart from LINQ, nullability handling and some others, the languages are incredibly similar in their feature set on paper. This is not talking about DX etc. though.
Perhaps in Australia, but certainly not worldwide. C# is way smaller than even Go in total, and Java is a lumbering giant. Slow perhaps, but there's no David around at the moment.
My instincts tell me that there’s no way Go is larger than C# worldwide. Large enterprises are still predominantly on C# and Java… Tiobe index, whatever you may think of it, does not support that… What’s your source?
Source for "C# is way smaller than even Go"? It's possible that there are more shops that use some Go (esp. for DevOps) than there are ones that use some C#, but that's not quite the same as C# being "way smaller".
Right now if I type the following keywords in Seek this is what I get (in order):
SQL - 11,425 jobs
Java - 7,390 jobs
Python - 6,777 jobs
C# - 4,995 jobs
JavaScript - 4,208 jobs
TypeScript - 758 jobs
Ruby - 252 jobs
Golang - 206 jobs
I also think that C# and .NET are awesome. Especially latest releases dotnet 6 and upcoming 7 have a ton of new things to be even more productive.
I like the fact, that you can develop command line apps, Web APIs, Desktop Apps and smartphone apps all with the same toolset, including the fact that deployment is possible on nearly every major platform for every major platform (except iOS and macOS Apps, as always only on macOS). Even systems programming and AOT is doable or full featured static deployment is possible integrating a small runtime into a single binary.
And boy is .NET fast...
This facts made Golang pretty interesting to me, but what I did not like here is the lack of a usable cross platform Plugin-Loader technology, most of the stuff has to be monolithic, then the module management and some of the missing concepts (like generics, which is also now available in go).
The sheer amount of concepts in C# is overwhelming (from basics like Generics to less common ones like Extension-Methods, operator overloading, etc.).
I don't like Visual Studio as IDE, but VS Code is an acceptable alternative tool, although I personally prefer the non-free JetBrains Rider.
Nuget package manager also has it's caveats, e.g. that the official repo can only "unlist" packages, not delete them or that the publish times sometimes have horrible delays, but that's also still acceptable, since you can use the github package registry or bring your own to overcome these issues.
Technologies on my todo list include getting into MAUI (a cross platform UI stack) combined with Blazor[1], which can use Web Components in native UI apps and develop TRULY cross platform (Web, Desktop AND Mobile with the same codebase). Like electron, but without the browser dependency due to native integration.
Although everything is tied pretty tight to Microsoft, there is a huge open source community developing cross platform libraries, that are easy to use. Even though i find that microsoft has often made strange decisions in the past, the current state is clearly a recommendation to have a look.
I tried writing a simple crud api with asp.net, which should parse and respond json. It was the worst development experience I ever had while writing json apis.
Validation? Not existent. OpenAPI/swagger documentation generation? Not existent.
Then it also tried to force me into using MVC, while acting that it is express with its middlewares.
I switched back to node.js with fastify and wrote my app in an hour.
I really like C# for cli and windows desktop applications, but I probably won’t touch it for the web in the next few years.
Validation and Swagger/OpenAPI have been available for a long time and well documented. I don't know what resources you used to learn ASP.NET, but they failed you.
FluentValidation and Swashbuckle are two great libraries for the tasks you referenced. This is a good enough reference repository should your curiosity be piqued again in the future: https://github.com/jasontaylordev/CleanArchitecture
Yep. The problem that the parent commenter had is distinguishing between "Not existent" i.e. the tool that I am trying out sucks; and "I don't know how to use this tool yet" - a completely normal part of the learning experience.
Failing to find the differences between them will impede learning in general.
As a C# developer I could say the same about my experience dealing with my first foray into [insert random language] and my attempt to develop [something with a non-trivial framework].
The issues you had could be attacked by navigating through this section of documentation, diving into the tutorial referenced in the beginning of the Overview section and the subsequent sections: https://docs.microsoft.com/en-us/aspnet/core/web-api/?view=a.... This is not necessarily in defense of c# and dotnet, but this reads like you barely spent any time trying to digest the documentation.
I’ve been a C# developer for a decade and I still think it’s hopelessly convoluted for getting very simple things up and running. Maybe there is something wrong with me, but it’s just not intuitive to me and it has frankly never been. I do think the move to core and then core to .net has improved things, but it’s still a really weird and way of doing things compared to other languages that I have worked with, and most of the “boiler plate projects” are very rarely useful, so why are they there?
Then once you need to go beyond the standard libraries it becomes a nightmare to deal with. In some cases, like extending the AD libraries, it’s sort of easy to extend classes with methods but the documentation on how to do so tends to assume a lot of domain knowledge. In other cases like if EF’s standard functionality isn’t enough for you, or you need to deal with weirdly formatted XML or non standard SOAP requests (don’t ask) it can be such a nightmare that it’s sometimes easier to write a micro-service in another language to do the “translation”.
I think it speaks of a language that doesn’t see too much use by its own creators. I may be wrong on that, but having build a lot of things for Azure, Typescript has often felt more like a first class citizen than C#. Obviously not for everything, far from it, but sometimes and those sometimes are enough to make C# troublesome because unlike things like typescript that are great second class citizens in the Microsoft ecosystem, C# isn’t. It either fits really well or you have to fight it.
I wholly disagree as a person who worked in C#/.NET for over 15 years and recently waded into Node/JS/TS dev. C# and .NET are hands down the easiest platform to start on.
In my decade around management that was not my experience with onboarding new people.
Maybe that is because we didn’t have a fascist linter for C# the way we do with Typescript, but it’s always been much, much, harder to get people to make “good” C# code in my experience. It hasn’t been hard to have the build things in C#, but it’s been hard to get people to build things the same way so that they can work on each others code flawlessly. So hard that I would never again consider using resources on it until developers drop significantly in pay, which isn’t likely to happen until I’m retired, if ever.
I wonder if it has to do with regional differences. I’m Danish, everyone (there are odd cases, but it’s more “everyone” than “almost everyone”) here has a CS degree and often they’ve been taught Java, sometimes C# but poorly, while obtaining it.
That's true (and minimal APIs help a lot) but ASP.NET still has a real problem with too much magic.
For example, the secret incantations required to output a mere string as raw json mimetype or log incoming deserialization errors* are unintuitive and very labourious - see InvalidModelStateResponseFactory. Or that I had to create a custom output formatter to output raw json. Why? Sometimes I just want ASP.NET to get out of my way and it's not trivial to tell it to let go.
* For example, url?parameter=1 for a boolean parameter, which would have worked with .NET Framework but won't for .NET Core/.NET.
And it says right at the bottom, that OpenAPI and model binding is not supported in their route to code feature.
I initially googled how to create a simple json api, and that’s the documentation which I found. Looks really easy in the beginning, but after you’re done with your routes, you’ll read at the end of the documentation, that OpenAPI generation, model binding etc is not supported. I blame that the guide‘s title is misleading and - of course - that I should’ve read till the end before actually following any step of that tutorial.
Well, while I understand, what you are trying to say (a simple crud web api should be easy to accomplish), I think that you were just overwhelmed by amount of possibilities, tutorials and outdated information, because C# / .NET is evolving fast.
That said, you may take a look at my small very early state pet project `tonehub`[1], which can be seen as pretty modern CRUD Web API in 2022, utilizing swashbuckle for OpenAPI, JsonApiDotNet for CRUD, Entity Framework 6 for Database, HostedServices for background tasks and some other nice concepts (DI / IoC, Options Pattern, FileStreams, etc.). I could also use SignalR for WebSockets / Realtime, integrated OpenID/OAUTH2 Authentication, FluentValidation for validation, Api Versioning and much more.
I've never accompilished something like this with this small amount of code...
I think that's the barrier with C# in general - the framework nature of it means there's a lot of "I don't know what I don't know" especially with ASP.NET which is quite large in scope. Don't get me wrong - that's the usual dev reaction when switching from their familiar language/tools to a new one but I don't think, at least historically, C#/ASP.NET made it as easy as it could of been. Which namespace do I open to import the right extension method to register swagger generation? How do I configure it? All that stuff IS existent actually and having worked with both in my current role the .NET version eventually ends up being a "just works" experience. Its just hard to approach and integrate if you don't already know the "patterns" and the libraries. Sadly there's a lot to learn compared to say Fastify for a basic working app. However it is very configurable and flexible. I've seen the same reaction from dev's to the Spring Framework as well - its just feels bloated for a lack of a better term to people coming from JS.
As per another comment after having seen JS devs switch to F# for very large professional application and not wanting to go back I feel its fine for web. YMMV.
> Which namespace do I open to import the right extension method to register swagger generation
If you use the templates provided by .NET Command Line Interface or Visual Studio, you'll get this all baked in & setup.
VS also added a very nice feature where it suggests & imports popular packages if you type a method on a type that's well known. If you already have it added to your project but need a using statement in this file, it'll pick that up fast as well.
They've also improved their docs quite a bit from years ago with lots of good examples for common things.
- Templates are no substitute for intuitive and minimal code for a number of reasons. (e.g. how to extend, how to customize, confidence that it isn't brittle if I change one thing, etc etc). If a template doesn't have the exact variation you want (e.g. a faster logging library) the learning curve is very high for a newcomer .NET dev. NOTE: I think this applies to some other OO languages too.
- Suggesting popular packages and namespaces is a great tooling improvement. But it could also imply a closed wall garden. The fact that other non C#/Java like languages don't have this problem even with something as minimal as VS Code as your IDE shows that the tooling is trying to cover over a language and/or library problem. With the Java/C#/other old OO lang workflow you need the knowledge you need to use the library itself (convention based, which class, which extension method, which namespace for that object to configure this feature, startup class conventions, etc). It isn't discoverable even with the packages imported. Remember just getting Serilog working in new ASP.Core and it taking a day or so with all the packages, config, etc etc if you don't already know what you are doing.
I like the improved docs. But fundamentally simplification/minimization is better. I think the dev workflow that means I don't need these tooling improvements is still a better experience. I like .NET, but I do understand when using other languages they seem to not have these issues despite not having the uber tooling that C# has. They don't have package suggestions, they barely even have auto complete yet the library design feels a lot more intuitive.
I can look up say a Fastify, Golang, even some F# examples with something like Giraffe and get a web app quickly with little code and no convention magic with everything being explicit yet concise. No fancy attributes I need to remember, no conventions in my startup classes I need to understand if any customisation, even dep injection is something to learn from people coming from some other platforms rather than just standard library calls composed together.
I actually like the .NET platform, don't get me wrong, I do think it is one of the best web platforms right now. Its more intuitive than Spring/Java as a comparison but that isn't saying much IMO. For newcomers I think the user experience to newcomers who are used to a lot less ceremony could be improved further. My first suggestion would be less "developer headspace required" to get started. On a personal note I think natural F# code tends to favor this from the teams I've been in but can't put my exact finger on a reason as to why - it feels more like coding Go/JS to me at least than C#.
I'm curious who does this well? I've personally not found any specific language or framework that is better than others unless you're using their preferred libraries. At that point it depends more on the library authors than the base framework.
For newcomers, I would say the best user experience (no matter language/framework) is provided by code hinting such as GitHub GitLens & competitors do. If I'm using an unfamiliar framework/language it's great at suggesting what I might want without me having to search.
You might really like the new .NET minimal APIs that are being built for web development. They're very similar to a Node.JS style of API.
In regards to logging specifically, I've found swapping logging tools fairly easy & straightforward as far as adding the logging in the code base. If there has been anything challenging it's been outside the code base & setting up the infrastructure or learning the logging's reporting tools. I'm curious what was challenging for .NET with you. It's usually as simple as using Ilogger no matter the tool & writing a few lines in the program.cs file.
Since I'm already spawning a TestHost and trying out various API calls, one of these tests basically does "curl $host/openapi/openapi.json | diff ./docs/openapi.json". If it spots a change and fails the test, I check that the difference is expected, and if so I temporarily enable and run a different "test" which actually writes the updated file.
ASP.NET configuration is one of the most arcane parts of .NET that I don't like. You have to perform the incantation thrice: add package reference, add service reference, invoke the builder extension. And there's the right order and the wrong order of invocations, and if you pick the wrong one, your app silently won't work correctly.
Arcane? What did you expect? Add a package and magically everything works? If you make it work by just adding a reference its “too much magic”, if you make it so people write everything “it’s boilerplate” and if you do something in between “its arcane”.
Totally opposite experience for me. C# + .NET ASP core Web Api framework + Swashbuckle + FluentValidation does out of the box what I still haven't seen a good solution for in the NodeJs world (which is the one I'm in now).
NestJS seems to hit the sweet spot for these. I'd add a proper Result type (from fp-ts) to get better error handling (than try-catch everywhere) and you're good to go.
We've just started looking into that, but the amount of existing raw JS+express we have means adopting something like NestJS is going to be a huge undertaking. What slightly baffles me is that at no point did anyone seem to stop and think if there shouldn't be a better way...
What do you actually mean by "non-existent"? The asp.net framework includes more functionality by default with its standard libraries than just about anything else.
> It was the worst development experience I ever had while writing json apis. Validation? Not existent. OpenAPI/swagger documentation generation? Not existent.
I'm not sure which learning material you used back then but this seems more like an unfortunate accident.
With .NET 6 SDK, 'dotnet new webapi' will give you a template project that does everything you listed save for extended validation logic which you can easily add with 'FluentValidation'.
In addition, to run ASP.NET Core nowadays you only need:
var builder = WebApplication.CreateBuilder();
var app = builder.Build();
app.MapGet("/posts/{name}", ([FromRoute] string name) => /* controller logic, classes will be serialized as JSON */);
await app.RunAsync("http://localhost:8080");
This will scaffold a project which is more or less the exact same as Flask, Express, or any other "easy" framework.
OpenAPI output is built-in, but tooling for development does require a bit of knowledge (agree that Microsoft would benefit from making this work out of the box).
> I switched back to node.js with fastify and wrote my app in an hour.
Of course you did. You're on familiar ground.
Personally I'm also familiar with .Net and could do the same in that stack in that timeframe too. Like with many things worth doing, it requires a time investment to reach that point.
Having said that, .Net APIs support JSON request/response out of the box, validation is available on the models in seconds using a powerful set of attribute annotations, and Swagger is also built in out of the box. And API projects can seem similar to MVC ones as they use the same framework and libraries, but whilst the out of the box APIs have controllers they don't have views.
So to repeat, it's down to familiarity.
Edit: For clarity this is not a criticism. I fully understand why these things may not be obvious up front. Both the validation attributes and the Swagger URL for the default support are not obvious to the newcomer.
I've been a .NET developer professionally for seven and a half years. Rider is the way to go. Visual Studio has improved dramatically over the last decade or so, but Rider is still way ahead of it on code search/discovery, performance, and general user experience. I did a tech talk at my company where I demoed Rider vs Visual Studio 2019 performance on our bigger projects... it was embarrassing for VS. VS 2022 was substantially better on performance, but also crashed during the demo.
Fair question, devs who do not want to share telemetry for the dotnet core SDK simply need to set an environment variable. VSCode has a similar setting in the options. Not sure about Visual Studio as I haven’t used it in a while.
Rider does not have a community edition unlike IDEA. It was created due to a combined threat of VS Code and Roslyn and is the reason ReSharper is almost neglected these days.
ReSharper isn't a heavy focus because it's not worth it anymore. To get the same performance as other tools they'd need to throw out a ton of work and rewrite it for Roslyn. With Rider, they get to continue to use their existing ReSharper codebase to power it.
I'd love to use Rider on Linux or even Windows. Sadly the lack of .NET hot reload on Linux and Rider's issues with hot reload on Windows are what keep me on Visual Studio. (Rider's implementation of hot reload doesn't support assemblies loaded at runtime yet, which my application depends on).
It's sad that the time saved with Visual Studio's hot reload alone seems to outweigh the (massive) performance gains from using Rider, given that I have to restart VS from its memory leaks multiple times a day or it will slow to a crawl. Omnisharp isn't performant or reliable enough for daily use, either. The current state of .NET tooling leaves me unsatisfied.
I don't disagree, and I love F# but I think it owes a lot of that to OCaml. That said, since we're talking about C#, F# and VS Code I'm gonna vent a little about something that arises when you use all three :D
If you open a C# project in VS Code when the "Ionide" extension (basically the F# extension for VS Code) is installed then the extension thinks it's a F# project and will open some F# stuff after a few seconds (or prompt you to setup some F# stuff in its gitignore). The root cause has been identified (plugin activates when it sees a ".sln" file), a PR has been opened and rejected with no mention as to why (https://github.com/ionide/ionide-vscode-fsharp/pull/1401) and the developers behind it are frustratingly non-communicative about it, closing issues about it (https://github.com/ionide/ionide-vscode-fsharp/issues/1701), they're not present in the discussion (https://github.com/ionide/ionide-vscode-fsharp/discussions/1...). Usual rules about OSS maintainers apply, they don't technically owe us users anything, we should be patient and respectful etc ... but man it is truly bizarre to be ignored or ghosted like this.
I still need to get into OCaml. I of course know bits by virtue of having used F# and SML, but OCaml definitely has its own unique features. For F#, I appreciate how well it sits upon the host VM for the CLR and .NET. It just integrates almost seamlessly while still being a functional-first ML. When I use F#, it's by far the easiest code I write. I find myself just writing out the domain and boom, I got a working program. Recently, I wrote some bindings for a C/C++ DLL, and F# really made that easy. It's the easiest time I've ever had creating such bindings in a language.
For the Ionide stuff, I agree. I don't use it, even though I use Visual Studio Code for other languages, and am happy enough with Visual Studio on Windows and Visual Studio for Mac on macOS.
It's not as bad as in npm with node_modules, because .NET provides a lot of base functionality in the standard library.
But when you start to use multiple nuget packages, sooner or later you will also enter dependency hell, where managing versions and updates of nuget packages gets very painful.
All in all we have to reference about 10 external libraries. The visual studio nuget package manager started to be frustrating if you need to manage those dependencies in multiple solutions. We therefore switched to Central Package Management [1], but then you realize, that you're just shifting the problem around. Now we have to put the whole dependency tree into the file 'Directory.Packages.props' and have to manage the version of 140 libraries. If there are version conflicts, we force nuget to use the latest version and just hope for the best.
Managing versions of dependencies and dependencies of dependencies is a major pain, but it's an ubiquous pain all programming environments share. And no, .NET won't relieve you from that.
I'm not sure if it will help in your scenario, but faced with a similar problem (~80 project solution, mixed c#/f#, with varying dependencies), I found success with Paket (https://github.com/fsprojects/Paket)
It is much more prevalent in the f# community (at this point `dotnet restore` is a perfectly fine default until you hit trouble), but isn't limited to just being applied there.
Yeah this is probably one of the biggest pain points, but modern tooling is really helping to the tide on this. Dependency management is never fun in any language, and .NET has some quirks which make it a challenge as you say. I switched to .NET from java about 5 years ago now and I'm pretty I !are the switch as .NET just keeps getting better. Dependency management is one of the last pieces of the puzzle to really solve for in terms of getting a much better experience. That said if you're starting a brand new .NET project today you can set up your CI/CD pipelines to do Continuous Deployment and use Renovate to automatically upgrade your dependencies and merge if your tests are green. In addition the trend is for smaller codebases these days which makes it far easier to upgrade major versions of dependencies due to much smaller scope of breaking changes. I think those two things in combination eliminate some of the pain we've all felt with not being able to upgrade several years out of date dependencies in huge monolithic codebases. I'm pretty excited for the future of .NET to be honest.
Did you really mean only 10 external libraries? If you'd said 100 I could understand - I hit a version conflict issue in a recent project on adding what was probably package #60 or so, but solved it easily enough after a bit of googling. And we knew we were using a lot of quite old packages (including .NET 2.1 EF, because of a rare breaking change they introduced with 3.0 that we didn't have a good solution for).
Our dev loop playbook at work has an advice to never touch Visual Studio's nuget package manager haha.
Instead, dotnet CLI + VS Codes find+replace does a very good job at managing dependencies. It has never been a pain and on project build, all imported version will be consolidated to a single one anyway.
> I don't like Visual Studio as IDE, but VS Code is an acceptable alternative tool, although I personally prefer the non-free JetBrains Rider.
I've used Visual Studio for 20 years now, and while the tooling has come a long way, I'm starting to feel like MS and the community are abandoning it for VS Code. I don't mind VS code, but unfortunately the stack I'm working in (Dynamics 365) requires plugins for Visual Studio that tend to lag behind the release cycle of Visual Studio versions by a few years. I use Rider for .net core projects on my mac and it's fantastic.
In fact my biggest criticism of my day to day job is Microsoft's support for this incredibly enterprisey framework I have to work in.
I see they move in VSCode direction with tools like Power Platform CLI [1], power platform tools extension [2]. PCF (PowerAps Component framework) enabling to develop UI components in frontend framework-of-choice... however none of that is available (yet?) for On-Premise deployment so we're 2nd class citizens. Because of that, haven't been able to play with this and try out so don't know how far that tooling goes.
As a platform, I really like it. Sane, consistent (except some very early stuff there), the backend extensibility - thumbs up for that.
F&O would be former AX? That seems highly rewarded field. I know it only from SQL point of view - It helped grow my SQL skills when SQL would be brought to it's knees (along with the business) due to skewed data distribution and occasional query plan invalidation.
Yep, it's the replacement for AX. I can't say I love working in it, but the clients are massive and as such, it can be a rewarding financial choice. The tooling is poor and the APIs are a bit difficult but it's made for some fun workarounds :)
Yeah I know all this, you can even use BaGet[1] symbol server to cache or manage private dependencies in an enterprise network. That is not the point... I think that the most used tool / platform should provide more flexibility for non-enterprise or less expierienced developers.
No offense, I like nuget, but I recently made a typo and checked in 0.0.23 instead of 0.0.2. Now, everytime I add a dependency that is < 0.0.23 to a project, that has not been synchronized / validated yet (the other problem I described), it automatically takes the best match, which is 0.0.23 assuming to be the newest package, even if unlisted.
I also burned a 1.0.0 because of a failing script like that... not really bad, but annoying...
Just developed something using MAUI's predecessor Xamarin.Forms
It was perfect and exactly what I wanted. I had experience with XAML and MVVM thanks to Silverlight and WPF, so that explains at least some of why it was such a breeze. But it is way nicer than coding for the web, and I've done my fair share of that.
I was able to port over most of the code to MAUI easily, except for the missing controls. But MAUI is very exciting overall, and I look forward to using it more. After a map control is released I will fully port my app.
I grew up on C# and tried server side JS recently, and my god, the decision fatigue of picking every little library to do every little thing! C# is just so batteries-included. I'm not sure Blazor is ready for prime time but I like the promise of being able to use C# everywhere.
Mostly agree with the author. But just wanted to point out that if we're doing C#/Java style OO patterns in JS (as in the Repository example shown), the value of using JS diminishes to almost nothing. JS works better without classes (and interfaces against them if using TypeScript).
Could you explain your point a bit more? They are EEE'ing a VSCode extension, so you're going to avoid that and the language, and the entire ecosystem?
They are replacing an open source extension with a closed source extension. Makes people nervous given the embrace, extend, extinguish paradigm that they previously employed.
Sorry, but OmniSharp sucks, and this is not a controversial opinion even among Microsoft employees. I am all for the .NET experience in VS Code improving greatly from where it is with OmniSharp. This will actually help increase adoption of .NET, which, I remind you, is open source.
I agree. This appears more like an attempt to get the most value (integration of proprietary Visual Studio features that devs want) into the VSCode extension as quickly as possible.
Said proprietary libraries are likely not able to be easily open sourced for a variety of possible reasons, so a closed source LSP bridge was the compromise the teams came to.
The directly related fight here is Microsoft's pylance on the Python side. pyright still exists and many of the components in pylance are still open source, but pylance itself is closed source and bundles closed source tools. (That is pylance is not just a pyright fork, but closed source LSP bridge for pyright + proprietary parts.)
It's not without controversy on the Python side as well.
At some point it simply becomes questions of stewardship and transparency: How good are they at pointing out the open source parts wrapped inside the closed source LSP bridge? What cadence do they upstream fixes to the open source parts?
So far Microsoft's stewardship on the Python side seems strong: pylance has a lot of transparent documentation of all the open source bits. There seems to be a steady upstream flow to pyright for users that prefer to stay entirely with an open source LSP. Microsoft isn't treating it like a competition to "win" and encourages users to make their own choice among the options.
Of course, Microsoft doesn't "own" Python in the same way it "owns" .NET so I can definitely understand why there's increased fear that Microsoft won't be as good of a steward with respect to this "competition" with OmniSharp simply because of .NET's past. But in .NET's past this controversy would be happening after Microsoft did all the work in building the closed source LSP replacement. The fact that we're having this discussion now in only an "architectural discussion" state says a lot already about how Microsoft's stewardship and transparency have changed today.
Maybe it's good to have an open ecosystem for using the language that doesn't rely on paying for an IDE? I personally soured on Kotlin for this same reason!
It's slow, it's bloated, it's loaded with way too many configuration options and yet still doesn't have a lot of config I like from other editors. It has plenty of plugins and still manages to be missing extensions that I find important.
Development with Visual Studio just doesn't feel very good compared to other environments these days.
You mean lack of GUI tooling, no proper debugger, no parallel code debugging, no GPGPU debugging, no hotcode reload, no REPL, no mixed language debugging, no lifecycle management,... yeah those environments rock.
Yes, VS is free for individual devs, and for five users in a small business. Does it matter though? If you're too cheap to pay for developer tools, you're probably a terrible place to work at.
Yeah it's pretty important if you're at such a terrible place to work at, because you can make that place a little less terrible, and because you can use the C# experience you garner to get into a less terrible job.
Why do people feel they are absoultely entitled to having best-in-class IDEs for free? Don't the developers of those IDEs have the right to, you know, eat?
ALso, JetBrains' IDEs are:
- free for students, startups and opensource projects
- cost an insane "two/three beers a month" for individual licenses (yeah, it's more expensive than two beers in many countries, but as a developer I could easily afford it even in the shithole that is Moldova)
I'm not entitled to a best-in-class IDE experience, I'm just happy using one of the dozens of equivalent languages that do have them with an open community.
Those are not best-in-class. Pretty much the entire industry is now VS Code by default - which is very good but not a full IDE like VS or Rider/IntelliJ series.
I'm extremely happy writing Rust with neovim and rust-analyzer. There are plenty of long time rust users who will absolutely tell you that rust-analyzer beats IntelliJ Rust, and I find it very much comparable to writing Java in IntelliJ, which I do professionally. Likewise, Elixir's open source and community developed LSP is incredible and easily an IDE-class experience with neovim or VSCode.
No language has been tied to an IDE since at least early 2000s. Microsofts own compilers are free to use.
So no idea what you're talking about when you talk about "a language that doesn't rely on paying for an IDE".
And the tools for most of the languages supported by the open community? The top, best-of-breed of these tools can barely do the bare minimum of refactoring and maybe symbol lookups. Even to this day you can read things like "X is amazing for refactoring because you change something, and the compiler will tell you all the places where it can't compile".
Good tools are expensive. And, surprisingly, Jetbrains' IDEs are not expensive at all. And are several orders of magnitude more powerful than anything the "open community" has come up with.
And, to re-iterate, no language is dependent on an IDE these days. Go grab Kotlin's CLI compiler, https://kotlinlang.org/docs/command-line.html fire up your vi/emacs/gedit and code to your heart's content if you're so set against commercial IDEs.
On the other hand, I have no idea what you're arguing about any more. The context is about using VS Code (or something else) with OmniSharp instead of VS and Rider; what does the bare minimum of being able to compile code have to do with it? It's almost like you're making my point: if you want to be productive with C#, you have to use proprietary tools; otherwise, all you can do is just compile your code!
> And, surprisingly, Jetbrains' IDEs are not expensive at all. And are several orders of magnitude more powerful than anything the "open community" has come up with.
This says more about the languages and ecosystems you're used to. Try out rust-analyzer and say that again!
> The context is about using VS Code (or something else) with OmniSharp instead of VS and Rider
This is what you said, in it's entirety: "Maybe it's good to have an open ecosystem for using the language that doesn't rely on paying for an IDE? I personally soured on Kotlin for this same reason!"
And then you go ahead and praise a tool that implements LSP...
Do you realise that "open ecosystem" literally couldn't produce anything of note for any language until the megacorporation you love to hate came along and provided a solution? It wasn't "open ecosystem" that gave you the language server protocol. It was Microsoft that designed it and implemented it for their own VS Code. And the "open ecosystem" that sat on its ass for decades flocked to it and to the protocol like kids to the Pied Piper of Hameln.
And again with "you need paid IDE to develop this and that". No. You don't. There's LSP for C#. There's LSP for Kotlin. You'd know that if you went ahead and looked just slightly beyond your blind hate of commercial IDEs.
Honestly, you've been attacking me personally for quite some time now for no reason (I've done the courtesy of not attacking you, perhaps you could try to do the same?) so I'll not bother responding after this. At any rate,
> You'd know that if you went ahead and looked just slightly beyond your blind hate of commercial IDEs.
Maybe you missed me saying I use IntelliJ professionally in the previous comment? I'm a happy, paying user of JetBrains IDEs, I've defended them several times on HN myself. I don't hate commercial IDEs; I hate being forced to use them.
It's extremely bizarre that you assume I'm trying to cheap when I'm trying to be principled: I believe the presence of free (as in speech) solutions are essential for me to seriously consider a language. Being tied to a corporation's whims to efficiently use it is ridiculous; I was a happy F# hacker myself until I saw the more recent moves MS has been making. I think what they're doing - replacing omnisharp with a closed source solution and the debacle with trying to make hot reload a paid VS feature being two major, recent issues - show that MS simply cannot be trusted to run a language ecosystem without trying to force its users into behaving as they want them to. There's simply no reason to invest any time into the dotnet ecosystem when there's very comparable languages with comparable performance and ecosystems which don't have this issue.
> And then you go ahead and praise a tool that implements LSP...
What? I'm afraid you've completely lost me here. It doesn't matter that MS came up with LSP, so long as the protocol is open and people can implement and use it without MS's approval. Dozens of editors that have nothing to do with MS implement LSP, the fact that it was made by them is almost incidental.
I work at Microsoft as a SWE and use VS Code for c# and js. I've been using VS and Rider a bit as well, but after years of doing python and everything else in VS Code, it's just so familiar and it works just fine for everything my team does so far.
Obviously everyone's preferences are different, so this isn't a direct response but just another anecdote.
I tried VS Code and couldn't get used to it. So now I use Rider for C# and Webstorm for JS. Sometimes I open Visual Studio, though:
> There are some custom plugins someone in my org wrote that help accomplish some team-specific tasks
> When I need to work on stored procedures in our SQL databases. Rider doesn't know how to parse the schema from the sql project files, instead it wants me to connect to a live database or it will color everything with little red underlines and give me no autocomplete
I think it's nice that my employer is willing to pay for my Jetbrains licenses despite the fact that it is selling a proprietary competitor and also simultaneously pushing an open source alternative. I appreciate it.
Licensing costs, licensing costs, and the fact that you often don't need to go through corporate approvals to download VSCode and the C# extension particularly if you are an employee who isn't nominally a "software developer".
VSCode with the C# extension is the preferred C# development environment of corporate shadow IT.
My understanding is that with .NET Core, the experience of developing and running on Linux is on-par with Windows(?). However, my impression is that once it comes to building web services, ASP.NET has more "windows-specific" assumptions/moving parts - can someone knowledgeable on this correct me if I'm wrong?
Any .NET NuGet packages targeting .NET Core/.NET 5+ without the -windows TFM will run on any platform that CoreCLR runs on. ASP.NET 6 is no exception. There is nothing Windows-specific in there any longer, and there hasn't been for quite some time. ASP.NET now runs by default on Kestrel, Microsoft's cross-platform web server.
> Any .NET NuGet packages targeting .NET Core/.NET 5+ without the -windows TFM will run on any platform that CoreCLR runs on.
I got sleepy just reading this. There's just so much fragmentation and frameworks and different versions of frameworks and web-servers... can't Microsoft just let the .NET be and let them do their thing? They have certainly pumped out loads of amazing software that seemed to get a knee on the guts by higher management.
In fairness that is what they have done. .NET Framework is dead, .NET Core is "dead" (to clarify: .NET Framework dies with .NET 4 and .NET Core/CoreCLR is .NET 5 and above).
Mono is a cross-platform (ish) implementation of .NET Framework, but its future is (eventually) to be replaced with the main .NET which is now based on the cross-platform version (.NET 5 and above, which is currently distinguished from Framework by continuing to call it ".NET Core"). Mono and .NET Framework will fade away once Unity gets their act together and moves on from it.
tl;dr: .NET 5 and above are, for all intents and purposes, the only future path for .NET, but we're in a transitionary period right now.
Note that Mono, the framework, is indeed dying. But Mono, the runtime, is now part of .Net and it's an alternative to CoreCLR, used for things like Xamarin/MAUI and Blazor.
Though most of the time, you don't need to know any of this, you just use .Net and it works on Windows, Linux, Android, Apple and in the browser.
You can also use the .NET CrossCore assemblies (available since .NET Framework Core 4.777.2.1) and do multi-targeting for ASP.NET Core (the Framework version of ASP.NET Core, not the Core version which since version 5.0 is incompatible). Using ASP.NET Core 6 (the new name of ASP.NET 4.2) you can also target Linux if you compile with the flag /fuckallthatshit
I wouldn't call it on par. But it has been getting better. Developing on Linux still isn't great (I vastly prefer Visual Studio over VSCode for .NET), but might be good with the Rider IDE, which I haven't used. Running it has come a long way, but there are still some annoyances left. I'd still say that it is good, though
The only parts that are noticeably Windows-centric are some of the tools around .NET. The older tools are Windows-only, you can't get Visual Studio on Linux.
For ASP.NET there is nothing Windows-specific in there I've noticed.
There's no issues with Windows specifics in /ASP\.NET( Core)?/ version >= 5.0.
There's some issues if you need to use an older version of ASP.NET and whether or not it has "Core" in the name, but after .NET 5 and ASP.NET 6 there's no longer that fork to confuse things and it's back to much simpler version numbers/checks and no longer needing to worry about the word "Core".
- Ignore all the DotNet version names and numbers unless you're working on legacy stuff.
- If you're starting from scratch all you need to know is that you should use DotNet 6+ and you'll be on the mainstream track with full cross-platform support.
- Nothing is Windows-specific unless you're actually wanting to target Windows stuff specifically.
- If you're doing desktop dev MAUI is the way forward, but personally I don't trust Microsoft with desktop stuff any more (too much switching and deprecation over the years).
Thanks - I was actually more confused by the comments as I'm a total beginner to .NET (just interested to learn). This sounds like a more simple/distilled advice in my context.
Obviously there is some degree of subjectivity as what a given language's competitors are. In some sense all languages compete with one another but I do think there is some natural clumping of languages/ecosystems.
In my view Python and Ruby are not natural competitors to C# as they are dynamically typed and (in Python's case) interpreted. Similarly Rust, C, and C++ are not natural competitors to C# as they do not have a GC. Java, C# and Go, on the other hand, are pretty similar.
This obsession of dynamically typing vs static typing is not useful. ASP.net is used to develop web applications. C# does have better performance than Python, but I highly doubt most applications will ever need or care about that. Choosing C# over Python (or Ruby, JS etc) for performance reasons is premature optimization at best.
Maybe you have some legacy codebase in C# that you need to leverage.
All other reasons to chose C# over something else for web applications seem to lack evidence but certainly not conviction. So yes, Python is a direct competitor to C#, as in there are many more Python web projects out there than C# ASP.net ones.
They definitely see Go as direct competition, or did at various points. Some of the work that was done in Python 15 years ago is now done in Go, mostly because of its superior support for highly-parallel workloads; so Python developers have reacted and improved the parallelization story in various ways (yes, it's still not as good as it could be, but it's undoubtedly better than it was when Go took a significant bite off the ecosystem).
As for Java and C#, it is a fact that all of them joustle for the backend market together with Python. Java and C# were there first and have massive commercial backing pushing them, but Python has slowly carved a larger and larger role on the back of technical merit. As long as it continues to do that, I don't think you need to worry.
I don’t see Python having a lot to offer in terms of technical merit really. Python’s strength is language ergonomics and fun factor. I hope they keep it that way.
Or Kotlin, since it's IMO a slightly better language than C# in terms of ergonomics and features.
I understand that 90% of Kotlin's audience is mobile devs and server-side Kotlin is rare, but as a .NET developer, a few years ago I did a small production Spring Boot webservice in Kotlin and the experience was really good.
Reading this post, it seems like the author never tried Typescript which seems to be heavily influenced by C#. I hate JavaScript as a language, but Typescript is very palatable. Like it or not JavaScript and Typescript are the franca lingua of programming for now
The problem with TypeScript is that because it's compiled to JavaScript eventually, it's broken whether it wants to be or not. TS might make sense on its own, but the medium is the message. You can't escape the bizarre stuff JS does when it's right there, under the hood, waiting for you...
That is true, but its strengths tend to outweigh its weaknesses.
Nothing is as universal as typescript / JavaScript. Unlike other languages you also don’t have to context change when you’re transitioning from working on the backend to the front end. Everything also tends to be rewritten for node eventually.
The author specifically mentions TypeScript. But it doesn't do anything about the dependency problem, nor the performance. And it can only patch over JS flaws so much, since the runtime and stdlib are still whatever the ES spec says they are.
Where to start. Comparing advisories per package isn't a good metric. It assumes the usage and visibility is the same. Assuming the much smaller community around nuget packages won't bite you just as hard as bigger communities in terms of supply-chain attacks is a fallacy. Provided you can even meet your supply chain needs, and that's not a given in dotnet.
And not comparing ASP.net to more mature web frameworks is also a strange choice. At the very least, you need very capable developers not to shoot yourself in the food with the enterprisy dependency injection magic. In my opinion much more so than with other frameworks. I mean, if you have a steady supply of highly-qualified dotnet engineers, go for it...
Until .NET has the equivalent of Zod, I'm not that interested.
Being able to write a validation schema and deriving types from it automatically - that I can share on client and server - is just too big an advantage.
Similar in F# land is https://github.com/Zaid-Ajaj/Fable.Remoting
While both client and server are designed to be used from F#, they should be able to be used from js/ts as well as c# if desired, though I have not tested that.
Without JetBrains Rider .NET would have no cross platform dev experience.
VS is shitty Windows bloatware, VS for Mac is utter rubbish and OmniSharp was killed by Microsoft because they didn't fancy to give away dev tools for free and purposefully killed it in order to replace OmniSharp with a closed source extension, which as of today doesn't exist yet. So if you are a Linux developer then you are basically fucked today if you wanted to use .NET, except there is Rider. Without Rider .NET would be completely unattractive today.
If one is okay with this then .NET is amazing. Otherwise I cannot advocate for .NET anymore I am afraid. Microsoft doesn't see what's good for them. VS Code is the future, not VS. They invest too much time and money and marketing in selling VS to developers instead of making VS Code a great free OSS experience.
I think they are exactly seeing this and acting on it. IMHO they will start offering on VS Code a basic free product (a stable omnisharp equivalent) good enough for coding, debugging, etc. and then pricy options like visual designers, intellitrace, AI-guided coding, hot reload, etc. IMHO they will do the same for Python, PHP and others.
They head of the dev division needs to protect the revenue. Simple as that.
However, I completely agree with your sentiment: "Microsoft doesn't see what's good for them" ... because "free" is not "open source" and trust does not come from "free" but from "open source".
Totally get the bigger point, but I have to say the latest VS Mac is actually shaping up quite well and I like it.
Though of course in retrospect it does depend upon which workloads you're working on - and I mostly do command line tooling, web apps, and APIs, none of which require a design surface so maybe that's why my opinion differs as I've no informed idea how good/bad the layout aspect is.
I started out agreeing heavily with the article (yeah, javascript sucks today!), but one thing stuck out to me:
If Typescript makes Javascript so much work because the tooling discourages learning best practices, how does moving to C#, which is designed very similarly, help?
I.e. if half the cardinal sin was creating Typescript in the first place and that's part of why Javascript sucks so bad (I am inclined to agree, FWIW), how does C# then make it better?
Author is light on the details here. I do agree that strong typing systems, safety checks are preferably on backend systems-grade code, at least, but I don't think C#'s types are strong enough, for that prefer something like a Haskell-ish language, Cayenne e.g., Ada, and with strong code-re-usability. I decline to champion a particular language, I only know C# has a lot of baggage from Java/Typescript/Javascript, which it would be better without (C# is also starting to suffer from a C++-ish problem, where there are so many new and different ways to do the same thing that interoperability and "good" standards are swiftly becoming a problem).
This thread shows there is still a large amount of FUD around .NET and it’s community.
Folks here still think it’s Windows-only and comparable to Java. Yet latest TechEmpower benchmarks shows .net running on Linux and being faster than Go, Python, Node, and Rust.
VS Code has a C# debugger on Linux. There are certainly limitations to the open source C# support in VS Code, but for students it should be easily sufficient.
If you want a language where not only the core and main libraries are open source, but also all the tools then C# is probably not the right choice. If free (but not open) tools for most use cases and paid tools for larger companies or higher-level demands are okay, then C# fits.
OmniSharp (VS Code extension for C#) has been discontinued and there is no replacement yet. Besides, Microsoft purpusefully sabotaged OmniSharp to make it so unusable that it forces people to use Visual Studio, so even if a beginner on Linux would decide to try C# with a discontinued product they would only face difficulties and a basically horrendous mostly broken experience. .NET on Linux is non existent without Rider and there is no way to sugarcoat this fact. It's sad how ignorant some people are about this and keep peddling untruths about C# that it is well supported on Linux when it isn't.
It is not discontinued, it is regularly updated, and all the interesting parts are coming straight out of the compiler project (Roslyn) which will be the source for all future alternative extensions. Surely, they have different interest and do not put too much money into OmniSharp.
Do I like that some part of the stack is closed source (like the debugger and in future the extension host): No! Does it lead to a broken or discontinued future: No!
Compared to my experiences with PHP, Java and JavaScript, C# on Linux is just fine.
I use vscode on Linux without any problems. Can debug and do all I need to do without any problems. Omnisharp may not be perfect but it works. It will be interesting to see what is going to replace it but short of the closed source concerns I’m fairly sure it will still work.
And please stop this fake reality bullshit. NOBODY, not a single freaking person who wants to learn a new language will start off by searching the internet for an IDE and debugger where they can apply for a free license and then wait a few days so they can try it out. That is just ridiculous to even suggest.
If one wants to learn a language they download the SDK, open VS Code and look for an extension. If there is none or the one that exists doesn't work they basically say "WHAT THE FUCK IS THIS SHIT", close it and walk away with the conclusion that it's not well supported. Let's stay real please okay.
Then you should say: "a person who just starts with .Net".
> And please stop this fake reality bullshit. NOBODY, not a single freaking person who wants to learn a new language will start off by searching the internet for an IDE and debugger
I started with .net only 4 years ago. I went ahead and got myself Rider because I dislike VS Code and I already had 6 years experience with other JetBrains IDEs.
Oh look. I'm that "no single person" who went ahead and looked for an IDE. And bought it
> Let's stay real please okay.
Screaming nonsense at the top of your lungs doesn't make you any closer to reality.
> And please stop this fake reality [...]. NOBODY, not a single freaking person who wants to learn a new language will start off by searching the internet for an IDE and debugger where they can apply for a free license and then wait a few days so they can try it out. That is just ridiculous to even suggest.
I actually did. JetBrains products were really nice to try out whilst studying in university and eventually lead to me purchasing the ultimate tools package for any personal or professional projects that I might want to do.
It's really amazing to have the same set of tools for almost all of the languages that you might want to work with, that work consistently across all of the OSes that you might use. Normally I avoid paid software because of the vendor lock in, but a lot of the time it feels like JetBrains are just the company that you should reach for to avoid headaches, for better or worse.
For comparison, in the Java ecosystem, you also have Eclipse which has performance problems and an odd/unstable plugin ecosystem (though some swear by it) and NetBeans which has been handed over to Apache but doesn't really get much love or attention towards its development at all. Of course, some might use Visual Studio Code or another text editor with plugins but not being able to do refactoring across a project with 4000+ source files makes that approach dead on arrival for me, for all but the smallest projects.
The situation is pretty similar in regards to C#: you have Visual Studio which limits the platforms, JetBrains Rider which is a paid project, Visual Studio Code plugins which are insufficient and also something like MonoDevelop, which has pretty much been abandoned.
Only for some students. If you don't have an .edu address and your college or university is not in their pre-approved list, it's difficult to get a free license. It's a pretty typical attitude towards us coming from third-world countries though, and we developed our own ways of dealing with this.
Rider is free for students and that is how I started using it.
Also, VS Code with OmniSharp isn't that bad for smaller projects for development and is pretty good for debugging for apps of all sizes (my 2 year experience with it).
So to claim that you cannot debug C# on Linux for free is false.
Every benchmark is a cheat and not a real-world problem.
I also thought their benchmark is a cheat. But it is not. It is testing exactly what the benchmark was testing in that scenario. That is why TechEmpower Benchmark suite is so powerful. It uses different web server scenarios (connection, JSON parsing, database connections, ...). The different test case implementation .NET and others have are making sure no other factor is influencing this. For example: when you benchmark connections why dealing with MVC, validation and database connections.
It is not .NET who cheats, it is the others who do not properly isolate the tested performance aspect.
And to make the comparison a bit more real and day-to-day applicable, you need to pick the right framework configuration (like aspcore-mw @ 80% / aspcore-mvc @ 37%) and compare with other reasonable scenarios (like express @ 1% / spring @ 2% / quarkus @ 8%). Both are then far of the top 10 ten list but still comparable. The top 10 combinations are for cases where developer productivity does not matter but throughput is the key (e.g. a DoH resolver or a system like a Cache / Database).
Until Microsoft can match the dev experience of writing front and backend in typescript with pnpm, I’m not touching the dotnet/nuget cli(s) with a 10-ft poll. If you want to write C# just write go
I don't get this. If you want to write C#, write C#. If you want to write Go, just write Go.
Go is a great language because of its simplicity and ecosystem, has lots of useful things in the standard library, has pretty good runtime performance and also compiles to static executables easily (which is especially useful for projects like Nomad). It's both a good fit for web development, as well as writing smaller or larger utilities. Honestly, its packaging situation is leaps and bounds ahead of something like Python, so I predict great future for it in DevOps too.
C# is a more advanced language with a rich history and a lot of the functionality for web development in particular coming as first party packages. Some of that historical baggage weighs it down and the complexity can be annoying, but ASP.NET Core, EF Core, Kestrel and many other components are great. Plus, running on *nix is good, even though the single executable/runtime/deployment situation isn't quite as easy as with Go.
Write code in whatever technologies work for you. My caveat to add would be that I'd (almost) always develop front end and back end separately, since the React/Angular/Vue webapp really shouldn't care much about what technologies are behind the APIs. Of course, being able to use a single language for both FE and BE development is also a worthwhile approach!
That’s because my argument has nothing to do with the language itself but you still felt compelled to write an essay. I’m saying the modern Linux-based tooling, ecosystem, and devex of C# is inferior to so many other choices.
I don't get it because the claim that "If you want to write code in language X, just use language Y" doesn't vibe well with me. It feels needlessly dismissive somehow.
Hence the exploration of the good things about each of the languages and genuine reasons why people might enjoy using them for slightly different use cases.
At the end of the day, everyone can make that choice for themselves, unless their org makes it for them.
The performance really is astonishing in many areas now.
The part that keeps me hooked is the fact that I can stand up something capable of producing those numbers in 30 lines of code using 1st party dependencies only. I can then have a full prototype to demo by late afternoon, again having antagonized over exactly zero 3rd parties.
For me, the performance numbers aren’t just about speed while in production. It’s also about speed to production. Having the confidence that it’s almost certainly going to be fast enough by default keeps me from worrying about optimizing random bullshit throughout.
I still haven’t seen anything that comes remotely close to the combination of speed and stability offered here. I do some pretty nasty things with the runtime and it just copes. GC seems like pure magic now too. I continue to avoid things like LOH allocations with streams, but I don’t worry about it like I used to in the 4.x days.
PHP is still a thing since time immemorial… And will remain there for a long time to come. (Seems like they made quite some improvements in the latest iterations as well.)
> If you like the productivity, just wait till you try Rails.
I like Rails (vintage, Rails 5). Unfortunately DotNet and EF combined now have virtually the same productivity but with massively better performance. Which is a shame as Ruby is a great language.
Coming from Java, Go, and Javascript, C#/.net just plain sucks. Things that should be simple, e.g. Collections APIs.. aren't. I stopped trying after this realization.
I preferred the C# from 15 years ago compared to whatever is going on over there at present. If you're already indoctrinated into the ecosystem, I'm sure it's fine. Otherwise, buckle up - things are going to get choppy.
Maybe I was using it wrong? As I recall, "the usual" APIs present in most other OO languages were not available when I tried to help a friend with a project 3 montjs ago.
You might've forgotten to reference LINQ and Collections.Generic in your project? Because C# definitely has good collection APIs that influenced many languages including Java Streams.
Which collection APIs were you missing? Between the standard interfaces and their default implementations[1] and the extension methods to IEnumerable[2] you can do quite a lot in my experience.
.NET core can run on any platform it wants, but as long as it's from Microsoft, the company as we know it, I won't even write "Hello, World!" with it.
A language can't be the fastest at everything in today's mature language ecosystem. OTOH, Debian's "Programming Language Games" benchmarks shows it's on par with Java (which is not slow in any means), and not as fast as you claim [0].
In the page I shared, some C# benchmarks are impressively fast, because they are written with explicit hand crafted SSE3/AVX vectors, which a run of the mill programmer won't want to touch (for most of the time, anyway).
Comparing .NET Core, which is a hybrid JIT language with purely interpreted ones like NodeJS and Python also makes no sense at all, considering Python Compiler does not do any optimizations whatsoever, and is still confined to a single core per process unless you pull some tricks.
Choosing horses for courses is fine, and we all shall do it, but claiming a language as winner over a single benchmark suite, including the one I referenced is wrong.
Curious, what is it with Microsoft that makes it so poisonous for you that you won't touch anything they make with a ten foot pole? As an example, I'd say Facebook (Meta) is a way more toxic company but I've never heard of a developer have moral arguments against using React
I'm using Linux for 20 years, and witnessing what Microsoft is doing for more than 25. Being openly hostile towards Linux and plotting ways to lock it out of hardware platforms and tech ecosystems is enough of a motivation for me.
It's not only their stance against Linux only, but everything competing with them.
I believe hardware and software should be open and platforms shall compete openly. I don't use any vendor which openly kills this interoperability and try to corner market with underhanded tactics.
It's not limited to Microsoft, though. I use Java because there's OpenJDK, Go because there's gcc-go toolchain, etc. Similarly I don't use Rust because it's LLVM only for now.
However, this doesn't mean that I want these to disappear. I want them to compete fairly, so we can improve. I'm not a web-dev so I have no need for this frameworks, but I'd make similar choices if I enter to that arena, too.
> I believe hardware and software should be open and platforms shall compete openly. I don't use any vendor which openly kills this interoperability and try to corner market with underhanded tactics. [..] Similarly I don't use Rust because it's LLVM only for now.
I'm curious, what do you have against LLVM? I'm sure it supports fewer backends than GCC, no surprise given their relative ages, but it's still got quite a few and it's open enough that it has documented support for adding new backends.
I think the point was not against LLVM itself, but rather against languages for which only a single implementation is available, which is a pretty strong argument IMHO.
I'm not strictly against LLVM. My objections are the license, and how companies use it against GCC/GNU.
I open everything I can, and strictly with GNU/GPLv3+. I want this code can be built and improved upon, even after I abandon it voluntarily or involuntarily. Hence I choose GPL licensed (or close as much as possible) toolchains and tools as much as possible.
For example, I use Eclipse, and include .project files in the repositories, so one can import the project as is, and continue playing, or maintaining the code. I'm improving my Eclipse knowledge to use agnostic paths, so anyone cloning the repo can directly import to Eclipse, and just click build.
I also plan to make my Eclipse and toolchain settings available to make my development environment completely reproducible.
On the case of the Rust, I'm waiting gccrs, which is arriving as an unofficial language in gcc-13. This will both provide an alternative and GPL licensed implementation of the language, and I can be sure that the code I leave behind can be built with the public version of the GCC.
Moreover, I use no compiler specific extensions, because I'm not trying to lock anyone to any toolchain. I'm just trying to make sure that the repo is buildable. I may even add a LLVM (or go-gc) test path to make sure that I don't break anything between implementations.
IOW, I have strong opinions about software freedom, and I apply them to my code, but not force people to obey them (except the license, because I need to underpin it). It's a strong stance, yet there's no insistence. I just set an example, and try to make it a very good one, to show it can be done.
FWIW I also use Linux exclusively, develop (and host) dotnet applications on it, and have my own gripes with it (mostly with Linux still being treated as a second-tier platform which is only good for servers as far as MS is concerned — I'm not talking about the abomination that VS is — try to compare the official profiling & debugging tooling).
There's an important distinction: License. OpenJDK is GPL2.0, .NET runtime is MIT. They may be same in terms of openness, but not in freedom sense.
As a result, OpenJDK is much more sustainable in the long term, since it can't be closed down and crippled as easily.
While I am no enemy of MIT/BSD style licenses, the "freedoms" they provide to corporations are damaging to open source ecosystem in my eyes.
OpenJ9 looks like EPL licensed, and indeed interesting. It's worth a look.
I'm not writing Java with any considerable volume for some time (because, I didn't need that), hence I was just keeping that in my peripheral vision without paying much attention. However, I'm using Eclipse because it's a great IDE for my needs, and comes with OpenJ9 embedded.
Thanks for bringing this to my attention, will look deeper.
us old farts remember Microsoft (and Gates) as true villains. Things have changed but those wounds run deep and the scars remain. Every time i see the Bill and Melinda Gates foundation in the news all i can see is Bill trying to buy his way into heaven.
I never considered Microsoft as villains in the 90s. They were the only company making computers usable, and thanks to them I didn't have to use the archaic Unix systems that were prevalent at the time. Microsoft was being unfairly punished for things that are commonplace today, like integrating browsers with operating systems.
They have strategy called Embrace, Extend, Extinguish.
They are still running this strategy, but now also buy good PR buying paying high profile developers thru their developer advocate positions.
"""
Microsoft finally is fulfilling its dream of EEE to Linux. Windows Subsystem for Linux (WSL) embraced the API – letting you run Linux binaries (and GUIs!) on Windows natively. Next, WSL extended the kernel with GPU driver support.
"" " - https://matt-rickard.com/embrace-extend-extinguish/
The difference between the shootout microbenchmarks and the TechEmpower benchmarks is that the former test computation-intensive tasks and the latter test an end-to-end web backend example. It tests how good the compiler is, how good the DB drivers are, how good the HTTP stack is.
What's so good about MS ranking in the TechEmpower benchmarks is that it's the fastest full-featured "enterprise" framework. Frameworks like drogon or just-js are impressive feats of engineering, but the only reason they exist is so that their authors can mention that on their resume. If you run them in production, you are on your own.
There's equally fast Vert.x, which you can buy support from Red Hat for, but most Java shops use Spring Boot (vmware or Red Hat support available), which is easier, but hopelessly slow in comparison.
> The difference between the shootout microbenchmarks and the TechEmpower benchmarks is that the former test computation-intensive tasks and the latter test an end-to-end web backend example.
That proves my point even further, because I don't develop anything remotely web-related, hence that performance scenario is completely moot for me.
> What's so good about MS ranking in the TechEmpower benchmarks is that it's the fastest full-featured "enterprise" framework.
Again, the same because the software I develop is not "Enterprise" either.
What I develop is scientific software, and needs to be extremely performant. In my case C++ is the best language, but it's not the best for every case. This is why I also learn Go and use Python for other tasks.
In my case, Debian's benchmarks are directly related to my use cases, however even that's not a definitive measurement for my case. It's just a bunch of data to keep in mind.
> That proves my point even further, because I don't develop anything remotely web-related, hence that performance scenario is completely moot for me.
I hope you realize non-web development is a niche nowadays. So it's perfectly reasonable to prioritize .NET benchmarks that target ASP.NET Core web apps/APIs.
I hope you realize that web-development in my discipline is a niche nowadays. So, it's perfectly reasonable to prioritize bare metal and micro performance benchmarks that target naked performance, OS and GPU apps/APIs.
Our vantage points are different, and these different vantage points need not to see the complete ecosystem as a whole. It's too big to generalize from a single vantage point, and just because our view reveal us a little of something doesn't mean it is, in fact, little.
There's a whole invisible world out there, from DBs themselves to OS kernels to embedded platforms, and everything in between.
> I hope you realize non-web development is a niche nowadays.
That's a terrible attitude. If you want a certain ecosystem to get a better rep, you have to be ready to talk with different communities, and accept their feedback.
Python is what it is largely because it can cater to a large number of these very different communities, which has ensured its long-term success. Compare with Ruby, which became effectively a web-only language and has since struggled to go anywhere.
> Otherwise we would be coding web applications in assembly
Some people write web-apps in C. Just because you don't like something, it doesn't mean the world agrees.
>Ruby, wouldn't even be a blip in history radar if it wasn't for Ruby on Rails
Hard disagree. Ruby was getting traction on its own, as "the purest OOP language you can use in the real world", around the same time Python was starting to get traction (early 2000s). Then RoR blew up, effectively coopting the entire ecosystem. Since then, Python has slowly gone from strength to strength in so many different fields, whereas Ruby died on its ass as soon as people moved on to other tools for web.
I only looked at the binary example and it’s some of the worst C# code I’ve ever seen. It’s synchronizing every task in a loop instead of waiting for the tasks to complete like the Java example. It’s returning a result instead of using an array like the Java example. The 2 examples are not equivalent.
I know no C#, but you can contribute a better one if you prefer. Some of the languages have multiple implementations in the games and their performance vary a lot.
I know, I've written NodeJS for a very short time, and remember liking it. However I can't position it into my current ecosystem where code is probably be seen by multiple people and need to understand/improve it.
I recently worked with some .Net developers who wanted a primarily Java based company to let them work with .Net. In their opinion .Net was so much better (faster, larger ecosystem, more developers) that it would pay off quickly. When I asked them for documentation, they pointed to some microbenchmarks that had no significance to the type of work they would do. They also complained that Java was more "corporate" than ".Net", which is ridiculous in my opinion. Even if that was the case, the differences would be a "rounding error"
This seems more like Yet Another Medium Article shooting fish in a barrel by describing problems with the JS ecosystem rather than an actual case for C# and .NET.
> This seems more like Yet Another Medium Article shooting fish in a barrel by describing problems with the JS ecosystem rather than an actual case for C# and .NET.
> My hope is that .NET and C# have a resurgence as .NET 6 rounds the corner. With .NET 6, C# 10, and minimal APIs, the language feels more modern than ever and is the perfect gateway from TypeScript/JavaScript on the server to .NET.
Oh please please please let this come true so I can write c# on the backend again. I love typescript because it made JavaScript (i.e. front end web) so much less shit to work on, and I’d prefer it over ruby or python backends still, but c# hits such a sweet spot of ease to write, while still remaining relatively performant.
Go and rust are probably better for certain applications, but c# would be light years ahead of things like ruby or python.
It must be one old article, because what rounds the corner is .NET 7, while .NET 6 and minimal APIs have been available for a better part of a year already
Microsoft and trustworthy communication can't me mentioned rationally in the same sentence. I've been working with them as a customer and partner for 30 years and have been screwed over and over again. They are the worst company I've ever worked with or for or with their technology.
Hot reload for ASP.NET works fine nowadays in VS and even with older versions of .NET.
Dependency handling is still a large problem with .NET. Especially since current is often used instead of LTS. There is also no good way of sharing code between applications.
Arrow functions, btw, solves the this/that problem in JS making React development easier etc.
What I see a lot is private Nuget packages with common functionality used within several applications at companies. These are often binaries (one can place code in a Nuget packages but it won’t update, at least not last time I tested it). In the world pre GIT it was common to link in these files and build them along with the solution. Meaning, one did not have to try to align every .NET version or keep adding build targets to the Nuget packages.
That's what I'm used to too. Shared code in Nuget packages in an internal Nuget feed. But definitely not binaries, as I've never had issues with Nuget packages not updating.
You don't think something being hard to input can be blamed on the OS at all?
The only built-in way to type a sharp outside wordpad is to have a special registry key set then hold alt and type +266F, isn't it? That sounds to me like it falls under "dreadful support for Unicode".
375 comments
[ 3.0 ms ] story [ 334 ms ] threadI like F# too, but I'll stick with one of it's non-MS controlled alternatives.
You can see it in Windows too, where you can burrow deeper and deeper into progressively older settings dialogs, because they reshuffle the Control Panel every few years.
Also keep in mind that .NET Core is not only open source, but comes with complete protection from any patents Microsoft might have. The only thing Microsoft can sue people over is the .NET Core trademark itself.
This is what I assumed the parent post was referring to. Mostly because it mirrors complaints I've heard (and maybe had) about the .net gui story. WinForms -> WPF -> whatever the windows store app framework was called -> I think MAUI now?
But if you wanna use VSCode or Rider then the support is 100%
I also use Rider exclusively and going to Visual Studio on Windows now and then I'm not missing much (visual studio did have some nice plugin for debugging compiler plugins, had to hack around than in Rider)
I can't comment on Unity part.
F# for me overpromises and underdelivers - it all sounds amazing in theory but it's been 3 times over the last decade where I've tried to use it (last time just a few months ago) and it never just works - I've spent diagnosing "why isn't this F# feature working as advertised" than solving my problem (from tooling like F# projects breaking autocomplete in VS solution - even for C# projects, to language features like type providers just being a nightmare to work with and integrate into CI/CD)
My observation is that the ex JS/Ruby/etc devs learning curve's seem to favor F# over C# as it is more like these languages. There's just a lot less to learn, and the coding style (e.g. modules, function first, etc) is more synonymous with langs like JS than heavy OO languages. I've recently inherited a team that moved to .NET from JS, and getting them to try C# has been painful especially when using things like ASP.NET. There's a lot of knowledge I just took for granted - we don't realise how much knowledge is required to use standard Java/C# OO in a production like setting that many dev's stumbled on when they were junior but have long forgotten the learning curve they went through. They tend to be framework heavy/dependent and require much more experience. From patterns (what's a strategy, repository, etc etc), to dep injection frameworks, to which refactoring tools I need, etc, etc - where in F# in my recent experience the experience is more, but still not quite "just code and work it out as you go".
The pit of success favors F# over C# in my experience with these teams especially if you keep it simple with the features used.
My experience has been that F# appeals to coders who are using the .NET platform coming from languages like JS/Go/etc but also has static typing who usually at least in the jobs I've been in are often on a Mac. C# dev's typically come from Java/C# enterprise kind of shops. Not one is better than the other and I will work in whatever space has interesting problems to solve - I think the difference is more cultural than technical.
Author really needs to give Blazor a try. I wrote some comments last week speculating that I'd use Dart or TypeScript with C# .NET on the client because WebAssembly doesn't do DOM manipulation, but turns out I should have waited to learn it better before making a comment.
I've learned I can add events and event handlers to elements without ever leaving C#. Then when I need to use a JavaScript library, I can load it just in time for my component. Once I got the hang of it I really felt like I've found the sweet spot for front end development.
Blazor is in development and will only get better. I believe it will eventually be recognized for what it is, but it's still early.
The issue that I have is since it is a thin-client re-deploys kick everyone off immediately. Where the web is totally stateless this is 100% state full. I'm used to being able to deploy production fixes rapidly without disturbing anyone's work but with Blazor server that's impossible. I've started to look into load-balancing solutions or something but not being able to roll out fixes throughout the day is almost a deal breaker for me.
This person was able to get it from 14.4MB to 4.4MB: https://www.michielpost.nl/posts/reducing-blazor-webassembly...
Whether that's acceptable is up for debate but it is in line with most SPAs/websites these days.
Here's a small gist where I use fable-py to use the python prettymaps project that was posted a week ago on HN: https://gist.github.com/Banashek/1cc3d8435843bcff230906fb037...
I call that bureaucratic software because it reminds me of doing taxes. It's put me off from trying a lot of Microsoft tools, but with Blazor I decided to push through the pain. Once I did, I could see the logic of it and it became less of an annoyance
This will allow people to write competing frontend frameworks, or mix and match their JS framework of choice while calling into .NET app logic.
The latter already possible, though a bit hacky with the official tooling at the moment, since Mono can compile regular .NET code to WASM no problem (a fact already extensively used by game engines like Godot or Unity).
How good can it get though? Blazor WASM suffers from the huge initial, multi-megabyte download of the .NET runtime. How is that expected to come down to something in the range of 50-500kb what we have with most JS frameworks now? I just cannot do that on public-facing parts of an application. It is unusable when accessed from a slow mobile network. Company-internal stuff sure, who cares.
I really wanted to love Blazor, and evaluated replacing some of the complex frontend UIs at work which are a JS nightmare with either Blazor Serverside or WASM. But serverside seems like an afterthought to me. I recently learned about Phoenix Liveview here on HN, and according to what I read, it seems like a much better option if you want that server-side rendering stream model. With Blazor-server, I get the feeling it is only a makeshift-solution until WASM takes off, and that makes me even more reluctant to use it.
Due to cache partioning in browsers now, this will still be a big issue for all clients. Don't also forget that many clients are in poor internet speed zones.
A 2MB "buy in" will be unacceptably high for lots of projects (but not all, obviously).
The biggest way server side fucked us was originally db contexts are bound to scope via IOC in asp.net similar to MVC or razor pages.
Which is fine when your scope is a single request, but when the scope is a circuit you get so many weird fucking errors. We worked around this by disabling tracking. But the right fix is we should have used factories, but we didn't figure this out until it was too late and we had written a fuck ton of code.
This is such an obvious issue and should have been in the docs but wasn't.
But other than that it seemed fined.
As far server-side Blazor - it seems like an afterthought because you read about Phoenix Liveview? How is that a serious evaluation? Blazor is a core part of the framework now and the server-side model is always going to be a serious option because it enables functionality that can be done with the disconnected client/WASM mode (like direct DB access without the serialization + API overhead).
I suspect you're talking about full apps that include third party deps. The majority of SPAs are < 1MB unzipped and <150KB zipped. Source:
https://gist.github.com/Restuta/cda69e50a853aa64912d
You can't look at some site that has 10MB of third party deps and compare that to what Blazor is doing. You'll still need third party deps with Blazor as well.
The sites that have a large 10MB bundle would have had 100's of 100KB scripts pre-spa days.
I mean .NET core was pretty much in this boat pre v3, it took them years to move past the .NET standard mess, Xamarin never cleaned up and they are hoping MAUI will eventually just sweep it under the rug.
I wouldn't bet on any Microsoft stack that hasn't had 3+ years of successful use in the wild - I've been burned too many times. You might say the same is true for any other project/stack - but even when they moved to OSS .NET projects have this Microsoft level of complexity and boilerplate that makes diagnosing trivial things a slog. And Microsoft likes to put "stable" label on a lot of things these days with the pressure to ship. Good rule of thumb - not worth my time until v3.
Clients have been very happy with the results.
Then I built my own startup with it, and we have a solution that 3 devs have been working on for 2 years.
I can't recommend Blazor enough. I love it.
I have run into a fuck ton of problems with MAUI though. It's a fucking dumpster fire of a technology.
* Blazor server side I have very limited experience with client side.
That’s a pretty extraordinary claim.
I know single stack can be more productive, but that sounds very impressive. Could you perhaps talk details of:
- styling blazor (eg. Bootstrap, tailwind); is it just drop in? How do you use it, eg. Without the tailwind preprocessor npm package?
- interactive front end components (eg drag and drop) that lag badly when using SS blazor in examples.
- bridging to native js (which is ultimately unavoidable in situations where you need integration like maps as far as I know)
- scaling load on concurrent users (one ws per user right? Are you using the signalr service & functions? I tried this and found the long running azure functions are quite expensive to run. Do you have advice?
1. We just dropped in a wrapbootstrap template.
2. We wrote some javascript for interactive front end components like drag and drop or rich text editors. It was a little more work than it would have been in React but not much and everything else more than made up for it.
3. We found it wasn't particularly difficult. We'd just put JSRuntime.InvokeAsync in a C# method. Used it for things like popups and initializing some js libraries.
4. We're only using Azure App Service and Azure SQL database. Our long running functions we just run as a scheduled service on the app service. (though eventually we'll to do some refactoring when we need to scale horizontally). We're a B2B SaaS company so our revenue is quite high compared to our compute usage. By our back of the envelope calculations we won't have to add another server until we're somewhere between 5 and 15 million ARR. We think we'll need to do about 2-3 months of refactoring at that point to allow for horizontal scaling.
I wouldn't recommend Blazor-Server Side for B2C typical applications that have a low ARPU.
The big advantage in development speed is we got the functionality of a SPA but at the development cost of a classic multi-page application.
That's part of my problem with it - from what I see they are pushing two independent tech stacks (WASM and dynamic server rendering/JS updates) under the same name - but the APIs underneath and the architecture is very different.
Or at least those were my findings last time I tried. I would be very happy if that isn't the case currently.
For intranet web apps it looks amazing though.
Yes. Server-side Blazor is incredibly productive and fantastic for complex UIs, especially for B2B and other SaaS products.
But so much of the world is user clicks a button, run server side code, update html, and blazor is an amazing fit for that.
Like I'd never build a Google sheets, Microsoft word, or outlook replacement in Blazor.
But I'd totally build a hub spot, Salesforce, Facebook, reddit or hacker news clone with it.
The thing is, Blazor will become the lingua franca of (web) UI development for bigcorps, so I just need to suck it up and learn it (I'm a .NET consultant geared towards finance & insurance)
I tried Blazor. We used it for one mission critical project.
We found that the development cycle is too long and it has too much friction compared to Node for front-end development.
Back to Node for frontend (Vue)!
Then there is a Redux-like option and.. No thanks :D
At least from the perspective of recruiting in Australia.
Python is on the way up and third most popular but well behind C# and TypeScript.
Golang is on the way up but very small in terms of number of developers.
Java is on the way down but will never vanish, it's just not super popular any more.
Ruby is small enough to just be a footnote.
There's lots of other languages that make up the long tail.
The message is that if recruiting matters then you should be using C# and TypeScript.
lolwut. TypeScript is niche compared to Python.
Even accounting for that line from the comment?
You choose typescript over python because Brython and JavaScripthon and Transcrypt have no ecosystem that makes more sense than using NPM, and the people who like to program in python prefer the challenges of other domains than what's in the web browser.
That just makes "most popular programming language" a silly metric. It doesn't mean that nobody uses the language because you ignore all the people who use it for things you aren't interested in.
> just my own observations (probably wrong).
I am currently in the process of learning C#. I did a deep but brief dive into every language feature in C# 10. Being proficient in Python, absolutely nothing surprised me. All the same concepts, save for a handful, exist in either language, sometimes down to the exact keyword usage. LINQ is a big differentiator in favor of C#, but modern (that is, typed) Python looks very similar to C# (C# left, Python right):
ABCs -- ABCs
Interfaces -- Protocols/ABCs
LINQ -- ??
Enumerable/Enumerator -- Iterable/Iterator
class -- class
static -- staticmethod
foreach -- for
for -- for(range(...))
try/catch -- try/except
break/continue -- break/continue
enum -- Enum
struct -- dataclass, perhaps
namespace -- automatic on the file level
out -- pass by reference
switch/case -- match/case (both do structural pattern matching)
throw -- except
typeof -- type
overloaded methods -- singledispatch (only works for a single argument sadly, no stdlib multidispatch)
inheritance (single) -- inheritance (multiple)
object -- object (root of the type hierarchy)
generics -- generics as well (via typing, runtime never cared anyway of course)
lambda -- lambda
nullability -- None (C# can have nullable reference types, Python types are not nullable, None exists as a first-class type, not a subtype of all other types; similar ergonomics but different structurally)
extension methods -- just go wild in Python (although binding methods after class definition is cumbersome)
tuples -- tuples (both can do unpacking, multiple returns etc.)
operator overloading -- operator overloading
reflection -- reflection (arguably a Python strong-point)
async/await -- async/await
decorators (exist as a pattern) -- decorators (supported on the syntax level)
?? -- top-level/first-class-citizens functions
I probably got a couple wrong, but you get the idea: apart from LINQ, nullability handling and some others, the languages are incredibly similar in their feature set on paper. This is not talking about DX etc. though.
TIOBE has C# much larger than Go and growing, and it also has Go slightly shrinking over the past year.
https://www.tiobe.com/tiobe-index/
Same results on Stackoverflow https://insights.stackoverflow.com/survey/2021
Same results on IEEE Spectrum https://spectrum.ieee.org/top-programming-languages/
Same for PYPL https://pypl.github.io/PYPL.html
I cannot find a single place that looks at a large dataset and a decent number of languages that gives the result you claim.
Care to list where you got your data to support this claim?
I like the fact, that you can develop command line apps, Web APIs, Desktop Apps and smartphone apps all with the same toolset, including the fact that deployment is possible on nearly every major platform for every major platform (except iOS and macOS Apps, as always only on macOS). Even systems programming and AOT is doable or full featured static deployment is possible integrating a small runtime into a single binary.
And boy is .NET fast...
This facts made Golang pretty interesting to me, but what I did not like here is the lack of a usable cross platform Plugin-Loader technology, most of the stuff has to be monolithic, then the module management and some of the missing concepts (like generics, which is also now available in go).
The sheer amount of concepts in C# is overwhelming (from basics like Generics to less common ones like Extension-Methods, operator overloading, etc.).
I don't like Visual Studio as IDE, but VS Code is an acceptable alternative tool, although I personally prefer the non-free JetBrains Rider.
Nuget package manager also has it's caveats, e.g. that the official repo can only "unlist" packages, not delete them or that the publish times sometimes have horrible delays, but that's also still acceptable, since you can use the github package registry or bring your own to overcome these issues.
Technologies on my todo list include getting into MAUI (a cross platform UI stack) combined with Blazor[1], which can use Web Components in native UI apps and develop TRULY cross platform (Web, Desktop AND Mobile with the same codebase). Like electron, but without the browser dependency due to native integration.
Although everything is tied pretty tight to Microsoft, there is a huge open source community developing cross platform libraries, that are easy to use. Even though i find that microsoft has often made strange decisions in the past, the current state is clearly a recommendation to have a look.
https://www.youtube.com/watch?v=2eIsQ3Pm2bE
I switched back to node.js with fastify and wrote my app in an hour.
I really like C# for cli and windows desktop applications, but I probably won’t touch it for the web in the next few years.
https://docs.microsoft.com/en-us/aspnet/core/web-api/route-t...
Failing to find the differences between them will impede learning in general.
The issues you had could be attacked by navigating through this section of documentation, diving into the tutorial referenced in the beginning of the Overview section and the subsequent sections: https://docs.microsoft.com/en-us/aspnet/core/web-api/?view=a.... This is not necessarily in defense of c# and dotnet, but this reads like you barely spent any time trying to digest the documentation.
Then once you need to go beyond the standard libraries it becomes a nightmare to deal with. In some cases, like extending the AD libraries, it’s sort of easy to extend classes with methods but the documentation on how to do so tends to assume a lot of domain knowledge. In other cases like if EF’s standard functionality isn’t enough for you, or you need to deal with weirdly formatted XML or non standard SOAP requests (don’t ask) it can be such a nightmare that it’s sometimes easier to write a micro-service in another language to do the “translation”.
I think it speaks of a language that doesn’t see too much use by its own creators. I may be wrong on that, but having build a lot of things for Azure, Typescript has often felt more like a first class citizen than C#. Obviously not for everything, far from it, but sometimes and those sometimes are enough to make C# troublesome because unlike things like typescript that are great second class citizens in the Microsoft ecosystem, C# isn’t. It either fits really well or you have to fight it.
Maybe that is because we didn’t have a fascist linter for C# the way we do with Typescript, but it’s always been much, much, harder to get people to make “good” C# code in my experience. It hasn’t been hard to have the build things in C#, but it’s been hard to get people to build things the same way so that they can work on each others code flawlessly. So hard that I would never again consider using resources on it until developers drop significantly in pay, which isn’t likely to happen until I’m retired, if ever.
I wonder if it has to do with regional differences. I’m Danish, everyone (there are odd cases, but it’s more “everyone” than “almost everyone”) here has a CS degree and often they’ve been taught Java, sometimes C# but poorly, while obtaining it.
For me, fsharp interactive is one of the best prototyping experience I have ever experienced.
For example, the secret incantations required to output a mere string as raw json mimetype or log incoming deserialization errors* are unintuitive and very labourious - see InvalidModelStateResponseFactory. Or that I had to create a custom output formatter to output raw json. Why? Sometimes I just want ASP.NET to get out of my way and it's not trivial to tell it to let go.
* For example, url?parameter=1 for a boolean parameter, which would have worked with .NET Framework but won't for .NET Core/.NET.
And it says right at the bottom, that OpenAPI and model binding is not supported in their route to code feature.
I initially googled how to create a simple json api, and that’s the documentation which I found. Looks really easy in the beginning, but after you’re done with your routes, you’ll read at the end of the documentation, that OpenAPI generation, model binding etc is not supported. I blame that the guide‘s title is misleading and - of course - that I should’ve read till the end before actually following any step of that tutorial.
That said, you may take a look at my small very early state pet project `tonehub`[1], which can be seen as pretty modern CRUD Web API in 2022, utilizing swashbuckle for OpenAPI, JsonApiDotNet for CRUD, Entity Framework 6 for Database, HostedServices for background tasks and some other nice concepts (DI / IoC, Options Pattern, FileStreams, etc.). I could also use SignalR for WebSockets / Realtime, integrated OpenID/OAUTH2 Authentication, FluentValidation for validation, Api Versioning and much more.
I've never accompilished something like this with this small amount of code...
[1] https://github.com/sandreas/tonehub
As per another comment after having seen JS devs switch to F# for very large professional application and not wanting to go back I feel its fine for web. YMMV.
If you use the templates provided by .NET Command Line Interface or Visual Studio, you'll get this all baked in & setup.
VS also added a very nice feature where it suggests & imports popular packages if you type a method on a type that's well known. If you already have it added to your project but need a using statement in this file, it'll pick that up fast as well.
They've also improved their docs quite a bit from years ago with lots of good examples for common things.
- Templates are no substitute for intuitive and minimal code for a number of reasons. (e.g. how to extend, how to customize, confidence that it isn't brittle if I change one thing, etc etc). If a template doesn't have the exact variation you want (e.g. a faster logging library) the learning curve is very high for a newcomer .NET dev. NOTE: I think this applies to some other OO languages too.
- Suggesting popular packages and namespaces is a great tooling improvement. But it could also imply a closed wall garden. The fact that other non C#/Java like languages don't have this problem even with something as minimal as VS Code as your IDE shows that the tooling is trying to cover over a language and/or library problem. With the Java/C#/other old OO lang workflow you need the knowledge you need to use the library itself (convention based, which class, which extension method, which namespace for that object to configure this feature, startup class conventions, etc). It isn't discoverable even with the packages imported. Remember just getting Serilog working in new ASP.Core and it taking a day or so with all the packages, config, etc etc if you don't already know what you are doing.
I like the improved docs. But fundamentally simplification/minimization is better. I think the dev workflow that means I don't need these tooling improvements is still a better experience. I like .NET, but I do understand when using other languages they seem to not have these issues despite not having the uber tooling that C# has. They don't have package suggestions, they barely even have auto complete yet the library design feels a lot more intuitive.
I can look up say a Fastify, Golang, even some F# examples with something like Giraffe and get a web app quickly with little code and no convention magic with everything being explicit yet concise. No fancy attributes I need to remember, no conventions in my startup classes I need to understand if any customisation, even dep injection is something to learn from people coming from some other platforms rather than just standard library calls composed together.
I actually like the .NET platform, don't get me wrong, I do think it is one of the best web platforms right now. Its more intuitive than Spring/Java as a comparison but that isn't saying much IMO. For newcomers I think the user experience to newcomers who are used to a lot less ceremony could be improved further. My first suggestion would be less "developer headspace required" to get started. On a personal note I think natural F# code tends to favor this from the teams I've been in but can't put my exact finger on a reason as to why - it feels more like coding Go/JS to me at least than C#.
For newcomers, I would say the best user experience (no matter language/framework) is provided by code hinting such as GitHub GitLens & competitors do. If I'm using an unfamiliar framework/language it's great at suggesting what I might want without me having to search.
You might really like the new .NET minimal APIs that are being built for web development. They're very similar to a Node.JS style of API.
In regards to logging specifically, I've found swapping logging tools fairly easy & straightforward as far as adding the logging in the code base. If there has been anything challenging it's been outside the code base & setting up the infrastructure or learning the logging's reporting tools. I'm curious what was challenging for .NET with you. It's usually as simple as using Ilogger no matter the tool & writing a few lines in the program.cs file.
services.AddSwaggerGen();
app.UseSwagger();
app.UseSwaggerUI();
Since I'm already spawning a TestHost and trying out various API calls, one of these tests basically does "curl $host/openapi/openapi.json | diff ./docs/openapi.json". If it spots a change and fails the test, I check that the difference is expected, and if so I temporarily enable and run a different "test" which actually writes the updated file.
They are existent and good.
With .NET 6 SDK, 'dotnet new webapi' will give you a template project that does everything you listed save for extended validation logic which you can easily add with 'FluentValidation'.
In addition, to run ASP.NET Core nowadays you only need:
OpenAPI output is built-in, but tooling for development does require a bit of knowledge (agree that Microsoft would benefit from making this work out of the box).
A small repo here showing how to connect OpenAPI and front-end TypeScript client generation: https://github.com/CharlieDigital/dotnet6-openapi
Of course you did. You're on familiar ground.
Personally I'm also familiar with .Net and could do the same in that stack in that timeframe too. Like with many things worth doing, it requires a time investment to reach that point.
Having said that, .Net APIs support JSON request/response out of the box, validation is available on the models in seconds using a powerful set of attribute annotations, and Swagger is also built in out of the box. And API projects can seem similar to MVC ones as they use the same framework and libraries, but whilst the out of the box APIs have controllers they don't have views.
So to repeat, it's down to familiarity.
Edit: For clarity this is not a criticism. I fully understand why these things may not be obvious up front. Both the validation attributes and the Swagger URL for the default support are not obvious to the newcomer.
https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry
There are countless, better privacy respecting tools.
It's sad that the time saved with Visual Studio's hot reload alone seems to outweigh the (massive) performance gains from using Rider, given that I have to restart VS from its memory leaks multiple times a day or it will slow to a crawl. Omnisharp isn't performant or reliable enough for daily use, either. The current state of .NET tooling leaves me unsatisfied.
Agreed. But F# is one of the best designed languages around.
If you open a C# project in VS Code when the "Ionide" extension (basically the F# extension for VS Code) is installed then the extension thinks it's a F# project and will open some F# stuff after a few seconds (or prompt you to setup some F# stuff in its gitignore). The root cause has been identified (plugin activates when it sees a ".sln" file), a PR has been opened and rejected with no mention as to why (https://github.com/ionide/ionide-vscode-fsharp/pull/1401) and the developers behind it are frustratingly non-communicative about it, closing issues about it (https://github.com/ionide/ionide-vscode-fsharp/issues/1701), they're not present in the discussion (https://github.com/ionide/ionide-vscode-fsharp/discussions/1...). Usual rules about OSS maintainers apply, they don't technically owe us users anything, we should be patient and respectful etc ... but man it is truly bizarre to be ignored or ghosted like this.
For the Ionide stuff, I agree. I don't use it, even though I use Visual Studio Code for other languages, and am happy enough with Visual Studio on Windows and Visual Studio for Mac on macOS.
It's not as bad as in npm with node_modules, because .NET provides a lot of base functionality in the standard library.
But when you start to use multiple nuget packages, sooner or later you will also enter dependency hell, where managing versions and updates of nuget packages gets very painful.
All in all we have to reference about 10 external libraries. The visual studio nuget package manager started to be frustrating if you need to manage those dependencies in multiple solutions. We therefore switched to Central Package Management [1], but then you realize, that you're just shifting the problem around. Now we have to put the whole dependency tree into the file 'Directory.Packages.props' and have to manage the version of 140 libraries. If there are version conflicts, we force nuget to use the latest version and just hope for the best.
Managing versions of dependencies and dependencies of dependencies is a major pain, but it's an ubiquous pain all programming environments share. And no, .NET won't relieve you from that.
[1] https://docs.microsoft.com/en-us/nuget/consume-packages/cent...
It is much more prevalent in the f# community (at this point `dotnet restore` is a perfectly fine default until you hit trouble), but isn't limited to just being applied there.
Instead, dotnet CLI + VS Codes find+replace does a very good job at managing dependencies. It has never been a pain and on project build, all imported version will be consolidated to a single one anyway.
I've used Visual Studio for 20 years now, and while the tooling has come a long way, I'm starting to feel like MS and the community are abandoning it for VS Code. I don't mind VS code, but unfortunately the stack I'm working in (Dynamics 365) requires plugins for Visual Studio that tend to lag behind the release cycle of Visual Studio versions by a few years. I use Rider for .net core projects on my mac and it's fantastic.
In fact my biggest criticism of my day to day job is Microsoft's support for this incredibly enterprisey framework I have to work in.
I see they move in VSCode direction with tools like Power Platform CLI [1], power platform tools extension [2]. PCF (PowerAps Component framework) enabling to develop UI components in frontend framework-of-choice... however none of that is available (yet?) for On-Premise deployment so we're 2nd class citizens. Because of that, haven't been able to play with this and try out so don't know how far that tooling goes.
As a platform, I really like it. Sane, consistent (except some very early stuff there), the backend extensibility - thumbs up for that.
[1] https://docs.microsoft.com/en-us/power-platform/developer/cl...
[2] https://marketplace.visualstudio.com/items?itemName=microsof...
It's to avoid the npm left-pad problem. nuget.org packages are idempotent.
For the publish times, I found out you can cut it in more than half if you tell nuget to ignore caches.
Draft releases would be awesome.
You can use your own private repos like MyGet[1] or Github Packages [2].
1. https://www.myget.org/ 2. https://docs.github.com/en/packages/working-with-a-github-pa...
No offense, I like nuget, but I recently made a typo and checked in 0.0.23 instead of 0.0.2. Now, everytime I add a dependency that is < 0.0.23 to a project, that has not been synchronized / validated yet (the other problem I described), it automatically takes the best match, which is 0.0.23 assuming to be the newest package, even if unlisted.
I also burned a 1.0.0 because of a failing script like that... not really bad, but annoying...
https://github.com/loic-sharma/BaGet
Drop nupkg in a folder, use it as a source, you now have a "feed".
It was perfect and exactly what I wanted. I had experience with XAML and MVVM thanks to Silverlight and WPF, so that explains at least some of why it was such a breeze. But it is way nicer than coding for the web, and I've done my fair share of that.
I was able to port over most of the code to MAUI easily, except for the missing controls. But MAUI is very exciting overall, and I look forward to using it more. After a map control is released I will fully port my app.
I submit for the record:
- Apollo Client: https://github.com/apollographql/apollo-client/blob/main/src...
- Storybook: https://github.com/storybookjs/storybook/blob/next/lib/chann...
- Nest: https://github.com/nestjs/nest/blob/master/packages/core/nes...
- MongoDB Driver: https://github.com/mongodb/node-mongodb-native/blob/main/src...
- Prisma: https://github.com/prisma/prisma/blob/main/packages/engine-c...
https://github.com/OmniSharp/omnisharp-vscode/issues/5276
Sounds like a pretty good reason to me?
I agree. This appears more like an attempt to get the most value (integration of proprietary Visual Studio features that devs want) into the VSCode extension as quickly as possible.
Said proprietary libraries are likely not able to be easily open sourced for a variety of possible reasons, so a closed source LSP bridge was the compromise the teams came to.
It's not without controversy on the Python side as well.
At some point it simply becomes questions of stewardship and transparency: How good are they at pointing out the open source parts wrapped inside the closed source LSP bridge? What cadence do they upstream fixes to the open source parts?
So far Microsoft's stewardship on the Python side seems strong: pylance has a lot of transparent documentation of all the open source bits. There seems to be a steady upstream flow to pyright for users that prefer to stay entirely with an open source LSP. Microsoft isn't treating it like a competition to "win" and encourages users to make their own choice among the options.
Of course, Microsoft doesn't "own" Python in the same way it "owns" .NET so I can definitely understand why there's increased fear that Microsoft won't be as good of a steward with respect to this "competition" with OmniSharp simply because of .NET's past. But in .NET's past this controversy would be happening after Microsoft did all the work in building the closed source LSP replacement. The fact that we're having this discussion now in only an "architectural discussion" state says a lot already about how Microsoft's stewardship and transparency have changed today.
It's slow, it's bloated, it's loaded with way too many configuration options and yet still doesn't have a lot of config I like from other editors. It has plenty of plugins and still manages to be missing extensions that I find important.
Development with Visual Studio just doesn't feel very good compared to other environments these days.
https://visualstudio.microsoft.com/license-terms/mlt031819/
This is the rare post where I would be fucking ecstatic to be proven wrong but sadly I believe I'm correct.
It's free for individual developers, small businesses, and work on open source projects (no matter the size of the organisation).
https://visualstudio.microsoft.com/vs/pricing/
ALso, JetBrains' IDEs are:
- free for students, startups and opensource projects
- cost an insane "two/three beers a month" for individual licenses (yeah, it's more expensive than two beers in many countries, but as a developer I could easily afford it even in the shithole that is Moldova)
So no idea what you're talking about when you talk about "a language that doesn't rely on paying for an IDE".
And the tools for most of the languages supported by the open community? The top, best-of-breed of these tools can barely do the bare minimum of refactoring and maybe symbol lookups. Even to this day you can read things like "X is amazing for refactoring because you change something, and the compiler will tell you all the places where it can't compile".
Good tools are expensive. And, surprisingly, Jetbrains' IDEs are not expensive at all. And are several orders of magnitude more powerful than anything the "open community" has come up with.
And, to re-iterate, no language is dependent on an IDE these days. Go grab Kotlin's CLI compiler, https://kotlinlang.org/docs/command-line.html fire up your vi/emacs/gedit and code to your heart's content if you're so set against commercial IDEs.
> And, surprisingly, Jetbrains' IDEs are not expensive at all. And are several orders of magnitude more powerful than anything the "open community" has come up with.
This says more about the languages and ecosystems you're used to. Try out rust-analyzer and say that again!
This is what you said, in it's entirety: "Maybe it's good to have an open ecosystem for using the language that doesn't rely on paying for an IDE? I personally soured on Kotlin for this same reason!"
And then you go ahead and praise a tool that implements LSP...
Do you realise that "open ecosystem" literally couldn't produce anything of note for any language until the megacorporation you love to hate came along and provided a solution? It wasn't "open ecosystem" that gave you the language server protocol. It was Microsoft that designed it and implemented it for their own VS Code. And the "open ecosystem" that sat on its ass for decades flocked to it and to the protocol like kids to the Pied Piper of Hameln.
And again with "you need paid IDE to develop this and that". No. You don't. There's LSP for C#. There's LSP for Kotlin. You'd know that if you went ahead and looked just slightly beyond your blind hate of commercial IDEs.
> You'd know that if you went ahead and looked just slightly beyond your blind hate of commercial IDEs.
Maybe you missed me saying I use IntelliJ professionally in the previous comment? I'm a happy, paying user of JetBrains IDEs, I've defended them several times on HN myself. I don't hate commercial IDEs; I hate being forced to use them.
It's extremely bizarre that you assume I'm trying to cheap when I'm trying to be principled: I believe the presence of free (as in speech) solutions are essential for me to seriously consider a language. Being tied to a corporation's whims to efficiently use it is ridiculous; I was a happy F# hacker myself until I saw the more recent moves MS has been making. I think what they're doing - replacing omnisharp with a closed source solution and the debacle with trying to make hot reload a paid VS feature being two major, recent issues - show that MS simply cannot be trusted to run a language ecosystem without trying to force its users into behaving as they want them to. There's simply no reason to invest any time into the dotnet ecosystem when there's very comparable languages with comparable performance and ecosystems which don't have this issue.
> And then you go ahead and praise a tool that implements LSP...
What? I'm afraid you've completely lost me here. It doesn't matter that MS came up with LSP, so long as the protocol is open and people can implement and use it without MS's approval. Dozens of editors that have nothing to do with MS implement LSP, the fact that it was made by them is almost incidental.
I tried VS Code and couldn't get used to it. So now I use Rider for C# and Webstorm for JS. Sometimes I open Visual Studio, though:
> There are some custom plugins someone in my org wrote that help accomplish some team-specific tasks > When I need to work on stored procedures in our SQL databases. Rider doesn't know how to parse the schema from the sql project files, instead it wants me to connect to a live database or it will color everything with little red underlines and give me no autocomplete
I think it's nice that my employer is willing to pay for my Jetbrains licenses despite the fact that it is selling a proprietary competitor and also simultaneously pushing an open source alternative. I appreciate it.
https://www.jetbrains.com/remote-development/gateway/
VSCode with the C# extension is the preferred C# development environment of corporate shadow IT.
Edit: I love vscode for c#
Windows -> Linux
WSL -> Linux
WSL2 -> Linux (Its real Linux)
macOS -> Linux
All of the scenarios were deployed to AWS.
I got sleepy just reading this. There's just so much fragmentation and frameworks and different versions of frameworks and web-servers... can't Microsoft just let the .NET be and let them do their thing? They have certainly pumped out loads of amazing software that seemed to get a knee on the guts by higher management.
Mono is a cross-platform (ish) implementation of .NET Framework, but its future is (eventually) to be replaced with the main .NET which is now based on the cross-platform version (.NET 5 and above, which is currently distinguished from Framework by continuing to call it ".NET Core"). Mono and .NET Framework will fade away once Unity gets their act together and moves on from it.
tl;dr: .NET 5 and above are, for all intents and purposes, the only future path for .NET, but we're in a transitionary period right now.
Though most of the time, you don't need to know any of this, you just use .Net and it works on Windows, Linux, Android, Apple and in the browser.
For ASP.NET there is nothing Windows-specific in there I've noticed.
There's some issues if you need to use an older version of ASP.NET and whether or not it has "Core" in the name, but after .NET 5 and ASP.NET 6 there's no longer that fork to confuse things and it's back to much simpler version numbers/checks and no longer needing to worry about the word "Core".
- If you're starting from scratch all you need to know is that you should use DotNet 6+ and you'll be on the mainstream track with full cross-platform support.
- Nothing is Windows-specific unless you're actually wanting to target Windows stuff specifically.
- If you're doing desktop dev MAUI is the way forward, but personally I don't trust Microsoft with desktop stuff any more (too much switching and deprecation over the years).
In my view Python and Ruby are not natural competitors to C# as they are dynamically typed and (in Python's case) interpreted. Similarly Rust, C, and C++ are not natural competitors to C# as they do not have a GC. Java, C# and Go, on the other hand, are pretty similar.
Maybe you have some legacy codebase in C# that you need to leverage.
All other reasons to chose C# over something else for web applications seem to lack evidence but certainly not conviction. So yes, Python is a direct competitor to C#, as in there are many more Python web projects out there than C# ASP.net ones.
As for Java and C#, it is a fact that all of them joustle for the backend market together with Python. Java and C# were there first and have massive commercial backing pushing them, but Python has slowly carved a larger and larger role on the back of technical merit. As long as it continues to do that, I don't think you need to worry.
I understand that 90% of Kotlin's audience is mobile devs and server-side Kotlin is rare, but as a .NET developer, a few years ago I did a small production Spring Boot webservice in Kotlin and the experience was really good.
Nothing is as universal as typescript / JavaScript. Unlike other languages you also don’t have to context change when you’re transitioning from working on the backend to the front end. Everything also tends to be rewritten for node eventually.
And not comparing ASP.net to more mature web frameworks is also a strange choice. At the very least, you need very capable developers not to shoot yourself in the food with the enterprisy dependency injection magic. In my opinion much more so than with other frameworks. I mean, if you have a steady supply of highly-qualified dotnet engineers, go for it...
Being able to write a validation schema and deriving types from it automatically - that I can share on client and server - is just too big an advantage.
Similar in F# land is https://github.com/Zaid-Ajaj/Fable.Remoting While both client and server are designed to be used from F#, they should be able to be used from js/ts as well as c# if desired, though I have not tested that.
gRPC seems like it's just for the server.
Without JetBrains Rider .NET would have no cross platform dev experience.
VS is shitty Windows bloatware, VS for Mac is utter rubbish and OmniSharp was killed by Microsoft because they didn't fancy to give away dev tools for free and purposefully killed it in order to replace OmniSharp with a closed source extension, which as of today doesn't exist yet. So if you are a Linux developer then you are basically fucked today if you wanted to use .NET, except there is Rider. Without Rider .NET would be completely unattractive today.
If one is okay with this then .NET is amazing. Otherwise I cannot advocate for .NET anymore I am afraid. Microsoft doesn't see what's good for them. VS Code is the future, not VS. They invest too much time and money and marketing in selling VS to developers instead of making VS Code a great free OSS experience.
They head of the dev division needs to protect the revenue. Simple as that.
However, I completely agree with your sentiment: "Microsoft doesn't see what's good for them" ... because "free" is not "open source" and trust does not come from "free" but from "open source".
Though of course in retrospect it does depend upon which workloads you're working on - and I mostly do command line tooling, web apps, and APIs, none of which require a design surface so maybe that's why my opinion differs as I've no informed idea how good/bad the layout aspect is.
If Typescript makes Javascript so much work because the tooling discourages learning best practices, how does moving to C#, which is designed very similarly, help?
I.e. if half the cardinal sin was creating Typescript in the first place and that's part of why Javascript sucks so bad (I am inclined to agree, FWIW), how does C# then make it better?
Author is light on the details here. I do agree that strong typing systems, safety checks are preferably on backend systems-grade code, at least, but I don't think C#'s types are strong enough, for that prefer something like a Haskell-ish language, Cayenne e.g., Ada, and with strong code-re-usability. I decline to champion a particular language, I only know C# has a lot of baggage from Java/Typescript/Javascript, which it would be better without (C# is also starting to suffer from a C++-ish problem, where there are so many new and different ways to do the same thing that interoperability and "good" standards are swiftly becoming a problem).
Folks here still think it’s Windows-only and comparable to Java. Yet latest TechEmpower benchmarks shows .net running on Linux and being faster than Go, Python, Node, and Rust.
https://news.ycombinator.com/reply?id=32220935&goto=item%3Fi...
(Also the benchmarks are a cheat, look at the source code of C# vs the source code of Go or Java)
If you want a language where not only the core and main libraries are open source, but also all the tools then C# is probably not the right choice. If free (but not open) tools for most use cases and paid tools for larger companies or higher-level demands are okay, then C# fits.
Do I like that some part of the stack is closed source (like the debugger and in future the extension host): No! Does it lead to a broken or discontinued future: No!
Compared to my experiences with PHP, Java and JavaScript, C# on Linux is just fine.
As all JetBrains products, it's free for students, open source projects, and classroom assistance, and training courses. https://www.jetbrains.com/rider/buy/#discounts
And it includes an excellent debugger.
And please stop this fake reality bullshit. NOBODY, not a single freaking person who wants to learn a new language will start off by searching the internet for an IDE and debugger where they can apply for a free license and then wait a few days so they can try it out. That is just ridiculous to even suggest.
If one wants to learn a language they download the SDK, open VS Code and look for an extension. If there is none or the one that exists doesn't work they basically say "WHAT THE FUCK IS THIS SHIT", close it and walk away with the conclusion that it's not well supported. Let's stay real please okay.
Then you should say: "a person who just starts with .Net".
> And please stop this fake reality bullshit. NOBODY, not a single freaking person who wants to learn a new language will start off by searching the internet for an IDE and debugger
I started with .net only 4 years ago. I went ahead and got myself Rider because I dislike VS Code and I already had 6 years experience with other JetBrains IDEs.
Oh look. I'm that "no single person" who went ahead and looked for an IDE. And bought it
> Let's stay real please okay.
Screaming nonsense at the top of your lungs doesn't make you any closer to reality.
I actually did. JetBrains products were really nice to try out whilst studying in university and eventually lead to me purchasing the ultimate tools package for any personal or professional projects that I might want to do.
It's really amazing to have the same set of tools for almost all of the languages that you might want to work with, that work consistently across all of the OSes that you might use. Normally I avoid paid software because of the vendor lock in, but a lot of the time it feels like JetBrains are just the company that you should reach for to avoid headaches, for better or worse.
For comparison, in the Java ecosystem, you also have Eclipse which has performance problems and an odd/unstable plugin ecosystem (though some swear by it) and NetBeans which has been handed over to Apache but doesn't really get much love or attention towards its development at all. Of course, some might use Visual Studio Code or another text editor with plugins but not being able to do refactoring across a project with 4000+ source files makes that approach dead on arrival for me, for all but the smallest projects.
The situation is pretty similar in regards to C#: you have Visual Studio which limits the platforms, JetBrains Rider which is a paid project, Visual Studio Code plugins which are insufficient and also something like MonoDevelop, which has pretty much been abandoned.
But "we developed our own ways of dealing with this" is so very true :)
Also, VS Code with OmniSharp isn't that bad for smaller projects for development and is pretty good for debugging for apps of all sizes (my 2 year experience with it).
So to claim that you cannot debug C# on Linux for free is false.
Perhaps not truly free, but within reach for most people.
Also, the EAP is $0 (although it's pre-release and not always guaranteed to be available)
I also thought their benchmark is a cheat. But it is not. It is testing exactly what the benchmark was testing in that scenario. That is why TechEmpower Benchmark suite is so powerful. It uses different web server scenarios (connection, JSON parsing, database connections, ...). The different test case implementation .NET and others have are making sure no other factor is influencing this. For example: when you benchmark connections why dealing with MVC, validation and database connections.
It is not .NET who cheats, it is the others who do not properly isolate the tested performance aspect.
And to make the comparison a bit more real and day-to-day applicable, you need to pick the right framework configuration (like aspcore-mw @ 80% / aspcore-mvc @ 37%) and compare with other reasonable scenarios (like express @ 1% / spring @ 2% / quarkus @ 8%). Both are then far of the top 10 ten list but still comparable. The top 10 combinations are for cases where developer productivity does not matter but throughput is the key (e.g. a DoH resolver or a system like a Cache / Database).
I don't get this. If you want to write C#, write C#. If you want to write Go, just write Go.
Go is a great language because of its simplicity and ecosystem, has lots of useful things in the standard library, has pretty good runtime performance and also compiles to static executables easily (which is especially useful for projects like Nomad). It's both a good fit for web development, as well as writing smaller or larger utilities. Honestly, its packaging situation is leaps and bounds ahead of something like Python, so I predict great future for it in DevOps too.
C# is a more advanced language with a rich history and a lot of the functionality for web development in particular coming as first party packages. Some of that historical baggage weighs it down and the complexity can be annoying, but ASP.NET Core, EF Core, Kestrel and many other components are great. Plus, running on *nix is good, even though the single executable/runtime/deployment situation isn't quite as easy as with Go.
Write code in whatever technologies work for you. My caveat to add would be that I'd (almost) always develop front end and back end separately, since the React/Angular/Vue webapp really shouldn't care much about what technologies are behind the APIs. Of course, being able to use a single language for both FE and BE development is also a worthwhile approach!
That’s because my argument has nothing to do with the language itself but you still felt compelled to write an essay. I’m saying the modern Linux-based tooling, ecosystem, and devex of C# is inferior to so many other choices.
Hence the exploration of the good things about each of the languages and genuine reasons why people might enjoy using them for slightly different use cases.
At the end of the day, everyone can make that choice for themselves, unless their org makes it for them.
The part that keeps me hooked is the fact that I can stand up something capable of producing those numbers in 30 lines of code using 1st party dependencies only. I can then have a full prototype to demo by late afternoon, again having antagonized over exactly zero 3rd parties.
For me, the performance numbers aren’t just about speed while in production. It’s also about speed to production. Having the confidence that it’s almost certainly going to be fast enough by default keeps me from worrying about optimizing random bullshit throughout.
I still haven’t seen anything that comes remotely close to the combination of speed and stability offered here. I do some pretty nasty things with the runtime and it just copes. GC seems like pure magic now too. I continue to avoid things like LOH allocations with streams, but I don’t worry about it like I used to in the 4.x days.
I like Rails (vintage, Rails 5). Unfortunately DotNet and EF combined now have virtually the same productivity but with massively better performance. Which is a shame as Ruby is a great language.
I think the end game may be one unique ecosystem per developer (like with JS frameworks).
I preferred the C# from 15 years ago compared to whatever is going on over there at present. If you're already indoctrinated into the ecosystem, I'm sure it's fine. Otherwise, buckle up - things are going to get choppy.
Most languages copy c#
[1]: https://docs.microsoft.com/en-us/dotnet/api/system.collectio...
[2]: https://docs.microsoft.com/en-us/dotnet/api/system.collectio...
A language can't be the fastest at everything in today's mature language ecosystem. OTOH, Debian's "Programming Language Games" benchmarks shows it's on par with Java (which is not slow in any means), and not as fast as you claim [0].
In the page I shared, some C# benchmarks are impressively fast, because they are written with explicit hand crafted SSE3/AVX vectors, which a run of the mill programmer won't want to touch (for most of the time, anyway).
Comparing .NET Core, which is a hybrid JIT language with purely interpreted ones like NodeJS and Python also makes no sense at all, considering Python Compiler does not do any optimizations whatsoever, and is still confined to a single core per process unless you pull some tricks.
Choosing horses for courses is fine, and we all shall do it, but claiming a language as winner over a single benchmark suite, including the one I referenced is wrong.
Choose what works best for you.
[0]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
It's not only their stance against Linux only, but everything competing with them.
I believe hardware and software should be open and platforms shall compete openly. I don't use any vendor which openly kills this interoperability and try to corner market with underhanded tactics.
It's not limited to Microsoft, though. I use Java because there's OpenJDK, Go because there's gcc-go toolchain, etc. Similarly I don't use Rust because it's LLVM only for now.
However, this doesn't mean that I want these to disappear. I want them to compete fairly, so we can improve. I'm not a web-dev so I have no need for this frameworks, but I'd make similar choices if I enter to that arena, too.
I'm curious, what do you have against LLVM? I'm sure it supports fewer backends than GCC, no surprise given their relative ages, but it's still got quite a few and it's open enough that it has documented support for adding new backends.
I open everything I can, and strictly with GNU/GPLv3+. I want this code can be built and improved upon, even after I abandon it voluntarily or involuntarily. Hence I choose GPL licensed (or close as much as possible) toolchains and tools as much as possible.
For example, I use Eclipse, and include .project files in the repositories, so one can import the project as is, and continue playing, or maintaining the code. I'm improving my Eclipse knowledge to use agnostic paths, so anyone cloning the repo can directly import to Eclipse, and just click build.
I also plan to make my Eclipse and toolchain settings available to make my development environment completely reproducible.
On the case of the Rust, I'm waiting gccrs, which is arriving as an unofficial language in gcc-13. This will both provide an alternative and GPL licensed implementation of the language, and I can be sure that the code I leave behind can be built with the public version of the GCC.
Moreover, I use no compiler specific extensions, because I'm not trying to lock anyone to any toolchain. I'm just trying to make sure that the repo is buildable. I may even add a LLVM (or go-gc) test path to make sure that I don't break anything between implementations.
IOW, I have strong opinions about software freedom, and I apply them to my code, but not force people to obey them (except the license, because I need to underpin it). It's a strong stance, yet there's no insistence. I just set an example, and try to make it a very good one, to show it can be done.
Which is mostly (~95%) developed by Oracle and is about the same in its openness and community participation as
https://github.com/dotnet/runtime/
is.
Or maybe you meant OpenJ9?
FWIW I also use Linux exclusively, develop (and host) dotnet applications on it, and have my own gripes with it (mostly with Linux still being treated as a second-tier platform which is only good for servers as far as MS is concerned — I'm not talking about the abomination that VS is — try to compare the official profiling & debugging tooling).
As a result, OpenJDK is much more sustainable in the long term, since it can't be closed down and crippled as easily.
While I am no enemy of MIT/BSD style licenses, the "freedoms" they provide to corporations are damaging to open source ecosystem in my eyes.
OpenJ9 looks like EPL licensed, and indeed interesting. It's worth a look.
I'm not writing Java with any considerable volume for some time (because, I didn't need that), hence I was just keeping that in my peripheral vision without paying much attention. However, I'm using Eclipse because it's a great IDE for my needs, and comes with OpenJ9 embedded.
Thanks for bringing this to my attention, will look deeper.
In proper society, the population would get to vote on the initiatives they care about.
They are still running this strategy, but now also buy good PR buying paying high profile developers thru their developer advocate positions.
""" Microsoft finally is fulfilling its dream of EEE to Linux. Windows Subsystem for Linux (WSL) embraced the API – letting you run Linux binaries (and GUIs!) on Windows natively. Next, WSL extended the kernel with GPU driver support. "" " - https://matt-rickard.com/embrace-extend-extinguish/
What's so good about MS ranking in the TechEmpower benchmarks is that it's the fastest full-featured "enterprise" framework. Frameworks like drogon or just-js are impressive feats of engineering, but the only reason they exist is so that their authors can mention that on their resume. If you run them in production, you are on your own.
There's equally fast Vert.x, which you can buy support from Red Hat for, but most Java shops use Spring Boot (vmware or Red Hat support available), which is easier, but hopelessly slow in comparison.
That proves my point even further, because I don't develop anything remotely web-related, hence that performance scenario is completely moot for me.
> What's so good about MS ranking in the TechEmpower benchmarks is that it's the fastest full-featured "enterprise" framework.
Again, the same because the software I develop is not "Enterprise" either.
What I develop is scientific software, and needs to be extremely performant. In my case C++ is the best language, but it's not the best for every case. This is why I also learn Go and use Python for other tasks.
In my case, Debian's benchmarks are directly related to my use cases, however even that's not a definitive measurement for my case. It's just a bunch of data to keep in mind.
I hope you realize non-web development is a niche nowadays. So it's perfectly reasonable to prioritize .NET benchmarks that target ASP.NET Core web apps/APIs.
Our vantage points are different, and these different vantage points need not to see the complete ecosystem as a whole. It's too big to generalize from a single vantage point, and just because our view reveal us a little of something doesn't mean it is, in fact, little.
There's a whole invisible world out there, from DBs themselves to OS kernels to embedded platforms, and everything in between.
IOW, horses for courses.
That's a terrible attitude. If you want a certain ecosystem to get a better rep, you have to be ready to talk with different communities, and accept their feedback.
Python is what it is largely because it can cater to a large number of these very different communities, which has ensured its long-term success. Compare with Ruby, which became effectively a web-only language and has since struggled to go anywhere.
Hard disagree. I prefer specialized tools over jack-of-all-trades. Otherwise we would be coding web applications in assembly.
Your example, Ruby, wouldn't even be a blip in history radar if it wasn't for Ruby on Rails, a specialized and very productive toolkit.
Just because RoR now has more competition doesn't mean it isn't/wasn't awesome.
Some people write web-apps in C. Just because you don't like something, it doesn't mean the world agrees.
>Ruby, wouldn't even be a blip in history radar if it wasn't for Ruby on Rails
Hard disagree. Ruby was getting traction on its own, as "the purest OOP language you can use in the real world", around the same time Python was starting to get traction (early 2000s). Then RoR blew up, effectively coopting the entire ecosystem. Since then, Python has slowly gone from strength to strength in so many different fields, whereas Ruby died on its ass as soon as people moved on to other tools for web.
Thanks for reminding, BTW. :)
That's not true atm.
At time of writing (TechEmpower 21) Rust frameworks have top 3 out ouf 5 slots (#2, #3 and #5) in composite rankings. https://www.techempower.com/benchmarks/#section=data-r21&tes...
Which goes to show, benchmarks change and depend on use case. And Rust is very competitive (in league with C/C++).
Java and C# are very similar languages.
It's the very definition of blog spam.
Oh please please please let this come true so I can write c# on the backend again. I love typescript because it made JavaScript (i.e. front end web) so much less shit to work on, and I’d prefer it over ruby or python backends still, but c# hits such a sweet spot of ease to write, while still remaining relatively performant.
Go and rust are probably better for certain applications, but c# would be light years ahead of things like ruby or python.
https://isdotnetopen.com/
If Microsoft would only clearly and trustworthy communicate.
Dependency handling is still a large problem with .NET. Especially since current is often used instead of LTS. There is also no good way of sharing code between applications.
Arrow functions, btw, solves the this/that problem in JS making React development easier etc.
YMMV - maybe you've been especially unlucky.
See: https://docs.microsoft.com/en-us/dotnet/csharp/
The only built-in way to type a sharp outside wordpad is to have a special registry key set then hold alt and type +266F, isn't it? That sounds to me like it falls under "dreadful support for Unicode".