Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why you should learn F#

dusted.codes

Post reply on HN
Print view View original

31–40 of 179 posts

Re: Why you should learn F#

#31

Post by smcl »

jweir wrote: post #20
smcl wrote: post #12

Earlier quoted context omitted.

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.

ML (Meta Language) vs ML (Machine Learning). It is confusing. When I hear ML, I think the language (cause I am "old"), but it is usually the process (Machine Learning) cause that is what is hot. https://en.wikipedia.org/wiki/ML_%28programming_language%29

Right - I'm pretty familiar with Ocaml so the distinction is pretty clear on my end. I'm just a bit suspicious of this one thing in the comment I replied to.

Re: Why you should learn F#

#32

Post by dgudkov »

urda wrote: post #6

Do HN users have any F# references, books, or guides they recommend? I've always been intrigued by F# but haven't found a good project / use case for it, but I suspect that's because I need to know more about it first.

>I've always been intrigued by F# but haven't found a good project / use case for it

I would highly recommend trying F# on a project with complex data processing.

Re: Why you should learn F#

#33

Post by daxfohl »

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. Second, functions only replace single-function interfaces. Even with a purist view of ISP, there are still plenty of occasions where a service would expect to call multiple functions on a contained service. Passing all those in as multiple parameters gets unwieldy in real world scenarios. Third, F# has no way to inject a dependency into a whole module, so you have to go function by function. Injection into classes is much easier to manage this way. Finally since none of the services or interfaces are named, they don't work with IoC containers.

The good side is that there is nothing in F# preventing you from using classes and interfaces in your design. Unsurprisingly this is my preferred way to go about it.

I kinda wish the function based DI wasn't brought up so much and so early. It's a big mental leap that I think turns off some people coming from other languages. And for limited benefit. Or negative benefit in plenty of cases.

Re: Why you should learn F#

#34

Post by algorithmsRcool »

contravariant wrote: post #16
algorithmsRcool wrote: post #14

F# is 3 big things to me: Safer threading with immutability Safer programming with null-safety Safer logic with precise domain modeling The precise domain modeling is the real paradigm shift. The whole point of static typing is to inform the compiler about your intent so that it can provide guarantees about correctness. F# makes it easy to define lots of small types that precisely model state so that you can give mor…

>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' from CommandLine and Env vars, do some parsing, then spit out proper types/objects.

- The backend that would interpret this data and make decisions, make some API calls and maybe copy some files.

Because of the way our our software is built, we have 5 or 6 different 'flavors' of our app that needed special treatment during build. The complexity of branching on if it was a build step or a release step, the different flavors of our app and the need to deal with input data that may or may not be there got the best of me and I spent weeks making tweaks to deal with NREs at runtime because i hadn't handled some weird case.

So i trashed the tool and rebuild the front end in F#. I spent a little time making a very accurate type representation of the data model. Including defining a lot of stuff as optional and introducing a lot of discriminated unions to represent possible branches. Then i essentially just filled in the blanks (match cases) and fixed the compile errors until every case was covered and I was done. No bugs.

You see the big, big win of F# is the default path doesn't let your cheat yourself.

You MUST handle every switch/match case.

You MUST fully construct your records.

If your function may fail, you MUST use Option to express None/Null

And you MUST handle every option type as potentially None and write handling logic

When you define your data model, just be on honest about what data needs to be where and the compiler will keep you on the straight and narrow.

Re: Why you should learn F#

#35

Post by pimeys »

algorithmsRcool wrote: post #14

F# is 3 big things to me: Safer threading with immutability Safer programming with null-safety Safer logic with precise domain modeling The precise domain modeling is the real paradigm shift. The whole point of static typing is to inform the compiler about your intent so that it can provide guarantees about correctness. F# makes it easy to define lots of small types that precisely model state so that you can give mor…

I would say it's the same with Rust and Haskell. And I agree, the superior type system of these languages is really a game changer for me and it's very hard to go back to languages missing these features.

Re: Why you should learn F#

#36

Post by davidgrenier »

phillipcarter wrote: post #28
zamalek wrote: post #26

Earlier quoted context omitted.

Cargo[1]. REPL[2]. [1]: https://ardalis.com/how-to-add-a-nuget-package-using-dotnet-... [2]: https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/fsh...

Note: the REPL doesn't _quite_ work fully cross-platform with .NET Core yet. But the work is ongoing and something we're (fairly) close to releasing. When it's done, you can simply "reference a package" in a script or interactive session, and it will resolve whatever that dependency graph is and let you use it as if you were editing source code in a project in an IDE.

I care about this a lot. All my respects for the efforts in that direction.

Re: Why you should learn F#

#37

Post by algorithmsRcool »

ambulancechaser wrote: post #29
contravariant wrote: post #16

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.

We found it quite nice for properties of objects that appear over time. Think things like Order that might or might not have delivery details. In C# you are making classes with nullable delivery timestamps, delivery person, etc. And one or two properties isn't that bad but it gets a little onerous when you start to have constraints like "these four properties are either all null or all populated". In F# it is trivial…

> There is no unspoken agreement...

Yes! That is exactly right, F# give you the tools to express your actual model with little/no ambiguity.

Re: Why you should learn F#

#38

Post by jjtheblunt »

jweir wrote: post #22

A gripe about F# on MacOs - how to install it, count the ways - 6. https://fsharp.org/use/mac/ Don't I need Mono, wait, shouldn't I be using .NET? Oh I will probably install it one way, only to discover I should have installed it another. I find the .NET and Mono differences confusing. So this is a barrier to entry to consider. That said, this free book is kind of nice introduction: https://www.oreilly.com/programmin…

brew install fsharp or similar worked fine for me.

Re: Why you should learn F#

#39

Post by contravariant »

ambulancechaser wrote: post #29
contravariant wrote: post #16

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.

We found it quite nice for properties of objects that appear over time. Think things like Order that might or might not have delivery details. In C# you are making classes with nullable delivery timestamps, delivery person, etc. And one or two properties isn't that bad but it gets a little onerous when you start to have constraints like "these four properties are either all null or all populated". In F# it is trivial…

I see, although it looks like you're really after a state-machine there. Which I admit aren't the easiest to create in C#, and immutability and null-safety definitely make it easier...

Although personally I'd rather have the different states encapsulated in separate classes than a single type that encapsulates all possible states and enforces them through the constructor.

Re: Why you should learn F#

#40

Post by AdeptusAquinas »

phillipcarter wrote: post #18

Hey folks, Glad to see Dustin's good post get some visibility here :) If anyone is interested in learning F#, there are some resources available: F# docs index (has multiple guides for specific editors and a comprehensive overview of the language): https://docs.microsoft.com/dotnet/fsharp/ F# on JavaScript with Fable: https://fable.io/docs/ More F# in the browser with WebSharper: https://try.websharper.com/ F# on Azu…

Great thing about this article is that it treats C# with respect, even as it lambasts it :) Good examples real world situations, no exaggerations. FSharp For Fun and Profit often uses straw-man implementations of C# to compare against, which I think does harm to the argument.
Post reply on HN