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

We write operating systems in C because it’s a thin veneer over assembly and coding in assembly is really hard. We use C++ instead of other languages because of its C interop.

Erlang is a really good fit for concurrency so that’s one of the few languages that’s used where it is for its technical merits.

Python is used for academic work solely because it’s easy to learn and easy to get started with so a lot of colleges used python to teach engineers/scientists programming. Python became the language of academia because that’s what the people in academia knew. If colleges had adopted Ruby or Lia for their Programming for non CS majors 101 classes instead, Lua or Ruby would be the language of academia.

Don’t disagree with a lot of the rest of your post, but this is a real, genuine virtue and ought not to be lightly dismissed.

Javascript is as easy to learn as any language, like understanding the syntax of a loop or an if-statement.

But to do anything practical at all, I'd say you quickly bump into a jungle of libraries you need for everything, and then it is just as complicated as any other language, or more. The javascript ecosystem is a nightmare.

Node makes this a lot harder, the simplest way to have interactivity is the readline library, and that requires you to understand functions, closures and the idea of a callback and why one is needed.

Then there's the "R way" of learning Python, in a Jupyter notebook, by stringing functions from Numpy, Pandas, Matplotlib and perhaps some other libraries in your field together, with no understanding of what a loop is, because you don't really need those for basic dataframe and tensor work.

I've taught Haskell at an university and almost none of the students ever found the model of computation natural. I think we humans simply find following a series of steps easier than reasoning in an abstract mathematical sense.

That being said, I absolutely see the value of the latter, and consider it a good thing that functional concepts are gaining popularity in imperative languages.

They seem naturally sequential and an imperative to me.

I can't imagine how a list of instructions would be clearer in haskell.

    cook meat sauce = do
       pan <- getPan
       addTo pan meat
       cookFor pan 10
       addTo pan sauce
       cookFor pan 3
       food <- contents pan
       pure food

Although written in an imperative style and thus superficially similar, the haskell differs in that it is referentially transparent.

I think that makes it objectively clearer, because it implies certain guarantees that nothing will surprise the reader.

It is not at all obvious that this is truly the case. If it was the case, why didn't humans intuitively develop mathematics from a computational foundation? It took centuries before we made the leap from mathematical abstractions to Turing machines, and the two are (in some great general sense) isomorphic.

So, you are right regarding the mindset of human philosophers, but that is not the sort of problems OP's students were tasked with solving.

Python's REPL isn't even any good, but it does at least exist which is more than you can say for most languages.

(And there's also the fact that it's crazy popular.)

Perhaps some of the old Lisp or Smalltalk environments could rival that, but no other modern language except Julia and R, which also have Jupyter support, come even close when repl ergonomics is concerned.

Think of all the urgent iOS, Windows etc. patches which could be avoided if the software didn’t suffer from a number of classes of avoidable vulnerabilities.

> There is a reason that we write {...} rather than in C# or F#.

So are you arguing in favor of C#/F# here? you believe it was more suited for all of these cases? I hope not.

But again, if it's neither, then this comment seems like a out-of-context straw man.

Allowing your code base to run ok for 10 years, 20, 30 without change. You are talking Cobol type situations where the rest of the industry has moved on, and now your are stuck. So each individual has to judge jumping ship and migrating their systems.

Even Python took the leap and did a major revision that broke everything. But guess it had to be done.

They could ship both interpreters and communicate with RPC for all I care as long as shit still worked. Though to be fair I haven’t written a single line of Python 2 for about 10 years now.

> We do not guarantee 100% compatibility between major versions. This is true for both ASP.NET Core and the runtime itself. We intentionally make breaking changes where we believe that they are necessary to move the platform forward and the cost of the .NET ecosystem adjusting to them is low enough.

There is a major .NET release every year. Every other release is LTS with 3 years of support.

> The old .NET framework will be supported for many decades into the future

I'd guess so but Microsoft is not as clear on this as you'd wish. In all their policy documents they say it's "supported as a Windows component on the latest required update" or "Beginning with version 4.5.2 and later, .NET Framework is defined as a component of the Windows operating system (OS). Components receive the same support as their parent products, therefore, .NET Framework 4.5.2 and later follows the lifecycle policy of the underlying Windows OS on which it is installed." To me this seems to be carefully written to allow the possibility of changing that Windows component status in a Windows release. So, .NET Framework is supported as long as it is part of Windows, until it isn't.

The major releases of modern .NET are relatively painless now, there aren't that many breaking changes. This is pretty much the same as many other languages, and kinda unavoidable unless you go for an ecosystem that aims for very long term stability and is essentially frozen.

The early .NET Core releases had some annoying breaking changes, but it's very different today.

This is a true caveat for any language or framework, and is a sensible disclaimer.

But I think the author was referring to transition from “.Net Framework 4” series (since 2001 when I first used it, ~23 years ago) where Microsoft declared “.Net Framework 4.8” would be the last major version of that series. And that new developments should use the “.NET Core” series, which is now named just “.NET “.

I have a fairly large portfolio of legacy in-life systems that are stuck in limbo now, and a limited group of developers to move them to .NET 8.

We wont have to move them into isolated mode on short notice, to get them to .NET 8 but this isn’t the Microsoft of old, where backwards-compatibility is a paramount consideration.

This is flawed logic and I assume people upvote it for visibility rather than genuine agreement.

There is so much different syntactic sugar to do the same thing that it’s becoming very difficult to onboard new devs to any slightly complex application worked on by multiple devs because invariably the codebase will consist of 3-4 syntaxes doing the same thing which can get really hard to grok.

In an ideal world C# would have gotten rid of a lot of the ceremonial code it had but unfortunately backwards compatibility means that’s not likely to happen.

I wish C# declared a preferred singular syntax for every scenario and provided IDE support to warn when that preferred syntax wasn’t being used.

No one is sure what problem it is trying to solve anymore.

Also the amount of people I see blowing their toes off by not understanding stuff like LINQ and when stuff is executed and materialised into memory is insane. That and entirely not understanding async and any weird side effects like things happening on other threads and losing context and all sorts. Urgh.

Im sure C# version 22 or whatever it's on now will allow you to write in plain English at compile time and it'll use CoPilot to compile this to C# which doesn't work.

Built in ones are here https://learn.microsoft.com/en-us/visualstudio/ide/visual-cs...

If you want to apply a coding style, there are lots of free tools for that even, or you could investigate something like ReSharper from jetbrains.

https://learn.microsoft.com/en-us/visualstudio/ide/code-styl...

Too many smart language people trying to justify their salary.

Have an example of overlapping syntax?

int Foo => 4;

private int Foo { get => 4; }

private int Foo { get { return 4; } }

https://sharplab.io/#v2:CYLg1APgAgTAjAWAFBQMwAJboMLoN7LpHoCW...

Yes, so you are right.

I don't get why in IL, the expression bodied member is different, though. Still, makes sense if you have learned C# starting from the most verbose form (3) then (2) was introduced, then (1).

E.g. you could add

private int Foo { get; } = 4;

To the above example given that the behaviour is identical, although the compiled output should be different so I didn't to avoid any nit pickers.

Miles ahead of the tooling, frameworks, and features of most languages.

>There is a reason that we write javascript in the browser

Yes, we're stuck with it.

>and operating systems in c or c++

Yes, the legacy.

>and telco services in erlang

Erlang doesn't have some particular stronghold in telco services. It was created by Ericsson for their own such use, but it's not like other/most telcos use Erlang. Ericsson itself even neglected (and for a period even banned new Erlang projects, preferring other languages).

>and academic works in python rather than in C# or F#

Huh? Who writes "academic works in Python"? I'm sure some do. Still many write Java, C#, and others, including C++ and even Haskell. Except if by "academic works" you meant "in machine learning and scientific computing", or "use as teaching language".

> Yes, the legacy.

That's hardly the only reason, and certainly not the reason why new OSes are not written in .net languages.

If we had more mature systems languages suitable for OS development sooner, people wouldn't use C and C++.

The Fable compiler for F# barely adds any cost on top of what TS adds in terms of dependencies, compilation and tooling and IMO gives you a much better language for developing applications. And you still get to use the JS ecosystem.

Most of the cost is related to familiarity with both F# and JS, node and the browser.

But once you match on a pipeline of Results you can never go back!

I've tried plenty of other to-JS compilers, even for languages that I love, and I still choose TypeScript every time.

It doesn’t feel that much different than the TS compilation process. It is not what you’re expecting.

We tried Haskell in the browser before and it was a huge mistake. We want back to TypeScript afterwards.

Haskell wouldn't work in this context.

I've had a very easy time debugging Fable compiled projects.

Again, I have extensive node and JS experience which is absolutely required for working on a Fable project.

I would argue that the hardest parts of TypeScript aren't that much less of a leap than F#.

I would argue that this code is easier to debug than the equivalent .tsx:

  [<ReactComponent>]
  let Counter() =
      let (count, setCount) = React.useState(0)
      Html.div [
          Html.button [
              prop.onClick (fun _ -> setCount(count + 1))
              prop.text "Increment"
          ]
  
          Html.button [
              prop.onClick (fun _ -> setCount(count - 1))
              prop.text "Decrement"
          ]
  
          Html.h1 count
      ]

  [<ReactComponent>]
  let ShowGreeting(props: {| greeting : Greeting |}) =
      React.fragment [
          Html.h2 props.greeting.heading
          Html.h4 props.greeting.subheading
          Html.p props.greeting.content
      ]
  
  app.get("/", fun req res next ->
      promise {
          let! response = 
              req 
              |> gql "query { greeting { heading subheading content } }" {||}
              
          match response with
          | Ok response -> 
              let greeting : Greeting = response?greeting
              ShowGreeting ({| greeting = greeting |})
              |> res.renderComponent
          | Error message -> next()
      }   
  )

Compare this to the try/catch approach you'd be using in TS:

https://fex-template.fly.dev/form-validation

I wish that instead of TypeScript, MS had just used F#.

It seems like they took some of the concepts of what can be done in F# and made TypeScript. I wish they had just stuck with F#.

It's almost like it was marketing, like they didn't like how F# was viewed so TypeScript was a re-branding.

Maybe it is because TypeScript can be considered a DSL that could be built by F#. Like Elmish.

EDIT> Yeah, not sure if enough people understand F#. You can easily build TypeScript from F#. Or maybe the downvotes are from Haskell people that just view, a functional language can build anything so it isn't worth commenting on.

Am I not contributing to the conversation? Has anyone else even mentioned F# or Fable?

You're obviously not going to use it for low level or high performance system programming, or numeric stuff where you'd use Python, but for day to day getting stuff done it's amazing.

Besides,Isn't typescript developed by the same people who made C# and also takes quite few inspirations from it?

Google is the only company that is in a position to do anything about this and they gave up on Dart. So yeah, we're basically stuck with it.

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.

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.

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.

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!

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!

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.

I prefer unopinionated frameworks

I've bitten the bullet with sveltekit, and it does get the job done I have to admit.

But if you aren’t interested keeping up with “JavaScript framework of the week”, you can do a lot worse than react.

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

[2] https://learn.microsoft.com/en-us/aspnet/core/blazor/compone...

I'm not a .Net developer and never have been. But I used to do a lot of technical due diligence work. Which sometimes means sitting down and going through the most critical code, and sometimes nearly all of the code in a project. When you do this kind of work you encounter lots of different languages and software cultures.

One thing I notice about .Net in particular is that it is often the choice of companies that have a weak software development culture. My guess is that people choose .Net in these companies because they already have a "relationship" with MSFT products. MSFT is what management knows and trusts. Often because they're not qualified to make technical decisions and they think MSFT is somehow a safe choice.

This is also why they tend to choose Azure. It isn't so much a conscious choice based on the merits of the technology. They almost never tried AWS or GCP first, and there is very often some financial incentive to choose Azure (eg licensing package deals).

The .Net projects I've reviewed are often often mediocre software engineering. In particular during M&A, you encounter a lot of code bases that use old .Net versions, old libraries and critical code that hasn't been touched for years. Presumably because the companies that tend to choose .Net often do not invest in the codebase once it is "done". It also isn't unusual that much of the code is written by junior consultants.

This is my experience and it is what it is. It isn't so much about technology as it is about certain types of companies.

But it does result in me having certain prejudices when I hear that something is written in .Net. It is easy to expect bad things when people say "we use .Net".

My experience is the same, but instead of .NET replace it with Java and Spring, it’s otherwise essentially the same

On average Java codebases I have reviewed tended to be slightly better than the C# codebases. The C# codebases I've seen have tended to be more "garden variety meh" while Java tend to be either south or north of "meh" - if that makes any sense. They're more often either terrible or fairly nice. Though I've been lucky and seen more nice than awful Java. (There is a separate circle of hell for Spring and other metastasizing frameworks).

That being said, the all-time worst codebase I have reviewed was in Java. An EMV system written in a hurry with almost zero error handling.

Razor didn't go anywhere, it's still the predominant language .NET Server HTML Views is written in since its release in 2010, whether it's in MVC, Razor Pages or even Blazor which enjoys the same familiar statically-typed syntax with great tooling and high performance compiled views.

There's no chance that's going to happen with Blazor, which has become the future of .NET Web App development, it's a unique technology that's highly versatile whose multiple rendering options supports a wide number of different use-cases that's enjoyed by most of .NET developers.

Personally I think it's a fresh of breath air after several years of fragile npm SPA development with broken upgrades stemming from its 100s of deps of varying quality and uncoordinated releases. All I liked from SPAs is its fast navigation, but we also get that from Blazor's Enhanced navigation without SPA complexity, heavy client state, maintaining client side routing, poor SEO, large complex builds, etc.

Extrapolating abandonment of Windows GUI software with poor business models, with cross-platform libraries running on growing revenue centers is foley, I'll happily take any "5 year Blazor" bet.

Front end .Net is a shit show. You are right to stay the hell away from it.

I won’t comment on whether blazor is a good framework for frontend web dev. But it’s far from unique.

These days there’s heaps of languages you can use for both front- and backend web programming. JavaScript and typescript, obviously. Dart. And Go and Kotlin have some blazor-like wasm builds (though they still have a large download size). Lately I’ve been noodling with web dev in rust with Dioxus. It’s crazy fast - it trades blows with the best JS frameworks. And it’s very ergonomic. It’s basically solidjs rewritten in rust. The resulting wasm bundle is bigger than the equivalent JavaScript code, but it’s really not too bad given wasm parses several times faster than JavaScript.

Blazor looks nice. And wasmgc should dramatically reduce the resulting wasm bundle size soon. But it’s far from unique. You can make webpages in almost any language now.

https://book.leptos.dev/view/01_basic_component.html

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)

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.

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.

As with any “typical workhorse” consumers, you land up with lots who are not necessarily passionate about their day job.

Perhaps you’re right it’s more common that C# developers are dispassionate, but I don’t think it means that there isn’t a pretty large absolute number of passionate users, even if the proportion may be low.

Look at Windows, its number of users dwarfs everything else, I fully expect that it has a much much higher percentage of dispassionate users compared to any other operating system, but it’s not to say that there aren’t a lot of passionate users of Windows.

My point is that even if it is indeed true that C# has a very high percentage of dispassionate developer, it really doesn’t mean or say much, aside from the fact that it’s used a lot.

Overall, I thoroughly enjoy using Windows and C# and I’m not going to switch to Linux or macOS for reasons like “wanting to stand out” or “not be associated with dispassionate computer users”, to me it would be like cutting off my nose to spite my face.

Windows and C# have for a very long time been super reliable for me, they really have delivered on “just works” over and over, I haven’t lost any appreciable time to things not working.

I tried Linux desktops a while back and concluded that, outside of people who just need a browser, it’s generally for people who enjoy tinkering with it, while I more prefer that my OS can just play the game I want, or just use the tool I need without needing to spend time tweaking things for it to work.

As for macOS, as a power user, I feel it’s firstly not worth the premium price tag difference, and secondly I can’t see it being worth my having to give up my Windows muscle memory. Admittedly, the battery life is probably unmatched, but I have never found myself wishing that I had more battery life than I get on my business class Dells.

It's also worth realising you've self-selected for tools that work on Windows (e.g. I rarely see Windows simply because the tools I use require UNIX). I don't see Windows going away any time soon (simply because Apple is too expensive), but the rise of mobile devices (e.g. tablets) which cover the needs of basic users mean that it's going to be relegated at some point (as old laptops are replaced by other devices) to being a desktop OS for gamers and business users who require native Windows software (because the web equivalent is too slow/bloated). I expect cheap Chromebooks to replace cheap Windows laptops (as long as Google doesn't screw that up).

However, since you bring up the mobile space, Android is another way to prove one of my points.

Like Windows in the desktop space, Android has a somewhat overwhelming market share (globally), and similarly to Windows has the highest percentage of dispassionate technology users, where they care more about using their social media or payment processing app than what OS their device is running.

Also, I disagree that my usage of Windows is self selecting, it’s actually more selected by device manufacturers and the developers of the software I use.

Between Windows and Linux, I’ll have way less driver issues on Windows. For commercial desktop software, the vast majority is built targeting Windows. I choose the OS which is most likely to run the hardware and software I need with the least amount friction.

ChromeOS may one day become the dominant OS (it also may not), but today, outside of using a web browser, I don’t think it’s unfair to say to say it’s the “poor man’s” choice of OS in the desktop space.

As a final remark, it feels like you’re taking my appreciation of MS’s present day offerings as some sort of attack against your preferences. If you’re happy using non-MS stuff, great for you, but that doesn’t in any way detract from my being incredibly happy with my choice, which just happens to be different.

For a not-insignificant proportion of the population (which heavily overlaps with the dispassionate technology users), media consumption on a mobile device covers their needs (and for things like 2FA, not having a mobile device is an issue), so their laptop/desktop (Windows or Mac) ages out of support and eventually is no longer used (and given the costs of mobile devices, they're not likely to buy a replacement laptop/desktop). Some might use a work/school device, but now what they get is based on their work/school provides (and if ChromeOS is good enough and much cheaper to run, then users won't have a choice). Also BYOD policies generally work against Windows, as a sufficiently large Apple contingent will push moves away from systems that only work on Windows. I would be expect Windows usage to settle to at least 3 times MacOS usage (given Window's better legacy and meeting the needs of white-collar professionals more, and desktop gaming), but my feeling is we're going to see less traditional general-purpose systems (which is somewhat sad), and a bigger divide between those who use desktops/laptops and those who don't.

I would still suggest you have self-selected: if the programming languages and the tools you use (and the kind of projects you work on) are effectively Windows-only, naturally you're going to be happy on Windows (and there's nothing wrong with that). But it's worth remembering that for other ecosystems (e.g. Python since you brought it up), running those ecosystems on Windows is second class (whether that's caused by Microsoft or by the ecosystem), or, because Windows is not UNIX, practically not possible at all (and some of the UNIX software I run for work predates the NT kernel, to be clear).

My only issues with Windows are: 1. how much random junk there is now (advertising in the start menu, really?!?), which I feel is a negative for Microsoft (let Google do that, and catch the flak for it); and 2. having to use it (and wasting time on it) when it's obvious it's the wrong tool for the job (e.g. trying to use an ecosystem where Windows is a second class citizen).

Finally, I do think it's somewhat sad that there's less interaction and knowledge sharing than there could be between Microsoft's ecosystem and those ecosystems outside of it, both could benefit from it (e.g. I hear about Blazor, and it sounds cool, but how would I use it from (C)Python).

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.

At work I maintain most of the project files and some of the surrounding tooling for our product and being able to clone the repository and opening the solution without having to configure or do anything else is still very high on the priority list since it makes starting out easy, it makes just opening up the project and making a small change easy, etc. Some of us switch between languages, products and projects multiple times a day and this sort of thing is a major help in not spending as much time setting up things.

On the other hand, even though I very much like understanding things beneath the surface, I'm still very much lost in how JS bundlers work¹ and Java with Gradle or Maven is also very mysterious to me. Probably also a function of the frequency and time I spend on setting up those things beyond just writing code.

___________

¹ It also doesn't help there there's lots of things that simply cannot work in the browser, e.g. importing CSS or JSON files as JS modules, that the bundler makes magically work in some way.

Compared to `cargo build` or `go build`, the GUI-first nature of .net and the build-your-own-toolchain approach of C feel like they're extreme examples of different ends of the spectrum.

But my last two decades have been pretty much all .net and I live a lot of each day in visual studio. I feel a couple of orders of magnitude more productive in .net and I find it hard to imagine why I would want to use any other tools at this point. For getting stuff done, .net is hard to beat.

yes, yes it is. Its fine for teaching, but my word when you're dropped into a large project with no context, it really really sucks. especially if someone is doing "clever" stuff (I'm looking at you research engineer writing "optimised" c++)

I was dropped into a Unity VR project with a C++ plugin than called out to a fancy backend. Unity is a bit of a arse to use because so many information is locked in videos.(thank fuck for LLMs) Everything being c# turned out to be really rather good. Especially if you have a working intellitune.

Dropping out to c++ on the back end was utterly frustrating. cryptic errors, random stack traces, lots of tears. All of that can get into the sea.

It is something that you do learn to like when you understand what is going on, but actually just want to fix a problem.

Not that the way the C compiler, linker, execution environment has any significant connection to how C# works. But you have seen the computer on a different level. By the way, seeing the operating system is another level entirely and writing one was an eye opening moment for me that I can only recommend.

I think because PHP devs are most likely JS devs too and the developer experience becomes different for every language. Logging works everywhere.

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.

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.

Having an easy to use (scripting) language that can do serious work was and still is awesome

On C# and .NET we still don't have a portable C++/CLI, it's still something that is only for Windows and only MSVC. Maybe if they ever port that. But for now I will stick to python.

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

.NET is C# and ecosystem, so we're rightly equating, but not conflating them.

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.

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

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

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.

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

JVM + k8s + PostgreSQL is my current Boring Stack of choice but I think you could be equally justified with .NET.

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.

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

All of it seems to be quite capable, but how Microsoft-centered is it?

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.

They usually bundle them in. For example the SQLite packages are bundled with ~23 different native binaries for all of the platforms it supports, and they'll be output to the right place as part of the build process. There's nothing you need to configure.

For licensing or packaging reasons this might not apply to everything (ie ffmpeg).

Wy do I keep seeing posts like this? .NET seems like a religion to some.

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.

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

All this shit however did pay my mortgage off.

I would not choose it now so I don’t think it holds any more.

Go will become the next .net in 20 years.

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?

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.

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.

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.

It feels like a language made by someone who wants to sell developer tooling

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

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

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

https://joeduffyblog.com/2016/11/30/15-years-of-concurrency/

> Developers already had several mechanisms for introducing concurrency, and yet struggled to write correct code.

> STM could handle all of the decisions transparently like figuring out how coarse- or fine-grained synchronization to use, the contention policies around that synchronization, deadlock detection and prevention, and guarantee that you didn’t forget to lock when accessing a shared data structure. All behind a tantalizingly simple keyword, atomic.

> STM also came with simple, more declarative, coordination mechanisms, like orElse. So, although the focus was on eliminating the need to manually manage locking, it also helped evolve synchronization between threads.

Fascinating stuff.

> Unfortunately, after a few years of prototyping deep runtime, OS, and even hardware support, we abandoned the efforts.

Oh well.

> It wasn’t even clear that STM would be the correct tool for the job once we got to that point.

This is just sour grapes. You already identified the problem and the solution. There's no walking that back.

> My brief summary is that it’s more important to encourage good concurrency architecture than it is to make poor ones “just work”

We'll I guess there's just nothing to do but leave it to the programmer to get right!

Miles ahead? Or DNF?

But did you have a different language in mind? One that followed .NET's Linq?

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.

On the other hand, you can easily have a programming career in .net alone. Its not going away the next 30 years.

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

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.

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.

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.

However, you will see a lot of projects, especially OSS ones which are structured in more C or Rust like style with e.g. Types.cs if API surface is small - no need for a file per class or struct if declaring it takes 1-10 lines (especially with records and primary constructors).

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.

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.

This is meaningless.

The first google hit for this is https://dev.to/maxarshinov/a-brief-history-of-asyncawait-264...

> Despite that C# was the first mainstream language that popularised the async/await keywords, it wasn’t the language that invented the concept. F# added asynchronous workflows with await points in version 2.0 in 2007 (5 years before C#).

Which is exactly my point about c# mainstreaming and popularising concepts that already exist, even if they exist in less-known or less polished versions.

See also the usual reference: https://en.wikipedia.org/wiki/Async/await

Sure, if you really care you probably will go for something lower level, but if you don't want to abandon all the nice things that high lvl language offer, C# still exposes some tools to get your hand dirty every now and then. (Unsafe, stack allocation etc.)

Kotlin meanwhile goes even further then java and completely removes the distinction between stack and heap, slamming every single type into an object. Painful.

> Nowadays busy with Scala and Kotlin.

Perhaps not a reference to Kotlin being a good replacement for C#, but you did mention it in a post pushing Java.

Maybe one day when CLR gets rid of the remaining C++ and COM stuff that is still around.

- A GUI toolkit that is available everywhere, not just on some platforms, needed 3rd parties for others.

- Two major implementations with Real Time GC, and bare metal support.

- A compiler toolkit, that even handles LLVM IR.

- A couple of bootstrapped versions

- Several implementations for various kinds of deployment workloads, specially when taken beyond the desktop

- An almost compatible ecosystem that powers 80% of the global phone market

- Three IDEs, written on the language, portable across the three major ecosystems, freely available and with access to their source code

Just a quick overview beyond guest languages stuff, don't want to bother with all the stuff.

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.

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

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

I also really like the ability to use split queries, when needed: 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-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.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/#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

I could also not get AutoMapper (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/

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.

This might be worth fixing, you're paying a performance penalty by needing to do intermediary deserialization and by using the old Newtonsoft serializer (STJ is significantly more performant).

Request validation (ie with FluentValidation) would shake out any deserialization mistakes.

> I've also run into some ecosystem issues where the OpenAPI codegen was a bit lacking and wouldn't actually generate code that works

Try Microsoft's new Kiota generator, its works a lot better.

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

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.

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)

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.

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?

While mine was a bit tongue-in-cheek and apparently stung several people, it also has facts behind it. Working on many super-parallel tasks like, you know, good old web apps and APIs, have shown me that using regular threads does not scale.

There is tech out there that solves these problems and many C# and Java devs come off as grumpy curmudgeons instead of being proper techies and engaging arguments on their merit. And you seem to be another example.

Do better. The metrics and numbers are out there on the internet clearly showing that M:N parallel runtimes beat the classic threading model. That you might have chosen not to look for them is not a rebuttal by itself.

I do, which makes the rest of your comment a very boring ad-hominem.