Live data from Hacker News

Why you should learn F#

dusted.codes

41–50 of 179 posts

Re: Why you should learn F#

#41
post #33

The only thing I don't like is the DI story presented here and many other F# guides. Having gone down that rabbit hole and using F# in production for 5 years now, I have gone back to classes and interfaces in almost all cases. Functions as DI mechanism suffers from a few things. First, it's hard to search for implementations. They could be defined anywhere. With interfaces, the implementations are a hot key away. Sec…

I use classes and interfaces at component boundaries, which is encouraged by the FSharp style guide https://docs.microsoft.com/en-us/dotnet/fsharp/style-guide/, and use just functions for DI internally where it makes sense.

Re: Why you should learn F#

#42
post #33

The only thing I don't like is the DI story presented here and many other F# guides. Having gone down that rabbit hole and using F# in production for 5 years now, I have gone back to classes and interfaces in almost all cases. Functions as DI mechanism suffers from a few things. First, it's hard to search for implementations. They could be defined anywhere. With interfaces, the implementations are a hot key away. Sec…

It sounds like your (more or less) just using classes for just namespacing functions and allowing bundles of functions to get brought in?

Re: Why you should learn F#

#43

Earlier quoted context omitted.

>I have personally struggled with domain complexity in C# that i was able to model precisely in F# and have it work perfectly on the first try. If you're willing to provide a (simplified) example I would be very interested.

I don't think i can release the exact code but my case was like this. I was writing a little program to help glue some things together in our build/release pipeline. This tool would be deployed to the build server and get invoked by the build agent. (This could have been a script, but the complexity got to be too much to keep organized) The tool had two halfs: - The frontend whose job was to gather up all the 'input'…

I really need to make time to look into F# some time, it sounds like it has the things I like in C# but more so.

Re: Why you should learn F#

#44
post #12
post #11

Earlier quoted context omitted.

F# is the evolution of ML.NET developed at Microsoft Research.

Is that right? I know they have a machine learning library called ML.NET ... but it seems weird to me that they’d recycle the name.

I got it a bit wrong. It was Caml.NET.

https://www.microsoft.com/en-us/research/project/f-at-micros...

Re: Why you should learn F#

#45
"No matter if you are already a functional developer from a different community (Haskell, Clojure, Scala, etc.) or you are a complete newbie to functional programming (like I was 3 years ago) I think F# can equally impress you" -> "For this task and for the rest of this blog post I'll be comparing F# with C# in order to show some of the benefits."

F# is neat, and I see why it's useful if you have a big .NET program already, but for anyone else I don't see why I'd pick it over a more mature (and less Microsoft-centric) functional language like OCaml, SML, or Erlang.

Does F# have any unique features that other functional languages lack, or is .NET integration its killer feature?

Re: Why you should learn F#

#46
post #19

Now release a native F# variant with rustup/cargo like tooling and a REPL and I'm sold.

It's trailing behind C# (as always), but the plan is to support F# in CoreRT, which will get you your native builds.

Re: Why you should learn F#

#47
post #45

"No matter if you are already a functional developer from a different community (Haskell, Clojure, Scala, etc.) or you are a complete newbie to functional programming (like I was 3 years ago) I think F# can equally impress you" -> "For this task and for the rest of this blog post I'll be comparing F# with C# in order to show some of the benefits." F# is neat, and I see why it's useful if you have a big .NET program a…

.NET integration is probably the biggest killer feature, because that unlocks official support for most important platforms that you'll need to use. Using AWS or Azure or GCP because your business is moving stuff to a butt provider? You have access to fully-supported SDKs maintained by teams who do that stuff for a living. And so on. .NET also has a spectacular standard library, and with .NET Core, runs _very_ well in any environemnt.

But from a language standpoint, here are three unique features

* Type Providers, which let you generate types based on a data source, and tie compilation to the use of that data being correct

* Active Patterns, which are similar to Haskell's View Patterns, and let you tie some arbitrary functionality that ultimately returns an Option into a pattern for neat pattern matching

* Computation Expressions, which let you express, compose, sequence, etc. monadic and monoidal computations in a convenient syntax that's super easy for newcomers to grok. There is also an RFC and WIP implementation that expands these to support applicative constructs

There's more (Units of Measure, universal quantification via Interfaces, etc.) but these three tend to be something people like a lot.

Re: Why you should learn F#

#48
Someone I interviewed some years back did their interview in F#. I didn't know F# and tried to make that abundantly clear to them, but they persisted nonetheless. I had messed around with O'Caml back in college and so at least had a passing familiarity with functional language concepts, but I really had no idea if what the candidate produced could be considered quality production code. That didn't help their chances of getting the job.

Re: Why you should learn F#

#49
post #45

"No matter if you are already a functional developer from a different community (Haskell, Clojure, Scala, etc.) or you are a complete newbie to functional programming (like I was 3 years ago) I think F# can equally impress you" -> "For this task and for the rest of this blog post I'll be comparing F# with C# in order to show some of the benefits." F# is neat, and I see why it's useful if you have a big .NET program a…

The .Net ecosystem is definitely a killer feature. Everything you want, and it 'just works', as well as everything being seamlessly integrated with each other. This is only possible with the backing of a huge amount of funding, and there are probably millions of man hours spent on it at this point.

Re: Why you should learn F#

#50
post #45

"No matter if you are already a functional developer from a different community (Haskell, Clojure, Scala, etc.) or you are a complete newbie to functional programming (like I was 3 years ago) I think F# can equally impress you" -> "For this task and for the rest of this blog post I'll be comparing F# with C# in order to show some of the benefits." F# is neat, and I see why it's useful if you have a big .NET program a…

.NET integration is probably the biggest killer feature, because that unlocks official support for most important platforms that you'll need to use. Using AWS or Azure or GCP because your business is moving stuff to a butt provider? You have access to fully-supported SDKs maintained by teams who do that stuff for a living. And so on. .NET also has a spectacular standard library, and with .NET Core, runs _very_ well i…

Thanks, I completely missed to talk about type providers, active patterns and unit of measure, but then the post was already so long lol. I think I'll add other good blog posts which cover all these topics to my final notes!
Post reply on HN