[trangus_1985]

I started a project that I hope to maybe turn into a product (foss/community edition hybrid approach). One of the tech stacks I evaluated was mono-based, using c# and the .net libraries.

I ended up turning down that choice due to a couple of factors, but one of them was the glacial pace of .net process and development. It just didn't look or feel like a healthy ecosystem, if you weren't paying microsoft $$$$. Just a ton of small warning flags around the community, the stack, and the maintenance of core projects.

C#, .NET, and the associated ecosystem doesn't feel good to work with, out of date, and in desperate need of modernization. The alternatives (spring, flask/falcon, lightbend) all seemed much more modern and easy to work with.

I actually have a concrete example of this: one of the features of my project is that you can define yaml based configuration documents, and share them. Using something that was easy to write for small but coherent configurations was crucial - XML was right out. The .NET ecosystem's yaml support is not great, feels kinda janky, and yaml validation is a paid product! That's completely untenable for something that's still in the weekend work phase. And it wasn't just that, but tons of things I had become accustomed to in python were either incredibly immature or paid. Not to mention that the built in build system was horrific, confusing, and had weak documentation. It's probably a lot easier when you just write a check to a contractor to set up a template for your team, but I have no luxury. Sure, some of this is on me, but I wanted to get started building and the .net ecosystem repeatedly got in my way until I was forced to give up.

So, upon hearing that the .net foundation is spending all of its time generating stacks of bureaucracy and causing internal drama, I feel like I made the right choice. At this point, it's unlikely I re-evaluate .net for future projects unless I hear massively good things (like what happened with java, which took a decade).

[cyral]

> C#, .NET/FCL, and the associated ecosystem doesn't feel good to work with, out of date, and in desperate need of modernization.

I recently built a company over the past year with .NET (after not using it for 5+ years) and felt the total opposite. I suspect you may be referring to the old .NET back when you needed Mono to run it on anything but Windows? .NET Core has been out for a few years and is an amazing improvement, the APIs (especially for web dev) feel very complete and modern, and there have been a lot of neat language features added in the recent major versions. The old .NET was definitely clunky though for targeting anything but Windows apps or servers.

Not sure what you are referring to for the paid products - .NET Core is now open source and even accepts PRs. Although there is no official YAML support still, so maybe the third party library was paid? JSON is a great option these days and .NET's new JSON parser is really fast and uses much less memory (Years ago C# got support for the new Span<T> and Memory<T> types which allow type-safe access to the underlying memory, making serialization operations much better since there isn't a bunch of copying and allocating involved any more)

[Mertax]

This is our experience too. We have 5 software engineers maintaining 3 mobile apps, 1 desktop app, 1 SDK product, and 1 web-app (Blazor) all with a shared C#/.NET code base that is bringing about $6M annually if you include the associated hardware product revenue. I’m not aware of many other tech stacks out there that can “natively” integrate with hardware/sensors and get that level of code sharing maintained by such a small team.

[cyral]

How is your experience with using Blazor and also creating the mobile apps (not even sure what .NET tech is used for that these days)? I maintain a web and mobile app so using C# across all platforms would be amazing, but I thought Blazor was still too new so I decided to use TypeScript & React for the web and mobile apps.

[billfruit]

Not exactly related, how is Xamarin integrated into this ecosystem. Does Xamarin have a future?

[Mertax]

While Xamarin has some pain points it definitely satisfies a market need for “native” cross platform development. My company uses it quite a bit. With .NET MAUI on the horizon as the evolution of Xamarin it has a future. Although I do wonder if the Blazor (mobile bindings) might end up having the brighter future. Kind of seems like the back up plan to appeal more to the HTML/CSS web devs who don’t want to adopt/learn the XAML UI markup.

[crobibero]

The “next” Xamarin is Maui, which has been delayed until Q2 2022

[weq]

.net7+ is basically .netcore + xamrain integrated into a single product. MS are evolving xamarin into a new UI framework called MAUI

[meibo]

Sadly(or luckily, for the people that haven't had any contact with the ecosystem), you must have missed the semi-recent open source developments around .NET Core. It's open, has a very healthy community and is well supported by Microsoft.

Sure, back in the days when you had to rely on Mono for cross-compact, this is exactly the answer you'd expect from anyone, but it couldn't be further away from the truth nowadays with the modern runtime and ASP .NET Core.

[oneepic]

I can't refute your examples, but I think on one hand, C#/.NET has a lot of modern stuff you maybe didn't see, which you'd wish other languages had. The lang has great features (i.e. properties; the libraries for collections/concurrent collections; System.Linq; and Tasks, to name some). VS has great profiling tools (cpu/memory) if you know how to use them. Package and dependency management were bad, but I believe got some needed improvements starting with .NET Core. Things like that.

OTOH, that said, I don't actually prefer C#/.NET, when I think of those techs I don't think of a great OSS ecosystem (more like marketing blog posts by Microsoft MVPs, as opposed to technical deep dives by passionate engineers). I also think of github repos with at least 10x more open issues than stars or forks. These techs have great features, and they're used for successful projects/companies, but there's something about the fact MSFT owns them that makes me not want to use them at all, and just prefer golang/java/etc.

[mattmanser]

MVPs are passionate engineers!

They're not microsoft employees. It's just MS has explicitly recognized them.

There's an irony that the award MS gives to passionate engineers in the .Net community has been completely misunderstood by someone outside of it.

If you want to see a great example of a passionate engineer who's been awarded the MVP, go read a few Rick Strahl blog posts.

Another one was Scott Hanselman, though I believe he joined MS like 10 years ago.

They addmitedly muddy the waters by awarding the MVP to their own employees writing about their new stuff, but even they can be passionate and interesting. Scott Guthrie's time on ASP.Net is a good example.

[oaiey]

When you join the MVP program you are an evangelist. You are briefed, you are under NDA and you start to have a very different view that the broader community. Not every MVP is like that, but while I like the content they create I see them seriously disconnected from many .NET developers and actual use cases.

[oneepic]

This. I shouldn't have said MVPs aren't passionate engineers. But I do feel a significant side of their content is just marketing.

[ksm]

I think that is because product teams at Microsoft more or less expect MVPs to function as evangelist of the things they want to communicate marketing-wise. Originally the program started as recognizing community leaders/technical experts in specific MS technologies, but I feel things got hijacked somewhat along the way. Teams see MVPs as credible voices towards their audience so naturally the tempatation to use them as marketing voice is there.

Add to that the fact that MVPs themselves are passionate about those MS technologies so they for most part do want to repeat marketing line.

I used to be MS MVP, not for developer tech but for it pro side of things, and definitely saw these ”asks” in the messaging the product team did towards us from time to time.

[Rapzid]

> The alternatives (spring, flask/falcon, lightbend) all seemed much more modern and easy to work with

I never thought I'd see Spring(or any of those) described as more modern and easy to work with than .Net haha. Spring is the Java land web framework bloatlord. It's quickly fallen behind and out of favor in recent years with the hip crowd preferring micro frameworks like Quarkus or Micronaut. Spring abandoned hot-reload in favor of restarting app context which takes FOR EV ER on larger projects; .Net is releasing hot reload as a first class platform feature as we speak.

.Net runtime is one of the hotest pieces of action on the planet. AOT compile, multi-core threading, async/await, Span<T>. Mono is pulling its weight too with compile to WASM. Then you have ASP.NET, Entity Framework, and a lot of other really great and performant build blocks.

[tasogare]

> C#, .NET/FCL, and the associated ecosystem doesn't feel good to work with, out of date, and in desperate need of modernization.

You must have miss dotnet Core because the modernization you're asking happened years ago.

[trangus_1985]

Ah yeah, I was using core I think. Sorry, it's been a while, I kinda glazed over the acronyms and names over time. Since it was my own project, I really was trying to do things "the modern way".

[gregoryl]

Why were you targeting mono then?

[trangus_1985]

Frankly, I don't remember. It's been a long time and using .net was a failed experiment.

>Why were you targeting mono then?

Well here's another issue with .net I ran into... really unclear guidance from numerous sources who all really wanted you to use THEIR stack and thus end up paying THEM.

I did multiple things, multiple attempts to make it work. I tried to do it "the right way" from various sources.

The reason I was targeting mono at some point was because I wanted to run a microservice, without paying windows server licenses fees, and as best I can tell, that was the root runtime I'd need to target.

Keep in mind that this was me, going in blind into a large and established ecosystem. I don't think going astray detracts from some of my bigger complaints, such as the poor quality of community open source libraries.

[Merad]

> Well here's another issue with .net I ran into... really unclear guidance from numerous sources who all really wanted you to use THEIR stack and thus end up paying THEM.

Meaning no offense, but it’s hard to see how you ended up so far off the mark. The .Net frameworks and runtimes (.Net Framework, .Net Core, and mono) have always been free. Likewise for the Asp.Net web framework you would have been using for web applications. I’ve been in the .Net ecosystem for over 10 years and I’m not aware of _any_ paid web stacks that would align with the quote above. Not to say that they don’t exist somewhere out there to extract money from foolish enterprise IT departments, but they aren’t even close to mainstream. If you did this experiment within the last 5 years it would have been extraordinarily hard for you to miss out on .Net Core, especially considering it was built to do exactly what you want - microservices with Linux as a first class citizen.

[tasogare]

> really unclear guidance from numerous sources who all really wanted you to use THEIR stack and thus end up paying THEM

Sorry but at this point it is hard to believe you are posting in good faith and not trolling. Even back in the Windows only days the runtime was free and there was free dev tools (VS C# Express). Mono was free too, and open source. I know no paying runtime and I've been using the language and tools as a daily driver for a decade.

It's been possible to build micro-services in ASP.net Core running on Linux (and in Docker containers) for the last 3 years very easily.

[gregoryl]

Agree, I decided not to reply - if, a year ago, you ended up on the path of "compile to run on mono", you didn't bother to read any of the .net5 documentation - and without checking, likely just the main download page for dotnet core. /shrug

[cosmotic]

Why would you start a project on a platform then build that product on a foundation of one of that platforms weaknesses instead of one of its strengths? This anecdote is not good evidence against the platform.

[oneepic]

You're referring to the YAML point? The way I read it, it sounds like the poster only learned about the issue when they ran into it during development. That being said, a couple of specific complaints is probably not the best argument against a broader platform.

[cosmotic]

I remember XML support in .NET being excellent. The author could have used C# classes that would serialize/deserialize to/from the XML, then used built-in tools to generate an XML schema for the config files. The schema could then be consumed by vendors or other connected projects using .NET and have perfect, code-first, statically typed interop. You'd never be writing XML itself or the schemas or the serialization/deserialization code. You can't get any of that with YAML, it doesn't support that sort of safety. You'd have to manually implement all the safety checks and serialization/deserialization for a worse end result. Of course that would be a bad outcome.

[sumnole]

the .net ecosystem is somewhat pay to win - its like the apple store of the devtool world, clients are actually willing to pay. if your company has the funds, you have access to some of the best tools in development, but you can get pretty far with its free options too.

C# is quite a nice language to work with. historically projects were very enterprisey oop monsters but cleaner functional paradigms are trending in the .net space.

[trangus_1985]

Yes, I quite like C#, the language. That's why I put so much effort into trying to make it work - it's become one of my favorite languages!

[hvidgaard]

You can absolutely write in a functional style. It does not have to be the enterprise OOP monsters of the past. Apart from something radical such as adapting a Hindley-Milner type system, I'm not sure it can support functions much better than it already is.

I think most people simple oppose to the idea of a static type system, and my experience is that static type checking is an absolute time saver in the long run for large long lived. Significantly.

[ahepp]

I'd love to hear more about the top tier paid tools. I haven't really experienced that before.

[sumnole]

General dev tools: ndepend, ncrunch, Redgate sql kit, Jetbrains dot suite, LinqPad

RAD components: Telerik, Asp.net zero

Libraries: EPPlus, SyncFusion PDF

Editors: VS enterprise, JetBrains Rider

DB: Sql Server OS: Windows, Windows Server

MS products for biz: Azure DevOps, Teams, Office Suite

misc Windows tools: Listary, Directory Opus, Chocolatey, PowerGrep

all stuff that makes the dev experience very comfortable

[initplus]

This list to me reflects a different element of the .NET ecosystem: .NET teams don't just buy into .NET, they also adopt often buy whole hog into a grab bag of other MS solutions alongside.

Are Windows Server, SQL Server, Azure DevOps, Teams, Chocolatey, and PowerGrep really a better dev experience than Linux, Postgres, Github, Slack, apt, and actual grep?

Many are debatable, but SQL Server & Windows Server are honestly a huge pain to deal with, and on top of that cost a boatload in licensing fees. Even Microsoft has decided Azure devops is a waste of time post github acquisition and it is apparently eventually going away. Teams honestly sucks in comparison to Slack.

[oaiey]

That is seriously outdated in 2021. A modern .NET developer use Postgre, SPAs like everyone else, vscode notebooks, VS Code, etc.

Visual Studio or JetBrains rider is the only thing a professional developer needs. Which is tiny investment for a professional. The rest of the products I have not seen in new projects use for years.

[metaltyphoon]

Why is any of this necessary?

[munchbunny]

It's not, although Microsoft absolutely tries to make it much easier to write/deploy/maintain C# in an all-Azure tech stack. That's good or bad, depending on whether you have other reasons to be on Azure.

I'd say Visual Studio (not VSCode) is pretty much the only not-really-optional, not-really-free dependency. I suppose that means you also need to buy Windows.

Personally, while I use(d) C# for work and I think it comes with a solid toolchain and I have no big complaints, I have never chosen it when I could choose the stack from the beginning.

[na85]

With lsp-mode you can write C# in emacs and still get Intellisense code completion!

[to11mtm]

Closest I can think of is the days of yore where .NET Component licensing was a thing that was encountered frequently enough it was mentioned more prominently in books. This was useful for a lot of 3rd party developers that wanted to provide either tooling or runtime libraries to IT Shops. UI Toolkits and other 'specialized' libraries would use this mechanism as a way to keep some level of IP Protection.

I ran into this scheme in the wild with Devart's DotConnect for Oracle; at the time it was worlds better than the free 1st party providers, and came with some interesting T4 templates for generating models for either EF or their special adaptation of L2S, and MVC CRUD HTML generation. Fairly cheap for an unlimited site license too.

[heavyset_go]

> And it wasn't just that, but tons of things I had become accustomed to in python were either incredibly immature or paid.

What are some of those things?

[trangus_1985]

it's been about a year but it was a death by a thousand papercuts kinda thing.

I want to add that I was not an experienced python developer at the time - I'd used it for a handful of simple automation scripts. My day job was writing scala.

- targeting mono under nginx on linux, from within windows was really difficult, I could never quite get it to work

- no support for monodevelop on windows - cross platform was crucial to me and it just got so onerous. And maybe it's just me, but I was really hitting a lot of frustration with visual studio.

- i wanted to use both yamlschema (broken at the time) and jsonschema (paid)

- msbuild is abysmal with useless error messages. I struggled to run a simple shell script during the build process.

- a couple of libraries I tried were broken or unmaintained. The .net ecosystem seems to have very low quality of community maintained tools.

- no clear guidance around using DAPR without paying microsoft (which i guess is fair, but being vendor locked before I even start is a rough look)

- ... and that's all I can remember. There was more.

I fully acknowledge that some, if not all, of those complaints may be self-inflicted. I can't say that, for my first complicated project in python, it's been completely smooth sailing.

However, with python/falcon, it didn't feel like I was fighting with the ecosystem to define a package, import the package into a microservice codebase, and then get the service running with full test coverage. It didn't feel like I was fighting to bring a third party library in, verify it's actively being maintained, and start using it.

I spent as much time getting a simple microservice hello world with authz/authn validation and a reasonable packaging system, in python, set up in about time as it took me to give up on msbuild.

I've found bootstrapping python microservice development on windows to be quite well supported. I didn't find that with .net.

[Hawxy]

I think the only time I've found people this far off the main track is users that only know C#/mono coming from Unity Engine.

> targeting mono under nginx on linux...no support for monodevelop on windows

Because you should have never been anywhere near mono.

Even a year ago, if you followed the main .NET documentation it would have directed you to install the .NET 3.1 or 5 SDK on to your linux environment and get setup with VSCode. It's the first step in the hello world tutorial: https://dotnet.microsoft.com/learn/dotnet/hello-world-tutori...

> no clear guidance around using DAPR without paying microsoft (which i guess is fair, but being vendor locked before I even start is a rough look)

Dapr is not a Microsoft product. Microsoft does not offer commercial support for it. There's docs for the .NET library on the Dapr website, along with various community support channels available.

> I've found bootstrapping python microservice development on windows to be quite well supported. I didn't find that with .net.

Bootstrapping a worker service or ASP.NET Core on windows is either a few clicks in VS, or a one line command via the dotnet CLI.

[trangus_1985]

>I think the only time I've found people this far off the main track is users that only know C#/mono coming from Unity Engine.

Damn, almost direct hit. I was a game developer for a year or so about 10 years ago. We were using xna.

[jolux]

Have you tried using .NET Core? It's a pretty thorough reworking of .NET Framework that is officially supported by Microsoft on Mac, Linux, and Windows, and pretty much all of my experiences with it thus far have been positive. VS Code has great built-in support for it.

[bayesian_horse]

IMHO for startups, productivity and development speed usually beats performance and enterprisy-ness (looking at you, Spring).

F# dominates C# there, but Django, FastAPI, various other options for Node or other languages, are simply easier to learn and faster to iterate. You can change/reload a Django app several times before the C# compiler finds a problem with your static types in a bigger codebase...

And to me it seems like you can acquire technical debt in C# just as fast as with any other language. Maybe faster because it is harder to learn and less "obvious" with all the DI magic. Of course, if you are proficient in C# and its ecosystem, you can write some damn fine software in it. If so, I wish you the best of luck finding affordable coworkers who can do the same.

[mattmanser]

This is pretty much nonsense, not sure when you developed C#, but Type feedback is instant and pretty much always has been.

Also, you're making up an impossible scenario, a startup that's moving fast, but somehow has a 'bigger' codebase.

[bayesian_horse]

I'm not saying it's at the same time. And yes, type feedback is mostly instant.

The code base I'm currently working on takes a long time to compile and sometimes there are errors. Or there are runtime errors. Combined with the much higher volume of code I have to write, and the greatly reduced readability C# does feel a lot less productive than Python.

[mattmanser]

Usually when I see that, it's because someone's implemented an inappropriate pattern, or gone over board on 'SOLID' principles or whatever.

C# developers seem especially prone to getting trapped in stupid implementations that massively bloat the code. For taking some Uncle Bob dictat to an unnecessary extreme, or implementing a dangerous pattern like CRQS stupidly for a simple CRUD app. Less a reflection on the language and more of a reflection of the enterprisey culture.

I was interviewing in the C# world recently, it was quite disheartening to hear the same phrases repeated 'hybrid microservices' (i.e. we've got the worst of both worlds in one project! But our TA got to put microservices on his CV!) or 'we value SOLID code' (i.e. we've massively over-engineered our code, development has slowed to a crawl, there are far too many interfaces, and debugging is a nightmare!).

But you can write great, terse, code in C#, and I feel much quicker than dynamically typed languages. I feel like I can implement the same code much faster in C# than I do in the equivalent javascript, even though I've been writing javascript for longer, and that's down to the autocompletion and snippets of a powerful IDE, which dynamic languages will never be able to match. It's also much easier and quicker to move code, refactor, and generally redesign your code on the fly as you're exploring the problem space.

[bayesian_horse]

Even Javascript has quite a bit of autocompletion nowadays, with all the annotations coming from typescript. Much less typescript itself. Frameworks on the JS side also massively improved.

Same thing with Python. Not that it really needed annotation much, the productivity always was quite high, whatever people not using Python said. Now there is static type checking and the IDEs got even smarter. In my experience even statically typed software still needs automated and manual testing so much of the benefits are limited.