I disagree; C# is bad by comparison. I cannot think of a single reason to use C# over F#, can you? F# is essentially C# but with better defaults and much more easily extensible.
- Accessing the DB is easier in C# (just select a nice micro-ORM), type providers do not always cut it.
- When using any kind of library that relies on anonymous types (e.g. Dapper for database access).
- Tooling is still not complete, not being able to create directories in F# project (!) from IDE level (and even if you edit .fsproj, it can be a bit buggy) is really annoying in both web and desktop apps.
- If you want to use some of object-oriented features e.g. co/contravariance in interfaces, protected access modifier.
- (admittedly, that does not happen often) no unsafe context/keyword
That being said, I agree that F# has a very sane set of defaults and I really like using F# for library work.
The rest of the real arguments are essentially "library support". Which is a good argument, but not really about the language itself. There's no reason that WPF, DB access, etc. can't be just as fine in F#.
(C#'s limitations, like no tuples, led high-profile projects like ASP.NET MVC to do dumb hacks like "pass in an object and we'll assume each field is a parameter". If C# had been more capable in the first place, they wouldn't have resorted to such hacks.)
You shouldn't be writing WPF apps at all.
Says who? Are we supposed to stop writing Windows desktop apps in C# just because the frameworks are in maintenance mode?
And you can use F#! http://funscript.info/
As mentioned, not a big fan of transpiling.
In general, I find writing in C#, I'm going to need 50-200% more code for "business logic" type code that doesn't particularly benefit from F#. That is, using F# as a better C#. And this is after C# hacked in async - before that, there's no comparison if you need async style code.
If C# added pattern matching, tuples, active patterns, type inference, everything-as-an-expression, nesting, more comprehensions, etc. etc., then yes, C# would be competitive. And with all the resources C# gets, the IDE would be far better than F#, sure.
C# is for legacy and large corporate red-tape-encumbered enterprise projects only, as far as I'm concerned.
But then what of C#, which lacks object expressions? Which forces you to declare a type, often an interface, just to implement a member or two?
In the enterprise C# is the way to go. You won't find many Fortune 500 companies, with offshoring projects, going F# instead of C#.
For many 9 - 5 developers, C# is already too complex, many of each are ex-VB developers.
F# lacks the Visual Studio tooling support for the typical enterprise projects workflow and frameworks.
Usually it is C++ > Java > C# > VB.NET > .... in the Fortune 500 world set I work on.
Not to mention the C++ salary rates in High Performance Finance and High Performance Computing in general. I doubt any C# developer would get those rates.
It is a pity. I did do some C# work but preferred writing C++ hence I do it as a day job now (and a sideline for fun too!).
Even Java jobs are offered for more than C++.
Clearly not all places are equal. :)
I did C++ for many years, was on the C++ side since day one on the C vs C++ wars, since 1993.
Nowadays mostly Java, C# on the job. C++, among others, mostly on hobby projects.
Given my Turbo Pascal initial background I still prefer more memory safe systems languages though. Although modern C++ surely feels good.
Ideally, a "work from home" remote job would suit me where I get to write C++ all day. Know anyone offering such a delight?
What hobby projects do you write? I am working on a scheduling system.
Not much nowadays, as family and friends take most of the time.
Also, the .NET libraries we end up using were, to my knowledge, written in C#. Sometimes interacting with them feels awkward if done functionally.
I noticed that was something certain folks tended to do, they'd insist on creating an expression as a series of folds and maps, even if it had a very simple expression otherwise (as a list comprehension or simple for..in loop). Cast those cares aside, and write what is most useful for your use case.
Sometimes though, you do want break/goto/continue, although in most cases I think such code is better off in C or Rust.