9 ms·

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

by Touche 12y ago

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.

DrJokepu 12y ago
For me, writing procedural OO code in F# always felt awkward and inconvenient. This is a problem because most of the .NET runtime was designed with procedural OO code in mind.
math 12y ago
I trialed F# a while back. Something I certainly noticed was not having as much help from the IDE (no resharper). The lambda notation also annoyed me (by comparison to C#). Yeah, I know it's no big deal and I understand the trade-offs being made.. but it still annoyed me. Pattern matching is one of the draw cards - but I see that is coming in C# soon.
- edgyswingset 12y ago
  Did you give F# Power Tools a go? It gives you a lot of what is missing out of the box. It's still not as great as C# IDE support, but for most things it gets the job done.
- MichaelGG 12y ago
  While this may come across as sour grapes, I find generally I need less IDE help in F#, since I'm not typing as much boilerplate. For instance, almost all type annotations are inferred (20:1 in my own empirical study), so there's a ton of code I simply don't need to type. 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.
- CmonDev 12y ago
  Sadly F# had inherited all the OCAML luggage, including the arcane academic ML syntax.
nbevans 12y ago
This. F# is superior in every way. The constant stream of articles about C# 6.0 are getting ridiculous when .NET already has a language that is a natural successor. C# is for legacy and large corporate red-tape-encumbered enterprise projects only, as far as I'm concerned.
Hakeashar 12y ago
- Writing a WPF app in F# is a real pain (no partial classes, no nice MVVM framework support like Caliburn.Micro). C# is way better there. - 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.
- MichaelGG 12y ago
  F# has unsafe capabilities. Look at NativePtr and friends. And since you can make operators, you can end up writing fairly concise code. 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.)
- Touche 12y ago
  > Writing a WPF app in F# is a real pain (no partial classes, no nice MVVM framework support like Caliburn.Micro). C# is way better there. You shouldn't be writing WPF apps at all.
  - sandyarmstrong 12y ago
    > 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?
    - 12y ago
seanmcdirmid 12y ago
C# is a stronger OO language than F#, if you prefer OOP over FP. It also has a lot of functional features that allow you to dip into FP when that is convenient. Not as great as Scala, but definitely a huge step up from Java.
- MichaelGG 12y ago
  What in particular do you mean by this? "Protected" accessibility, automatic mutual recursion for everything, nested classes -- and a few other edges? Is that enough to say C#'s a "stronger OO" language? Perhaps strictly speaking, as in, it has those few features more. But in practise? 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?
  - seanmcdirmid 12y ago
    Small potatoes. If I have an OO design, I'm not going to be able to use modules for that, or even structural typing. If you do a lot of class programming, F# doesn't make sense.
    - kvb 12y ago
      I don't think that's fair at all; F#'s integration with the .NET type system is one of its best features. I find that creating class types (and instances) in F# is usually easier than doing so in C#. And with object expressions, you can even program in an arguably purer object oriented style, declaring only interfaces but never concrete class types.
      - deleted 12y ago
        [deleted]
    - MichaelGG 12y ago
      I'm not sure how this is relevant. F# handles creating classes just fine. It's come a long way from the OCaml crosscompiler that you might be remembering.
edgyswingset 12y ago
Sometimes a procedural approach is better for certain (in my opinion, limited) problems. I'd rather use a procedural language for those cases. Also, the .NET libraries we end up using were, to my knowledge, written in C#. Sometimes interacting with them feels awkward if done functionally.
- MichaelGG 12y ago
  Fortunately, F# does OO and procedural pretty well, so you shouldn't feel pressure to use a functional style if it doesn't fit. 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.
pjmlp 12y ago
Besides all the issues pointed out by Hakeashar. 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.
- 72deluxe 12y ago
  If C# is already too complex for 9 to 5 developers, how does it earn more than a C++ developer?! The mind boggles.
  - pjmlp 12y ago
    In which company?! 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.
    - 72deluxe 12y ago
      Here in the UK I see jobs being advertised in Birmingham for big money for C# but C++ is always lower. 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++.
      - pjmlp 12y ago
        Thanks for the clarification, what about London (city)? 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.
        12y ago

by Touche 12y ago

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.

DrJokepu 12y ago

For me, writing procedural OO code in F# always felt awkward and inconvenient. This is a problem because most of the .NET runtime was designed with procedural OO code in mind.

math 12y ago

I trialed F# a while back. Something I certainly noticed was not having as much help from the IDE (no resharper). The lambda notation also annoyed me (by comparison to C#). Yeah, I know it's no big deal and I understand the trade-offs being made.. but it still annoyed me. Pattern matching is one of the draw cards - but I see that is coming in C# soon.

edgyswingset 12y ago
Did you give F# Power Tools a go? It gives you a lot of what is missing out of the box. It's still not as great as C# IDE support, but for most things it gets the job done.
MichaelGG 12y ago
While this may come across as sour grapes, I find generally I need less IDE help in F#, since I'm not typing as much boilerplate. For instance, almost all type annotations are inferred (20:1 in my own empirical study), so there's a ton of code I simply don't need to type. 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.
CmonDev 12y ago
Sadly F# had inherited all the OCAML luggage, including the arcane academic ML syntax.

nbevans 12y ago

This. F# is superior in every way. The constant stream of articles about C# 6.0 are getting ridiculous when .NET already has a language that is a natural successor. C# is for legacy and large corporate red-tape-encumbered enterprise projects only, as far as I'm concerned.

Hakeashar 12y ago

- Writing a WPF app in F# is a real pain (no partial classes, no nice MVVM framework support like Caliburn.Micro). C# is way better there. - 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.

MichaelGG 12y ago
F# has unsafe capabilities. Look at NativePtr and friends. And since you can make operators, you can end up writing fairly concise code. 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.)
Touche 12y ago
> Writing a WPF app in F# is a real pain (no partial classes, no nice MVVM framework support like Caliburn.Micro). C# is way better there. You shouldn't be writing WPF apps at all.
- sandyarmstrong 12y ago
  > 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?
  - 12y ago

seanmcdirmid 12y ago

C# is a stronger OO language than F#, if you prefer OOP over FP. It also has a lot of functional features that allow you to dip into FP when that is convenient. Not as great as Scala, but definitely a huge step up from Java.

MichaelGG 12y ago
What in particular do you mean by this? "Protected" accessibility, automatic mutual recursion for everything, nested classes -- and a few other edges? Is that enough to say C#'s a "stronger OO" language? Perhaps strictly speaking, as in, it has those few features more. But in practise? 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?
- seanmcdirmid 12y ago
  Small potatoes. If I have an OO design, I'm not going to be able to use modules for that, or even structural typing. If you do a lot of class programming, F# doesn't make sense.
  - kvb 12y ago
    I don't think that's fair at all; F#'s integration with the .NET type system is one of its best features. I find that creating class types (and instances) in F# is usually easier than doing so in C#. And with object expressions, you can even program in an arguably purer object oriented style, declaring only interfaces but never concrete class types.
    - deleted 12y ago
      [deleted]
  - MichaelGG 12y ago
    I'm not sure how this is relevant. F# handles creating classes just fine. It's come a long way from the OCaml crosscompiler that you might be remembering.

edgyswingset 12y ago

Sometimes a procedural approach is better for certain (in my opinion, limited) problems. I'd rather use a procedural language for those cases. Also, the .NET libraries we end up using were, to my knowledge, written in C#. Sometimes interacting with them feels awkward if done functionally.

MichaelGG 12y ago
Fortunately, F# does OO and procedural pretty well, so you shouldn't feel pressure to use a functional style if it doesn't fit. 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.

pjmlp 12y ago

Besides all the issues pointed out by Hakeashar. 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.

72deluxe 12y ago
If C# is already too complex for 9 to 5 developers, how does it earn more than a C++ developer?! The mind boggles.
- pjmlp 12y ago
  In which company?! 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.
  - 72deluxe 12y ago
    Here in the UK I see jobs being advertised in Birmingham for big money for C# but C++ is always lower. 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++.
    - pjmlp 12y ago
      Thanks for the clarification, what about London (city)? 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.
      - 12y ago