3 ms·

> If you program with the same mindset of F# in C# then the differences are not super quantifiable. I think they are. F# defaults to immutable stuff. Everytime

by knocte 8y ago

> If you program with the same mindset of F# in C# then the differences are not super quantifiable. I think they are. F# defaults to immutable stuff. Everytime you write anything in C# and forget the word "readonly", you're opening the door for a race condition. Also F# is much more succinct, things that take dozens of lines in C# are just one line in F#, take a look at this quick guide I wrote: https://github.com/knocte/csharp2fsharp https://github.com/knocte/csharp2fsharp

keithnz 8y ago
While those are nice things, they don't really bite me in the C# world. There's a lot of fuss about it in the F# world, but it really isn't that big of a problem in my experience. I do like the robustness of it, but in practical terms... it's only a minor point in F#s favor
- knocte 8y ago
  I guess you say this because you don't really do multi-threading that much or haven't had the urge about parallelising your work yet ;)
  - keithnz 8y ago
    I have, and I do.
    - knocte 8y ago
      Cool, now go and read this C# horror story: http://tomasp.net/blog/csharp-async-gotchas.aspx/ http://tomasp.net/blog/csharp-async-gotchas.aspx/
  - sk5t 8y ago
    C# with the good old .NET BCL has excellent support for multithreading, even if some language features could make it even better, there's no need for smugness.
    - knocte 8y ago
      I didn't say that C# doesn't have support for multithreading, I said that C#+multithreading is more prone to race-conditions than F#+multithreading.
      - sparkie 8y ago
        I wish MS had continued support for their "Axum" project, or at least open-sourced it so that it could be continued outside of MS. It was essentially a C# subset with "static" removed and replaced with "isolated", with some other new stuff added. Code was separated into domains and actors, which could be safely used without the concerns on race conditions. Essentially erlang-like programming on .NET
        knocte 8y ago
        Interesting.
- AdeptusAquinas 8y ago
  Speaking as someone who has been doing C# for over 15 years, and still professionally, but who uses F# almost exclusively in my private projects, the biggest things are: - discriminated unions. DU types don't exist in C# or lots of other languages, and change the way you program - complex match expressions (fortunately coming in C# 8) - value tuples (thankfully arrived in c# 7) - the pipe operator and partial application (another thing that changes the way you program) - super implicit typing (its to var what var was to explicit typing) - and its use of option/result types, along with compiler enforcement of all conditions. Before I picked up F# properly, I looked at it as fancy but overhyped. But then, its a bit of a plato's cave type of thing: you don't know why `type A = B of int | C of string * bool` is awesome until you have used it a bunch of times.
  - keithnz 8y ago
    Speaking as someone who's been programming for nearly 40 years, C# since it came out in beta, and F# when it first came out ( though I haven't used it consistently since then). I know about all those things, I have done signifiant programming with F# and other functional languages. Like I said, I like F# and I think it is a nicer language and I like it is more functional, but in the broader picture, I don't think the advantages are that significant that you'd bet your products on it. I'd tend to suggest something like Elixir might be a better option. But you may hit a sweet spot where F# is a good choice... cool, but I think the sweet spot is quite small
- daxfohl 8y ago
  For me, `with` is enough. e.g. `let output = { input with status = "failed" }`. For all those times you want to be able to return a modified value but not mutate the original. Once you're used to doing this in F# you take it for granted. Going back to a project with the C# mindset of `{get;set;}` everywhere, passing "records" into functions and not being able to prevent those functions to mutate them, it seems so unprincipled. The other stuff in F# is also great, but even with none of it, the simple `with` operation is the thing that changes the whole game.
- Risord 8y ago
  I agree that mutability won't often bite professional programmers as you say. But as context is good to know that quite typical F# programmer has strong C# background like you. Individual features are often raised during discussions but point behind features is mind-shift (at least for me). You don't have to remember/think/know: -Possibility that somebody somewhere is unexpectedly effecting on you -How to move data, it's just parameters and return values -What object identity is -etc. It takes time to adapt to these constraints in a way you really don't have to think them. But as gain you can free quite a lot your mental load. As result I feel that with F#: -I feel significantly less stress -It's easier to model complex system and understand/trust their behavior -After 6-12mo I can constantly write clean and maintenable code. In contrast I am not very happy any of my C# projects after 6yr experience. Yea yea not silver bullet but I love it.

by knocte 8y ago

keithnz 8y ago

While those are nice things, they don't really bite me in the C# world. There's a lot of fuss about it in the F# world, but it really isn't that big of a problem in my experience. I do like the robustness of it, but in practical terms... it's only a minor point in F#s favor

knocte 8y ago
I guess you say this because you don't really do multi-threading that much or haven't had the urge about parallelising your work yet ;)
- keithnz 8y ago
  I have, and I do.
  - knocte 8y ago
    Cool, now go and read this C# horror story: http://tomasp.net/blog/csharp-async-gotchas.aspx/ http://tomasp.net/blog/csharp-async-gotchas.aspx/
- sk5t 8y ago
  C# with the good old .NET BCL has excellent support for multithreading, even if some language features could make it even better, there's no need for smugness.
  - knocte 8y ago
    I didn't say that C# doesn't have support for multithreading, I said that C#+multithreading is more prone to race-conditions than F#+multithreading.
    - sparkie 8y ago
      I wish MS had continued support for their "Axum" project, or at least open-sourced it so that it could be continued outside of MS. It was essentially a C# subset with "static" removed and replaced with "isolated", with some other new stuff added. Code was separated into domains and actors, which could be safely used without the concerns on race conditions. Essentially erlang-like programming on .NET
      - knocte 8y ago
        Interesting.
AdeptusAquinas 8y ago
Speaking as someone who has been doing C# for over 15 years, and still professionally, but who uses F# almost exclusively in my private projects, the biggest things are: - discriminated unions. DU types don't exist in C# or lots of other languages, and change the way you program - complex match expressions (fortunately coming in C# 8) - value tuples (thankfully arrived in c# 7) - the pipe operator and partial application (another thing that changes the way you program) - super implicit typing (its to var what var was to explicit typing) - and its use of option/result types, along with compiler enforcement of all conditions. Before I picked up F# properly, I looked at it as fancy but overhyped. But then, its a bit of a plato's cave type of thing: you don't know why `type A = B of int | C of string * bool` is awesome until you have used it a bunch of times.
- keithnz 8y ago
  Speaking as someone who's been programming for nearly 40 years, C# since it came out in beta, and F# when it first came out ( though I haven't used it consistently since then). I know about all those things, I have done signifiant programming with F# and other functional languages. Like I said, I like F# and I think it is a nicer language and I like it is more functional, but in the broader picture, I don't think the advantages are that significant that you'd bet your products on it. I'd tend to suggest something like Elixir might be a better option. But you may hit a sweet spot where F# is a good choice... cool, but I think the sweet spot is quite small
daxfohl 8y ago
For me, `with` is enough. e.g. `let output = { input with status = "failed" }`. For all those times you want to be able to return a modified value but not mutate the original. Once you're used to doing this in F# you take it for granted. Going back to a project with the C# mindset of `{get;set;}` everywhere, passing "records" into functions and not being able to prevent those functions to mutate them, it seems so unprincipled. The other stuff in F# is also great, but even with none of it, the simple `with` operation is the thing that changes the whole game.
Risord 8y ago
I agree that mutability won't often bite professional programmers as you say. But as context is good to know that quite typical F# programmer has strong C# background like you. Individual features are often raised during discussions but point behind features is mind-shift (at least for me). You don't have to remember/think/know: -Possibility that somebody somewhere is unexpectedly effecting on you -How to move data, it's just parameters and return values -What object identity is -etc. It takes time to adapt to these constraints in a way you really don't have to think them. But as gain you can free quite a lot your mental load. As result I feel that with F#: -I feel significantly less stress -It's easier to model complex system and understand/trust their behavior -After 6-12mo I can constantly write clean and maintenable code. In contrast I am not very happy any of my C# projects after 6yr experience. Yea yea not silver bullet but I love it.