24 ms·

The Case for C# and .NET

314 points by greenSunglass 4y ago

barrenko 4y ago
.Net suffers from the same problem as computer science in the popular joke - names for things.
wrnr 4y ago
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.
- cosmotic 4y ago
  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.
  - bm3719 4y ago
    They also have a history of randomly deciding to dump a technology (including full languages) too, leaving those invested in it holding the bag. I like F# too, but I'll stick with one of it's non-MS controlled alternatives.
    - Barrin92 4y ago
      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.
      - j0057 4y ago
        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.
        philliphaydon 4y ago
        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.
        kgeist 4y ago
        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.
        int_19h 4y ago
        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.
      - tbrownaw 4y ago
        I hear some of IBM's stuff has a pretty long history to it.
    - Salgat 4y ago
      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.
      - tbrownaw 4y ago
        > 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?
        Salgat 4y ago
        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.
      - bm3719 4y ago
        J# is one that comes to mind. Spent some time learning this only to have it dropped the next year.
        kgeist 4y ago
        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.
  - ihateolives 4y ago
    For running, yes. For developing, no.
    - celdon25 4y ago
      What part of the .NET SDK isn't supported on Linux?
      - philliphaydon 4y ago
        I think they are referring to visual studio support which doesn’t exist on linux. But if you wanna use VSCode or Rider then the support is 100%
        celdon25 4y ago
        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.
    - eropple 4y ago
      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.
    - tbrownaw 4y ago
      What? I do occasional dotnet development on Linux. Using the dotnet SDK which is from Microsoft, and VS Code which is also from Microsoft.
    - metaltyphoon 4y ago
      Huh?
- verisimilidude 4y ago
  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.
- moonchrome 4y ago
  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)
  - throw868788 4y ago
    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.
labrador 4y ago
> 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.
- tbrownaw 4y ago
  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.
  - wvenable 4y ago
    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.
  - drewrv 4y ago
    It's a pain, but there are some optimizations to shrink the large download size. This person was able to get it from 14.4MB to 4.4MB: https://www.michielpost.nl/posts/reducing-blazor-webassembly-download-size 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.
andrewstuart 4y ago
C# and TypeScript seem to be far and away the most popular programming languages today. 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.
- tus666 4y ago
  > Python is on the way up and third most popular but well behind C# and TypeScript. lolwut. TypeScript is niche compared to Python.
  - zdragnar 4y ago
    > from the perspective of recruiting in Australia. Even accounting for that line from the comment?
    - tus666 4y ago
      Even more so. Python is huge in Australia. Can't count front-end as Python is not applicable there.
      - zdragnar 4y ago
        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.
sandreas 4y ago
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. https://www.youtube.com/watch?v=2eIsQ3Pm2bE https://www.youtube.com/watch?v=2eIsQ3Pm2bE
- mccorrinall 4y ago
  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.
noveltyaccount 4y ago
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.
jeswin 4y ago
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).
- CharlieDigital 4y ago
  If you look at how major backend projects structure their code, it's almost always object-oriented TypeScript. I submit for the record: - Apollo Client: https://github.com/apollographql/apollo-client/blob/main/src/core/QueryManager.ts#L82 https://github.com/apollographql/apollo-client/blob/main/src... - Storybook: https://github.com/storybookjs/storybook/blob/next/lib/channels/src/index.ts#L35 https://github.com/storybookjs/storybook/blob/next/lib/chann... - Nest: https://github.com/nestjs/nest/blob/master/packages/core/nest-application.ts https://github.com/nestjs/nest/blob/master/packages/core/nes... - MongoDB Driver: https://github.com/mongodb/node-mongodb-native/blob/main/src/collection.ts https://github.com/mongodb/node-mongodb-native/blob/main/src... - Prisma: https://github.com/prisma/prisma/blob/main/packages/engine-core/src/library/LibraryEngine.ts#L56 https://github.com/prisma/prisma/blob/main/packages/engine-c...
evasb 4y ago
I wouldn't lose a second to C# or any MS platform unless required for employment reasons. https://github.com/OmniSharp/omnisharp-vscode/issues/5276 https://github.com/OmniSharp/omnisharp-vscode/issues/5276
- oneepic 4y ago
  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?
  - agent281 4y ago
    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.
  - ghuntley 4y ago
    See https://www.isdotnetopen.com/ https://www.isdotnetopen.com/
  - d3nj4l 4y ago
    > They are EEE'ing a VSCode extension, so you're going to avoid that and the language, and the entire ecosystem? Sounds like a pretty good reason to me?
- nathanaldensr 4y ago
  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.
  - Hawxy 4y ago
    > Sorry, but OmniSharp sucks 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.
noisy_boy 4y ago
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?
- shhsshs 4y ago
  I have ton of experience with ASP.NET Core and have not had that impression in the slightest.
- nizmow 4y ago
  You're wrong. Everywhere I've worked the general pattern is to build using Windows/Linux and deploy entirely on Linux (or Docker).
- metaltyphoon 4y ago
  There is nothing in ASP NET that is more “windows specific”. Since its inception, I have used these scenarios and they all worked without flaws: Windows -> Linux WSL -> Linux WSL2 -> Linux (Its real Linux) macOS -> Linux All of the scenarios were deployed to AWS.
- nathanaldensr 4y ago
  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.
  - spyremeown 4y ago
    > 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.
osigurdson 4y ago
The article makes a case against using Node.js but doesn't bother to provide a comparison of C# and its actual competitors: Java and Go.
- metaltyphoon 4y ago
  If you are looking at server side stuff, here you go https://www.techempower.com/benchmarks/#section=data-r21 https://www.techempower.com/benchmarks/#section=data-r21
- bayesian_horse 4y ago
  Python, Ruby.
  - osigurdson 4y ago
    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.
    - bayesian_horse 4y ago
      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.
      - 4y ago
chaostheory 4y ago
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
- int_19h 4y ago
  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.
- bayesian_horse 4y ago
  It does seem like the author doesn't have much experience outside dotnet and node.
- ivraatiems 4y ago
  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...
  - chaostheory 4y ago
    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.
bayesian_horse 4y ago
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...
LAC-Tech 4y ago
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.
- banashark 4y ago
  Zod is really cool. Similar in F# land is https://github.com/Zaid-Ajaj/Fable.Remoting 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.
- bob1029 4y ago
  Perhaps you should look into the .NET implementation of gRPC. It works really well in my experience.
  - LAC-Tech 4y ago
    The thing with zod is that by reusing schemas on server and client, I get extra client side validation for free. gRPC seems like it's just for the server.
dustinmoris 4y ago
Hottake: 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.
- oaiey 4y ago
  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".
- kcartlidge 4y ago
  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.
smaudet 4y ago
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).
CyanLite4 4y ago
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.
- dustinmoris 4y ago
  The dev experience is Windows only, STILL: https://news.ycombinator.com/reply?id=32220935&goto=item%3Fid%3D32219836%2332220935 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)
  - DeWilde 4y ago
    I use Rider on my Ubuntu machine and the dev experience for me, is even better than using VS2022 on Windows.
    - dustinmoris 4y ago
      - fabian2k 4y ago
        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.
        dustinmoris 4y ago
        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.
PeeMcGee 4y ago
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.
- thefz 4y ago
  ... with large gifs in the middle.
  - quickthrower2 4y ago
    He already said “medium article”
- throw_m239339 4y ago
  > 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. It's the very definition of blog spam.
lamontcg 4y ago
No mention of leftpad? Kids these days don't study history.
mostertoaster 4y ago
> 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.
- Angius 4y ago
  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
TeresaFord 4y ago
brainzap 4y ago
wake me up when it is really open source
- iasay 4y ago
  This. https://isdotnetopen.com/ https://isdotnetopen.com/
  - oaiey 4y ago
    The page is 100% accurate but so FUDy ;). Not helpful. If Microsoft would only clearly and trustworthy communicate.
    - iasay 4y ago
      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.
raydiatian 4y ago
Why did you not include Go in your analysis?
AtNightWeCode 4y ago
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.
- nso 4y ago
  What do you mean when you say there is no good way to share code between applications?
  - AtNightWeCode 4y ago
    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.
    - kcartlidge 4y ago
      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. YMMV - maybe you've been especially unlucky.
dgudkov 4y ago
It's a pity the author doesn't mention F#.
fravelgue 4y ago
Source of some images: https://docs.microsoft.com/en-us/nuget/concepts/security-best-practices https://docs.microsoft.com/en-us/nuget/concepts/security-bes...
jjgreen 4y ago
There are 171 posts at the time of writing, only one (this one) includes the character ♯
- xnorswap 4y ago
  Because even microsoft doesn't call it C♯, they call it C#. See: https://docs.microsoft.com/en-us/dotnet/csharp/ https://docs.microsoft.com/en-us/dotnet/csharp/
- legalcorrection 4y ago
  Will you tire of posting about this stupidity? https://news.ycombinator.com/item?id=32117175 https://news.ycombinator.com/item?id=32117175
  - Dylan16807 4y ago
    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".
  - jjgreen 4y ago
    Oh I do hope not. As Dr Johnson said, "when a man is tired of mocking Microsoft, he is tired of life".
karmasimida 4y ago
C# is good, but not good enough to convince me overcoming the hurdle to onboard with its ecosystem. The deal isn't sweet enough. Language isn't important unless it is business critical. And successful businesses are scarce.
- Angius 4y ago
  What hurdle?
vietvu 4y ago
The problem is not with .NET itself, it's Microsoft. I don't even consider using VsCode as main editor because it's from MS.
- jeremycarter 4y ago
  There are genuine people behind these tools. Awesome people.
  - smallerfish 4y ago
    Sure, but they work for Microsoft. Who tried to own the industry in the 1990s.
reverseblade2 4y ago
Just use F# instead and you will have Rust, typescript, Javascript, dart, python all at once https://twitter.com/FableCompiler/status/1550429007443017729?s=20&t=XwBoT5kiWwJGy7-9VCghbw https://twitter.com/FableCompiler/status/1550429007443017729...
- pjmlp 4y ago
  Unfortunely not with same tooling level as C# and VB enjoy.
  - owenm 4y ago
    I used to use Visual Studio and VSMac for my F# experimentation. Over the past couple of years, Ionide has got so much better that I've switched completely over to it from VS for all my F# work. The new 7.0 release a couple of days ago looks to have continued this trend.
    - pjmlp 4y ago
      Try to do a GUI or EF data model design in Ionide, hot code reload while changing a GUI design, or using annotations from code generators.
      - throw868788 4y ago
        My view: F#, or to be honest a cross-platform IDE like VS Code isn't probably appropriate for many of these apps or rather the dev workflow that Microsoft promote in those frameworks feels like old .NET to me. The frameworks themselves weren't designed for a minimal IDE, and language first development initially often assuming dev is in full Visual Studio with GUI XAML editors, EF designers, etc. To be bluntly honest with my opinion it isn't a dev workflow that would fly/got started in other more open languages including F# which should be develop-able and maintainable with a lot less tooling support. F# feels like a different dev workflow than C#, which IMO is a very good thing in F#'s favor. It feels more like coding JS, Go, etc to me with static typing and richer features. I also think EF, as it is designed, doesn't lean to the FP approach that well. I personally don't like EF - I'm happy with something in .NET like DbUp for migrations and straight SQL. Normally I get better performance anyway doing this and in the age of microservices I feel this pattern actually makes it easier to change DB's if you need to (but I still assert you probably never will without a rewrite most of the time) - just use the different query language and port your data access layer. Move to Redis? Just port your F# module that queries the DB in SQL to Redis code. In F# it also allows a richer data modelling experience doing it this way (e.g use of DU's for modelling cases in your domain) since db logic is decoupled from your domain types. I never believed my domain model had to look similar to my DB table design which is what EF typically encourages. Especially with the modern features of DB's like Postgres you are leaving more and more performance on the table. In the apps I've written doing that leads to lower DB performance than otherwise, sometimes for some quite trivial apps. TL;DR: Tooling like Resharper, designers, etc is nice but often is there IMO because the language itself is bloated and not expressive enough to just state your original intent there succinctly. If the code is enough then F# can express pretty much what C# can.
TheRealDunkirk 4y ago
The speed comparison is fascinating. Ruby often takes a hit in these parts for being slow, and the inference is usually versus Java, but hose numbers suggest they’re about the same? (Though I’m a big fan of Rails, it’s a criticism I acknowledge, as I came to it from PHP.) And people blithely never refer to JavaScript’s speed, but this is suggesting that it’s 50% slower than EITHER. My point is that the usual conversation about speed of languages seems to need some adjustment.
hypeatei 4y ago
I like C# but I've really come to dislike the idea of exceptions and null after working with Rust. I think C# would benefit from a Result/Option addition.
- code_runner 4y ago
  It should be a simple wrapper Func<> with a generic Option<T>. I’m sure there is a library out there doing it already.
- svick 4y ago
  For null, there are nullable reference types now. Exceptions are here to stay though. I don't see how you could retrofit something like Rust's Result on top of .Net. (Also, .Net has a pattern that's an alternative to exceptions: `bool TrySomething(out T result)`. But it's quite limited, in several ways.)
  - ttymck 4y ago
    Are you suggesting a Result type and Exceptions are mutually exclusive? Scala bolted `Either` (a Result type) on top of Java, and it worked exceptionally well in my experience.
cesarb 4y ago
The thing I miss the most with C# and dotnet is offline documentation. With Java, I can install the java-17-openjdk-javadoc package and have the full API reference (at /usr/share/javadoc/java/index.html), and download a couple of PDF files to have also the full language and bytecode specification. With Rust, I can install the rust-doc package and have the full API and language reference (at /usr/share/doc/rust/html/index.html). But so far, I haven't found an equivalent for dotnet, unless you're running Visual Studio on Windows. When you want to learn by leisurely browsing the API documentation and language reference, the speed difference is massive: the online documentation takes a bit of time to switch from one page to another, while with offline documentation it's nearly instant.
- jtwigg 4y ago
  could you clone the docs repo? https://github.com/dotnet/docs https://github.com/dotnet/docs
- Kye 4y ago
  You might be able to do something with this: https://github.com/dotnet/docs https://github.com/dotnet/docs The browsy bits might not work without a server (not sure), but the documents themselves are markdown.
- exyi 4y ago
  I use Zeal documentation browser and it has most of .NET docs available offline
- zczc 4y ago
  Most topics on docs.microsoft.com have links to pdf, e.g. https://docs.microsoft.com/en-us/dotnet/csharp/ https://docs.microsoft.com/en-us/dotnet/csharp/ have "Download PDF" in bottom left corner which links to 2756 pages of C# documentation: https://docs.microsoft.com/en-us/dotnet/opbuildpdf/csharp/toc.pdf?branch=live https://docs.microsoft.com/en-us/dotnet/opbuildpdf/csharp/to...
zirak 4y ago
The data this article quotes doesn't smell right. The tables and graphs in "The Performance Problem" section should at least feel a little strange. Looking at the original article[1], we can see the source code for JavaScript [2], Python [3], and .Net [4] shows that...there just isn't much going on here. This isn't a comparison of how fast these are. It's a comparison of how fast this AWS setup could do its thing, and how fast this DynamoDB client library is. In the "So Why/Not .NET?", there's the "Advisories by package ecosystem and severity"[5] graph. So it doesn't feel a little strange that NuGet is the pinnacle of software engineering, and programs there just have no security vulnerabilities? Or maybe...there's some bias going on here, and NuGet isn't as interesting to look at as PyPI, so there are fewer advisories being published? That's another way to look at it. When things look too good to be true, maybe they are. I don't care if the author (or anyone else) wants to use .Net, have fun. I do care that we sometimes approach technological issues with hostility and rivalry, accepting random data which seem to support us without looking them through. [1] https://filia-aleks.medium.com/aws-lambda-battle-2021-performance-comparison-for-all-languages-c1b441005fd1 https://filia-aleks.medium.com/aws-lambda-battle-2021-perfor... [2] https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-performance/blob/main/node-lambda/lambda.js https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-p... [3] https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-performance/blob/main/python-lambda/lambda.py https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-p... [4] https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-performance/blob/main/dotnet-lambda/src/DotNetFunction/Function.cs https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-p... [5] https://octoverse.github.com/static/github-octoverse-2020-security-report.pdf https://octoverse.github.com/static/github-octoverse-2020-se...
mattgreenrocks 4y ago
The article mentions it, but I'll reiterate: the .NET CLR is fantastic. C# is a great language for the backend: GC'd, lots of libraries, fast runtime, and expressive enough. Do I wish it was more functional? Absolutely. But it doesn't aspire to be that. The ecosystem deserves mention. There are some high-quality libraries that work well, even if they aren't the most popular. Take objectional relational mappers, for instance. You can go whole hog and have an ultra-coupled, er, cough, "batteries-included" ORM much like every other ecosystem, or experiment with a multitude of options between writing your own SQL but letting the ORM handle hydration, and a full-blown ORM. Tooling support has always been top of the line, too. It is only in the past few years that other languages have caught up with the quality there (Eclipse/IntelliJ excepted).
- mirekrusin 4y ago
  > ...objectional relational mappers... love this typo. will use objectionable-relational mappers from now on. - objectionable - adjective, arousing distaste or opposition; unpleasant or offensive (definition source: Oxford Languages)
- bob1029 4y ago
  > Do I wish it was more functional? Absolutely. But it doesn't aspire to be that. I somewhat disagree about the aspirations. Have you tried out things like switch expressions and LINQ? You can apply functional concepts almost everywhere these days. Complex state machines can be modeled using 100% functional techniques.
sylens 4y ago
I have been teaching myself C# for the last two or three months (with the fantastic C# Player's Guide by RB Whitaker) and I have come to really enjoy working with the language. Discovering Properties, which combine fields and their accessor methods and can be auto-implemented and initialized, was the first moment I realized it might make my life a whole lot easier. I'm not entirely sold on its use for desktop GUI development yet (will watch MAUI closely) but I am eager to jump into Blazor and see if I can start to remove JavaScript from my stack.
redleggedfrog 4y ago
Shhhhh, you're giving away my precious secrets!
zumu 4y ago
Kind of an aside, but any one have a clue why those Haskell benchmarks are so slow? In my experience Haskell is relatively fast, so there must be some caveat that these test cases are hitting.
SZJX 4y ago
This article seems to be a lot focused on why you should be careful about using JavaScript for backend development. C#/.NET is one valid alternative, but many others surely also provide similar benefits and also avoid the pitfalls of JS. I agree that .NET is really solid and seems often unfairly seen in a negative light though.

314 points by greenSunglass 4y ago

.Net suffers from the same problem as computer science in the popular joke - names for things.

wrnr 4y ago

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.

cosmotic 4y ago
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.
- bm3719 4y ago
  They also have a history of randomly deciding to dump a technology (including full languages) too, leaving those invested in it holding the bag. I like F# too, but I'll stick with one of it's non-MS controlled alternatives.
  - Barrin92 4y ago
    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.
    - j0057 4y ago
      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.
      - philliphaydon 4y ago
        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.
        kgeist 4y ago
        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.
      - int_19h 4y ago
        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.
    - tbrownaw 4y ago
      I hear some of IBM's stuff has a pretty long history to it.
  - Salgat 4y ago
    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.
    - tbrownaw 4y ago
      > 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?
      - Salgat 4y ago
        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.
    - bm3719 4y ago
      J# is one that comes to mind. Spent some time learning this only to have it dropped the next year.
      - kgeist 4y ago
        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.
- ihateolives 4y ago
  For running, yes. For developing, no.
  - celdon25 4y ago
    What part of the .NET SDK isn't supported on Linux?
    - philliphaydon 4y ago
      I think they are referring to visual studio support which doesn’t exist on linux. But if you wanna use VSCode or Rider then the support is 100%
      - celdon25 4y ago
        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.
  - eropple 4y ago
    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.
  - tbrownaw 4y ago
    What? I do occasional dotnet development on Linux. Using the dotnet SDK which is from Microsoft, and VS Code which is also from Microsoft.
  - metaltyphoon 4y ago
    Huh?
verisimilidude 4y ago
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.
moonchrome 4y ago
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)
- throw868788 4y ago
  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.

labrador 4y ago

> 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.

tbrownaw 4y ago
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.
- wvenable 4y ago
  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.
- drewrv 4y ago
  It's a pain, but there are some optimizations to shrink the large download size. This person was able to get it from 14.4MB to 4.4MB: https://www.michielpost.nl/posts/reducing-blazor-webassembly-download-size 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.

andrewstuart 4y ago

C# and TypeScript seem to be far and away the most popular programming languages today. 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.

tus666 4y ago
> Python is on the way up and third most popular but well behind C# and TypeScript. lolwut. TypeScript is niche compared to Python.
- zdragnar 4y ago
  > from the perspective of recruiting in Australia. Even accounting for that line from the comment?
  - tus666 4y ago
    Even more so. Python is huge in Australia. Can't count front-end as Python is not applicable there.
    - zdragnar 4y ago
      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.

sandreas 4y ago

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. https://www.youtube.com/watch?v=2eIsQ3Pm2bE https://www.youtube.com/watch?v=2eIsQ3Pm2bE

mccorrinall 4y ago
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.

noveltyaccount 4y ago

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.

jeswin 4y ago

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).

CharlieDigital 4y ago
If you look at how major backend projects structure their code, it's almost always object-oriented TypeScript. I submit for the record: - Apollo Client: https://github.com/apollographql/apollo-client/blob/main/src/core/QueryManager.ts#L82 https://github.com/apollographql/apollo-client/blob/main/src... - Storybook: https://github.com/storybookjs/storybook/blob/next/lib/channels/src/index.ts#L35 https://github.com/storybookjs/storybook/blob/next/lib/chann... - Nest: https://github.com/nestjs/nest/blob/master/packages/core/nest-application.ts https://github.com/nestjs/nest/blob/master/packages/core/nes... - MongoDB Driver: https://github.com/mongodb/node-mongodb-native/blob/main/src/collection.ts https://github.com/mongodb/node-mongodb-native/blob/main/src... - Prisma: https://github.com/prisma/prisma/blob/main/packages/engine-core/src/library/LibraryEngine.ts#L56 https://github.com/prisma/prisma/blob/main/packages/engine-c...

evasb 4y ago

I wouldn't lose a second to C# or any MS platform unless required for employment reasons. https://github.com/OmniSharp/omnisharp-vscode/issues/5276 https://github.com/OmniSharp/omnisharp-vscode/issues/5276

oneepic 4y ago
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?
- agent281 4y ago
  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.
- ghuntley 4y ago
  See https://www.isdotnetopen.com/ https://www.isdotnetopen.com/
- d3nj4l 4y ago
  > They are EEE'ing a VSCode extension, so you're going to avoid that and the language, and the entire ecosystem? Sounds like a pretty good reason to me?
nathanaldensr 4y ago
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.
- Hawxy 4y ago
  > Sorry, but OmniSharp sucks 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.

noisy_boy 4y ago

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?

shhsshs 4y ago
I have ton of experience with ASP.NET Core and have not had that impression in the slightest.
nizmow 4y ago
You're wrong. Everywhere I've worked the general pattern is to build using Windows/Linux and deploy entirely on Linux (or Docker).
metaltyphoon 4y ago
There is nothing in ASP NET that is more “windows specific”. Since its inception, I have used these scenarios and they all worked without flaws: Windows -> Linux WSL -> Linux WSL2 -> Linux (Its real Linux) macOS -> Linux All of the scenarios were deployed to AWS.
nathanaldensr 4y ago
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.
- spyremeown 4y ago
  > 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.

osigurdson 4y ago

The article makes a case against using Node.js but doesn't bother to provide a comparison of C# and its actual competitors: Java and Go.

metaltyphoon 4y ago
If you are looking at server side stuff, here you go https://www.techempower.com/benchmarks/#section=data-r21 https://www.techempower.com/benchmarks/#section=data-r21
bayesian_horse 4y ago
Python, Ruby.
- osigurdson 4y ago
  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.
  - bayesian_horse 4y ago
    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.
    - 4y ago

chaostheory 4y ago

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

int_19h 4y ago
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.
bayesian_horse 4y ago
It does seem like the author doesn't have much experience outside dotnet and node.
ivraatiems 4y ago
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...
- chaostheory 4y ago
  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.

bayesian_horse 4y ago

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...

LAC-Tech 4y ago

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.

banashark 4y ago
Zod is really cool. Similar in F# land is https://github.com/Zaid-Ajaj/Fable.Remoting 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.
bob1029 4y ago
Perhaps you should look into the .NET implementation of gRPC. It works really well in my experience.
- LAC-Tech 4y ago
  The thing with zod is that by reusing schemas on server and client, I get extra client side validation for free. gRPC seems like it's just for the server.

dustinmoris 4y ago

Hottake: 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.

oaiey 4y ago
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".
kcartlidge 4y ago
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.

smaudet 4y ago

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).

CyanLite4 4y ago

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.

dustinmoris 4y ago
The dev experience is Windows only, STILL: https://news.ycombinator.com/reply?id=32220935&goto=item%3Fid%3D32219836%2332220935 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)
- DeWilde 4y ago
  I use Rider on my Ubuntu machine and the dev experience for me, is even better than using VS2022 on Windows.
  - dustinmoris 4y ago
    - fabian2k 4y ago
      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.
      - dustinmoris 4y ago
        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.

PeeMcGee 4y ago

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.

thefz 4y ago
... with large gifs in the middle.
- quickthrower2 4y ago
  He already said “medium article”
throw_m239339 4y ago
> 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. It's the very definition of blog spam.

lamontcg 4y ago

No mention of leftpad? Kids these days don't study history.

mostertoaster 4y ago

> 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.

Angius 4y ago
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

TeresaFord 4y ago

brainzap 4y ago

wake me up when it is really open source

iasay 4y ago
This. https://isdotnetopen.com/ https://isdotnetopen.com/
- oaiey 4y ago
  The page is 100% accurate but so FUDy ;). Not helpful. If Microsoft would only clearly and trustworthy communicate.
  - iasay 4y ago
    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.

raydiatian 4y ago

Why did you not include Go in your analysis?

AtNightWeCode 4y ago

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.

nso 4y ago
What do you mean when you say there is no good way to share code between applications?
- AtNightWeCode 4y ago
  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.
  - kcartlidge 4y ago
    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. YMMV - maybe you've been especially unlucky.

dgudkov 4y ago

It's a pity the author doesn't mention F#.

fravelgue 4y ago

Source of some images: https://docs.microsoft.com/en-us/nuget/concepts/security-best-practices https://docs.microsoft.com/en-us/nuget/concepts/security-bes...

jjgreen 4y ago

There are 171 posts at the time of writing, only one (this one) includes the character ♯

xnorswap 4y ago
Because even microsoft doesn't call it C♯, they call it C#. See: https://docs.microsoft.com/en-us/dotnet/csharp/ https://docs.microsoft.com/en-us/dotnet/csharp/
legalcorrection 4y ago
Will you tire of posting about this stupidity? https://news.ycombinator.com/item?id=32117175 https://news.ycombinator.com/item?id=32117175
- Dylan16807 4y ago
  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".
- jjgreen 4y ago
  Oh I do hope not. As Dr Johnson said, "when a man is tired of mocking Microsoft, he is tired of life".

karmasimida 4y ago

C# is good, but not good enough to convince me overcoming the hurdle to onboard with its ecosystem. The deal isn't sweet enough. Language isn't important unless it is business critical. And successful businesses are scarce.

Angius 4y ago
What hurdle?

vietvu 4y ago

The problem is not with .NET itself, it's Microsoft. I don't even consider using VsCode as main editor because it's from MS.

jeremycarter 4y ago
There are genuine people behind these tools. Awesome people.
- smallerfish 4y ago
  Sure, but they work for Microsoft. Who tried to own the industry in the 1990s.

reverseblade2 4y ago

Just use F# instead and you will have Rust, typescript, Javascript, dart, python all at once https://twitter.com/FableCompiler/status/1550429007443017729?s=20&t=XwBoT5kiWwJGy7-9VCghbw https://twitter.com/FableCompiler/status/1550429007443017729...

pjmlp 4y ago
Unfortunely not with same tooling level as C# and VB enjoy.
- owenm 4y ago
  I used to use Visual Studio and VSMac for my F# experimentation. Over the past couple of years, Ionide has got so much better that I've switched completely over to it from VS for all my F# work. The new 7.0 release a couple of days ago looks to have continued this trend.
  - pjmlp 4y ago
    Try to do a GUI or EF data model design in Ionide, hot code reload while changing a GUI design, or using annotations from code generators.
    - throw868788 4y ago
      My view: F#, or to be honest a cross-platform IDE like VS Code isn't probably appropriate for many of these apps or rather the dev workflow that Microsoft promote in those frameworks feels like old .NET to me. The frameworks themselves weren't designed for a minimal IDE, and language first development initially often assuming dev is in full Visual Studio with GUI XAML editors, EF designers, etc. To be bluntly honest with my opinion it isn't a dev workflow that would fly/got started in other more open languages including F# which should be develop-able and maintainable with a lot less tooling support. F# feels like a different dev workflow than C#, which IMO is a very good thing in F#'s favor. It feels more like coding JS, Go, etc to me with static typing and richer features. I also think EF, as it is designed, doesn't lean to the FP approach that well. I personally don't like EF - I'm happy with something in .NET like DbUp for migrations and straight SQL. Normally I get better performance anyway doing this and in the age of microservices I feel this pattern actually makes it easier to change DB's if you need to (but I still assert you probably never will without a rewrite most of the time) - just use the different query language and port your data access layer. Move to Redis? Just port your F# module that queries the DB in SQL to Redis code. In F# it also allows a richer data modelling experience doing it this way (e.g use of DU's for modelling cases in your domain) since db logic is decoupled from your domain types. I never believed my domain model had to look similar to my DB table design which is what EF typically encourages. Especially with the modern features of DB's like Postgres you are leaving more and more performance on the table. In the apps I've written doing that leads to lower DB performance than otherwise, sometimes for some quite trivial apps. TL;DR: Tooling like Resharper, designers, etc is nice but often is there IMO because the language itself is bloated and not expressive enough to just state your original intent there succinctly. If the code is enough then F# can express pretty much what C# can.

TheRealDunkirk 4y ago

The speed comparison is fascinating. Ruby often takes a hit in these parts for being slow, and the inference is usually versus Java, but hose numbers suggest they’re about the same? (Though I’m a big fan of Rails, it’s a criticism I acknowledge, as I came to it from PHP.) And people blithely never refer to JavaScript’s speed, but this is suggesting that it’s 50% slower than EITHER. My point is that the usual conversation about speed of languages seems to need some adjustment.

hypeatei 4y ago

I like C# but I've really come to dislike the idea of exceptions and null after working with Rust. I think C# would benefit from a Result/Option addition.

code_runner 4y ago
It should be a simple wrapper Func<> with a generic Option<T>. I’m sure there is a library out there doing it already.
svick 4y ago
For null, there are nullable reference types now. Exceptions are here to stay though. I don't see how you could retrofit something like Rust's Result on top of .Net. (Also, .Net has a pattern that's an alternative to exceptions: `bool TrySomething(out T result)`. But it's quite limited, in several ways.)
- ttymck 4y ago
  Are you suggesting a Result type and Exceptions are mutually exclusive? Scala bolted `Either` (a Result type) on top of Java, and it worked exceptionally well in my experience.

cesarb 4y ago

The thing I miss the most with C# and dotnet is offline documentation. With Java, I can install the java-17-openjdk-javadoc package and have the full API reference (at /usr/share/javadoc/java/index.html), and download a couple of PDF files to have also the full language and bytecode specification. With Rust, I can install the rust-doc package and have the full API and language reference (at /usr/share/doc/rust/html/index.html). But so far, I haven't found an equivalent for dotnet, unless you're running Visual Studio on Windows. When you want to learn by leisurely browsing the API documentation and language reference, the speed difference is massive: the online documentation takes a bit of time to switch from one page to another, while with offline documentation it's nearly instant.

jtwigg 4y ago
could you clone the docs repo? https://github.com/dotnet/docs https://github.com/dotnet/docs
Kye 4y ago
You might be able to do something with this: https://github.com/dotnet/docs https://github.com/dotnet/docs The browsy bits might not work without a server (not sure), but the documents themselves are markdown.
exyi 4y ago
I use Zeal documentation browser and it has most of .NET docs available offline
zczc 4y ago
Most topics on docs.microsoft.com have links to pdf, e.g. https://docs.microsoft.com/en-us/dotnet/csharp/ https://docs.microsoft.com/en-us/dotnet/csharp/ have "Download PDF" in bottom left corner which links to 2756 pages of C# documentation: https://docs.microsoft.com/en-us/dotnet/opbuildpdf/csharp/toc.pdf?branch=live https://docs.microsoft.com/en-us/dotnet/opbuildpdf/csharp/to...

zirak 4y ago

The data this article quotes doesn't smell right. The tables and graphs in "The Performance Problem" section should at least feel a little strange. Looking at the original article[1], we can see the source code for JavaScript [2], Python [3], and .Net [4] shows that...there just isn't much going on here. This isn't a comparison of how fast these are. It's a comparison of how fast this AWS setup could do its thing, and how fast this DynamoDB client library is. In the "So Why/Not .NET?", there's the "Advisories by package ecosystem and severity"[5] graph. So it doesn't feel a little strange that NuGet is the pinnacle of software engineering, and programs there just have no security vulnerabilities? Or maybe...there's some bias going on here, and NuGet isn't as interesting to look at as PyPI, so there are fewer advisories being published? That's another way to look at it. When things look too good to be true, maybe they are. I don't care if the author (or anyone else) wants to use .Net, have fun. I do care that we sometimes approach technological issues with hostility and rivalry, accepting random data which seem to support us without looking them through. [1] https://filia-aleks.medium.com/aws-lambda-battle-2021-performance-comparison-for-all-languages-c1b441005fd1 https://filia-aleks.medium.com/aws-lambda-battle-2021-perfor... [2] https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-performance/blob/main/node-lambda/lambda.js https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-p... [3] https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-performance/blob/main/python-lambda/lambda.py https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-p... [4] https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-performance/blob/main/dotnet-lambda/src/DotNetFunction/Function.cs https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-p... [5] https://octoverse.github.com/static/github-octoverse-2020-security-report.pdf https://octoverse.github.com/static/github-octoverse-2020-se...

mattgreenrocks 4y ago

The article mentions it, but I'll reiterate: the .NET CLR is fantastic. C# is a great language for the backend: GC'd, lots of libraries, fast runtime, and expressive enough. Do I wish it was more functional? Absolutely. But it doesn't aspire to be that. The ecosystem deserves mention. There are some high-quality libraries that work well, even if they aren't the most popular. Take objectional relational mappers, for instance. You can go whole hog and have an ultra-coupled, er, cough, "batteries-included" ORM much like every other ecosystem, or experiment with a multitude of options between writing your own SQL but letting the ORM handle hydration, and a full-blown ORM. Tooling support has always been top of the line, too. It is only in the past few years that other languages have caught up with the quality there (Eclipse/IntelliJ excepted).

mirekrusin 4y ago
> ...objectional relational mappers... love this typo. will use objectionable-relational mappers from now on. - objectionable - adjective, arousing distaste or opposition; unpleasant or offensive (definition source: Oxford Languages)
bob1029 4y ago
> Do I wish it was more functional? Absolutely. But it doesn't aspire to be that. I somewhat disagree about the aspirations. Have you tried out things like switch expressions and LINQ? You can apply functional concepts almost everywhere these days. Complex state machines can be modeled using 100% functional techniques.

sylens 4y ago

I have been teaching myself C# for the last two or three months (with the fantastic C# Player's Guide by RB Whitaker) and I have come to really enjoy working with the language. Discovering Properties, which combine fields and their accessor methods and can be auto-implemented and initialized, was the first moment I realized it might make my life a whole lot easier. I'm not entirely sold on its use for desktop GUI development yet (will watch MAUI closely) but I am eager to jump into Blazor and see if I can start to remove JavaScript from my stack.

redleggedfrog 4y ago

Shhhhh, you're giving away my precious secrets!

zumu 4y ago

Kind of an aside, but any one have a clue why those Haskell benchmarks are so slow? In my experience Haskell is relatively fast, so there must be some caveat that these test cases are hitting.

SZJX 4y ago

This article seems to be a lot focused on why you should be careful about using JavaScript for backend development. C#/.NET is one valid alternative, but many others surely also provide similar benefits and also avoid the pitfalls of JS. I agree that .NET is really solid and seems often unfairly seen in a negative light though.