> It's incredibly fast and productive and has allowed me to create more as a single-person than entire teams using other languages.

Another startup founder and CTO here. Can confirm this. Once you get to know the framework, it's really hard to describe how productive you can become. Static type checking, fast compile times, LINQ!, ... It's a 10x ecosystem in the hands of competent developers.

So, our back-end and business logic is in .netcore/C#. Our front-end is a desktop app written in Java 11/JavaFX. The two communicate with a thin IPC layer (stdio pipes). With "new" java (11 and onwards) I'm almost as productive as with C#. If C#/.net is 10x, I'd rate Java as 8x.

Thank you very much for sharing your thoughts and experiences. Please see my reply to the parent comment (by @manigandham) about one of .NET-side reasons for my contemplation. I'm curious about your opinion on this aspect.

In that comment you're comparing a statically-typed language (C#) with a dynamically-typed one (Python) and your main concern is that C# libraries feel "overengineered". This totally makes no sense to me because the whole development methodology will be different between the two. I.e., it makes no sense to me because your concern is the most shallow one.

And yes, using a statically typed language with strict typechecking (i.e., no implicit integral conversions like in C and C++) leads to programs that feel "engineered" (I wouldn't say overengineered) but which are easy to confidently refactor and build upon.

IOW, flexible/productinve language + static typing + good IDE (VS) = easy to develop "obviously correct" code that works when it compiles and which obviates the need for a huge battery of tests. IME.

Thank you for sharing your thoughts. I certainly agree with you on benefits of using statically-typed languages (and this is one of the reasons for my potential selection of C# versus Python - though, mypy and pydantic packages seem to alleviate some/many/most(?) of Python's type-checking issues). However, that was not my point or concern. My reference to most C# code that I have seen felt as "overengineered" has nothing to do with language type systems and type checking (if anything, it leads to verbosity, but not overengineering). I thought that I clearly mentioned what specific aspects of the code produced that feeling for me: a "proper" implementation of design patterns, DDD and enterprise-focused features.

I appreciate your feedback. I definitely have a very positive feeling about .NET Core (C# and, to lesser degree, F#) platform (though, I think that .NET ecosystem is not as comprehensive / diverse as the Python one). What forces me to contemplate about .NET versus Python is that most of the C# source code I have looked at (especially ABP frameworks) have a feeling of being over-engineered / "heavy" (versus Python's being elegant / "light"). I understand that most of that comes from a "proper" implementation of design patterns, DDD and enterprise-focused features (which, actually, I need, by the way - hence my interest in ABP frameworks). But, still this feeling troubles me a bit. Perhaps, I just need to read and practice more in C# and .NET ... :-)

You can write complete C# apps in a single file if you want. It's not really that verbose (nowhere near Java). The structure and the huge standard library helps greatly compared to the messy nature of other languages like JS and Go that ends up with code and modules everywhere. You'll quickly learn and maneuver around the bigger patterns, which (like you say) are actually important in working with larger applications.

But nothing I say will be as useful as just working with it. Try spending a few hours working with some of the bigger frameworks and I'm sure you'll get it pretty quick. If you need help then there are plenty of people to ask as well, from HN to twitter to the .net repos.

Thank you for sharing your thoughts on this. I have already spent more than a few hours with the two large enterprise SaaS boilerplate frameworks that I mentioned above and, while I understand most concepts, it still feels quite overwhelming.

Now the question becomes whether it is worth spending time and effort learning more in terms of design patterns, DDD (maybe even CQRS and Event Sourcing) and specifics of these large third-party frameworks as well as practicing working with all that with a benefit of developing really solid enterprise-ready SaaS platform from the start VERSUS moving much faster by developing a more lightweight MVP in Python/FastAPI stack (with PostgreSQL / GraphQL / Vue in both cases) - still with basic/core enterprise features like cloud-native scalability (using Docker swarm mode) and multi-tenancy (using PostgreSQL row-level security) - with a disadvantage of having somewhat less solid architecture and/or some technical debt initially.

Well first of all, do you really need all that? How "enterprise" is the solution you're building? DDD is very involved and more academic than realistic. And you definitely don't need CQRS/Event sourcing, that's firmly in exotic territory for most projects.

There's a lot to enterprise stuff that also has nothing to do with the tech [1] so I would recommend starting with the default asp.net templates and build from there. Move fast and then add in the enterprise specific patterns when you need it.

1. http://www.enterpriseready.io/

Yes, I do need all that (except for CQRS and Event Sourcing, which I've briefly looked at and didn't like them, plus, they only make sense for certain types of systems based on microservices architecture). Yes, I'm familiar with relevant requirements and the EnterpriseReady project, in particular. Having said that, I certainly don't need all enterprise features for the MVP. How "enterprise" my market-ready solution should be? As comprehensively as most and then some. The solution's target market includes (mostly medium and large) industrial enterprises, government agencies and universities.