I was kinda looking at migrating my project over to .NET Core/.NET 5 lately... turns out that despite bringing over Windows Forms and WPF support, Microsoft refuses to port System.Speech for text-to-speech and speech recognition.
Turns out the reason why is that since the Speech team moved under Azure, the Speech team considers System.Speech "replaced" by Azure's cloud-based speech services. Kinda takes any idea I had of moving to Microsoft's modern platform off the table for me, because local-only functionality is a must-have in my book. And there's no reason my Windows machine shouldn't be able to do the same local-based speech capability PCs have had for the past couple decades without the cloud.
> Microsoft refuses to port System.Speech for text-to-speech and speech recognition.
I think it's more complicated than just 'porting'... Something tells me that System.Speech is a nice wrapper for a very windows specific API. Similar to how Microsoft isn't bringing over WCF Hosting (Because too many parts of it are dependent on Windows itself.)
Now, ideally, it would be nice if Microsoft would expose the existing System.Speech source code, so that somebody could begin the efforts of making it into an OSS Project that could eventually become multiplatform.
Windows Forms and WPF are also both Windows API wrappers, and they've been brought over for when you are targeting Windows-based platforms.
System.Speech is no longer available on Windows in .NET 5, even if you're using Windows Forms or WPF, which are Windows-only frameworks.
In theory, if Microsoft was at least holding up compatibility for such things on Windows, I could move my target towards .NET Core/.NET 5, then gradually replace Windows-specific code with cross-platform code. But as per usual, I'm getting the impression it'd be easier to start over than migrate.
I agree it'd be really nice if they open sourced the code necessary to look at porting System.Speech, but I imagine it'd be unpleasant as a business decision: It'd erode their ability to bill people for the Azure "replacement".
.NET Core/Standard already has windows specific API's, and .NET 5 is going to make them safer to use going forward with static analysis[0], so I doubt the Windows specificness is the reason why.
They could treat it like the UI stuff and make it windows only but still in Core 5. But there are other things that aren't getting ported forward for various reasons like WCF.
As WinRT fanboy, I must admit that with Project Reunion, everything UWP related in now in a chaotic state without any clear roadmap on how everything will move forward, just high level ideas.
So I wouldn't bet in anything WinRT related for the time being.
I investigated a little bit, but most of the speech libraries on NuGet are either wrappers for Google/Microsoft/Amazon/IBM cloud services, or are dependent on System.Speech anyways.
It's plausible if I really wanted to, I could run a separate service/application from some non-.NET-based alternative, but the integration is likely to be a lot messier. Right now, I'm not sure .NET 5 offers a compelling reason to drop .NET Framework, which Microsoft will presumably continue to support for at least the next decade.
Microsoft still lacks a cross-platform desktop UI framework, they have no project template in Visual Studio that would let you write a service that can run as a service on both Windows and Linux, and .NET 5 is missing lots of Windows integration functionality like System.Speech as well. I'd really like to make my project both run as a service, and run cross-platform, but there doesn't appear to be a good path to do either one with .NET 5 yet, and it'd likely take substantial rewriting just to get my project to .NET 5 on Windows.
> they have no project template in Visual Studio that would let you write a service that can run as a service on both Windows and Linux
I have lots of complaints about the state of the .NET ecosystem, but thankfully this one is pretty easy IMO. Basically just use the `dotnet new worker` .NET Core template; it scaffolds a project using the ASP.NET Core generic host, which can easily (a NuGet package and 1 line of code) be adapted to run as either a Windows Service or a systemd service on Linux.
It might be somewhat simple, but their paid Visual Studio IDE demonstrates no way to get there, and it probably should. The only project types tagged as services are .NET Framework templates to make a Windows service.
I have to apparently read blog posts about how to get there myself with .NET Core. Suffice to say, Microsoft's move to the open source/Linux mindset may have come at the cost of being similarly confusing to get started with.
Note that your blogs happily tell me to add a single NuGet package for Windows or Linux, but doesn't bother to tell me how to assemble a project that will work on both.
> Note that your blogs happily tell me to add a single NuGet package for Windows or Linux, but doesn't bother to tell me how to assemble a project that will work on both.
Well, the rest of the owl is fairly simple in this case.
System.Runtime.InteropServices.RuntimeInformation.IsOSPlatform() can be used to query the OS type, and you specify which builder option (i.e. if islinux UseSystemd ) to use there. I'd type a proper example but on a cell phone.
All of that said, YES you think they would document this better.
I mean, fundamentally it shouldn't even be "documented". They should have a template that just does it. I should select the Service (.NET Core) template, it should give me the start, restart, stop, etc. points to start adding code, and I should be able to select Windows or Linux as build options by default.
Anything that requires I go read a blog post is a massive regression from legacy .NET Framework templates, where I never had to know how a service is built.
Visual Studio has traditionally done most of the heavy lifting on managing scaffolding, but in the past couple releases I've found things are often broken unless I go manually edit some file that I previously never had to edit which can't even be edited from within the IDE.
I'll agree with you there. I'm not a fan of the scaffolding and the overall obtuseness around applicationbuilder, before I understood it the thing felt more unintelligible than a monad burrito to a first year cs student.
Seems like you can just call both UseWindowsService() and UseSystemd(), they will no-op if called on the wrong platform. Personally I think I'd rather split Linux+Windows into thin OS-specific projects, but I haven't tried that. Agreed that a template or better documentation for this kind of multiplatform scenario would be nice.
And if Microsoft wanted to bless Avalonia as such, great. In 2020, .NET shouldn't have like three Windows UI frameworks and zero officially recognized cross-platform ones, particularly if they want .NET Core to take off.
Out of everything in the new 5.0 release, I am looking forward most to the non-generic TaskCompletionSource. This is a primitive that has been bothering me for some time WRT tasks that return nothing. I've been resorting to using bool as the generic type argument and discarding the value in these cases.
Also, C# 9.0 is really cool. Will be abusing the new pattern matching stuff once we get a chance to upgrade. Looking like 3.1=>5.0 is going to be a non-event for us based on the current migration guides.
I'm most excited for records and `with`. This is a feature in C# I've been wanting for years and will really help make the use of immutable data throughout a system easier with a ton, and I mean a ton, less boilerplate.
Records are good, although in typical Microsoft style they've elected to call the new constructor syntax "positional" instead of "primary", and then subsequently failed to generalize the feature to normal classes.
With is just building on the anti-pattern where .NET programmers are too lazy to implement constructors.
The new with-expressions are a concession to the existence of initializers, which are themselves literally "stuff that should have been in the constructor" and are incompatible with immutability (hence the new init property hack).
The correct path would have been to require primary constructors for records as the only point of entry for data, declare initializers incompatible with primary constructors, and then just synthesize a method for creating copies - but hey, then you might as well just use Scala.
Speaking about the new records, it bothers me that the keyword in the class declaration is "data" but they call it "record". Why not just name it record? Or "value-data" or something more descriptive? Considering it's one of the biggest languages today, I'm assuming they have ton of people working on it, so I'm clearly missing something here. And why still call it a "class" in the code? Could just have been have keyword instead... So many questions
Seems my previous comment was based on outdated/wrong information, I'm sorry and thanks for clarifying :)
Edit: Seems the post I wrote was published 20th May (probably written before) and that was the same date someone said the same thing as my comment here in the discussion about the "records" feature https://github.com/dotnet/csharplang/issues/39#issuecomment-...
Ha, I don't know if you worked on this but I had hopes when I saw you'd gone back that maybe we'd finally see records. I'd been seeing your name on record proposals forever.
> I am looking forward most to the non-generic TaskCompletionSource
That has always seemed like a strange omission, but I can't say it's really caused me distress :)
Personally, I'm looking forward to the `half` type, the extra GC diagnostic info, improved app trimming, improved ASN and certificate handling, and of course the improved performance and increased reach of Span. But I think most of all, I'm looking forward to a long term plan and no more .NET Standard/Core mismatch.
> I've been resorting to using bool as the generic type argument and discarding the value in these cases.
After seeing other libraries do so, I've fallen into the habit of using a singleton 'Unit' or 'Empty' Type. (This technically also falls in line with the .NET conventions of DbNull.Value and Missing.Value)
Actually, typing that out, I wonder if we all should have been using Missing.Value all along? :)
DBNull is my least favorite part of any version of any .net thing I've ever seen. I hate it with a fiery passion. It forces otherwise sensibly typed variables to be `object`, among a host of other sins.
idk. Null in an object versus null from the database could mean something different so DBNull makes sense.
Also, I don't see how you could say DBNull is responsible for forcing object on us. They could have just as easily made it a struct and i dont see what it would solve.
> Null in an object versus null from the database could mean something different so DBNull makes sense.
Fortunately, it's super easy to tell the difference. `DatabaseQuery()` vs `SomeOtherFunction()`. See?
> Also, I don't see how you could say DBNull is responsible for forcing object on us. They could have just as easily made it a struct and i dont see what it would solve.
Doesn't matter. Even if it was a struct, the only way to store both kinds of value in one variable is to declare it an `object`, even if it was a struct. `null` is a perfectly legal value for a `string` variable, but as soon as the possibility for some other null object (or struct) is raised, the target variable must be `object`. C# doesn't do unions (as a first class language feature anyway).
None of that helps. A nullable int is `Nullable<int>` or `int?` for short. There is nothing about the language feature that allows you to represent null with a totally different type like `DBNull`, other than declaring your variable `object`. What's the return type of a method that sometimes returns `int` and sometimes `DBNull`? It can only be `object`.
I seem to be having some trouble explaining my point. Maybe this will illustrate better. What should be the declared return type of this method?
Why do you need to represent `null` with another type? Is this just an issue with DB query results? You can avoid it by making sure the query never returns null or read the values yourself using a type cast test:
int? someNumber = resultset.Records[0]["some_column"] as int?;
There's a difference in certain contexts between 'null' (i.e., a reader that is not initialized) versus DBNull (the value has been set as null by the db or something else). I still think its technically correct.
I get that it was annoying, but most of .NET before 3.5 was anyway. It's just nobody bothered to make the right syntactic sugar.
For callers that care about the distinction, there should (IMHO) have been a GetNullFlavor(). Personally, the number of times I've actually cared is indistinguishable from zero. But the number of times I've had to deal with the infectious stench of DBNull is higher than zero.
My point is that DBNull is only an edge case with DB queries. You can avoid ever dealing with it as I've shown or use an ORM like Dapper or Entity Framework that also handle it for you.
There's really no reason why you have to touch DBNull at all.
I really wish that were true. DBNull is in third-party libraries. And first- and second- too. Check out this code. Dot net really wants me to use DBNull. No database in play at all.
var dt = new DataTable();
dt.Columns.Add("name", typeof(string));
//dt.Columns.Add("count", typeof(int?)); // NotSupportedException: DataSet does not support System.Nullable<>.
dt.Columns.Add("count", typeof(int));
var row=dt.NewRow();
row["name"] = null;
//row["count"] = null; // ArgumentException: Cannot set Column 'count' to be null. Please use DBNull instead.
row["count"] = DBNull.Value;
dt.Rows.Add(row);
Yeah I definitely miss having an Option<T> or Result<T> type in C# like F# has.
I also don't like that DBNull and Missing are reference types, it would be better to use a value type for this to avoid having to do null checks similar to Nullable<T> but I guess in this case it doesn't matter since they are used for different purposes.
I'm excited about new native interop api (function pointers, UnmanagedCallersOnlyAttribute, etc.). It removes "managed code tax" for calling into dynamically loaded OpenGL/Vulkan methods from c#.
I'm playing around with GLFW via PInvoke, which meant marshalling openGL function pointers into managed delegates. In net5.0 preview, I can simply cast IntPtr into a function pointer, and boy, a call to your average openGL method is literally an order of magnitude faster.
Similar optimizations might have been technically possible before, but it required some icky bytecode tinkering.
It roughly corresponds to my observation, and I find it fast enough for all practical applications, including GLES rendering on ARM Linux: https://github.com/Const-me/Vrmac/
Can someone please explain what .NET framework is? Everytime I come across it, it seems like a mysterious microsoft thing and Wikipedia's explanation is even more confusing:
> .NET Framework (pronounced as "dot net") is a software framework developed by Microsoft that runs primarily on Microsoft Windows. It includes a large class library called Framework Class Library (FCL) and provides language interoperability (each language can use code written in other languages) across several programming languages.
What is .NET framework really?
Elsewhere, it is described as "A framework to build applications in Windows", but I thought that's what the Windows API helps with.
Any help with clarification would be great, thank you.
.NET was built in the time of early Java, and so has many similar characteristics: virtual machine with a garbage collector, executes compiled processor- and OS-independent binaries, supports multiple languages, and a large class library. A lot of these early bets were good. .NET has been used in almost all the relevant computing devices today, to greater or lesser degrees of success (not all from Microsoft).
More recently, .NET has been focused on cloud native space and high-performance web applications. It has been open source and cross platform for about 5 years now.
At its core: It’s what Microsoft made to compete with Java back in 2002.
It’s a development platform, with associated tooling, compilers and a runtime. It has a common standard-library independent of language used by the developer (which aids cross-language interop), but realistically speaking most people just use C#.
You can use it to create network services, console applications, web assembly programs or desktop GUI applications. It’s quite versatile.
And .NET 5 will seemingly be the first version to officially supersede the previously Windows-only “.Net Framework” with a modern, open-source, cross-platform version instead.
Are you building and/or using any .NET desktop GUI applications _on_ linux? I'd love to poke around some open-source projects to see how these are being made today.
> And .NET 5 will seemingly be the first version to officially supersede the previously Windows-only “.Net Framework” with a modern, open-source, cross-platform version instead.
If it is any consolation, Microsoft's description of .NET at its first launch was even more nebulous than that. I avoided it out of sheer confusion at how it was going to wax my car, do my taxes, and save my soul.
I suppose that it's very similar in spirit as Java, with the difference that Microsoft presented in a more encompassing way (assuming that the definition of "software framework" was given by MS).
Often in fact Java is described as a language, while, at a minimum, a Java distribution includes the JVM and the standard library.
Describing as a software framework is therefore (in this sense) more exact, as the .NET framework includes the CLR and its standard library (and possibly, other components).
The difference with the Windows API is that they are lower level. The simplest possible component one may think of is probably LINQ - querying functionalities are intuitively higher level than system APIs.
It’s huge, has 2 decades of legacy, and has many parts. Here’s the main ones.
1. Virtual machine and JIT compiler, usually called CLR = Common Language Runtime, it runs byte code called CIL = Common Intermediate Language. They have renamed it a few times; older docs/tools may call the byte code MSIL = Microsoft Intermediate Language, or just IL. In modern .NET this thing is platform-agnostic.
2. Standard libraries for that runtime. The modern implementation is called CoreFX. It includes large count of batteries: collections, LINQ, threading and synchronization, async-await runtime, reflection, and much more. Fortunately, CIL is very compact representation of code, takes a small fraction of an AMD64 equivalent.
The lower-level pieces are platform-agnostic, but there’re many windows-only pieces implementing GUI and integration with other OS-specific services like WMI, registry, ADSI and more. For WinForms and similar they just use [DllImport] to consume Win32 and GDI+. For WPF this includes large amount of compiled C++ DLLs that consumes DirectX 9 to render GUI and implement resource-intensive algorithms. For UWP this includes COM interfaces to call native Windows APIs (albeit these interfaces might be a part of Windows SDK, I’m not sure).
3. Programming languages and compilers for them, the main ones supported by MS are C#, VB.NET, and to lesser extent F#. Modern version has a single compiler for C# and VB called “Roslyn”, F# is a separate program. There’re third-party ones, see IronPython. Also some .NET based products include their custom compilers or code generators who produce CIL code from something else in runtime, I did it a few times, not too hard.
There’re smaller pieces like framework SDK (a set of command-line tools to create, compile and run projects), msbuild (a build system typically used on Windows or for larger projects), and many other random programs/libraries of varying utility.
Update: Forgot an important component, NuGet package manager. It’s an equivalent of Python’s pip, or JavaScript’s npm, an online repository of code packages. The majority of packages there only contain CIL code, i.e. they’re very small and platform-agnostic. The most popular package there is an alternative Json parser, was downloaded 650M times. Microsoft uses nuget to deliver optional pieces of the standard library, developers like me are publishing their weird libraries too https://www.nuget.org/profiles/ConstMe
Yes. Also .NET native, remoting, WCF, asp.net, and lots of other things. Two reasons.
1. The ecosystem is huge. People are writing thick books on these subjects.
2. Most of the above (except asp.net) is windows-only stuff. Even on Windows, the stuff most useful if you’re maintaining something from 10-20 years old, less so for new projects, at least in my experience.
Well, C++/CLI support was the biggest feature for the .NET Core 3.0 release, so it does matter.
Although I do concede that most likely Microsoft would happily get rid of it, and have everyone make use of C++ code in .NET via UWP components instead, preferably using C++/WinRT.
To simplify things you can say that .NET consists of three things:
1) A garbage collecting virtual machine (like the JVM) that executes Intermediary Language (IL) by just-in-time compiling it to native code.
2) A set of programming languages (C# being the most popular) that compiles to IL.
3) A broad set of libraries that are part of .NET or available from the NuGet package manager. This includes basic features like collections, JSON serialization and cryptographic primitives but also huge frameworks for web development using databases etc.
In recent years Microsoft has open sourced big parts of .NET and basically rebuilt it from the ground up to make it cross platform. In the process a lot has been improved in terms of usability and efficiency making .NET a serious contender when it comes to building something like large scale cloud applications.
The next major release of .NET is expected in November where the "old" Windows only version and the new improved cross platform version (.NET Core) will converge into .NET 5.
You would definitely be excused for feeling puzzled. I got thrown into a full time cross-platform .NET development role with zero experience in .NET, and figuring out how it all fit together (especially a couple of years ago) was a nightmare.
Has anyone here used (or are familiar with relevant cases of using) .NET for developing startup products, including MVPs? With some exceptions, I'm seeing .NET as predominantly an enterprise-focused technology. Strategizing about development of my MVP (B2B enterprise platform), as a CTO, I'm torn between a) Python and its great ecosystem (I plan to use FastAPI instead of more traditional Flask and Django), b) C# and .NET ecosystem and - to a lesser degree, for the reasons explained below - c) Julia and its emerging ecosystem.
As much as I'm excited about Julia, I think that both the language and the ecosystem have not yet reached enough maturity and critical mass of developers as well as comprehensive and stable general-purpose libraries and tools to be a safe choice for a startup, which is already a highly risky venture. I have to reduce risks, not add ones.
Between Python and .NET ecosystems, I'm more familiar with the former and, under equal conditions, would choose it over .NET. Additional argument in favor of this decision is that most of advanced ML/AI development is focused on Python high-level interfaces (and ML/AI is certainly a significant part of my future platform's value proposition). However, based on my research and recent .NET experience, I recognize its advantages versus the Python stack in some areas, including native type system support (though pydantic might be good enough for the Python stack; plus, it is used by FastAPI), rich set of native APIs, much better performance, much better support for domain-driven design (DDD), WebAssembly support, and, finally, much better support for developing multi-tenant applications. The last item is especially important in my case, since multi-tenancy and other relevant features (e.g., auditability) are strict requirements and Python ecosystem pales in comparison with .NET in this regard (the only decent project that I ran across is django-tenants, but a) it would force me to use Django and b) it only supports PostgreSQL schema-based multi-tenancy approach).
Would love to hear your opinions and thoughts on the above. Thank you in advance!
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.
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
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).
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).
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.
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.
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.
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.
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.
> 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.
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.
>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.
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.
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.
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.
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 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).
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.
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.
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.
> 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'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.
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.
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.
Turns out the reason why is that since the Speech team moved under Azure, the Speech team considers System.Speech "replaced" by Azure's cloud-based speech services. Kinda takes any idea I had of moving to Microsoft's modern platform off the table for me, because local-only functionality is a must-have in my book. And there's no reason my Windows machine shouldn't be able to do the same local-based speech capability PCs have had for the past couple decades without the cloud.