I have also found c# async to be lighter than go's concurrency story, and dotnet11 is going to make that much more clear.

Now: I write software for fun, not for money.

For general concurrency where async doesn't suffice, go is nicer than C#, but hopac is nicer than go.

If go had proper concurrentML I am pretty sure I would use go a lot more. Again: this is for hobby projects where I get to choose freely.

I am kind of curious if it becomes faster when moving to dotnet11.

* = Technically, Windows now supports the UTF-8 "code page" where applications can use UTF-8 natively, but all NT system calls use UTF-16, so the conversion still has to happen somewhere

The Runtime has explored attempting "UTF-8 native" string storage as a platform feature especially for Linux FFI, but yeah Windows using UTF-16 is still a compatibility issue where platforms themselves just don't agree.

Also Go is at the stage of C# .NET 2.0, and still plenty of lacking language features.

I really think the creator of C# made a disservice to the .NET community by picking Go for the Typescript rewrite.

Obviously, there's a trade off in size having a whole folder of files, some of which would be redundant with other applications, but folder of files using xcopy only deployments have seemed to become the standard in .NET. (Or perhaps more commonly, folder full of files added to a minimal "no runtime" Docker container overlay.)

I don't think I've ever seen a global install of a .NET 5+ runtime. I wouldn't be surprised if some Enterprise was doing it for some belief in HD space savings, but I've certainly not seen it. Just file folder deploys.

Static linking as the only way in most platforms, we moved into other mechanisms for a reason.

In Go the only way to do plugins, without shipping everything as source code is to use microservices, the more fashionable name for multiple process with OS IPC.

I wasn't using AOT, it was not something I needed/wanted, but for a TypeScript compiler it would make more sense. I only tried single file binary compilation, as I didn't want to deploy the runtimes, wanted to have them embedded to the air-gapped systems in a simple copy and runway (no installers, etc).

Doable, but requires a bit more of extra work, and Go plugin package is basically abandoned, it was not yet been removed due to backwards compatibility.

Fans of Go (myself included) prefer this. The small feature set is a feature, not a bug.

Go seems actively hostile to it's users, especially in comparison to C#.

But either way, this merely provides an excuse as to why Go is actively hostile to it's users. Backwards compatibility and language evolution are not mutually exclusive.

https://devblogs.microsoft.com/typescript/typescript-native-...

It is universal interface to query diverse sources of data. Most often you use linq to query arrays or lists. This is implemented as a set of extension methods on IEnumerable. Implementations for other data sources exists, most prominently Entity Framework which translates linq queries to sql queries.

Sure, having a runtime is downside but difference in container size for your average CRUD App doesn't really matter. Performance IME is very similar.

Ops type here.

Put things like their remote debugging experiences side-by-side and you will quickly learn why some of us go for the Microsoft tools rather than the others.

I don’t have much experience with Go lang but what I have seen, there is lots of things one has to implement on his own. Which has its own merits, but to go from 0 to full fledged enterprise app you need more time.

My experience with Go is a while back, before it got generics. While I liked the overall idea of a language with little syntax and a focus on simplicity, I didn't really like Go in the end. It was a weird mix of too low-level and high level code. It exposed low level details that I don't need to think about in C#, and it is missing convenient abstractions like LINQ.

Personally, I like async/await in C# more than Go concurrency. I know this is heretical here, but I don't care about function coloring or any of the abstract advantages of other concurrency approaches. Async/Await in C# works for me (in non-legacy code) and is easy to understand.

I'd beg to differ on the easy to understand... last time i worked with this stuff like ConfigureAwait only has cargo cults and no real good explanation, and wasn't covered in any recent version of eg. CLR via C#... Distributed tracing and thread management were totally bitten by async, also the way iterators and LINQ were broken... that was when I got off the train, as it broke the best abstractions for line of business code so that instead of designing an IO pipeline lazy developers could simple put Task.Run around blocking IO calls at the bottom of the codebas, and ... yeah, we are back at function coloring.

This brings me to: I winder for what kind of apps did you find it a delight, because for extensive data wrangling leveraging multiple calls it was a pain.

I'm using C# for the backend of a web application, not legacy but .NET Core from the start.

Something which was as easy as an IO call in the middle of a function running on a thread pool becomes a PITA if the IO call is cleverly async-ized (by wrapping the original sync IO method into a Task.Run(), but actually this is the better case!) ad then removed from the public API... (cannot recall the exact library, but it was a pain, as it was some core stuff, maybe vendored by MS themselves)

Also back then it caused us loosing correlation IDs as those were thread locals in traditional pre-async ASP.Net Core (think version 0.9-2.0 when I worked on that part, then up until core 4 and the async mania continuos broke readable calculation code in LINQ, TPL based performant data pipelines, etc...) and with async execution started to migrate between threads... If you needed high performance you already used threads, because it was not a classic web application, but a specialized optimization algorithm with a web api... and if you need more than CRUD, and use all the cores (and SIMD) to squeeze out all performance you have, you hit these problems right away. These all could be solved, but it actually broke stuff, a lot of stuff, as developers jumped on the fad, and it their sync code was turned into a .ConfigureAwait(false /* Microsoft blogs talk a lot about it without a clear explanation, so every cool kid does this */).GetAwaiter().GetResult()... then you some of your threaded code silently broken if you dare used Thread Locals... Faded memories, but that was when they f'ed up the C# language.

...oooh, that very much sounds like System.Data.SqlClient :)

Indeed, you need a crapload of ConfigureAwait() in desktop UI code, and it infects all underlying libraries that might have to run from a desktop app. The worst thing they ever added to our beautiful language.

I'm going to talk about the second part first. .NET is often deployed with a JIT compiler runtime like Java. That means that hello-world scripts use a lot more memory than Go, but that difference becomes a lot smaller on real-world programs and .NET can use less memory than Go depending on what you're doing.

C#'s concurrency can also be more efficient than Go's since it's coroutine based async/await is a lightweight state machine rather than green threads. That's not to say Go is especially heavy or anything, but it is more overhead.

In terms of "efficient in syntax", Go has a lot fewer features. That's one of Go's biggest strengths and weaknesses.

Here's an example. With Go, you just have struct tags: strings of anything that can be attached to a field in a struct. Let's say you have a User struct and you want to make it so the JSON won't have the user's email in it. You do: Email string `json:"-"`. But what if you mess up and write "jsom" or `json:-` without the quotes? It's basically a meaningless string to the compiler. With C#/.NET, you have annotatons/attributes that are a part of the language and checked as types. You'd do: [JsonIgnore] public string Email. JsonIgnore is an attribute class so your IDE can help you.

There's a lot in Go where the answer kinda becomes "f-it, we'll just use strings instead of having something meaningful." Go talks about how important error handling is, but then you get an error from a function and it's basically just a string. If you're doing good error handling, you want to handle different errors differently, but that's not easy in Go. Frankly, it's not easy in most languages, but this is definitely an area where it felt like Go gave up on creating something good in order to get something out the door quickly enough that Google didn't cancel the project. In a language like Zig, errors are enums and you get exhaustiveness checking. With Go, someone could add another error state to something you're using and you'd never know - or they could change the phrasing of an existing error and you'd silently stop matching on it.

Go's lambda syntax is clunky. func(x MyType) string { x.ToString(); } vs (x) => x.ToString()

There's lots of stuff like that. I'm not arguing that Go is bad, but it has a ton less stuff and that's both a blessing and a curse.

Golang is a fantastic delightful language, but it's still missing a lot of stuff that's existed in C# for years.

However, do you *need* all those .net tricks?

Golang is usually enough for a small project you need to build in a weekend. Scaling it to a mono repo with 200 developers might be a bit difficult

me miss spelling a tag has burnt me so many times.

Go is for me just a, hmm, concurrency programming language. Its popularity stems just from being pushed by Google, and the cosmetics of using braces. Despite what pundits say, it's completely and utterly not like C.

While C# is a successful and comfortable everything-language. It is blazing fast, has amazing tooling, you can get going to prototyping, then enterprise code, its serverside handling is excellent. It has many low level features and built-in data structures. It's I would say preferable for almost any kind of work except scripting. (I really don't like C# scripting.)

PowerShell says hello :)

Go's advantage is mostly the fast compile speed, goroutines, profiling, and a very opinionated formatter. Neither has an overwhelming advantage over the other though.

Some example.

Open API document generation using type handlers doing this in go was a pain in .net is comes out of the box.

A lot of people underestimate the power of extension methods.

.nets metadata system is compiled time safe where Go is not and this has burnt me a lot.

I really like go for command line tools Small binary sizes I lovely.

go's standard library is significantly more hackable than .nets there have been a few things where I've ended up using Go because to do it in .net would require me maintaining a fork of the standard library.

Go makes composing data insanely simple. where in .NET you can have an equivalency but it will be done via interfaces.

Go's Dark Type System is both great and really annoying.

C#'s stricter type system when it comes to interfaces can be really handy as that can be used as metadata to change how data is processed and enforce compile time checks.

https://github.com/dotnet/runtimelab/issues/2398

Be sure to read all the way to the bottom,

There have been smaller runtime improvements like this one in recent releases, but this one seems a big one to point to to prove that the runtime is truly growing at a faster and more interesting pace than the old days.

> One especially useful result is a clearer live call stack. Profilers and debuggers can show the asynchronous methods themselves instead of the infrastructure used to execute them. This is a distinction from exception stack traces, which already hide much of that infrastructure.

The tooling ecosystem in Python is just so bad that I can barely stomach it after spending the last 20 years in .NET. At times, when supporting analysts at work wanting to write a little glue code, I've found their main complaint about C# is "curly braces" (which seems like a really odd thing to complain about, but ok) and I've found it easier to teach them a little VB than to figure out whatever the hell is going on with dependency and runtime version management in Python.

And then, for the folks who go deep on Python for ML tasks, I've mostly found them caring now about specific libraries than the language itself. I then show them how .NET has equivalent or better libraries available and that a lot of the code-golf stuff they do in Python has a much cleaner version in F#.

The data ecosystem is not good though e.g. try doing a ridge regression in dotnet

They burried the lede on this one.

- .NET 10 is end of life'd on Nov 14th, 2028 - .NET 11 is end of life'd on Nov 9th, 2028

Which means anyone who upgrades to 11 has fewer days of support. But the idea is that you'll upgrade to 12 as soon as it's RTM'd.

The problem with that is I have clients who refuse to budge from 2.1 (or even upgrade to the 2.1 re-release: 2.3).

https://dotnet.microsoft.com/en-us/platform/support/policy/d...

.net 5 brought records,and then .net 6 brought record structs.

.net 9 previewed the field keyword, and .net 10 released it.

.net 5 brought primary constructors for records, then .net 8 expanded that to classes.

There's a few opposite examples too, but it's a trend I felt over the past decade.

My only wish is they just jumped C# and .NET versions to the year number, since they are incrementing annually anyway, and aren't do semver anymore.

I think Microsoft regretted those long (10 years) support guarantees they had for .net framework. In the end, it probably slows you down in terms of innovating

Anyway, the critique was less about the exact length of LTS, and more about the lack of significant difference between LTS and STS, i.e. why should I choose LTS in the first place. With STS, you have 2 years of support, and 1 year to upgrade. With LTS, you have 3 years of support, and 1 year to upgrade.

Not really for any groups that commonly use .Net. Even numbers are LTS and odd numbers are not, or at least it's been this way for a while.

>I have clients who refuse to budge from 2.1

Give me their names, sounds like it would be easy to penetrate them again and again and again with AI.

It's still in support, and led to one of the most confusing release announcements in history: https://devblogs.microsoft.com/dotnet/servicing-release-advi...

ASP.NET Core 2.3 does go end of life in April however: https://devblogs.microsoft.com/dotnet/aspnet-core-2-3-end-of...

In fact, desktop apps are mostly used for factories or Windows-only programs, which is a bit disappointing. It's a very good language for making games and the most widely used language for factory programming, but whether to build a product with it is a bit ambiguous. I'd use it when making a program for a specific customer, but for a product I'd probably use TypeScript.

> On the server side, TypeScript is actually better

I like TypeScript but I'd never pick it over C# on the server side unless I had to do React SSR for some reason.

I do agree that it's hard to beat web tech though. Great support across all platforms. Just don't forget to optimize.

Be aware

    (decimal)0.1
    // .NET 10: 0.1
    // .NET 11: 0.1000000000000000055511151231

    (decimal)0.1f
    0.100000001490116119384765625

Hell, on the rare occasion I've needed to use a decimal literal in code, I just use a decimal literal: don't do (decimal)0.1, just use 0.1m.

I hope this is a compiler warning at the least.

I know. It shouldn't be.

We do too at $dayjob, but use cents for everything and at the end of the calculation we divide by 100 to get the dollar amount.

Exchange rates are 4 decimals, so you would still not get bit by this.

However they still suffer from an incredible branding problem.

It's really too bad because as a runtime it's fairly incredible, and F# in particular is fun to work with. They also have good cross-platform support and tooling, which they didn't have a number of years ago.

Combine that with the fact that nobody really writes code anyway thanks to AI, and this could be a slam dunk runtime for an AI-native development environment.

But it will never happen.

    > ...this could be a slam dunk runtime for an AI-native development environment.

    - Roslyn analyzers
    - Simple, stable tool chain
    - Language has largely been stable and backwards compatible for the two and half decades of its existence
    - Now have a very, very good type system that promotes good practices
    - Very good corpus of docs

It's actually crazy what the agent can do with that.

Some folks out there still think .NET is Windows only. Some folks out there haven't looked at C# since the .NET Framework days. Some folks out there are still salty about some of Microsoft's decision around OSS (debugger, hot reload fiasco, etc.)

But day to day working with C# and .NET for backends? It's really fantastic. AI seems to like it a lot and a lot of tools for agents to go HAM. Roslyn analyzer, source generators, tons of really good docs from Microsoft, generally low variance and high consistency (e.g. Drizzle vs Prisma vs TypeORM vs Kysely vs ... in Node land).

My previous team switched from TS to C# and F#[0] and it was a blessing; a lot of the platform ops have been simplified. It's just one very solid tool chain and packages are generally stable. First party packages get consistent security updates.

C# feels like a really solid choice in the age of AI coding because of it's general stability, strong static analyzer, insistence on types, and really good tooling.

[0] https://engineering.usemotion.com/moving-off-of-typescript-e...

We shifted all new product backend build to C# (because at this time last year, we were still "AI assisted" and deemed F# too foreign for most devs to read well), but all internal tooling was built on F#.

By maybe May of this year? We had multiple F# backend codebases, fully AI generated. Only one person on the entire team had worked with F# by hand. Several things work in F#'s favor even though it has a lot less representation in training: 1) the people that write F# really love F# so the code out in the wild is going to be better quality (hunch), 2) F# is a bit more terse/dense than C# and less noise in context, 3) F# benefits from the same tooling stack, 4) F# type system is still a bit more expressive than C#.

I know C# deeply so I know what good looks like and I know how to get agents to write good C#. F# I'm less familiar with, but we had great success with it.

This in contrast to C# where, within one .csproj, there is no "order" and all classes and methods are able to mutually reference one another.

The F# way creates an annoying housekeeping step of maintaining file order, and would be a nightmare to do with manually edited .fsproj files (I have only ever written F# with an IDE), but IMO, it is worth it. On the reading side, it makes it easier to understand how a project you've never read before is structured, since you know the order of the F# source files also must be the bottom-to-top layering of the code. On the writing side, it sometimes causes one to rethink the architecture and simplify it to minimize the number of mutual declarations.

AI isnt quite as creative and clever coders as humans though, but thats true for any language you direct it at, but its a bit more obvious for higher level languages like F#.

The corporate history of C# is undeniably strong, and even till this day in modern C#, they still have a lot of legacy components in it, like AppDomain, APM and MarshalByRefObject.

It is also unfortunately that C# has largely lost in the AI race, that it failed to gain tractions from AI developers despite heavy investments from Microsoft. Early AI stuff like Semantic Kernel actually included C# as its primary languages besides from Python. Nowadays it is not mentioned so much and the default is just Python but perhaps it really isn't a fair comparison due to the gravity of Python in AI as a whole.

The fact that even within Microsoft, Rust wins over C# for agentic development, is a clear indication that C# has lost a meaningful place in software development as its former parent started to berate it as well.

Sure, maybe Bing and a large part of Azure still relies it, probably because of ASP.NET Core and Orleans, but outside of the two Microsoft greenhouses, it is a free for all battle royale where C# don't even have a chance of being picked at due to being too weak.

The last few thing C# is good at is just Unity I'm afraid, and that is also dying too as Unity is also not doing so well lately.

For web API backends and MCP servers, I firmly believe C# is the better choice.

For AI use cases (as in make calls to LLMs), there's not much difference, IMO from Python and C# and TypeScript. At the end of the day, those are all just REST API calls and SDKs are mostly wrappers around it.

For LoB apps where the AI/LLM is just one small leg of the actual flow, C# is still a winner, IMO, because of how good the overall stack is (e.g. EF Core). Orleans (actor model framework) is also super interesting and I'm exploring some memory/communication system based around it.

https://devblogs.microsoft.com/typescript/typescript-native-...

I was curious about their approach to durable execution, so I told them to come back to me when they had a .NET SDK.

The fact that they don’t is either due to the fact that they have a historic prejudice against Microsoft and by extension dotnet, or they can’t be bothered and see no point in it.

Either way the types of companies that are going to have a strong interest in resilient distributed applications, are corporations, and dotnet is still highly prevalent in those types of organizations.

So refusing to support dotnet as a SDK option in Restate is beyond short sighted. It’s leaving money in the table. I can’t take them seriously if that’s the case.

I think the fact that most coding agent images don’t include dotnet support by default. Just look at codex-universal. Swift gets included but not dotnet. Yes it’s not hard to install dotnet yourself and setup the environment, but there isn’t a real valid reason to exclude it since they’ve covered nearly every other popular language.

https://github.com/openai/codex-universal

This. A lot of segregation is very much due to this.

> I think the fact that most coding agent images don’t include dotnet support by default

And it gets worse that that:

https://github.com/openai/codex-universal/issues/13

https://github.com/openai/codex/issues/1276

https://github.com/openai/codex-universal/pull/120

And you see that the community members are doing the work for them, yet they would still refuse using the stiffiest corpo lingo in the most passive aggressive way

"Sorry, we're not accepting PRs in this repo. If you'd like to see a change to the codex universal docker image, please file a feature request in the main codex issue tracker."

Okay, so what the fuck is this:

https://github.com/openai/codex-universal/pull/131

https://github.com/openai/codex-universal/pull/90

I know, but the fact that it is not included by default, then someone made a PR to hopefully get it in, but got refused, tell him to turn around to another issue, and then idling that issue for a long time now, it really pisses me off because there is no communication whatsoever, just like how I have this recent situation with LayerStack has fucked up their control panel, and stripped some features, not ever telling me, just avoided me. This is the part that pisses me off.

"come on, it is just a matter of adding the fucking dotnet SDK by yourself". You know, the problem is not that simple anymore, there is a little hidden agenda which turned into a stance problem, or, oh, well, I hate to say it, "technological politics".

Yeah, I know, "tech is just a tool", then where are all the criticisms when the punks are boasting how "Rust or Golang is so fast, Python and Node is dead" blah blah blah.

Anyway, if you are just trying to hide the vendetta against dotnet, then just say it. Say it out loud and stop fucking around. Make an assertion and stand on your fucking ground.

I might point out that passive-aggressive weasels hiding behind stiff corporate speak are visually undifferentiatiable from people doing the best they can in a project with multiple competing goals in a world where they could lose their jobs for a careless public comment. Not everybody is free.

> I have to go on a furious exchange in the tickets to them

...furious?

Did you have to?

Did you _have_ to?

    > Being a Microsoft product is such a heavy baggage

JavaScript is one of the most common compile targets. "Who's the better JavaScript" was the most contested field a decade ago. These are not just toy languages - Facebook has Flow and Google has Dart. Both companies are far more web-adjacent than Microsoft. Yet Typescript won.

edit: I think it was considered, but go was a better fit

I guess I... just got bored of it, and fed up of Microsoft. I came to hate Windows and having to work on Windows so much that it sort of tainted C# for me. I'm not saying I'd never use it again but, whilst it will run cross-platform nowadays, so will loads of other languages and frameworks, so it's never at the top of the list when it comes to choosing something for a new project.

As for TypeScript? Absolutely loathe it. I'll use it professionally when I have to, but I'd never use it for one of my own projects. It's just so ugly I don't even like looking at it. I get why people like it but, for me, it's not enough. If I'm staring at something all day then, I'm sorry, it can't be ugly.

But, strangely, I still use and enjoy VS Code from Microsoft, and have no plans to switch to anything else.

(I also still have an Office subscription - or whatever it is Microsoft are calling that suite nowadays, I don't care - because I still use both Excel and Word fairly frequently. I could probably get by without, but I actually quite like Office - even on the Mac.)

The thing is, now most things I do target some flavour of Linux - and although I could write C# and target Linux with absolutely no problem - there are a lot of other options that C# has to complete with. Granted those options would also, at least in theory, have been viable options on Windows but it definitely would have felt a bit like paddling against the flow to host Ruby on Rails or Python or whatever on Windows.

And if I want to target command line or desktop with something cross-platform I'm going to compile to a native binary that requires minimal dependencies, so Rust feels like a more natural fit than C#, especially with Microsoft's desktop UI story being such a dog's breakfast (and even more-so when you account for cross-platform).

Again, in a commercial environment, I could imagine using Electron for that sort of thing because that's what most companies do (but because everything I do nowadays is backend, web, or systems integration, I haven't written a desktop app in a commercial context in 13 years, and I haven't written a command line app in that context since just before the pandemic). However, for my own projects I want to hew as closely as possible to my own principles and ideals and, for them, it'll be a cold day in hell before I ship a desktop or command line app that needs some giant runtime like Electron as a dependency.

Again, the point is that C#, whilst in many ways a great language, doesn't come out as the frontrunner.

    > As for TypeScript? Absolutely loathe it.

The main things I don't like about TS are the volatile tooling, bad habits from other devs (not declaring types), compromised ORMs, require lots of package hunting, and module system.

Language is fine, tho.

It was pretty impressive work to scale PostgreSQL.

I got so worked up by it I built my own TyepScript compiler with my clankers in C# to prove that it can be done, my revival of the Common Language Runtime concept, project Copeland:

https://github.com/yuechen-li-dev/copeland

Currently, Copeland compiles a dialect of TypeScript to JavaScript, C#, WASM via Blazor WebAssembly, and NativeAOT, runs in csproj, and uses xUnit.NET for testing framework.

(The other reason is that Microsoft still refuses to do the obvious thing in .NET 11 and take the best part of Rust and let enums be `match`ed, despite the fact that both TypeScript and C# have weak enums historically, so I added payload enums to my TypeScript dialect because Microsoft won't.)

Pattern matching is in C# unless I misunderstood you.

https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html

Instead of .NET 11's more awkward (imo) `union` form.

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

On the historical (And semi-current-ish) downside we had/have;

- lots of 'flash in the pan' stuff between 2008-2012ish (Silverlight comes to mind here)

- Anemic Entity Framework in pre-core, and the weird stuff EF Core had going on early in it's life.

- That constant worry as to whether you need to add .ConfigureAwait(false) to every async call in a library you want to open source.

- The thing where trying to do 'traits' in NetCore (Now that you can mostly mimic the behavior) has had some side-effects on performance, mostly resolved but still something you have to consider as far as impact. (To be clear tho, thank god, needed that...)

- WTF was that UWP workflow?

- Why can't we get a proper designer? I don't think it would be that hard especially given I can do nice things around workflow designers today. Speaking of workflows...

- The complete (what I probably guess was MS groups eating their own tail) thing where Workflow Foundation was almost truly productive, SSMS had a thing based on it that was surprisingly productive, and it has been murdered instead of getting the TLC it needed to really disrupt. This one is extra loud because it is so similar to the 'low code' platforms so many orgs have sank money into.

- Less impactful as far as people eating the lunch microsoft left on the table, but WCF.

The upshot is;

- If you're willing to do some looking there are great options out there. lazy example, linq2db is basically a DSL that is close enough to EFCore as far as 'how you compose' that you can teach it to a group of WITCH devs in 30 minutes or less.

- It really is easy to do all sorts of stuff. It's just productive.

And I am still not over the many breaking changes when they dumped full framework. Have to support a large code base, I think only now with AI will it be economical to redevelop it for .net core.

EF Core now is very, very good with only one minor gap with respect to migration merging (long migration history causes build times to explode).

Other than that I totally agree with everything you said.

    > I think C# would be a great choice for both CLI apps and server less functions.

I may have to play with F# for that.

https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

I'm especially interested in exploring F# as a concise, non ambiguous way to communicate definitions between humans and agents, somewhere between writing code like the olden days of yesteryear and describing things in English prose.

Yes, the plan is essentially 100% AI code with a small team of programmers and domain experts from other technical backgrounds. But still depends on a few things on the business end before I can really kick it off. More of an exploration until then.

But the gist of it is that I wire it up through Aspire (don't need to, but makes it nice) to set the environment variable on my main app host.

I have a small set of utility functions to access the DI container with common patterns like creating a scope for scoped services: https://github.com/zeeq-ai/zeeq-app/blob/main/src/backend/Ze... (optional, but useful)

And a skill: https://github.com/zeeq-ai/zeeq-app/blob/main/.agents/skills...

I recommend you "train" the skill like I do in my the blog post. Basically ask the agent to get an instance of an object from DI like a repository class or your DbContext and have it perform some operations. Have it wrap a function and add logging. Have it replace a function. Then once it learns how to do this, have it write the skill bespoke to your project.

I still choose .NET as the go-to whenever I can. On Windows or Linux.

I think the baggage view was valid for a while - but now we have a new generation of developers who only know about .Net Core and may not associate the Framework years in quite the same way.

Opinionated in a good way, which means almost all C# apps have the same parameterisation with environment variables, command line, and config files. It’s all very systematic, consistent, but flexible and pluggable.

“Node has that too!” you’re about to say. Lol, no. It has bits and pieces the devs have to wire themselves, which means a fleet of vaguely related apps made by independent teams will have wildly different config styles. Good luck consistently making all of them pull API client certs from KMS or Key Vault, or whatever!

OpenTelemetry is now baked in to the core components and rapidly spreading through other libraries.

Excellent “pervasive” system APIs for spans, traces, metrics, and logs means that the sources are omnipresent and very rich, going back decades. Even very old third party libraries are often a breeze to instrument.

Debug snapshots from production crashes on App Service feels like cheating.

Built in container build outputs with no extra tooling.

Sane defaults for its package manager means far fewer nasty security surprises.

Far more first-party “coverage” of essential capabilities in the optional Microsoft packages so you don’t have to resort to NPM where your security-critical code is written by Sergei and support is “LOL Wut!?”

A GC that automatically responds to container limits instead of the host limits.

It uses thread pools for async tasks in most configurations so whole categories of production-time issues that occur with single threaded runtimes just doesn’t happen.

Etc, etc…

A lot of people also seem to have bought into the "Clean Code" dogma popular in the 00s, completely still living in a world where RAM is cheap and JITs are magical.

Add to this the absolutely miserable state of Microsoft's official .NET documentation, and it's a bizarre experience. Everything is "documented" - with things like "Foo(): Constructs a new instance of the Foo class", in case you were wondering what a constructor is...

Context: I'm coming from a background of C++ and Rust. Especially the latter leaves .NET's documentation in the dust, but that doesn't mean the CLR isn't a piece of extremely solid engineering. I'm continually impressed by the .NET JIT and GC, for example, and when you dive into the poorly documented details of the standard library (it's open source these days), you'll see that the quality is very high almost every time.

So yeah, I agree that .NET and C# has everything it needs to be really great in the right hands, but many hands aren't super right.

My recommendation is always to understand the technology in depth, then make decisions based on what makes engineering sense. Understand the tools first. For me, that's a hands-on process, but others learn better from books. A lot of programming books seem a bit ideological from a methodological point of view, often written by people who thought they found the magic bullet (see the "Clean Code" fiasco) with perhaps limited time in the trenches.

Wait until you meet devs who don’t understand that other OS are a thing!

As far as I know, C# and friends still require setting up a project file, and there isn't a tutorial that has one you can easily copy.

Maybe this is why I also can't get into Android development.

(It also doesn't help that my Linux distro doesn't ship the toolchain because it can't be bootstrapped from text files, as far as I understand it)

You could also `dotnet run script.cs` to run a single file without setting up project.

dotnet new console

dotnet run

    dotnet new webapi
    dotnet new console
    dotnet new <template_or_sdk_here>
    dotnet run
    dotnet test

Thanks for the links. Your agent repl thing looks cool as hell.

Modern .NET is great though.

Have these decisions changed? Is everything now open source?

Maybe MS can work out a longish-term roadmap, where in a certain future version C# and TS gradually "morph" into being the same thing (e.g. Typescript 10 == C# 20 or so)

I suppose it would look a bit like F# (LMAO)

I recently tried to come back and the problem isn't the language. It's getting into it. Try to click "new project" and you're met with dozens of templates, and a lot of them sound identical to the untrained observer. Which web project should you start with? Which GUI project?

I pushed through it and made the wrong choice a few times for each of those. Apparently there are stable old one, and rapidly changing and underdeveloped new ones, and no way to tell them apart other than knowing the magic incantation.

Microsoft would do themselves a major favor if they cleaned that up and made things clearer, including definite guidance on why you should pick one template over another.

Instead, they treat them all as if they're perfect and newcomers have to just guess.

And no, web research doesn't help. There are tons of people who love each of them, and only a few people willing to write well-reasoned articles based on their experience, helping someone pick the best ones to start with.

You can get C# to match Rust or Go, but those would require going off the beaten path and you might as well use Rust or Go.

I think C# CLI for internal tooling that is only used by an existing C# codebase makes perfect sense. As a standalone tool that's being shipped for multiple platforms, it would be better to use Rust or Go since those will give smaller native binaries and default better performance profiles in speed and memory usage.

I think backend web APIs are where .NET shines.

but job offers are kind of boring :/

like databases, OSes, compilers, web browsers, etc.

Have to agree, PHP codebases also were nice organized, bigger repos, mostly web apps / company backoffice apps and so on. Personally, products were more interesting.

With today dotnet state, it really suits well for API development / microservices / integrations / we had many workers - jobs running, queue subscribers, K8S, good test coverage, open telemetry.

Even migrating from .NET Framework wasn't so big pain.

Job postings sucks nowadays for all stacks.

But I'm on linux now. If I wanted to pick up back up then what should I be using?

I prefer VS but for the performance, I use VS Code. Unable to work in Rider on 32 GB RAM.

Good IDE but they ignored bugs and serious performance problems for too long. The main project I'm working on isn't even that big, maybe 1M SLoC in total, most of them C#, and Rider really struggles with it even on good hardware.

This forced some architectural changes to satisfy the machine (breaking out libraries where they weren't necessary, running code analyzers only in CI, not during development, etc).

So I don't miss the experience.

MS finally have a language server (still in preview, but it works fine) which can be attached to helix in a couple of lines, and that + good knowledge of Unix command line tools is more than enough now.

There is a gigantic difference between "technically possible", "practical" and "enjoyable". I had some junior engineers hounding my ass about using ORMs and the liability of manual schema management until they saw how sqlproj and sql compare work in VS proper. You can certainly string this along with 3rd party and custom using other IDEs, but then you don't have as much time and energy to focus on the actual problem. Maintaining a stack just to maintain your stack is pretty crazy to me. I'll happily pay the idiot tax at Home Depot for the Milwaukee option so I can place an invariant on this part of the problem space. I never want to be in a position where I can blame my tools for a bad work product.

Either you should not be forced to upgrade, or backward compatibility should be guaranteed -- not both. But Microsoft is happy to say "hey, we're going to completely abandon support for every version of .NET every 2 years, and if you can't keep up to date then everything that goes wrong is all your fault." Meanwhile, they have no problem breaking your code.

This essentially kills the possibility of just writing a bunch of small, useful libraries, and having them be useful forever. It is the antithesis of a healthy software ecosystem. Are you really expecting that every single open source library that is referenced by a reference of your references is going to be maintained in the face of breaking changes every 2 years? If not, then upgrading your version of .NET is just a gamble that things won't randomly break. But you must upgrade, or you're a bad developer who's leaving your apps vulnerable and every automated security checking system in the world will yell at you about how awful you are. You must upgrade everything you have ever written every two years, and hope that every library you've ever depended on does the same, or you are putting yourself at risk of some breaking change sneaking its way in, or leaving yourself vulnerable to a critical security issue that Microsoft refuses to back-apply.

I cannot understand why I'm the only one shouting from the rooftops about this. It's completely unacceptable to me.

https://learn.microsoft.com/en-us/dotnet/core/compatibility/...