Hacker News Reader

I'm using .NET Core/F# for the backend of my bootstrapped "startup". I mostly have an iOS dev background so take my experiences with a grain of salt.

So far everything has gone pretty smooth. ASP.NET Core is running under the hood which seems to be pretty mature. F# and the libraries that I work with all provide a functional development experience. I interface with a Postgres database, so there's libraries for that as well.

You mentioned Domain-Driven Design. I would recommend reading Scott Wlaschins book Domain Modeling Made Functional [1].

If you are interested in playing around with F#, a quick way to start would be to try SAFE stack [2].

From what I have read during the last couple of months, MS seems to be interested in pushing F# as one of their go-to languages for machine learning. At least they have an F# example online [3], which can not be said for most other areas where F# would also be a good fit in my opinion.

[1] https://fsharpforfunandprofit.com/books/ [2] https://safe-stack.github.io [3] https://dotnet.microsoft.com/apps/machinelearning-ai/ml-dotn...

Much appreciate your feedback and advice. I was considering using F# instead C# for my potential .NET-based solution. But not because of Microsoft's ML push for F# (which seems to be just a move to achieve feature parity with C# within ML.NET framework, which, by the way, is not as comprehensive as relevant Python ecosystem), but rather because of F#'s meta-programming features. However, the advantages of F# still do not overweight its IMO two main disadvantages: a much more limited (vs. C#) pool of available developers and limited support by tools beyond Microsoft ecosystem (e.g., by JetBrains products).

> a much more limited (vs. C#) pool of available developers

I don't plan to hire anyone in the foreseeable future but what I can say is that there's 2 people happily working on the F# codebase at the moment, that do not have any prior experience in the language (professional Swift/ObjC background and played around with other languages). Getting into it is quite easy if you're interested in FP. I wouldn't worry too much about that. Just get some people who are experienced in .NET and some people who are good in FP.

> limited support by tools beyond Microsoft ecosystem (e.g., by JetBrains products)

I use JetBrains Rider on a Mac, without major problems so far

Fair enough. Thank you, will keep this in mind.

Google Jetbrains Rider.

Do not worry about the pool. The limiting factor in finding good people is the good part not the programming language.

Thank you for sharing your thoughts. I'm aware of JetBrains Rider. In fact, I have installed it on my desktop and used it to explore the above-mentioned .NET boilerplate templates (C#-based). Perhaps, I missed that Rider fully supports F#. Will check it out.

Re: finding good people - I certainly agree with importance of focusing on the good part. However, still ... having a significantly larger pool of developers statistically increases chances to find good ones (which is important, especially considering competition with big tech firms in hiring engineering talent).

Does it?

I mean, if I see a good developer who is interested in learning F#, that means I have found a good developer who is interested in learning something off the beaten path.

For certain organizations that is exactly what they need.

I think that you're missing my point about the statistical nature of engineering talent hiring. My argument is that you will have higher chances to "see a good developer" in the first place, if relevant pool of potential candidates is larger (of course, under other equal conditions).

Another aspect of that: do not do functional programming then. There are statistics for .NET which surely also apply to most languages: 10 million C# devs, 1 million VB.NET devs and 100k F# devs. By requiring functional programming the candidate pool shrunk by a factor of 100.

There is certainly a higher factor of high talent in FP capable programmers but at the same time the risk for bad hires due to lacking people skills or overly dogmatic work style increases.

Good points. Thank you for bringing them up.

But if you hire "programmers" and train them in F# on the job instead of looking specifically for "F# programmers" you sidestep that problem.

My organisations job ad is looking for people with "several years of programming experience by the way we do things in C# and F# but do not expect you to have".

Then we weed out the huge majority by issuing a tiny take-home code test (think a few fizzbuzz-style questions) that applicants can complete in whatever language or environment they want.

So far, we've received positive feedback on the approach, but also very few truly talented applicants. I think the latter is because we're extremely picky, but I don't know.

What I do know is that we wouldn't get better or more qualified applicants by limiting our search to a few languages. Some of the best so far have come with a language we would never have thought to list.

Thank you for sharing your feedback. Your approach certainly makes sense and I'm also not a fan of listing specific programming languages (as well as stacks, frameworks, platforms or products) as strict requirements. However, in my book, it makes sense only for mature companies and later-stage startups. Early-stage (especially, bootstrapped, small and non-VC-backed) startups simply cannot afford to spend time for training on the job.

Very good point regards training on the job. Indeed a factor to consider in discussion about early stage recruiting!!!

Thank you!

I think with the right, bright people, they'll train themselves in no time. But sure, that shifts the problem from getting "people who know F#" to "people who are very intelligent and experienced", which might be equally hard if not more so.

I believe it's worth it, but have no data to back it up.

Fair enough.

There's another point of view: that by targeting people who either know, or are interested in learning F#, or any other less popular language (like Rust, Erlang, Julia, etc.), you massively increase the quality of your applicant pool.

Developers that just want to pay the bills learn the popular languages: Python, javascript, Java, C#, Swift, etc. Developers who plays with (or maybe find little projects to do with) the like of F# are statistically more likely to care about their craft, even if they don't necessarily have the possibility to use these at their current jobs.

If someone contact you specifically because they want to use an FP language, but they can't at their current job, it's a very good sign. Of course if you limit yourself to something like: 5 years of experience writing F# in insert field of interest here, it's going to be very tough to hire anyone...

Generally, I agree with you, except for the argument that developers who play with (or do projects using) less popular languages "are statistically more likely to care about their craft" (do you have any data supporting this claim?). Being curious, while certainly a valuable trait, is not equivalent to "being caring" about some craft - it is a nice addition to the package. However, it is a bit more nuanced than that. For example, success or failure in using this strategy depends on startup's stage, funding, roadmap, team size, engineering culture as well as current or potential use of microservices architecture, which gives us much greater flexibility in a relevant technology stack selection.

I've been building startups for 15 years using .NET

It's incredibly fast and productive and has allowed me to create more as a single-person than entire teams using other languages. That still remains true today, even more so as it removes many of the limitations of the Windows-only desktop framework.

Even if you can't use C#/.NET for all the functionality you need, there are many ways to interface with other stacks from function calls, inter-process communication, RPC frameworks, etc. It's well-supported and very common now with the rise of microservices anyway. For AI/ML specifically, I suggest looking at the Machine Learning docs which list plenty of projects like ML.NET and integrations for Tensorflow and Spark.

https://dotnet.microsoft.com/apps/machinelearning-ai/

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.

> 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've worked at a startup that did this.

I don't know if this was the program we used, but you can get a LOT of free stuff from Microsoft as a startup. https://azure.microsoft.com/en-us/overview/startups/

>Between Python and .NET ecosystems, I'm more familiar with the former and, under equal conditions, would choose it over .NET.

I think one thing you need to do when creating a startup is, go with what you know (as you said). You want to decrease the risk that you're product is going to be blocked by encountering an edge case in a framework/language you don't know and you get stuck there for a long time. I am way more familiar with .NET than Python, but I use Python in my spare time and on side projects to build up those muscles.

If you're doing a startup and you want to go .NET, I don't think there's anything holding you back anymore. It's open source now, runs on Linux, and you don't have to pay a dime to develop with it. Microsoft will get you in that, it's WAY easier to pay a little bit to get Visual Studio Enterprise and to then hook that into Azure and all of a sudden you're paying them a ton of money. Yes, that's their master plan. But, no one is making you do that.

Where to stay away from .NET core: Lambdas. The startup time for Lambdas just isn't where it is for other languages, when I last looked at this. If someone has newer data to prove me wrong I'll freaking LOVE YOU FOREVER!

Anyway, depending on what and how you're building your startup, .NET maybe a great pick for you depending on your background. I wouldn't force myself to pick up a new ecosystem and do a startup if I was focused on delivering a product I wanted to deliver and not learning something new and cool.

Great feedback, much appreciated! I'm familiar with Microsoft for Startups program and I'm still considering it, though currently it's not a priority. I agree with most of your thoughts above. Don't have experience with .NET-based Lambdas, though, so I don't have an opinion on that yet. As for what I'm building, well ... I'm building a comprehensive (read: large) and complex B2B enterprise SaaS platform focused on a particular multi-disciplinary scientific domain. I'm a solo founder and have technical (and research) background, including software development and IT architecture experience.

Visual Studio Code is great and Jetbrains Rider is much cheaper and very capable. You can skip VS Enterprise for most projects, and the Professional version also costs a lot less if you just need advanced debugging.

Also Azure isn't really necessary at all considering the ubiquity of Docker and Kubernetes. I've been running .NET programs basically everywhere else other than Azure for a long time.

1000% Agree with everything said here.

Microsoft makes is stupid easy to use Azure, but that doesn't preclude how easy it is to use other hosting. It's like, you can have an iPhone and a windows laptop, but it doesn't integrate AS well as iPhone and a Mac.

I worked for two consultancies that basically created apps for multiple startups and we used .NET Core in almost all projects. I don't really have comparison because besides simple, personal Django projects I never had much experience with Python but I find .NET Core actually enjoyable(I come from Android Java/Kotlin world). I don't like the community which is, mostly still stuck in the enterprise(though that's changing alowly) and often feels like an MS cult, but otherwise, there's nothing bad I could really say about .NET. Especially when paired with Azure ecosystem, it's really easy do develop and deploy, it's really fast, easy to work with thanks to Entity Framework and stuff like LINQ, there's a lot of choice in libraries. Some are still stuck in .NET Framework(Windows) world, but most of Nugets already implement at least netstandard2.0 which allows you to use them with Core. In overall, especially now with Blazor becoming a thing, I'd recommend at least trying it out.

I don't quite get the hype around Blazor. Great idea but the implementation is a non-starter considering it has to send a whole runtime over the wire.

We use it in server-side mode (no WASM assembly to deliver). SSB is incredible for apps where you are expecting a well-bounded number of concurrent users.

We use it for internal business dashboards and devops management tools. The ability to inject & use existing .NET services is pretty incredible in terms of productivity. We now maintain a monorepository because of this reuse potential.

https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-...

It's amazing. I've been using server side blazor and it's been quick to develop, performant for users, and more interactive than SSR.

Down side is scaling, but I mostly write B2B apps. And by the time you run into scaling issues in B2B SaaS someone's rich.

Blazor is the first frontend component model framework built for the web that isn't older server-side templating and also not Javascript. Using a strong typed language like C# makes it very fast and productive, especially when reusing the same code and libraries with your server backend (something that was touted with node/JS but has been weighed down by the chaos of the JS ecosystem).

Blazor can also run in 2 modes:

1) server-side where the UI is controlled by a websocket (via SignalR) connection to the backend which processes all the logic. Developing complex interfaces becomes much easier because everything runs on the server and the distance between a database query and UI update is very short. Save the verbose JS->API->Backend layers of code.

2) client-side which uses cutting edge WebAssembly to run your app. The WASM version is getting smaller and faster with every release and isn't much bigger than your standard big SPA which also has megabytes of javascript these days. It has a great JSON library and can also support GRPC-Web now for easy RPC.

Typically modules come with their own contracts. Even in the backend by itself, we see same class definition as a model, as an entity and as a business object. OOP also had goals regarding reusability (see criticism section - https://en.wikipedia.org/wiki/Object-oriented_programming). Reusing the same code is hard.

True, but it's much harder in some languages than others, and much much harder when crossing language boundaries.

Copying a C# class to use as a DTO from a database entity is way faster than trying to worry about serializing to a JSON structure while maintaining all the fidelity (like dates, big ints, binary data, etc).

Another example is reusing business logic like validation for data input. Blazor lets you use a single layer of logic instead of using JS-based simple validation on the form and more detailed checks on the server.

I appreciate your prompt feedback with interesting details. Re: Blazor - while it's definitely a promising technology, I'm not sure how suitable it is for building SPAs. One potential issue that I can see is quite limited (and IMO very expensive, e.g.: https://www.syncfusion.com/sales/products/blazor) UI components ecosystem, when compared to the React/Vue/Angular one (I plan on using Vue).

You might qualify for the Syncfusion Community License: https://www.syncfusion.com/products/communitylicense

Radzen also has a component library available: https://blazor.radzen.com/

https://abp.io/ recently added Blazor to their framework that you might want to check out.

Thank you for your advice. The Syncfusion Community License is certainly interesting and I will keep it in mind (as well as Radzen). Though, frankly, I don't like these "lure into an ecosystem/platform/product with free goodies and then lock in to a very expensive deal" approaches. I prefer a decent progressive pricing tiers model. Re: ABP and Blazor - yes, I read about that, but I think that it is still an experimental feature: https://github.com/abpframework/abp/issues/394.

I didnt specify but we actually mostly use server side Blazor for now. The only issue with it so far is lack of proper hot reload which is annoying but manageable. Otherwise, it's really great. It's kinda an equivalent of Phoenix' LiveView. You only really send diffs over the wire, everything happens on the server, code sharing is very easy and makes developing very, very fast. Sure, SignalR might not be that scalable but IMO unless you're a giant with tens of thousands of active users at any given moment, I wouldn't care.

Interesting and good to know. Thank you for your additional clarifications. I would love to get my hands dirty with Blazor and many other technologies. The problem with being a very early-stage startup, despite being very tempting to jump the cutting edge bandwagon and (try to) use as many cool technologies as you can get your hands on, is to keep in mind the importance of risk management. More often than not, it makes sense to select a "boring" technology stack (http://boringtechnology.club), at least, for all or certain foundational layers or components of the larger system.

> Has anyone here used (or are familiar with relevant cases of using) .NET for developing startup products, including MVPs?

Yes, I have. I've been programming with C# since it was first released, so we're very well acquainted, and I can build MVPs quickly. As always though, it depends what you are used to.

> I'm seeing .NET as predominantly an enterprise-focused technology

I didn't see it as any more enterprise-focused than Java, andid say less so since dotnet core brought multi-platform support.

Thank you for your feedback. When I said "predominantly an enterprise-focused technology", I meant overall popularity for building in-house enterprise products versus developing startup products. Anyway, should I decide to use .NET, I would most likely use a high-quality boilerplate solution as a foundation. Specifically, I'm a big fan of (and have already played with) ASP.NET Boilerplate and its next-gen version called ABP Framework. They also have relevant attractive commercial versions.

I should have been clearer, but I meant for building MVPs for side-projects and startups (although I have actually built many an MVP with C# in the Enterprise world too).

I see. Thank you for the clarification.

I'm using .NET Core/C# as my backend for a WebXR project for remote learning of foreign languages. After a brief learning curve with ASP.NET Core (I used to do a lot of WebForms work before pivoting hard into VR) I'm enjoying it a lot.

Cool. Thank you for your feedback and good luck with your project.

Use what you know and run fast. Any day you've spent debating this is a day you aren't closer to shipping.

Thank you for your advice. I understand where you're coming from, however, I respectfully disagree (plus, in my case, your advice is not much applicable, since my knowledge and experience with Python and .NET ecosystems are not that much different - I still will need to master quite a lot of topics and aspects). If I would be debating which UI styling to use, which relational database to use or even which front-end framework to use, I would agree that it does not matter that much and should be based on existing knowledge and skill set. However, I strongly believe that spending enough time to select the best/optimal technology stack for the target product is worthwhile and will provide a high return on investment. You don't want to skimp on architectural decisions, since fixing the wrong ones will cost much time, money, effort and, sometimes, will even be outright impossible. Hence my deliberation.

My startup's target is actually to close the AI gap. We are re-exposing the entire TensorFlow Python API in C#: https://losttech.software/gradient.html

Thank you for chiming in. Interestingly enough, I ran across your startup not long ago, when exploring ML/AI landscape of the .NET ecosystem. Good luck with your venture. By the way, do you have plans to support other popular frameworks beyond TensorFlow? Just curious.

There's no plan to support any non-NN frameworks.

We might decide to add PyTorch support, if its adoption will continue to accelerate. But that won't happen for at least a year.

Understood. I certainly didn't mean non-NN frameworks, but rather meant other popular NN ones (PyTorch, MXNet, etc.).

I assume you are aware of Direct.ML and its Tensorflow integration?

https://cloudblogs.microsoft.com/opensource/2020/09/08/open-...

Yep, and it is currently many times slower than CUDA version on Nvidia. Haven't had an opportunity to compare tensorflow-rocm with it on AMD yet.

Sure, all the best for your endeavours. We need better managed language support for GPGPU.

> I plan to use FastAPI instead of more traditional Flask and Django

Why?

Because FastAPI is much faster* than both Flask and Django (see https://www.techempower.com/benchmarks/#section=data-r19&hw=...), supports Python type hints, is a great fit for my target architecture (SPA), supports both RESTful and GraphQL API styles, offers built-in validation and much more (https://fastapi.tiangolo.com/features).

*) Having said that, from the performance perspective, .NET Core and Julia (from my options) are certainly much more tempting.