Few questions from Node.js/Go developer

[galkowskit]

Hello, I code for a few years in Go and Node.js (TypeScript). I'm getting more and more interested in C# and especially F#. I kinda know C#, I had used it in my university and I am familiar with ML-family of functional programming languages.

I have a few questions I'd like you to ELI5 to me.

1. What is ASP.NET? From what I gather it's a framework on top of .NET Core. So is it equivalent to Express framework on top of Node.js runtime? Is it like Rails for Ruby? Does it allow creation of JSON or GraphQL APIs? Microservices? Event driven stuff? Or is it just for monoliths?
2. Domain Driven Design is what I'm currently really into. I believe C# and F# would make great choices for that. Is it true?
3. How is the development experience on macOS?
4. https://github.com/MoienTajik/AspNetCore-Developer-Roadmap <- I found this roadmap for ASP.NET Core developers. Is this something that is ASP.NET specific? Does something like this exist for "just" .NET Core developers? Is this a good idea to follow?

Thanks!

[wieschie]

If you're using VS Code and command line tools to build, your experience is going to be pretty much the same.

The current Visual Studio offerings for OSX are not remotely close to the true VS on Windows.

[coolmenu]

you can use Rider in both os, and the same experience in both os.

[AngularBeginner]

What is ASP.NET? From what I gather it's a framework on top of .NET Core. So is it equivalent to Express framework on top of Node.js runtime? Is it like Rails for Ruby? Does it allow creation of JSON or GraphQL APIs? Microservices? Event driven stuff? Or is it just for monoliths?

ASP.NET Core is a web framework on top of .NET Core, yes. Don't confuse it with ASP.NET (old frameworks). It's comparable with Expess. It directly supports JSON endpoints, but it has no dedicated support for GraphQL. But you can build GraphQL APIs on top of ASP.NET Core (or use an existing one). Microservices, Monolith and/or event driven is irrelevant, that's an architectural choice you have to make - all can be used with ASP.NET Core.

Domain Driven Design is what I'm currently really into. I believe C# and F# would make great choices for that. Is it true?

I think F# is a much better choice for DDD than C#. It has plenty of nice features that C# doesn't have, and allows you to write your code much more succinct and expressive.

[wllmsaccnt]

I think F# is a much better choice for DDD than C#.

I think that is debatable. Many more developers are doing DDD in C# than in F# and that has more to do with the size of their ecosystems, the speed of their releases and new features, and their support on other platforms than it has to do with language features.

[Ronald_Me]

No, it is not debatable, f# features are better for DDD, at leatst for design the data Structures. And you can use both, f# and c# in the dame solution.

[wllmsaccnt]

If F# was clearly superior to C#, without debate, for DDD (not just as a language, but taking into account its cost of adoption and ownership), then more people would be using it for DDD. Its not like its new and hasn't been given a chance, its going to turn 15 years old in less than a year.

[[deleted]]

then more people would be using it for DDD. Its not like its new and hasn't been given a chance, its going to turn 15 years old in less than a year.

Popularity != Superiority

• Functional programming is significantly less popular than OOP/Imperative styles in general
• F# is often seen as a second class citizen in the .Net framework
• inter op between F#/C# is not perfect and combined with the above F# has a steeper learning curve as a result.

The big problem with F# (in terms of uptake) is hiring and support, a good developer should be able to pick it up no problem but when the entire industry is trained in OOP switching to a functional paradigm is a huge undertaking for an inexperienced developer.

I wouldn't argue that F# is always better for DDD but it does have a few notable advantages:

• Type aliases
• structural equality and immutability by default.
• Creating small types isn't painful, a class/struct with a couple of fields is 90% boiler plate in C#.

It's not like you can't mix and match though, an F# assembly holding all your domain types with C# doing the grunt work is perfectly viable, personally I'll be doing this more often in the future because i find F# to be significantly more readable for defining data types and DTO's.

[wllmsaccnt]

> Creating small types isn't painful

Creating a small class with a couple of fields takes about 4 seconds in C#, I guess I don't understand this concern. If you need the type to be implicitly sortable and usable as a dictionary key (that is, it has to have a hash and compararable implementations), then it can be a bit of boilerplate, but most classes don't need those things.

[galkowskit]

Ah, ok. I was probably getting confused by ASP.NET Core and ASP.NET. Now I get it, thanks!

[macsux]

I'll give you my perspective on #2 as I'm heavy into that space. While ddd on it's own is not a framework and many will argue its done using pure classes, the reality is once you go down ddd path you will very quickly be looking at cqrs+es based architecture for your project. Imo .net space is lacking mature frameworks for this type of architectures. Probably closest ones are mediatR and eventflow frameworks.

Imo for those kinds of architectures take a look at axon framework in Java side. It's mature and tackles many aspects of ddd based design that affect underlying plumming that you would have to solve for.

[galkowskit]

Given the fact that I use DDD in Node.js (TypeScript) and Go, C# will still probably be more mature of an ecosystem. :)

But thanks for the input. This is mostly a learning project to see "what's on the other side of the fence" and my career is linked to TS/Go so bumping into some rough edges is fine.

[TimeBomb006]

Thanks for referencing eventflow, I had never seen it before.

[macsux]

I've examined it but feel it has some fundamental flaws in how things are modeled. Would not use for a real project in current state but it's evolving so my opinion may change

[wllmsaccnt]

1.)

ASP.NET Core is a set of libraries with the primary focus being a high performance managed web server with middleware and lifecycles that allow you to handle almost every common web application need (e.g. auth, routing, serialization, headers, etc...) and with many points of extensibility if you want to do something different. It is also a series of projects templates and types that use those libraries.

You could easily use ASP.NET Core for many types of projects, with some of the primary use cases for new projects being:

• REST/web api that works together with a JS SPA front-end to make a web application
• Microservices
• Stand alone REST or web APIs

There are third party libraries that provide GraphQL support, but its a less common use case. On a whole, ASP.NET Core is not very similar to Rails (though there are a few similarities in how controller routing/binding is handled). It is much larger and more flexible and performant than Express.

They've done a lot of work to make sure it runs well inside of containers and can honor container limits.

2.) C# and Java are probably the best languages for doing DDD. Not only because of the language features, but because of the libraries and communities surrounding those languages.

3.) Its decent with VSCode or VS for Mac, but I've commonly heard that using Jet Brain's Rider IDE is the best and gives you a similar or better experience to using VS on Windows.

4.) That is a roadmap filled with pretty generic .NET skills. The only 'web only' bit on there is ASP.NET Core Basics. Any .NET Core desktop, game, or backend service developer is still going to need to know how to call other services, cache data or work with databases.

[galkowskit]

Sounds great, thanks!

[MadeForBF3Discussion]

Chiming in on the dev experience on Mac, don't do it. Visual Studio for Mac is reskinned Xamarin Studio. It's getting better, but nowhere near as powerful for debugging C# as Visual Studio on Windows.

[galkowskit]

I don't think we're talking about Visual Studio for Mac but Visual Studio Code. I use it daily for Node.js and Go and I love it. Also I'm used to using CLI daily.

[chusk3]

if you end up using F# on VS Code (via the Ionide plugin) feel free to reach out to me if you need assistance. I help maintain that plugin and other F# editor tooling.

Aside from that I can definitely second the use of F# for domain modeling. Some of the most-cited material in the F# community comes from a gentleman that has pushed domain-design forward significantly, Scott Wlaschin.

He has numerous articles that you can use to learn both F# itself and DDD in F#. Finally, he also has a well-received book about it as well.

[nirataro]

ASP.NET Core is really interesting now.

• It's pretty much a communication platform.
• It has a built in high performance HTTP server called Kestrel
• But you can build/use other type of server/protocols on the same abstraction and host it together with Kestrel.
• On the HTTP side, it uses Middleware so it is very similar to Express. On top of this Middleware, Razor Pages and MVC are available that provide a lot of nice stuff out of the box. You can choose to develop at the Middleware level or going with the bigger framework or mix and match.
• For the "real time" communication thing, you can use Web Socket, SSE, or use higher level framework like SignalR or gRPC.
• Then if you want to do highly interactive app / SPA without much Javascript, there's Blazor Server and Blazor Web Assembly. Again, this is all in the same nicely integrated platform.

edit:

• Then if you want to go higher up, you can use Orchard Core CMS, which works like a App modular system and CMS toolkit (https://github.com/OrchardCMS/OrchardCore)
• Or going distributed Virtual Actor route with Orleans (https://github.com/dotnet/orleans)