9 ms·

Is .NET just miles ahead or am I delusional?

160 points by popcalc 3y ago

nopassrecover 3y ago
So I’ll say that I absolutely echo the post and general comments. I’ll also say, which I feel is a pariahable comment in 2024, that with 18 years of dev exp through the cycles of Web 1.0, 2.0, everything being a SPA, server-side rendering craze, and then wherever we are now, I just don’t get the hype around React for 95%+ of the scenarios it is used for. It is just so much more harder to get things done, to maintain them, to skill up. The complexity just feels superfluous. Like the Weekend at Bernie’s situation that is “agile methodologies” these days, my gut says this current world of tech must be far more shaped by economic and organisational factors. By contrast, on face value alone, something like Svelte feels so much closer to how programming used to feel.
- kayodelycaon 3y ago
  I don’t get the hype either. React makes some very difficult things easy but it consumes anything it touches. You’re stuck reimplementing basic browser behavior because React treats the browser as a compiler. It doesn’t extend the browser. React throws away decades of development and tooling. Before anyone starts screaming, you can use react for progressive enhancement. But I’ve never seen it used that way.
  - joseferben 3y ago
    imo remix (https://remix.run/ https://remix.run/) does a great job at that
  - deleted 3y ago
    [deleted]
  - jakjak123 3y ago
    I literally have no idea what you are talking about. What "basic browser behavior" are you reimplementing that React is blocking you from?
- ForHackernews 3y ago
  I think some version of HTMX / SvelteKit for bigger apps is the future. React is a dead-end, and it only lumbers on because so many people have staked their careers on it. It's the string theory of the webdev world.
  - pas 3y ago
    HTMX is nice if you really really really want to couple your backend to whatever happens on the frontend. And yes, yes of course, it makes sense for at least half of whatever anyone is doing nowadays. I'd even go as far as to say that HTMX with the microfrontends idea is the ideal for large organizations with microservices-like independentish features. ... that said, there's a good chance that eventually HTMX will become a WASM kernel capable of transmogrifying a well-annotated OpenAPI endpoint into some kind of UX-positive behavior. And at that point we can, again, finally free the forms from the frozen frontend frontier!
    - lurking15 3y ago
      I'm not even convinced that Javascript + JSON fat client architecture is decoupled. It hides the fact that the browser is for better or worse a hypermedia client.
      - pas 3y ago
        It's a spectrum! (Insert bell curve meme with "everything is connected" on the tails and "noo! that's too coupled" in the middle ! :D) It's also a lot of trade-offs in a big bundle. (How many people will work on the codebase? At the same time? Is the problem well-defined enough to agree on an API? How much "API evolution" are we expecting? Are there going to be wildly different user journeys based available based on state? Is this Roy Fielding persona in the room with us now? How experienced the developers are? What tools do they know well? How's the infra/devops/deployment story? Do we need to setup Maven and rebuild the whole J2EE JAR/WAR thing in order to change the CSS? Insert everything is an optimization problem meme! :`] ) And whatever stack a particular project ends up picking is just the current culmination of roughly two decades of very strong path-dependence, which itself is a result of a very weird non-cooperative speedrunning through various iterations of these problems. [0] And while the ecosystem will happily continue to churn the project will likely not have the luxury to rewrite everything every few years, so the developers ought to pick something they are comfortable with for the next X years. (And to solve for X we need to know whether this is a personal project or it's the current flagship darling of a soon-to-be multi-trillion dollar company...) [0] For example both Flash and Java have been sent to sleep with by JavaScript, because they were not able to coevolve with that scrappy thing which was initially thrown together by in 10 days. So it made a lot of sense to not pick JS, and to keep as much as possible on the server-side, or pick Flash for some amazing UX! But the JS engine was eventually secure and built-in to every browser and JS code could be delivered fast.
- pas 3y ago
  React is a great component-based (functionally pure-ish? puritan!) view library, but when all you have is a render() function things start to look like components even if they looked like something else before. And then, of course, a whole cottage industry sprung up around it, from create-react-app to hideous HOC form managers. It soon started to became a proper cult, attracting true believers who shunned types, who got burnt by just a bit too much webpack configuration craziness, and then VC money pured in and ... And now the king is dead, long live the king. All hail HTMX!
  - jakjak123 3y ago
    Conflating React with webpack is disingenuous at best.
- jakjak123 3y ago
  On the contrary, I think React still is fantastic, and I have been using it since 2015. I think you all have forgotten how terrible it was to get anything done without breaking things in the server side rendered apps of yesteryear. I remember, because I maintained one of those until 2021. Endless cycles of regression testing. Trying to make any of those pages client interactive, within two days you are longing back to something like React. In theory, you could introduce a little React on those pages, but since it is an older server side rendered app, there are no APIs to call, all the features are html pages that return mountains of markup. None of the css is consistent, and even a button is not a single button, its 25 slightly-almost-the-same-button. At least with React there is a good chance those would actually have ended up as the _same_ button component. In my opinion, the reason React still has staying power is the care with backward compatibility, and the fact that its very focused on being a View Library. State management and routing frameworks come and go, but those all live outside of React the library. React doesn't directly force you to have your CSS a single particular way. It's still mainly concerned about being a javascript library, even as JSX is quite far from JS, it is mostly fairly obvious how it ends up being plain JS.
  - JackMorgan 3y ago
    I agree, I recently had a client pay me to use ASP.NET MVC for a new website and it was _terrible_. So many easy things were not only hard, but the docs were just not there. It was extremely difficult to handle even basic layout changes. If I knew it really well, I still think it would have been slower than react to build, by an order of magnitude.
- galarzaalex 3y ago
  Sort of a newbie to agile/devops here but could you explain the comparison to Weekend at Bernie's? I only know the basic premise of the movie but can't follow how to fit agile methods vs older programming methods into the movie. Thanks!
  - grugagag 3y ago
    Bernie was dead but only two guys knew that, he appeared alive and well to everyone else.
- skeeter2020 3y ago
  Don't worry Svelte 5 will "rune" that feeling and pull you back into the React world.
  - josephg 3y ago
    Solidjs is hitting the spot for me lately. It’s basically react rewritten to actually use reactive views instead of virtual DOM diffing. Your code looks like react but the js bundle is smaller, simpler and faster. But if you aren’t interested keeping up with “JavaScript framework of the week”, you can do a lot worse than react.
rjbwork 3y ago
It's way ahead has been for some time. I saw it nearly 13 years ago in my internship and have done primarily .NET stuff in the interim. It's only gotten better with age, dotnet core and new features. There are gaps - data ecosystem is dominated by Java/Scala/Python. Numerical computing is dominated by Python (used to be R!). Microsoft has a decent story in their own ecosystem for the former. Their work on more numerical data types, generic math, and more are what I think is the start of bringing numerical computing to dotnet. Can't wait to see what the next 13 years hold.
- jemmyw 3y ago
  > saw it nearly 13 years ago in my internship and have done primarily .NET stuff in the interim If you've mainly done .NET stuff since you started out then I don't see how you can consider it well ahead or not. I've not used C# professionally since 2007 so I can't really comment either, other than that I've not wanted to go back to it, though I'm sure it's changed immensely. If you've not worked with other languages and tooling I don't think you're in a position to say what's best.
  - rjbwork 3y ago
    I've done some stuff in Node, Python, Java, Scala, R, TypeScript and some other stuff I'm sure, as well. But every time I'm on a project like that I just slog through, constantly reminded of what I'm missing. At this point I'm sure it's something like a "lingua franca" effect, but the point remains that I pine for comfy C# when I'm not using it. I will say I did quite like working with Scala the language, despite the rather uncomfy Java ecosystem/tooling. Probably the only direction I'd want to go to leave C#/.NET as my primary tools would be towards Scala/F#/Haskell/Clojure/Erlang, etc. but the market for those is comparatively tiny.
EliMdoza 3y ago
Have worked with .NET for several years and I'm happy to say is an insanely good option, and it's miles ahead of competition when it comes to serving a specifc profile of programmer. UX, APIs, docs, tooling are generally of very high quality. If as a programmer you do not ever want to get involved (good luck getting a change landed), and don't care to understand much of what's under the hood just want to read good docs and get back to your usecase, if you like automation as long as it's written by someone else (how many .NET devs can build a project without VS or even care to know?), if you're happy to confine your dev skills to the inside of a box defined by MSFT, there is no close second option.
- rjbwork 3y ago
  https://use.expensify.com/blog/ceo-friday-why-we-dont-hire-net-programmers https://use.expensify.com/blog/ceo-friday-why-we-dont-hire-n... this article again, but in HN comment form this time. yawn
  - devmor 3y ago
    I always find this article very funny. I do not really use .Net myself, only when I need to make a contribution to a project that is already written in it, but the few developers I know personally that use it are using it for incredibly nonstandard work. I know of an entire framework written in .Net that exists to hook into a proprietary, developer-hostile program and inject a full plugin ecosystem that exposes the protected memory and processing hooks of the program as a user-friendly API.
  - lupire 3y ago
    That article was a bad HN comment in blog form. The author even put a disclaimer apology on it.
  - spyke112 3y ago
    Wow, had not read that before. It seems really offensive to ordinary programmers that just want to get stuff done. I also find my peak productivity when using the .NET ecosystem, which after all is good for business.
bluescrn 3y ago
C# is great, IMHO. It's one of the main reasons that Unity did so well and continues to be so popular with indie devs even after all their mis-steps, and despite Unreal Engine offering better tech/tools in other important areas. It completely transformed game development. No debugging of memory leaks/corruption. Far less waiting for compiling/linking (and no header files!). Generics/Collections vs templates/STL. It's just vastly more productive, enabling tiny teams to do things that would have been impossible if everything had to be done in C/C++. (And if the alternative is not being able to make the game at all, then any performance down-sides are much less of a big deal)
a1o 3y ago
Are we conflating .NET with C# and ecosystem? My perception is lots of libraries that does serious work are just written in C and C++, in the future I imagine they will be in Rust and not C# - I am talking libraries you get from NuGet, lots of well maintained ones have a C# API that is a shell around something from elsewhere. Be it ImageMagick, lots of media decoding stuff or even proprietary things, like Flir. It's usually hard to find a library to do some work for you in C#, in NuGet, that is also maintained - you will have an easier time grabbing the sources and adding directly in your project so you can maintain it yourself as bug appears and debug it more easily. A lot of times the bug is the developer assumed everyone uses Windows. Most of time when using C# I am reinventing the wheel in it because of this. I also never had a C# project that used it exclusively.
- Hawxy 3y ago
  > Be it ImageMagick, lots of media decoding stuff or even proprietary things, like Flir. For ImageMagick specifically, there's a purist C# replacement (ImageSharp) that avoids the dependency on System.Drawing. > A lot of times the bug is the developer assumed everyone uses Windows. I can't say I've encountered this in years, most libraries are cross-platform out of the box with support for the major .NET 6+ targets (Windows, Mac, Linux).
- coldtea 3y ago
  >Are we conflating .NET with C# and ecosystem? .NET is C# and ecosystem, so we're rightly equating, but not conflating them.
  - lupire 3y ago
    (cries in VB.NET)
    - coldtea 3y ago
      Wasn't VB.NET basically a rework of VB to be a thin facade over the C#-oriented and tailored .NET semantics and libs?
- 3y ago
jonathanstrange 3y ago
I'm considering using C# and Avalonia for cross-platform GUI application development but what holds me back at the moment is that I find it hard to evaluate how much cross-platform this combo actually is, and how dependencies generally work in the ecosystem. I've read about a dozen different confusing .NET and NET Core versions, and it wasn't clear to me how to find out which packages from the package manager NuGet work on which platforms. All of it seems to be quite capable, but how Microsoft-centered is it?
- topbanana 3y ago
  I would go this way for cross platform native UI
  - deleted 3y ago
    [deleted]
- Hawxy 3y ago
  > it wasn't clear to me how to find out which packages from the package manager NuGet work on which platforms. As a default rule, any package you see that targets ".NET Standard 2.0" or ".NET 6+" is using the modern SDK and very likely works across all platforms. This will cover the vast majority of open source packages created/updated in the last 5 years. If a package only specifies '.NET Framework' then it'll be windows-only. Modern packages that are tied to a single platform will likely be named as such and will specify a target that locks it to that platform, ie `net8.0-ios16.0` for iOS.
  - jonathanstrange 3y ago
    Thanks, that's a super-helpful reply. Do packages with external C / C++ dependencies include binary blobs for platforms or compile them on the fly, or do they need to be configured for each platform? I mostly worried about standard stuff like Sqlite3.
    - Hawxy 3y ago
politelemon 3y ago
Where .NET is today, is where I had thought Java would be many years ago. I think there's something to be said about the consistency of C#'s programming API, design and syntactic sugar, as opposed to the smorgasboard of potluck-yolo interfaces that you're greeted with depending on what you're doing in Java. Linq is an interface that is barely present in other languages, despite being one of the most intuitive; Java's implementation focuses more on trying to say "we aren't C#, promise!" rather than providing a decent developer experience, and furthermore by giving itself a confusing name (Stream... Streams...). A recent addition, I'm glad that Java introduced templating and the design and intention behind it has so much potential compared to other languages, but in the end they've released it incomplete and "left as an exercise to the reader", which I think hurts. Where .NET isn't so strong is its package management, have a look at the maturity and security of maven packages compared to nuget. Yes, signing packages is a pain and yes there's a bit of a barrier to signing up and pushing your packages up to maven repository, but other languages will learn this lesson over time. Another area, relevant today, is data engineering. Python has shot ahead of everyone else thanks to its "there's one way to do it" philosophy, and thanks to pandas and its relatives. Just try writing parquet files in .NET and then see how simple and up to date it is in Python. Comparing web technologies though, well, Javascript development has and always will be a mess compared to any language ecosystem that you choose. You really don't have to try very hard. I think this will be the case for as long as web standards are in the hands of a few large vendors (who assume JS is the be-all and end-all), and the barrier to entry remains low.
whstl 3y ago
Some things like LINQ, Entity Framework and some features of ASP.NET MVC are still unmatched by most of the competition. The one thing I really miss is the simplicity and productivity of ASP.NET WebForms. It preceded Prototype, jQuery, PJAX, Turbolinks, Livewire, Hotwire, Next, Remix, Meteor. And it partially accomplished what lot of those only did later, but did so in the early 2000s. And it what was, IMO, a bit more "polished" and "finished" than most of what came later. It allowed us for making our own components, and had server-side rendered HTML but it allowed for richer interactions, the kind that we needed jQuery for a while, and today we need React components for. It had a vibrant community, but with the downside that it was 100% commercial. Visual Studio took care of everything we needed, it was indeed just about pressing F5 like someone said.
yawgmoth 3y ago
C# is hard to beat. ReSharper (and IntelliJ) really pushed Visual Studio to have a very high quality developer experience. But I don't miss csproj files, even though they no longer enumerate the contents of the project. Ugh, the conflicts.
pdimitar 3y ago
It's not difficult being in the top 5-10 inside the lower league. So I'd bet on "he is delusional". When .NET gets a proper M:N parallel runtime it's when they will even enter the competition. They are not even in it right now. Golang is miles ahead of .NET and it's far from many people's favorite tech.
- Xeamek 3y ago
  They won't because they already have async/await
  - pdimitar 3y ago
    Good, they have the first 3% covered. It's a start.
- martindevans 3y ago
  There was a "green thread" experiment for dotnet a while ago, here is the conclusion: https://github.com/dotnet/runtimelab/issues/2398 https://github.com/dotnet/runtimelab/issues/2398
  - pdimitar 3y ago
    Yeah, I saw that some time ago. Their conclusion is basically: "it's hard to integrate with the current ecosystem so we're giving up".
  - neonsunset 3y ago
    He doesn’t want to read all the research text, especially if it debunks his assertions. Your effort, although appreciated, is wasted on this kind of person.
    - pdimitar 3y ago
      I've read it. It was not impressive. They prioritized backwards compatibility which is of course their prerogative. But that's not how you progress. Having proper M:N parallel runtime is mandatory these days and it baffles me that there people who are still not sold on it. I take it they have jobs and tasks where it isn't necessary but it's an interesting question to ask: for how long?
high_na_euv 3y ago
Yes, .NET Lang and ecosystem is Miles ahead when it comes to almost everything except perf and fancy projects like kernel/db engine/embedded/fw I worked across various tech stack lvls - firmware, tools like compilers and web apps Ive used c#, c, cpp, js and C#s ecosystem was by far most robust and sane to work with C and CPP's std lib is fucking joke in compare to c#s Not even Talking about Lang design itself Id take dotnet cli with built in package manager, compiler, test Runner, crossplat publisher and many more, any Day over anything else
- vitorsr 3y ago
  Curious - there is one unnoticed comment on the thread that reminds me of my experience: > I feel the opposite. Was trying some number crunching, ok net doesnt have an fft. > What about digital filters... well... lacking > Displaying scientic graphs, like matplotlib. Nope, there might be a commercial package, but I didnt get a budget. As someone trying to develop numerical “enterprise” applications in the most boring, maintainable and longevous stack as possible, am I to write and maintain my own foreign function interfaces?
  - neonsunset 3y ago
    I don’t think this is a practical reality though. There is very good math and SIMD APIs for solving these kinds of problems natively, and finding decent bindings is just a matter of using search on nuget and GitHub. And given how dynamic the progress has been, “not possible” changing to “first class” can happen within a year or two.
    - aragilar 3y ago
      The question is then, why not use the native language, or a language where the binding are well-established (and not buggy-as-hell, as is the case with JS)?
asp_hornet 3y ago
> Professionally I've only ever worked in c# code bases. Pretty much answered their own question in sentence one. In my opinion OP is delusional. I worked in .net for 13 years and was stoked to leave. The layers of indirection, obtuse abstraction and over application of design patterns in “idiomatic c#” is preposterous.
- danielovichdk 3y ago
  Having worked professionally with .net for +20 years I have to admit that you have a good point. There are a lot of dogmatism tied to the platform, it's community ecosystem sucks and there is no real lust to go further than what Microsoft offers. On the other hand, you can easily have a programming career in .net alone. Its not going away the next 30 years.
  - asp_hornet 3y ago
    Well said. Its nothing to do with the language or tooling, just this weird ingrained dogma. > On the other hand, you can easily have a programming career in .net alone. Its not going away the next 30 years. Not to mention if a service offers an official client or SDK, C# is almost always on that list. That is awesome.
- andyjohnson0 3y ago
  > The layers of indirection, obtuse abstraction and over application of design patterns in “idiomatic c#” is preposterous. I don't think this is a problem that is specific to .net. These issues will be found in many large codebases built on platforms that are popular for enterprise development, such as Java.
pjmlp 3y ago
Not really, it is a great development experience, but so is the Java ecosystem, note the stress on ecosystem and not language grammar. Also LINQ that so many on the thread are salivating about, were already present in Smalltalk and Common Lisp collections, were influenced by ML languages and the time Erik Meijer from Haskell fame was part of Visual Basic team. See "Confessions of a Used language Salesman: Getting the Masses Hooked on Haskell". Nowadays busy with Scala and Kotlin. And since I made the reference, Java and .NET IDEs, still don't offer everything that Smalltalk or Common Lisp/Lisp Machines/Interlisp-D were capable of, and yes they also offer stuff that wasn't possible back then.
- SideburnsOfDoom 3y ago
  > Also LINQ that so many on the thread are salivating about, were already present in Smalltalk and Common Lisp collections I think that it's clear that C# in particular was never intending to originate new programming concepts; it was never a research language. It is a commercial language, and aims to take and popularise the best ideas from such research languages, and package them for coders who work in businesses. As such, there has to be some evidence for that idea already. It must be demonstrated to be effective. You can assume that any good idea in C# already existed somewhere else beforehand, even if not well known. It's not there to break conceptual ground or be in the first segment of the innovation curve.
  - mrkeen 3y ago
    > I think that it's clear that C# in particular was never intending to originate new programming concepts; it was never a research language. This is meaningless.
  - Xeamek 3y ago
    Wasn't c# the first to introduce the async() concept though?
    - paavohtl 3y ago
      I think it was the first language to specifically introduce the async and await keywords, but it wasn't even the first language on the .NET platform to support the programming model - that honor goes to F#. See https://tomasp.net/academic/papers/async/async.pdf https://tomasp.net/academic/papers/async/async.pdf
ludston 3y ago
Miles ahead of what? There is a reason that we write javascript in the browser and operating systems in c or c++, and telco services in erlang, and academic works in python rather than in C# or F#. .Net is the best at being .Net I guess. It has loads of libraries that are both good and terrible. I think the .Net web ecosystem is a god-awful mess of magic DSL's and configuration, and more and more sugar syntax is being added to C# to make it harder and harder to on-board new developers, and .Net Core deciding to break backwards compatibility is probably costing my org 10's of millions of dollars. But I guess I don't need to type as much as I did 10 years ago.
- throwaway2990 3y ago
  [flagged]
  - omnicognate 3y ago
    I can't speak for the person you're replying to but I have long professional experience with .NET and agree with what they said. I left my last job specifically to get away from it.
    - throwaway2990 3y ago
      [flagged]
      - omnicognate 3y ago
        > The OP and yourself must struggle with programming. shrug "Everybody who doesn't share my language preferences must be bad at programming." Enlightened thinking there.
      - BlueTemplar 3y ago
        It's more a fields thing. Biologists are all over R, physicists - Python, &c.
    - criddell 3y ago
vstenvik 3y ago
«I’ve only ever worked with C# and .NET» «Is .NET better than anything else?» Wy do I keep seeing posts like this? .NET seems like a religion to some.
- mrkeen 3y ago
  I'm surprised I don't see more. They have a non-negligable market share & people always say their language is the best.
  - Ezhik 3y ago
    I assume it's because .NET developers go home after their work day and do other stuff instead of posting about computers online.
    - SideburnsOfDoom 3y ago
      YMMV. For my co-workers, there is definitely an element of "go home after their work day to the wife and kids." Unless they're in the pub. But personally, when I post online about any topic, it's mostly because I find the whole "my language is better than yours" thing childish, arrogant, impolite and tiresome. I try not to have strong opinions about technologies that I don't know (and be honest, 99% of us don't know 99% of the technologies that exist) and to produce facts about ones that I do know.
coldtea 3y ago
Well, the other languages are what .NET would have been too if it only had 1/100th the resources, no dedicated IDE, no first class platform support, and no thousands-strong paid teams dedicated to quality of life improvements and tooling...
jpgvm 3y ago
IMO the .NET and JVM camps are well ahead of the rest when it comes to ecosystem quality/tooling/support/longevity. JVM + k8s + PostgreSQL is my current Boring Stack of choice but I think you could be equally justified with .NET.
jeffalyanak 3y ago
As someone who has worked with a very wide variety of languages, libraries, and frameworks over my career, I have encountered this and the inverse nearly every time I've learned a new language. Most languages with some amount of popularity have at least a handful of features that I wish other languages did as well and that can feel, at least in the moment, to be completely obvious and critical features that every language needs.
jbjbjbjb 3y ago
I agree apart from htmx recreating mvc, I don’t think mvc can do what htmx does but you can certainly add htmx into your mvc or razor pages
nottorp 3y ago
Most "new" languages are sponsored by orgs only interested in server side, where UI is done in the browser. Do you think Google cares about doing UIs in Go? So of course anything made before the browser became the local platform will be millions of miles ahead for developing local applications. Add to that that javascript libs seem to be done by a bunch of people rediscovering every screw and wheel on their own...
- coldtea 3y ago
  Most new languages aren't that featured and well-tooled for the server side either.
wkat4242 3y ago
Of Java, the most comparable platform, well yes I would say so. Java is a terrible mess.
izoow 3y ago
> Build stuff in .net is so easy, I just press F5 and I don't even know what happens, it just works I started out with C# as de-facto my first programming language and this is exactly the thing I didn't like. I had no idea what Visual Studio does and I was lost without it. Later moving onto C and starting from the ground up with just a text editor and a compiler was quite eye opening.
- plaidphantom 3y ago
  For me, .NET Core has been largely solving this problem over time. In classic .NET Framework it was nearly impossible to make something without Visual Studio's arcane templates. The `dotnet` command simplifies a lot of that, and projects have a lot less boilerplate.
- mrkeen 3y ago
  > > Build stuff in .net is so easy, I just press F5 and I don't even know what happens, it just works Sounds like PHP.
  - omnimus 3y ago
    Xdebug (php debugger) is not very popular imho. I think because PHP devs are most likely JS devs too and the developer experience becomes different for every language. Logging works everywhere.
    - mrkeen 3y ago
      Sorry, I didn't mean PHP just works. I mean "it just works" is what PHP devs say about their stack.
- lupire 3y ago
  Sure, C/C++ is interesting not learn how the toolchain works, but that's a different goal from successfully compiling software with large dependency trees.
- constantcrying 3y ago
gred 3y ago
Besides the one mention of Go, he seems to be comparing C# to JavaScript/TypeScript. C# is decent, but the JS/TS ecosystem does not set a high bar for comparison...
- creshal 3y ago
  Yeah, the comparisons seem to be fairly… one-sided. The people who love C# for being better than "everything else" seem to only have dealt with JS/TS/React and C(++), and not any of the actual competitors to C#.
JackMorgan 3y ago
I feel this way about F#. It's so much better than C#, I'm constantly missing things from it when in C#. I go back to C# and try to explain the missing features but just get blank stares, because it's hard to imagine a feature you've never seen before. C# is a fine server-side language, but to be honest it's only gotten there since .NET Core worked on Linux. I still have to work sometimes on crusty old framework projects that constantly break. Every week these teams are chasing down some MSBuild version error, or are dealing with an issue caused by the WCF SOAP endpoints, or some home grown ORM crap because EF was absolutely terrible until recently. So many build errors because the code runs on a windows server that just got patched and for some reason the code won't run. There's a real toxic cultural effect too. I know plenty of .NET projects that just collapsed because they followed the crowd and designed a complete mess of lasagna. I'm talking 10+ layers just to get a record out of the database and sent to an API. So many classes like "ManagerRepositoryFactoryFactoryImpl". So much indirection with event pipelines and listeners and DI. I've seen an audience give a standing applause to a C# talk where the main point was "more than one function in a file causes bugs, so every function should be in it's own file". There's so many niche cultures that celebrate what I'd call "bad code". And it's hard to buck that trend when a big chunk of your hiring pool has bought into a terrible design philosophy. Not everyone, plenty are wise and see it as nonsense, but plenty have bought into some really weird ideas, see it not work, but then blame the implementation not the philosophy. Then they move along to the next project, brimming with holy zeal to "fix" it with design patterns and event sourcing. But yeah, today, coming into it fresh, .NET Core is pretty rad. I manage three client projects on it, and it's pretty great. It's really smooth, builds great, is fast enough for CRUD, EF is decent and I can write raw SQL for the 20% of queries that need it. I can autogenerate swagger docs with swashbuckle, then autogenerate my typescript API consumer from that. I've got my code building and running in Linux docker containers and it all just works and it's fast enough for what I need. But it's forgetting a lot of history and culture to assume it was always this good. It definitely was the worst back in 2003-2014. Keep in mind it used to be closed source and you had to pay through the nose for Visual Studio just to build anything at all! IIS and VSS from 2008 still give me nightmares. Up until about 2020 I recommended people use other tools if they were starting a new project. Today, it's my first recommendation for a backend. (Also I think Visual Studio still is really lacking in features, so I use Rider instead and it's awesome. But to each their own)
KronisLV 3y ago
Currently using .NET and ASP.NET for the API of a project that I'm working on, overall it's a pretty lovely experience, especially with the JetBrains Rider as my IDE. Having worked with Java in the enterprise in the past, it feels like a more focused and sometimes more coherent experience (vs the more decentralized nature of Java), that now thankfully runs fine on Linux as well, don't even need to hope that Mono is good enough anymore. It actually feels pretty close to Java in some respects, for example LINQ and the Stream API are both pleasant to use and let me be pretty productive. Entity Framework Core is great, the way how they fetch related data is straightforwards: https://learn.microsoft.com/en-us/ef/core/querying/related-data/eager https://learn.microsoft.com/en-us/ef/core/querying/related-d... I also really like the ability to use split queries, when needed: https://learn.microsoft.com/en-us/ef/core/querying/single-split-queries https://learn.microsoft.com/en-us/ef/core/querying/single-sp... You can even scaffold your entity mappings from an existing database and manage database migrations separately (which I feel is a must unless you want to pour hours upon hours into learning yet another JPA-like), it's nice when something like that exists in a given ecosystem: https://blog.jetbrains.com/dotnet/2022/01/31/entity-framework-core-inside-rider-ui-way/#existing-database-scaffolding https://blog.jetbrains.com/dotnet/2022/01/31/entity-framewor... Some of the stuff in the ecosystem is also really nice, like using ActionBlocks from Dataflow for simple queues and task scheduling is very easy to get started with and pretty pleasant: https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.dataflow.actionblock-1?view=net-8.0 https://learn.microsoft.com/en-us/dotnet/api/system.threadin... Honestly, most of the docs that I've come across are rather pleasant and there's plenty of code examples to be had and even LLMs have enough codebases out there to be trained on and give decent output, in addition to the regular autocomplete in the IDE. Even some third party stuff like CsvHelper is really well put together: https://joshclose.github.io/CsvHelper/getting-started/#installation https://joshclose.github.io/CsvHelper/getting-started/#insta... That said, I've had issues where trying to deserialize incoming JSON requests ([FromBody]) lead to the whole object being null, due to it not matching the fields 1:1 or violating some nullability constraint, however that happened without a clear error message or as much as a warning in the logs, which felt insane and wasn't very discoverable. Now I just use JObject as the parameter and deserialize at the top of the controller method. I've also run into some ecosystem issues where the OpenAPI codegen was a bit lacking and wouldn't actually generate code that works, but maybe that's because the spec was bad: https://openapi-generator.tech/docs/generators/csharp https://openapi-generator.tech/docs/generators/csharp I could also not get AutoMapper (https://docs.automapper.org/en/stable/index.html https://docs.automapper.org/en/stable/index.html) working satisfactorily, so for now I'm stuck writing mappers by hand with said autocomplete sometimes doing it for me. There were issues with the runtime being unable to register the mappers or something like that, it was a while ago. Overall it felt like the MapStruct library in Java did everything better: https://mapstruct.org/ https://mapstruct.org/ On the other hand, I haven't had any of the Spring Boot DI related headaches (needing @Lazy sometimes) with ASP.NET, things there seem way more straightforwards and you clearly define whether something should be a Singleton or Scoped and the rest... just gets out of your way and works. Sadly, there have been very hard to track down cases where I try to do a _dbContext.Add(someEntity) and then when I do a save with just the fields in that one entity changed, the performance absolutely seems to slow down to a crawl. Adding _dbContext.ChangeTracker.AutoDetectChangesEnabled = false seemed to help, but I am still not entirely sure what lead to that behavior, the temp directory on my Linux box also started filling up very rapidly, yet the logs had nothing of use, definitely seems like something I'd need to investigate properly. Overall, .NET and its ecosystem is pretty good in most cases. Well, at least modern .NET. Also, it being used in gamedev is cool, for those who care about that sort of thing, I wonder why jMonkeyEngine never really took off.
switch007 3y ago
There's a lot of fanaticism around Blazor. I knew before clicking it would in part be about Blazor. And I knew they wouldn't mention where its use is suboptimal Anyone else find c# off-putting to read? Seems like so much white space and Capital.Letters(). On top of the font rendering and default font in visual studio which I find a bit ugly. And blurry iirc Edit: also, .net just has "cost center" vibes which I think puts off a lot of people. It may be great tech but we don't want to work at those kind of companies that use it
- JackMorgan 3y ago
  Oooof "cost center vibes" is so accurate. Not entirely true, I've worked some pretty damn cool .NET companies. But yeah, a lot of them are not places I want to work.
mythz 3y ago
The technical platform is strong but the ecosystem is weak, so it's advanced in some areas but lacking in others. Basically if a technology can't be hosted on Azure or monetized in some other way it doesn't get first class attention from MS and therefore rendered a niche since .NET's 3rd Party OSS ecosystem is weak. But the C# language is a well-designed modern statically typed language that enjoys best in class IDE tooling from JetBrains and Microsoft. The .NET Runtime is also a stellar performer, especially for a productive high-level language like C#. It also has some great tech that doesn't exist elsewhere, like Blazor which allows you to build entire websites (backend and frontend) with C#, although there are tradeoffs for pages needing interactivity where you can choose between Blazor Server which maintains a stateful rendering session on the server or WASM which requires a large download with slower initial start times. Personally I avoid both Blazor Interactivity options and go with Blazor Static Rendering enhanced with progressive JS which avoids both tradeoffs whilst enjoying great SSR/FCP performance and SPA performance without SPA complexity with the intelligent fine-grained updates in Blazor's enhanced navigation [1]. Blazor's Streaming Rendering is also the most elegant solution I've seen for delivering a live auto updating page with minimal effort [2]. [1] https://servicestack.net/posts/net8-best-blazor https://servicestack.net/posts/net8-best-blazor [2] https://learn.microsoft.com/en-us/aspnet/core/blazor/components/rendering?view=aspnetcore-8.0#streaming-rendering https://learn.microsoft.com/en-us/aspnet/core/blazor/compone...
- JackMorgan 3y ago
  Frankly, having lived and upgraded many projects through asp web forms, wpf, silverlight, and razor, I've decided "never trust .NET UI libraries to survive". So I'm avoiding Blazor entirely and just sticking with the react ecosystem. I trust that 100x more than I trust Blazor, partly because the ecosystem and user base is 100x larger. I won't be the slightest bit surprised to see Blazor tossed in the trash in three years, but I'll eat my hat if react is gone by then. Sure, maybe it's popularity will wane for some other similar library, in which case I'll switch to that. But I'm sticking with the beaten path on the front end.
  - cjk2 3y ago
    Ha we still have all of those (apart from Silverlight) in production. A number of years ago I had to get an overexcited architect to not rewrite everything in Silverlight. Front end .Net is a shit show. You are right to stay the hell away from it.
deleted 3y ago
[deleted]
cjk2 3y ago
I've been working with .Net from day one on large high traffic projects. No. It's overcomplicated, moves so fast that the maintenance overhead is insane, the open source ecosystem is incredibly volatile and immature and the attention of Microsoft is akin to a schizophrenic monkey. The tooling provided by Microsoft is buggy and unreliable and half the platform abstractions (certificates for example) are fucked up messes which cause endless deployment problems. Not only that you're working in a graveyard of abandoned projects and frameworks and legacy 3rd party components you still depend on because Microsoft sold everyone the ideology and then threw it out of the window or changed direction rapidly. Oh and don't get me started on C# which started off reasonable but is now the car Homer Simpson designed https://simpsonswiki.com/wiki/The_Homer https://simpsonswiki.com/wiki/The_Homer All this shit however did pay my mortgage off.
- criddell 3y ago
  It’s possible that everything you said is 100% true and it’s miles ahead of everything else.
  - cjk2 3y ago
    You’re not wrong from a historical perspective. It was that or PHP for me. I chose well. I would not choose it now so I don’t think it holds any more. Go will become the next .net in 20 years.
  - lawn 3y ago
    Logically possible yes, but that's not the reality.
  - dagaci 3y ago
    Haha, thats exactly i thought! But my experience is the opposite of everything he said!
mrkeen 3y ago
'Ahead'. Is there anything from .NET that has inspired features in other languages?
- spacechild1 3y ago
  Async/await?
- dagaci 3y ago
  Linq
  - mrkeen 3y ago
    That would put Haskell 'ahead' and .NET 'behind' in this example. But did you have a different language in mind? One that followed .NET's Linq?
- m0llusk 3y ago
  Interesting framing. In my opinion it is sort of the reverse. The structure of .NET was conceived at a time when Java and Objective-C were redefining how to relate to runtime. As a result it is .NET that picked up the inspired features from other languages, and that arguably has put .NET ahead of the languages that inspired it.
- tester756 3y ago
  https://willspeak.me/2021/11/24/red-green-syntax-trees-an-overview.html https://willspeak.me/2021/11/24/red-green-syntax-trees-an-ov... >The idea of red / green syntax trees initially came from the Roslyn C# compiler. It was adopted by Swift in their libsyntax implementation. The Rust Analyzer project built further upon this with the Rowan crate. Rowan extends the model of red-green syntax trees with the idea of dynamically typed nodes. Also probably this: https://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://joeduffyblog.com/2015/11/03/blogging-about-midori/ >Midori was a research/incubation project to explore ways of innovating throughout Microsoft’s software stack. This spanned all aspects, including the programming language, compilers, OS, its services, applications, and the overall programming models. We had a heavy bias towards cloud, concurrency, and safety. The project included novel “cultural” approaches too, being 100% developers and very code-focused, looking more like the Microsoft of today and hopefully tomorrow, than it did the Microsoft of 8 years ago when the project began.
addicted 3y ago
The article is right. .NET is way ahead of anything in the front end world. But that’s because the front end world is crap. React Server Components, the new great idea on the primary front end framework is recreating ASP.Net Web Forms. Badly. At least Web Forms was fully statically typed and provided easy embedding of simple JS instead of having to convert everything to the “React Way”. HTMX sounds great and is very good in many ways until you realize it’s little more than a desperate cry to go back 15 years in front end programming because front end development has become such a shit show over the past decade+. Pretty much everything in modern front end development is reversing whatever was done over the past decade and a half because pretty much everything done over the past decade and a half was done to compensate for all the problems with browsers. Now that browsers are becoming decent programming runtimes, and internet speeds and latencies have improved, you don’t need stuff like jquery to compensate for every browser doing things differently, or the virtual dom to compensate for awful DOM performance, or Lodash to compensate for terrible JS engine performance, etc.
jonathanlydall 3y ago
Like other highly successful products of Microsoft (e.g. Windows, Microsoft 365), I get the feeling that C# and .NET developers are a largely "silent majority" who may not be getting posted on or talking as much on places like HN compared to developers of alternative options, but this is mostly because they're just getting stuff done with minimal fuss or issue. I also get the sense that in the U.S. because Java was around for a bit before .NET, it got a head start in terms of market penetration and embedded in a lot of places, so when .NET arrived, even if it was better in some regards, it wasn't enough to justify throwing away investment that had already occurred in Java. As Java was overall more used in the U.S. hiring Java developers was easier, further cementing Java as more popular over .NET. Meanwhile in other places in the world where there had been less Java investment before the arrival of .NET, it is much more prominent as is the available hiring pool of .NET developers. As someone who's been using C# for 12 years now, I have always felt incredibly productive with it and even though I never especially felt the experience was bad, it seems to somehow continuously provide some pretty great quality of life improvements. As with any tool, it's not appropriate for certain kinds of problems, but outside of things like operating system/driver programming or super performance critical code, it is almost always a perfectly fine solution and you won't have any issue hiring developers for it going forward.
- subsection1h 3y ago
  > C# and .NET developers are a largely "silent majority" who may not be getting posted on or talking as much on places like HN compared to developers of alternative options, but this is mostly because they're just getting stuff done with minimal fuss or issue. Or maybe C# and .NET developers are people who learned to program solely to earn a paycheck and they don't chat about programming because they're not computing enthusiasts, which is my conclusion based on the fact that all but one of the C# developers I've interacted with in person are Windows users who have as much experience with other operating systems as one would expect from people who aren't computing enthusiasts.
  - tasuki 3y ago
    Harsh! I have similar experiences/feelings.
conaclos 3y ago
We are only human and thus mostly ignorant. We keep surfing between solutions, claiming that one is better than the other and realizing the problem of our preferred solution and moving on to another or even the previous one. As a community this creates trends. Because we have separate communities, we can even see repeated trends under different names.
peter_retief 3y ago
Miles ahead in what race? Honestly cannot think of any application that I would willingly choose .NET for. I know people who love .NET but they seem to all work for large corporations, no one in startups or doing anything I find interesting seem to use it. Maybe I have missed something?
throwaway13337 3y ago
I'm a chronic framework/language jumper who recently switched some projects to dotnet in production, but without a previous Microsoft-flavored background. I often read hn comments to figure out what I'm missing and what to look out for here. I'm sure this thread will be searched for by people like me in the future. In that spirit, here's my take. Pros: * Best performance of any language without memory management. This is true on Linux, and its memory footprint isn't bad either - especially with AoT. * Best standard library with great docs covering 90% of what you want in most modern apps. * Development tooling that is just awesome with rider. Easily navigate and understand the source code of imported libs. * A reasonable syntax that doesn't make weird decisions because of deep dogma. It beats Go, for me, for instance, because it uses exceptions, generics, and LINQ. This makes the code readable and reasonable to write. I know this is controversial. * Ridiculously simple deployment. No Redis - jobs and cache are practical in-process. Due to its performance, I don't even front it with nginx. Upload a binary on a fresh VM, supervisor and go. A tiny shell script. Cons: * Its object-oriented design. The way files are organized in Go makes a ton more sense and doesn't feel as heavyweight. Also, the addition of records instead of real, validatable value types was a huge missed opportunity. * Went heavily into async/await - indeed, it was the pioneer. Thread-per-connection, co/goroutines, or green threads are actually better models for most projects. I understand the issue with overhead. But the weird call stacks, and footguns inherent are definitely not worth it. * Compile time sucks. This is the biggest for me. Having a subsecond reload time is essential to a pleasant code flow for me. Hot reloading has too many holes to be practical and this seems like a blindspot. No one seems to mind but golang, node, and python are all much better here. My background: I wrote some successful SaaS web apps in Django and transitioned some to dotnet for maintainability. I'd previously used C# also as a game developer with Unity. But I bounce around a lot of tech. I'm in a unique situation as a solo project dev with a long time horizon. I can care about longevity, speed, and ease uniquely. I don't have to worry about employment opportunity of a stack, for example. Right now, I'm trying to decide between TypeScript/node and continuing with dotnet for my next project's backend. The backend I wrote in dotnet remains my most stable. It's beautifully simple to manage in production. If only they could make hot reload not feel so bad.
- neonsunset 3y ago
jonnat 3y ago
Whenever this comes up, my thought (admittedly from an outsider perspective) is that people can say that .NET is far ahead in the same way some may say that Oracle is far ahead: Both are enterprise focused technologies that were built using a sales-driven design, trying to check as many feature boxes as possible to help sales teams in their pitches. The problem is when you've been to too many sales pitches and start to equate box-checking with product quality.
baerrie 3y ago
Yeah, it has too many things. Working in mature C# codebases is like wading through a swamp, so many abstractions with long and obscure names that makes holding a mental model of the system in your head twice as hard as TS.
scapegoat2 3y ago
in my experience, you can be very productive with dotnet if you stay on the well-traveled path. I would not use it for private projects, but i like the opinionated defaults in a small team org setting. If your org is full on Microsoft ecosystem (Azure AD, Windows Server, ..) anyway, it fits in very well. you don't have to be clever or reinvent the wheel because 90% of standard use cases are well documented in microsoft docs. it has a steep learning curve though (e.g. auth in aspnet).
mhh__ 3y ago
I want to like C# but the spectre of java in there is really obvious to me at least. It feels like a language made by someone who wants to sell developer tooling
orwin 3y ago
To be fair, LINQ is quite a good idea. Not new at all, i think the first thing any serious lisper do on a DB-heavy project is writing a query/select macro that does exactly the same thing, except better (sadly, i do mean "writing" the best way would have been to treat it the same as the loop macro, but on the other hand, it's like 2 LOC for a quite complete select macro. Never thought of that, but maybe the conciveness of common lisp plays against code reuse)
- lispm 3y ago
  I would just use an existing Common Lisp library, which provides query and select.
probably_jesus 3y ago
[flagged]
deleted 3y ago
[deleted]
jinushaun 3y ago
I used C# and .NET professionally at a previous job. While I enjoyed writing modern C# that emulates python/ruby/JavaScript idioms, I didn’t like .NET the library. As C# gets more modern, you still have to interact with the ancient .NET library which seem like a relic from the 90s
dgellow 3y ago
I love that with modern .NET you can get started in a few minutes: 1. install the .NET SDK 2. install VSCode 3. install the C# Dev Kit vscode extension 4. run ".NET: New Project" in vscode That's it, you're done. You can build, run, test, debug in vscode. Or use the dotnet CLI if you prefer. It's so much better than having to install Visual Studio as a whole before you can try out the language/runtime, and that works cross-platform.
- neonsunset 3y ago
  You do not need DevKit, just plain C# extension.
shepherdjerred 3y ago
> Its not really typesafe, more like typescript where its autocomplete, but not real. That is a _wild_ complaint. Just like any language, TypeScript does give you type safety if you use it correctly, e.g. typing at the boundaries, avoiding casts/any, etc.
moribvndvs 3y ago
Wait until they find out how much stuff originated outside of dotnet. I recall a time when a significant portion of the dotnet community did not really venture outside of their ecosystem and were shocked to find that MS just adopted emergent or popular patterns, technologies, and technologies, as if nothing existed until MS built it[0]. The height of this attitude was before dotnet, MS, and really the proprietary software community had fully embraced open source software. I’m unsurprised to find it’s not entirely gone, but I hope it’s fast on its way out. While it’s great for any ecosystem to adopt new technologies and techniques into their stack, it’s detrimental to think a concept doesn’t exist until your preferred vendor releases their interpretation of it. Beyond the disregard for the effort of people who created and maintain the thing originally, this myopathy also leaves a community unable to gauge the quality of the adaptation to give feedback or avoid the thing altogether. This can and has lead to walled gardens, fractured protocols and standards, poor interoperability, and stagnation in the industry. Less dramatically, you might just be missing out on stuff that’s way cooler. [0] https://youtu.be/J6hijsqO8H0?si=t11hHPBpd9Z2jye0 https://youtu.be/J6hijsqO8H0?si=t11hHPBpd9Z2jye0
bitcharmer 3y ago
Is this a troll post?
mhh__ 3y ago
Another point about C# - I have never, ever, seen anyone call any C# code beautiful.
- neonsunset 3y ago
  Can you give an example of code you consider beautiful?
samoit 3y ago
My rule of thumb is: if it belongs to Microsoft avoid it.

160 points by popcalc 3y ago

So I’ll say that I absolutely echo the post and general comments. I’ll also say, which I feel is a pariahable comment in 2024, that with 18 years of dev exp through the cycles of Web 1.0, 2.0, everything being a SPA, server-side rendering craze, and then wherever we are now, I just don’t get the hype around React for 95%+ of the scenarios it is used for. It is just so much more harder to get things done, to maintain them, to skill up. The complexity just feels superfluous. Like the Weekend at Bernie’s situation that is “agile methodologies” these days, my gut says this current world of tech must be far more shaped by economic and organisational factors. By contrast, on face value alone, something like Svelte feels so much closer to how programming used to feel.

kayodelycaon 3y ago
I don’t get the hype either. React makes some very difficult things easy but it consumes anything it touches. You’re stuck reimplementing basic browser behavior because React treats the browser as a compiler. It doesn’t extend the browser. React throws away decades of development and tooling. Before anyone starts screaming, you can use react for progressive enhancement. But I’ve never seen it used that way.
- joseferben 3y ago
  imo remix (https://remix.run/ https://remix.run/) does a great job at that
- deleted 3y ago
  [deleted]
- jakjak123 3y ago
  I literally have no idea what you are talking about. What "basic browser behavior" are you reimplementing that React is blocking you from?
ForHackernews 3y ago
I think some version of HTMX / SvelteKit for bigger apps is the future. React is a dead-end, and it only lumbers on because so many people have staked their careers on it. It's the string theory of the webdev world.
- pas 3y ago
  HTMX is nice if you really really really want to couple your backend to whatever happens on the frontend. And yes, yes of course, it makes sense for at least half of whatever anyone is doing nowadays. I'd even go as far as to say that HTMX with the microfrontends idea is the ideal for large organizations with microservices-like independentish features. ... that said, there's a good chance that eventually HTMX will become a WASM kernel capable of transmogrifying a well-annotated OpenAPI endpoint into some kind of UX-positive behavior. And at that point we can, again, finally free the forms from the frozen frontend frontier!
  - lurking15 3y ago
    I'm not even convinced that Javascript + JSON fat client architecture is decoupled. It hides the fact that the browser is for better or worse a hypermedia client.
    - pas 3y ago
      It's a spectrum! (Insert bell curve meme with "everything is connected" on the tails and "noo! that's too coupled" in the middle ! :D) It's also a lot of trade-offs in a big bundle. (How many people will work on the codebase? At the same time? Is the problem well-defined enough to agree on an API? How much "API evolution" are we expecting? Are there going to be wildly different user journeys based available based on state? Is this Roy Fielding persona in the room with us now? How experienced the developers are? What tools do they know well? How's the infra/devops/deployment story? Do we need to setup Maven and rebuild the whole J2EE JAR/WAR thing in order to change the CSS? Insert everything is an optimization problem meme! :`] ) And whatever stack a particular project ends up picking is just the current culmination of roughly two decades of very strong path-dependence, which itself is a result of a very weird non-cooperative speedrunning through various iterations of these problems. [0] And while the ecosystem will happily continue to churn the project will likely not have the luxury to rewrite everything every few years, so the developers ought to pick something they are comfortable with for the next X years. (And to solve for X we need to know whether this is a personal project or it's the current flagship darling of a soon-to-be multi-trillion dollar company...) [0] For example both Flash and Java have been sent to sleep with by JavaScript, because they were not able to coevolve with that scrappy thing which was initially thrown together by in 10 days. So it made a lot of sense to not pick JS, and to keep as much as possible on the server-side, or pick Flash for some amazing UX! But the JS engine was eventually secure and built-in to every browser and JS code could be delivered fast.
pas 3y ago
React is a great component-based (functionally pure-ish? puritan!) view library, but when all you have is a render() function things start to look like components even if they looked like something else before. And then, of course, a whole cottage industry sprung up around it, from create-react-app to hideous HOC form managers. It soon started to became a proper cult, attracting true believers who shunned types, who got burnt by just a bit too much webpack configuration craziness, and then VC money pured in and ... And now the king is dead, long live the king. All hail HTMX!
- jakjak123 3y ago
  Conflating React with webpack is disingenuous at best.
jakjak123 3y ago
On the contrary, I think React still is fantastic, and I have been using it since 2015. I think you all have forgotten how terrible it was to get anything done without breaking things in the server side rendered apps of yesteryear. I remember, because I maintained one of those until 2021. Endless cycles of regression testing. Trying to make any of those pages client interactive, within two days you are longing back to something like React. In theory, you could introduce a little React on those pages, but since it is an older server side rendered app, there are no APIs to call, all the features are html pages that return mountains of markup. None of the css is consistent, and even a button is not a single button, its 25 slightly-almost-the-same-button. At least with React there is a good chance those would actually have ended up as the _same_ button component. In my opinion, the reason React still has staying power is the care with backward compatibility, and the fact that its very focused on being a View Library. State management and routing frameworks come and go, but those all live outside of React the library. React doesn't directly force you to have your CSS a single particular way. It's still mainly concerned about being a javascript library, even as JSX is quite far from JS, it is mostly fairly obvious how it ends up being plain JS.
- JackMorgan 3y ago
  I agree, I recently had a client pay me to use ASP.NET MVC for a new website and it was _terrible_. So many easy things were not only hard, but the docs were just not there. It was extremely difficult to handle even basic layout changes. If I knew it really well, I still think it would have been slower than react to build, by an order of magnitude.
galarzaalex 3y ago
Sort of a newbie to agile/devops here but could you explain the comparison to Weekend at Bernie's? I only know the basic premise of the movie but can't follow how to fit agile methods vs older programming methods into the movie. Thanks!
- grugagag 3y ago
  Bernie was dead but only two guys knew that, he appeared alive and well to everyone else.
skeeter2020 3y ago
Don't worry Svelte 5 will "rune" that feeling and pull you back into the React world.
- josephg 3y ago
  Solidjs is hitting the spot for me lately. It’s basically react rewritten to actually use reactive views instead of virtual DOM diffing. Your code looks like react but the js bundle is smaller, simpler and faster. But if you aren’t interested keeping up with “JavaScript framework of the week”, you can do a lot worse than react.

rjbwork 3y ago

It's way ahead has been for some time. I saw it nearly 13 years ago in my internship and have done primarily .NET stuff in the interim. It's only gotten better with age, dotnet core and new features. There are gaps - data ecosystem is dominated by Java/Scala/Python. Numerical computing is dominated by Python (used to be R!). Microsoft has a decent story in their own ecosystem for the former. Their work on more numerical data types, generic math, and more are what I think is the start of bringing numerical computing to dotnet. Can't wait to see what the next 13 years hold.

jemmyw 3y ago
> saw it nearly 13 years ago in my internship and have done primarily .NET stuff in the interim If you've mainly done .NET stuff since you started out then I don't see how you can consider it well ahead or not. I've not used C# professionally since 2007 so I can't really comment either, other than that I've not wanted to go back to it, though I'm sure it's changed immensely. If you've not worked with other languages and tooling I don't think you're in a position to say what's best.
- rjbwork 3y ago
  I've done some stuff in Node, Python, Java, Scala, R, TypeScript and some other stuff I'm sure, as well. But every time I'm on a project like that I just slog through, constantly reminded of what I'm missing. At this point I'm sure it's something like a "lingua franca" effect, but the point remains that I pine for comfy C# when I'm not using it. I will say I did quite like working with Scala the language, despite the rather uncomfy Java ecosystem/tooling. Probably the only direction I'd want to go to leave C#/.NET as my primary tools would be towards Scala/F#/Haskell/Clojure/Erlang, etc. but the market for those is comparatively tiny.

EliMdoza 3y ago

Have worked with .NET for several years and I'm happy to say is an insanely good option, and it's miles ahead of competition when it comes to serving a specifc profile of programmer. UX, APIs, docs, tooling are generally of very high quality. If as a programmer you do not ever want to get involved (good luck getting a change landed), and don't care to understand much of what's under the hood just want to read good docs and get back to your usecase, if you like automation as long as it's written by someone else (how many .NET devs can build a project without VS or even care to know?), if you're happy to confine your dev skills to the inside of a box defined by MSFT, there is no close second option.

rjbwork 3y ago
https://use.expensify.com/blog/ceo-friday-why-we-dont-hire-net-programmers https://use.expensify.com/blog/ceo-friday-why-we-dont-hire-n... this article again, but in HN comment form this time. yawn
- devmor 3y ago
  I always find this article very funny. I do not really use .Net myself, only when I need to make a contribution to a project that is already written in it, but the few developers I know personally that use it are using it for incredibly nonstandard work. I know of an entire framework written in .Net that exists to hook into a proprietary, developer-hostile program and inject a full plugin ecosystem that exposes the protected memory and processing hooks of the program as a user-friendly API.
- lupire 3y ago
  That article was a bad HN comment in blog form. The author even put a disclaimer apology on it.
- spyke112 3y ago
  Wow, had not read that before. It seems really offensive to ordinary programmers that just want to get stuff done. I also find my peak productivity when using the .NET ecosystem, which after all is good for business.

bluescrn 3y ago

C# is great, IMHO. It's one of the main reasons that Unity did so well and continues to be so popular with indie devs even after all their mis-steps, and despite Unreal Engine offering better tech/tools in other important areas. It completely transformed game development. No debugging of memory leaks/corruption. Far less waiting for compiling/linking (and no header files!). Generics/Collections vs templates/STL. It's just vastly more productive, enabling tiny teams to do things that would have been impossible if everything had to be done in C/C++. (And if the alternative is not being able to make the game at all, then any performance down-sides are much less of a big deal)

a1o 3y ago

Are we conflating .NET with C# and ecosystem? My perception is lots of libraries that does serious work are just written in C and C++, in the future I imagine they will be in Rust and not C# - I am talking libraries you get from NuGet, lots of well maintained ones have a C# API that is a shell around something from elsewhere. Be it ImageMagick, lots of media decoding stuff or even proprietary things, like Flir. It's usually hard to find a library to do some work for you in C#, in NuGet, that is also maintained - you will have an easier time grabbing the sources and adding directly in your project so you can maintain it yourself as bug appears and debug it more easily. A lot of times the bug is the developer assumed everyone uses Windows. Most of time when using C# I am reinventing the wheel in it because of this. I also never had a C# project that used it exclusively.

Hawxy 3y ago
> Be it ImageMagick, lots of media decoding stuff or even proprietary things, like Flir. For ImageMagick specifically, there's a purist C# replacement (ImageSharp) that avoids the dependency on System.Drawing. > A lot of times the bug is the developer assumed everyone uses Windows. I can't say I've encountered this in years, most libraries are cross-platform out of the box with support for the major .NET 6+ targets (Windows, Mac, Linux).
coldtea 3y ago
>Are we conflating .NET with C# and ecosystem? .NET is C# and ecosystem, so we're rightly equating, but not conflating them.
- lupire 3y ago
  (cries in VB.NET)
  - coldtea 3y ago
    Wasn't VB.NET basically a rework of VB to be a thin facade over the C#-oriented and tailored .NET semantics and libs?
3y ago

jonathanstrange 3y ago

I'm considering using C# and Avalonia for cross-platform GUI application development but what holds me back at the moment is that I find it hard to evaluate how much cross-platform this combo actually is, and how dependencies generally work in the ecosystem. I've read about a dozen different confusing .NET and NET Core versions, and it wasn't clear to me how to find out which packages from the package manager NuGet work on which platforms. All of it seems to be quite capable, but how Microsoft-centered is it?

topbanana 3y ago
I would go this way for cross platform native UI
- deleted 3y ago
  [deleted]
Hawxy 3y ago
> it wasn't clear to me how to find out which packages from the package manager NuGet work on which platforms. As a default rule, any package you see that targets ".NET Standard 2.0" or ".NET 6+" is using the modern SDK and very likely works across all platforms. This will cover the vast majority of open source packages created/updated in the last 5 years. If a package only specifies '.NET Framework' then it'll be windows-only. Modern packages that are tied to a single platform will likely be named as such and will specify a target that locks it to that platform, ie `net8.0-ios16.0` for iOS.
- jonathanstrange 3y ago
  Thanks, that's a super-helpful reply. Do packages with external C / C++ dependencies include binary blobs for platforms or compile them on the fly, or do they need to be configured for each platform? I mostly worried about standard stuff like Sqlite3.
  - Hawxy 3y ago

politelemon 3y ago

Where .NET is today, is where I had thought Java would be many years ago. I think there's something to be said about the consistency of C#'s programming API, design and syntactic sugar, as opposed to the smorgasboard of potluck-yolo interfaces that you're greeted with depending on what you're doing in Java. Linq is an interface that is barely present in other languages, despite being one of the most intuitive; Java's implementation focuses more on trying to say "we aren't C#, promise!" rather than providing a decent developer experience, and furthermore by giving itself a confusing name (Stream... Streams...). A recent addition, I'm glad that Java introduced templating and the design and intention behind it has so much potential compared to other languages, but in the end they've released it incomplete and "left as an exercise to the reader", which I think hurts. Where .NET isn't so strong is its package management, have a look at the maturity and security of maven packages compared to nuget. Yes, signing packages is a pain and yes there's a bit of a barrier to signing up and pushing your packages up to maven repository, but other languages will learn this lesson over time. Another area, relevant today, is data engineering. Python has shot ahead of everyone else thanks to its "there's one way to do it" philosophy, and thanks to pandas and its relatives. Just try writing parquet files in .NET and then see how simple and up to date it is in Python. Comparing web technologies though, well, Javascript development has and always will be a mess compared to any language ecosystem that you choose. You really don't have to try very hard. I think this will be the case for as long as web standards are in the hands of a few large vendors (who assume JS is the be-all and end-all), and the barrier to entry remains low.

whstl 3y ago

Some things like LINQ, Entity Framework and some features of ASP.NET MVC are still unmatched by most of the competition. The one thing I really miss is the simplicity and productivity of ASP.NET WebForms. It preceded Prototype, jQuery, PJAX, Turbolinks, Livewire, Hotwire, Next, Remix, Meteor. And it partially accomplished what lot of those only did later, but did so in the early 2000s. And it what was, IMO, a bit more "polished" and "finished" than most of what came later. It allowed us for making our own components, and had server-side rendered HTML but it allowed for richer interactions, the kind that we needed jQuery for a while, and today we need React components for. It had a vibrant community, but with the downside that it was 100% commercial. Visual Studio took care of everything we needed, it was indeed just about pressing F5 like someone said.

yawgmoth 3y ago

C# is hard to beat. ReSharper (and IntelliJ) really pushed Visual Studio to have a very high quality developer experience. But I don't miss csproj files, even though they no longer enumerate the contents of the project. Ugh, the conflicts.

pdimitar 3y ago

It's not difficult being in the top 5-10 inside the lower league. So I'd bet on "he is delusional". When .NET gets a proper M:N parallel runtime it's when they will even enter the competition. They are not even in it right now. Golang is miles ahead of .NET and it's far from many people's favorite tech.

Xeamek 3y ago
They won't because they already have async/await
- pdimitar 3y ago
  Good, they have the first 3% covered. It's a start.
martindevans 3y ago
There was a "green thread" experiment for dotnet a while ago, here is the conclusion: https://github.com/dotnet/runtimelab/issues/2398 https://github.com/dotnet/runtimelab/issues/2398
- pdimitar 3y ago
  Yeah, I saw that some time ago. Their conclusion is basically: "it's hard to integrate with the current ecosystem so we're giving up".
- neonsunset 3y ago
  He doesn’t want to read all the research text, especially if it debunks his assertions. Your effort, although appreciated, is wasted on this kind of person.
  - pdimitar 3y ago
    I've read it. It was not impressive. They prioritized backwards compatibility which is of course their prerogative. But that's not how you progress. Having proper M:N parallel runtime is mandatory these days and it baffles me that there people who are still not sold on it. I take it they have jobs and tasks where it isn't necessary but it's an interesting question to ask: for how long?

high_na_euv 3y ago

Yes, .NET Lang and ecosystem is Miles ahead when it comes to almost everything except perf and fancy projects like kernel/db engine/embedded/fw I worked across various tech stack lvls - firmware, tools like compilers and web apps Ive used c#, c, cpp, js and C#s ecosystem was by far most robust and sane to work with C and CPP's std lib is fucking joke in compare to c#s Not even Talking about Lang design itself Id take dotnet cli with built in package manager, compiler, test Runner, crossplat publisher and many more, any Day over anything else

vitorsr 3y ago
Curious - there is one unnoticed comment on the thread that reminds me of my experience: > I feel the opposite. Was trying some number crunching, ok net doesnt have an fft. > What about digital filters... well... lacking > Displaying scientic graphs, like matplotlib. Nope, there might be a commercial package, but I didnt get a budget. As someone trying to develop numerical “enterprise” applications in the most boring, maintainable and longevous stack as possible, am I to write and maintain my own foreign function interfaces?
- neonsunset 3y ago
  I don’t think this is a practical reality though. There is very good math and SIMD APIs for solving these kinds of problems natively, and finding decent bindings is just a matter of using search on nuget and GitHub. And given how dynamic the progress has been, “not possible” changing to “first class” can happen within a year or two.
  - aragilar 3y ago
    The question is then, why not use the native language, or a language where the binding are well-established (and not buggy-as-hell, as is the case with JS)?

asp_hornet 3y ago

> Professionally I've only ever worked in c# code bases. Pretty much answered their own question in sentence one. In my opinion OP is delusional. I worked in .net for 13 years and was stoked to leave. The layers of indirection, obtuse abstraction and over application of design patterns in “idiomatic c#” is preposterous.

danielovichdk 3y ago
Having worked professionally with .net for +20 years I have to admit that you have a good point. There are a lot of dogmatism tied to the platform, it's community ecosystem sucks and there is no real lust to go further than what Microsoft offers. On the other hand, you can easily have a programming career in .net alone. Its not going away the next 30 years.
- asp_hornet 3y ago
  Well said. Its nothing to do with the language or tooling, just this weird ingrained dogma. > On the other hand, you can easily have a programming career in .net alone. Its not going away the next 30 years. Not to mention if a service offers an official client or SDK, C# is almost always on that list. That is awesome.
andyjohnson0 3y ago
> The layers of indirection, obtuse abstraction and over application of design patterns in “idiomatic c#” is preposterous. I don't think this is a problem that is specific to .net. These issues will be found in many large codebases built on platforms that are popular for enterprise development, such as Java.

pjmlp 3y ago

Not really, it is a great development experience, but so is the Java ecosystem, note the stress on ecosystem and not language grammar. Also LINQ that so many on the thread are salivating about, were already present in Smalltalk and Common Lisp collections, were influenced by ML languages and the time Erik Meijer from Haskell fame was part of Visual Basic team. See "Confessions of a Used language Salesman: Getting the Masses Hooked on Haskell". Nowadays busy with Scala and Kotlin. And since I made the reference, Java and .NET IDEs, still don't offer everything that Smalltalk or Common Lisp/Lisp Machines/Interlisp-D were capable of, and yes they also offer stuff that wasn't possible back then.

SideburnsOfDoom 3y ago
> Also LINQ that so many on the thread are salivating about, were already present in Smalltalk and Common Lisp collections I think that it's clear that C# in particular was never intending to originate new programming concepts; it was never a research language. It is a commercial language, and aims to take and popularise the best ideas from such research languages, and package them for coders who work in businesses. As such, there has to be some evidence for that idea already. It must be demonstrated to be effective. You can assume that any good idea in C# already existed somewhere else beforehand, even if not well known. It's not there to break conceptual ground or be in the first segment of the innovation curve.
- mrkeen 3y ago
  > I think that it's clear that C# in particular was never intending to originate new programming concepts; it was never a research language. This is meaningless.
- Xeamek 3y ago
  Wasn't c# the first to introduce the async() concept though?
  - paavohtl 3y ago
    I think it was the first language to specifically introduce the async and await keywords, but it wasn't even the first language on the .NET platform to support the programming model - that honor goes to F#. See https://tomasp.net/academic/papers/async/async.pdf https://tomasp.net/academic/papers/async/async.pdf

ludston 3y ago

Miles ahead of what? There is a reason that we write javascript in the browser and operating systems in c or c++, and telco services in erlang, and academic works in python rather than in C# or F#. .Net is the best at being .Net I guess. It has loads of libraries that are both good and terrible. I think the .Net web ecosystem is a god-awful mess of magic DSL's and configuration, and more and more sugar syntax is being added to C# to make it harder and harder to on-board new developers, and .Net Core deciding to break backwards compatibility is probably costing my org 10's of millions of dollars. But I guess I don't need to type as much as I did 10 years ago.

throwaway2990 3y ago
[flagged]
- omnicognate 3y ago
  I can't speak for the person you're replying to but I have long professional experience with .NET and agree with what they said. I left my last job specifically to get away from it.
  - throwaway2990 3y ago
    [flagged]
    - omnicognate 3y ago
      > The OP and yourself must struggle with programming. shrug "Everybody who doesn't share my language preferences must be bad at programming." Enlightened thinking there.
    - BlueTemplar 3y ago
      It's more a fields thing. Biologists are all over R, physicists - Python, &c.
  - criddell 3y ago

vstenvik 3y ago

«I’ve only ever worked with C# and .NET» «Is .NET better than anything else?» Wy do I keep seeing posts like this? .NET seems like a religion to some.

mrkeen 3y ago
I'm surprised I don't see more. They have a non-negligable market share & people always say their language is the best.
- Ezhik 3y ago
  I assume it's because .NET developers go home after their work day and do other stuff instead of posting about computers online.
  - SideburnsOfDoom 3y ago
    YMMV. For my co-workers, there is definitely an element of "go home after their work day to the wife and kids." Unless they're in the pub. But personally, when I post online about any topic, it's mostly because I find the whole "my language is better than yours" thing childish, arrogant, impolite and tiresome. I try not to have strong opinions about technologies that I don't know (and be honest, 99% of us don't know 99% of the technologies that exist) and to produce facts about ones that I do know.

coldtea 3y ago

Well, the other languages are what .NET would have been too if it only had 1/100th the resources, no dedicated IDE, no first class platform support, and no thousands-strong paid teams dedicated to quality of life improvements and tooling...

jpgvm 3y ago

IMO the .NET and JVM camps are well ahead of the rest when it comes to ecosystem quality/tooling/support/longevity. JVM + k8s + PostgreSQL is my current Boring Stack of choice but I think you could be equally justified with .NET.

jeffalyanak 3y ago

As someone who has worked with a very wide variety of languages, libraries, and frameworks over my career, I have encountered this and the inverse nearly every time I've learned a new language. Most languages with some amount of popularity have at least a handful of features that I wish other languages did as well and that can feel, at least in the moment, to be completely obvious and critical features that every language needs.

jbjbjbjb 3y ago

I agree apart from htmx recreating mvc, I don’t think mvc can do what htmx does but you can certainly add htmx into your mvc or razor pages

nottorp 3y ago

Most "new" languages are sponsored by orgs only interested in server side, where UI is done in the browser. Do you think Google cares about doing UIs in Go? So of course anything made before the browser became the local platform will be millions of miles ahead for developing local applications. Add to that that javascript libs seem to be done by a bunch of people rediscovering every screw and wheel on their own...

coldtea 3y ago
Most new languages aren't that featured and well-tooled for the server side either.

wkat4242 3y ago

Of Java, the most comparable platform, well yes I would say so. Java is a terrible mess.

izoow 3y ago

> Build stuff in .net is so easy, I just press F5 and I don't even know what happens, it just works I started out with C# as de-facto my first programming language and this is exactly the thing I didn't like. I had no idea what Visual Studio does and I was lost without it. Later moving onto C and starting from the ground up with just a text editor and a compiler was quite eye opening.

plaidphantom 3y ago
For me, .NET Core has been largely solving this problem over time. In classic .NET Framework it was nearly impossible to make something without Visual Studio's arcane templates. The `dotnet` command simplifies a lot of that, and projects have a lot less boilerplate.
mrkeen 3y ago
> > Build stuff in .net is so easy, I just press F5 and I don't even know what happens, it just works Sounds like PHP.
- omnimus 3y ago
  Xdebug (php debugger) is not very popular imho. I think because PHP devs are most likely JS devs too and the developer experience becomes different for every language. Logging works everywhere.
  - mrkeen 3y ago
    Sorry, I didn't mean PHP just works. I mean "it just works" is what PHP devs say about their stack.
lupire 3y ago
Sure, C/C++ is interesting not learn how the toolchain works, but that's a different goal from successfully compiling software with large dependency trees.
constantcrying 3y ago

gred 3y ago

Besides the one mention of Go, he seems to be comparing C# to JavaScript/TypeScript. C# is decent, but the JS/TS ecosystem does not set a high bar for comparison...

creshal 3y ago
Yeah, the comparisons seem to be fairly… one-sided. The people who love C# for being better than "everything else" seem to only have dealt with JS/TS/React and C(++), and not any of the actual competitors to C#.

JackMorgan 3y ago

I feel this way about F#. It's so much better than C#, I'm constantly missing things from it when in C#. I go back to C# and try to explain the missing features but just get blank stares, because it's hard to imagine a feature you've never seen before. C# is a fine server-side language, but to be honest it's only gotten there since .NET Core worked on Linux. I still have to work sometimes on crusty old framework projects that constantly break. Every week these teams are chasing down some MSBuild version error, or are dealing with an issue caused by the WCF SOAP endpoints, or some home grown ORM crap because EF was absolutely terrible until recently. So many build errors because the code runs on a windows server that just got patched and for some reason the code won't run. There's a real toxic cultural effect too. I know plenty of .NET projects that just collapsed because they followed the crowd and designed a complete mess of lasagna. I'm talking 10+ layers just to get a record out of the database and sent to an API. So many classes like "ManagerRepositoryFactoryFactoryImpl". So much indirection with event pipelines and listeners and DI. I've seen an audience give a standing applause to a C# talk where the main point was "more than one function in a file causes bugs, so every function should be in it's own file". There's so many niche cultures that celebrate what I'd call "bad code". And it's hard to buck that trend when a big chunk of your hiring pool has bought into a terrible design philosophy. Not everyone, plenty are wise and see it as nonsense, but plenty have bought into some really weird ideas, see it not work, but then blame the implementation not the philosophy. Then they move along to the next project, brimming with holy zeal to "fix" it with design patterns and event sourcing. But yeah, today, coming into it fresh, .NET Core is pretty rad. I manage three client projects on it, and it's pretty great. It's really smooth, builds great, is fast enough for CRUD, EF is decent and I can write raw SQL for the 20% of queries that need it. I can autogenerate swagger docs with swashbuckle, then autogenerate my typescript API consumer from that. I've got my code building and running in Linux docker containers and it all just works and it's fast enough for what I need. But it's forgetting a lot of history and culture to assume it was always this good. It definitely was the worst back in 2003-2014. Keep in mind it used to be closed source and you had to pay through the nose for Visual Studio just to build anything at all! IIS and VSS from 2008 still give me nightmares. Up until about 2020 I recommended people use other tools if they were starting a new project. Today, it's my first recommendation for a backend. (Also I think Visual Studio still is really lacking in features, so I use Rider instead and it's awesome. But to each their own)

KronisLV 3y ago

Currently using .NET and ASP.NET for the API of a project that I'm working on, overall it's a pretty lovely experience, especially with the JetBrains Rider as my IDE. Having worked with Java in the enterprise in the past, it feels like a more focused and sometimes more coherent experience (vs the more decentralized nature of Java), that now thankfully runs fine on Linux as well, don't even need to hope that Mono is good enough anymore. It actually feels pretty close to Java in some respects, for example LINQ and the Stream API are both pleasant to use and let me be pretty productive. Entity Framework Core is great, the way how they fetch related data is straightforwards: https://learn.microsoft.com/en-us/ef/core/querying/related-data/eager https://learn.microsoft.com/en-us/ef/core/querying/related-d... I also really like the ability to use split queries, when needed: https://learn.microsoft.com/en-us/ef/core/querying/single-split-queries https://learn.microsoft.com/en-us/ef/core/querying/single-sp... You can even scaffold your entity mappings from an existing database and manage database migrations separately (which I feel is a must unless you want to pour hours upon hours into learning yet another JPA-like), it's nice when something like that exists in a given ecosystem: https://blog.jetbrains.com/dotnet/2022/01/31/entity-framework-core-inside-rider-ui-way/#existing-database-scaffolding https://blog.jetbrains.com/dotnet/2022/01/31/entity-framewor... Some of the stuff in the ecosystem is also really nice, like using ActionBlocks from Dataflow for simple queues and task scheduling is very easy to get started with and pretty pleasant: https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.dataflow.actionblock-1?view=net-8.0 https://learn.microsoft.com/en-us/dotnet/api/system.threadin... Honestly, most of the docs that I've come across are rather pleasant and there's plenty of code examples to be had and even LLMs have enough codebases out there to be trained on and give decent output, in addition to the regular autocomplete in the IDE. Even some third party stuff like CsvHelper is really well put together: https://joshclose.github.io/CsvHelper/getting-started/#installation https://joshclose.github.io/CsvHelper/getting-started/#insta... That said, I've had issues where trying to deserialize incoming JSON requests ([FromBody]) lead to the whole object being null, due to it not matching the fields 1:1 or violating some nullability constraint, however that happened without a clear error message or as much as a warning in the logs, which felt insane and wasn't very discoverable. Now I just use JObject as the parameter and deserialize at the top of the controller method. I've also run into some ecosystem issues where the OpenAPI codegen was a bit lacking and wouldn't actually generate code that works, but maybe that's because the spec was bad: https://openapi-generator.tech/docs/generators/csharp https://openapi-generator.tech/docs/generators/csharp I could also not get AutoMapper (https://docs.automapper.org/en/stable/index.html https://docs.automapper.org/en/stable/index.html) working satisfactorily, so for now I'm stuck writing mappers by hand with said autocomplete sometimes doing it for me. There were issues with the runtime being unable to register the mappers or something like that, it was a while ago. Overall it felt like the MapStruct library in Java did everything better: https://mapstruct.org/ https://mapstruct.org/ On the other hand, I haven't had any of the Spring Boot DI related headaches (needing @Lazy sometimes) with ASP.NET, things there seem way more straightforwards and you clearly define whether something should be a Singleton or Scoped and the rest... just gets out of your way and works. Sadly, there have been very hard to track down cases where I try to do a _dbContext.Add(someEntity) and then when I do a save with just the fields in that one entity changed, the performance absolutely seems to slow down to a crawl. Adding _dbContext.ChangeTracker.AutoDetectChangesEnabled = false seemed to help, but I am still not entirely sure what lead to that behavior, the temp directory on my Linux box also started filling up very rapidly, yet the logs had nothing of use, definitely seems like something I'd need to investigate properly. Overall, .NET and its ecosystem is pretty good in most cases. Well, at least modern .NET. Also, it being used in gamedev is cool, for those who care about that sort of thing, I wonder why jMonkeyEngine never really took off.

switch007 3y ago

There's a lot of fanaticism around Blazor. I knew before clicking it would in part be about Blazor. And I knew they wouldn't mention where its use is suboptimal Anyone else find c# off-putting to read? Seems like so much white space and Capital.Letters(). On top of the font rendering and default font in visual studio which I find a bit ugly. And blurry iirc Edit: also, .net just has "cost center" vibes which I think puts off a lot of people. It may be great tech but we don't want to work at those kind of companies that use it

JackMorgan 3y ago
Oooof "cost center vibes" is so accurate. Not entirely true, I've worked some pretty damn cool .NET companies. But yeah, a lot of them are not places I want to work.

mythz 3y ago

The technical platform is strong but the ecosystem is weak, so it's advanced in some areas but lacking in others. Basically if a technology can't be hosted on Azure or monetized in some other way it doesn't get first class attention from MS and therefore rendered a niche since .NET's 3rd Party OSS ecosystem is weak. But the C# language is a well-designed modern statically typed language that enjoys best in class IDE tooling from JetBrains and Microsoft. The .NET Runtime is also a stellar performer, especially for a productive high-level language like C#. It also has some great tech that doesn't exist elsewhere, like Blazor which allows you to build entire websites (backend and frontend) with C#, although there are tradeoffs for pages needing interactivity where you can choose between Blazor Server which maintains a stateful rendering session on the server or WASM which requires a large download with slower initial start times. Personally I avoid both Blazor Interactivity options and go with Blazor Static Rendering enhanced with progressive JS which avoids both tradeoffs whilst enjoying great SSR/FCP performance and SPA performance without SPA complexity with the intelligent fine-grained updates in Blazor's enhanced navigation [1]. Blazor's Streaming Rendering is also the most elegant solution I've seen for delivering a live auto updating page with minimal effort [2]. [1] https://servicestack.net/posts/net8-best-blazor https://servicestack.net/posts/net8-best-blazor [2] https://learn.microsoft.com/en-us/aspnet/core/blazor/components/rendering?view=aspnetcore-8.0#streaming-rendering https://learn.microsoft.com/en-us/aspnet/core/blazor/compone...

JackMorgan 3y ago
Frankly, having lived and upgraded many projects through asp web forms, wpf, silverlight, and razor, I've decided "never trust .NET UI libraries to survive". So I'm avoiding Blazor entirely and just sticking with the react ecosystem. I trust that 100x more than I trust Blazor, partly because the ecosystem and user base is 100x larger. I won't be the slightest bit surprised to see Blazor tossed in the trash in three years, but I'll eat my hat if react is gone by then. Sure, maybe it's popularity will wane for some other similar library, in which case I'll switch to that. But I'm sticking with the beaten path on the front end.
- cjk2 3y ago
  Ha we still have all of those (apart from Silverlight) in production. A number of years ago I had to get an overexcited architect to not rewrite everything in Silverlight. Front end .Net is a shit show. You are right to stay the hell away from it.

deleted 3y ago

[deleted]

cjk2 3y ago

I've been working with .Net from day one on large high traffic projects. No. It's overcomplicated, moves so fast that the maintenance overhead is insane, the open source ecosystem is incredibly volatile and immature and the attention of Microsoft is akin to a schizophrenic monkey. The tooling provided by Microsoft is buggy and unreliable and half the platform abstractions (certificates for example) are fucked up messes which cause endless deployment problems. Not only that you're working in a graveyard of abandoned projects and frameworks and legacy 3rd party components you still depend on because Microsoft sold everyone the ideology and then threw it out of the window or changed direction rapidly. Oh and don't get me started on C# which started off reasonable but is now the car Homer Simpson designed https://simpsonswiki.com/wiki/The_Homer https://simpsonswiki.com/wiki/The_Homer All this shit however did pay my mortgage off.

criddell 3y ago
It’s possible that everything you said is 100% true and it’s miles ahead of everything else.
- cjk2 3y ago
  You’re not wrong from a historical perspective. It was that or PHP for me. I chose well. I would not choose it now so I don’t think it holds any more. Go will become the next .net in 20 years.
- lawn 3y ago
  Logically possible yes, but that's not the reality.
- dagaci 3y ago
  Haha, thats exactly i thought! But my experience is the opposite of everything he said!

mrkeen 3y ago

'Ahead'. Is there anything from .NET that has inspired features in other languages?

spacechild1 3y ago
Async/await?
dagaci 3y ago
Linq
- mrkeen 3y ago
  That would put Haskell 'ahead' and .NET 'behind' in this example. But did you have a different language in mind? One that followed .NET's Linq?
m0llusk 3y ago
Interesting framing. In my opinion it is sort of the reverse. The structure of .NET was conceived at a time when Java and Objective-C were redefining how to relate to runtime. As a result it is .NET that picked up the inspired features from other languages, and that arguably has put .NET ahead of the languages that inspired it.
tester756 3y ago
https://willspeak.me/2021/11/24/red-green-syntax-trees-an-overview.html https://willspeak.me/2021/11/24/red-green-syntax-trees-an-ov... >The idea of red / green syntax trees initially came from the Roslyn C# compiler. It was adopted by Swift in their libsyntax implementation. The Rust Analyzer project built further upon this with the Rowan crate. Rowan extends the model of red-green syntax trees with the idea of dynamically typed nodes. Also probably this: https://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://joeduffyblog.com/2015/11/03/blogging-about-midori/ >Midori was a research/incubation project to explore ways of innovating throughout Microsoft’s software stack. This spanned all aspects, including the programming language, compilers, OS, its services, applications, and the overall programming models. We had a heavy bias towards cloud, concurrency, and safety. The project included novel “cultural” approaches too, being 100% developers and very code-focused, looking more like the Microsoft of today and hopefully tomorrow, than it did the Microsoft of 8 years ago when the project began.

addicted 3y ago

The article is right. .NET is way ahead of anything in the front end world. But that’s because the front end world is crap. React Server Components, the new great idea on the primary front end framework is recreating ASP.Net Web Forms. Badly. At least Web Forms was fully statically typed and provided easy embedding of simple JS instead of having to convert everything to the “React Way”. HTMX sounds great and is very good in many ways until you realize it’s little more than a desperate cry to go back 15 years in front end programming because front end development has become such a shit show over the past decade+. Pretty much everything in modern front end development is reversing whatever was done over the past decade and a half because pretty much everything done over the past decade and a half was done to compensate for all the problems with browsers. Now that browsers are becoming decent programming runtimes, and internet speeds and latencies have improved, you don’t need stuff like jquery to compensate for every browser doing things differently, or the virtual dom to compensate for awful DOM performance, or Lodash to compensate for terrible JS engine performance, etc.

jonathanlydall 3y ago

Like other highly successful products of Microsoft (e.g. Windows, Microsoft 365), I get the feeling that C# and .NET developers are a largely "silent majority" who may not be getting posted on or talking as much on places like HN compared to developers of alternative options, but this is mostly because they're just getting stuff done with minimal fuss or issue. I also get the sense that in the U.S. because Java was around for a bit before .NET, it got a head start in terms of market penetration and embedded in a lot of places, so when .NET arrived, even if it was better in some regards, it wasn't enough to justify throwing away investment that had already occurred in Java. As Java was overall more used in the U.S. hiring Java developers was easier, further cementing Java as more popular over .NET. Meanwhile in other places in the world where there had been less Java investment before the arrival of .NET, it is much more prominent as is the available hiring pool of .NET developers. As someone who's been using C# for 12 years now, I have always felt incredibly productive with it and even though I never especially felt the experience was bad, it seems to somehow continuously provide some pretty great quality of life improvements. As with any tool, it's not appropriate for certain kinds of problems, but outside of things like operating system/driver programming or super performance critical code, it is almost always a perfectly fine solution and you won't have any issue hiring developers for it going forward.

subsection1h 3y ago
> C# and .NET developers are a largely "silent majority" who may not be getting posted on or talking as much on places like HN compared to developers of alternative options, but this is mostly because they're just getting stuff done with minimal fuss or issue. Or maybe C# and .NET developers are people who learned to program solely to earn a paycheck and they don't chat about programming because they're not computing enthusiasts, which is my conclusion based on the fact that all but one of the C# developers I've interacted with in person are Windows users who have as much experience with other operating systems as one would expect from people who aren't computing enthusiasts.
- tasuki 3y ago
  Harsh! I have similar experiences/feelings.

conaclos 3y ago

We are only human and thus mostly ignorant. We keep surfing between solutions, claiming that one is better than the other and realizing the problem of our preferred solution and moving on to another or even the previous one. As a community this creates trends. Because we have separate communities, we can even see repeated trends under different names.

peter_retief 3y ago

Miles ahead in what race? Honestly cannot think of any application that I would willingly choose .NET for. I know people who love .NET but they seem to all work for large corporations, no one in startups or doing anything I find interesting seem to use it. Maybe I have missed something?

throwaway13337 3y ago

I'm a chronic framework/language jumper who recently switched some projects to dotnet in production, but without a previous Microsoft-flavored background. I often read hn comments to figure out what I'm missing and what to look out for here. I'm sure this thread will be searched for by people like me in the future. In that spirit, here's my take. Pros: * Best performance of any language without memory management. This is true on Linux, and its memory footprint isn't bad either - especially with AoT. * Best standard library with great docs covering 90% of what you want in most modern apps. * Development tooling that is just awesome with rider. Easily navigate and understand the source code of imported libs. * A reasonable syntax that doesn't make weird decisions because of deep dogma. It beats Go, for me, for instance, because it uses exceptions, generics, and LINQ. This makes the code readable and reasonable to write. I know this is controversial. * Ridiculously simple deployment. No Redis - jobs and cache are practical in-process. Due to its performance, I don't even front it with nginx. Upload a binary on a fresh VM, supervisor and go. A tiny shell script. Cons: * Its object-oriented design. The way files are organized in Go makes a ton more sense and doesn't feel as heavyweight. Also, the addition of records instead of real, validatable value types was a huge missed opportunity. * Went heavily into async/await - indeed, it was the pioneer. Thread-per-connection, co/goroutines, or green threads are actually better models for most projects. I understand the issue with overhead. But the weird call stacks, and footguns inherent are definitely not worth it. * Compile time sucks. This is the biggest for me. Having a subsecond reload time is essential to a pleasant code flow for me. Hot reloading has too many holes to be practical and this seems like a blindspot. No one seems to mind but golang, node, and python are all much better here. My background: I wrote some successful SaaS web apps in Django and transitioned some to dotnet for maintainability. I'd previously used C# also as a game developer with Unity. But I bounce around a lot of tech. I'm in a unique situation as a solo project dev with a long time horizon. I can care about longevity, speed, and ease uniquely. I don't have to worry about employment opportunity of a stack, for example. Right now, I'm trying to decide between TypeScript/node and continuing with dotnet for my next project's backend. The backend I wrote in dotnet remains my most stable. It's beautifully simple to manage in production. If only they could make hot reload not feel so bad.

neonsunset 3y ago

jonnat 3y ago

Whenever this comes up, my thought (admittedly from an outsider perspective) is that people can say that .NET is far ahead in the same way some may say that Oracle is far ahead: Both are enterprise focused technologies that were built using a sales-driven design, trying to check as many feature boxes as possible to help sales teams in their pitches. The problem is when you've been to too many sales pitches and start to equate box-checking with product quality.

baerrie 3y ago

Yeah, it has too many things. Working in mature C# codebases is like wading through a swamp, so many abstractions with long and obscure names that makes holding a mental model of the system in your head twice as hard as TS.

scapegoat2 3y ago

in my experience, you can be very productive with dotnet if you stay on the well-traveled path. I would not use it for private projects, but i like the opinionated defaults in a small team org setting. If your org is full on Microsoft ecosystem (Azure AD, Windows Server, ..) anyway, it fits in very well. you don't have to be clever or reinvent the wheel because 90% of standard use cases are well documented in microsoft docs. it has a steep learning curve though (e.g. auth in aspnet).

mhh__ 3y ago

I want to like C# but the spectre of java in there is really obvious to me at least. It feels like a language made by someone who wants to sell developer tooling

orwin 3y ago

To be fair, LINQ is quite a good idea. Not new at all, i think the first thing any serious lisper do on a DB-heavy project is writing a query/select macro that does exactly the same thing, except better (sadly, i do mean "writing" the best way would have been to treat it the same as the loop macro, but on the other hand, it's like 2 LOC for a quite complete select macro. Never thought of that, but maybe the conciveness of common lisp plays against code reuse)

lispm 3y ago
I would just use an existing Common Lisp library, which provides query and select.

probably_jesus 3y ago

[flagged]

deleted 3y ago

[deleted]

jinushaun 3y ago

I used C# and .NET professionally at a previous job. While I enjoyed writing modern C# that emulates python/ruby/JavaScript idioms, I didn’t like .NET the library. As C# gets more modern, you still have to interact with the ancient .NET library which seem like a relic from the 90s

dgellow 3y ago

I love that with modern .NET you can get started in a few minutes: 1. install the .NET SDK 2. install VSCode 3. install the C# Dev Kit vscode extension 4. run ".NET: New Project" in vscode That's it, you're done. You can build, run, test, debug in vscode. Or use the dotnet CLI if you prefer. It's so much better than having to install Visual Studio as a whole before you can try out the language/runtime, and that works cross-platform.

neonsunset 3y ago
You do not need DevKit, just plain C# extension.

shepherdjerred 3y ago

> Its not really typesafe, more like typescript where its autocomplete, but not real. That is a _wild_ complaint. Just like any language, TypeScript does give you type safety if you use it correctly, e.g. typing at the boundaries, avoiding casts/any, etc.

moribvndvs 3y ago

Wait until they find out how much stuff originated outside of dotnet. I recall a time when a significant portion of the dotnet community did not really venture outside of their ecosystem and were shocked to find that MS just adopted emergent or popular patterns, technologies, and technologies, as if nothing existed until MS built it[0]. The height of this attitude was before dotnet, MS, and really the proprietary software community had fully embraced open source software. I’m unsurprised to find it’s not entirely gone, but I hope it’s fast on its way out. While it’s great for any ecosystem to adopt new technologies and techniques into their stack, it’s detrimental to think a concept doesn’t exist until your preferred vendor releases their interpretation of it. Beyond the disregard for the effort of people who created and maintain the thing originally, this myopathy also leaves a community unable to gauge the quality of the adaptation to give feedback or avoid the thing altogether. This can and has lead to walled gardens, fractured protocols and standards, poor interoperability, and stagnation in the industry. Less dramatically, you might just be missing out on stuff that’s way cooler. [0] https://youtu.be/J6hijsqO8H0?si=t11hHPBpd9Z2jye0 https://youtu.be/J6hijsqO8H0?si=t11hHPBpd9Z2jye0

bitcharmer 3y ago

Is this a troll post?

mhh__ 3y ago

Another point about C# - I have never, ever, seen anyone call any C# code beautiful.

neonsunset 3y ago
Can you give an example of code you consider beautiful?

samoit 3y ago

My rule of thumb is: if it belongs to Microsoft avoid it.