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

91–100 of 179 posts

Re: Why you should learn F#

#91

Post by elcomet »

sifoobar wrote: post #83
pimeys wrote: post #35

Earlier quoted context omitted.

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.

For a while, yes. I know from experience that going the other way is a struggle as well. Habits die hard and change takes effort. There's nothing superior about these type systems, they're simply two of the most static and rigid systems in circulation right now. Try writing C, Lisp and Forth until it clicks. Then we can sit down and have an informed discussion about missing features.

They are not just static and rigid, Haskell has type inference , which is what ihmo makes it superior

Re: Why you should learn F#

#92

Post by GordonS »

bnt wrote: post #54

Honest question: As someone who does web development and is looking to learn a new programming language in 2018, would you recommend F# over Elixir (and why)?

I'm a C# and Typescript guy, and recently spent a day with each of Elixir and F#.

I loved them both!

Elixir has a great 'getting started' site, which was really well put together, and similarly the 'F# for Fun and Profit' site was great too, so I feel like I had equally good resources to introduce me to them both.

I'd love to spend more time with both of them, but in general I'm more comfortable with static typing, so if I progress further with either, it'll be F#.

I only wish that Microsoft would start treating F# as a first-class citizen alongside C# :/

Re: Why you should learn F#

#93

Post by rienbdj »

keithnz wrote: post #80
bnt wrote: post #54

Honest question: As someone who does web development and is looking to learn a new programming language in 2018, would you recommend F# over Elixir (and why)?

I'd suggest try both. The Elixir web world gets a lot more love than the F# one. F# always touts the advantage of living in the .NET world, but it means most things are built with C# in mind, not F#. There are F# frameworks, and they are nice, but the community is quite small. But the advantage is the .NET world has a vast amount of libraries for doing most things. OTP and Elixir is a better story than F# equivalents…

F# async and mailbox provide a decent actor model.

Writing an F# wrapper on c# libraries is usually very easy. You can also call c# code directly and it doesn’t look too bad.

Computation expressions can fulfil the needs of macros in many cases in a controlled way.

Re: Why you should learn F#

#94

Post by bunderbunder »

sifoobar wrote: post #83
pimeys wrote: post #35

Earlier quoted context omitted.

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.

For a while, yes. I know from experience that going the other way is a struggle as well. Habits die hard and change takes effort. There's nothing superior about these type systems, they're simply two of the most static and rigid systems in circulation right now. Try writing C, Lisp and Forth until it clicks. Then we can sit down and have an informed discussion about missing features.

I have spent some time loving all 3 of those languages, and also, most recently, F#.

I really do think that an ML-style type system is the better way to do domain modeling. The compiler support you get in F#, such as ensuring that your match expressions are complete, are nice. But what really makes me enjoy working that way is that (the non-OO bits of) F#'s type system makes it very easy to create domain models whose intent and inner workings are just obvious.

You're right, it's not correct to cast the differences as "missing features" - it's just different ways of doing things. And each has its own advantages and disadvantages. F#'s set of tradeoffs is just the one that most suits my tastes when I'm building LOB applications.

Re: Why you should learn F#

#95

Post by sparkie »

cgrealy wrote: post #55

While I really like the concept of functional programming and F# is definitely on my list of practical useful languages to learn, this article is clearly written by someone who doesn't know C# very well. Take the "To hell with interfaces" example. public interface ISortAlgorithm { List Sort(List values); } public class QuickSort : ISortAlgorithm { public List Sort(List values) { // Do QuickSort return values; } } pub…

I primarily use F# over C#, and I would prefer the interface version over the functions in many cases. An interface makes it a bit more explicit and self-explanatory what is expected to be passed. A Func, List> is not very meaningful and potentially ambiguous. Obviously, anywhere you expect more than one function, an interface is more desirable because it avoid the need to pass around multiple objects.

One thing that makes it a bit nicer in F# than in C# is that you can define object expressions wherever an interface is expected, so there's no need to declare a new type in the static scope somewhere (similar is possible in Java).

    DoSomething { new ISortAlgorithm with
                     member this.Sort values = ... }
                values
In terms of how they work, there's not really much difference. If something expects a function and you need to capture some local variable within that function, the framework will create a new type for that closure anyway.

Re: Why you should learn F#

#96

Post by sparkie »

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 used Expert F# (2.0) when learning some years ago. A bit dated now, but I believe that it has had a more recent revision.

It is co-authored by the language creator, Don Syme.

Re: Why you should learn F#

#98

Post by rkido »

daxfohl wrote: 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 believe this class-oriented workaround is a side-effect of Don Syme's decision to strip out the OCaml module system from F#.

Re: Why you should learn F#

#99

Post by victorNicollet »

contravariant wrote: post #39
ambulancechaser wrote: post #29

Earlier quoted context omitted.

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.

This is what F# does (define multiple classes), but each of these classes only takes one line of code.

Re: Why you should learn F#

#100

Post by sparkie »

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…

One of the features that makes F# great for organization is the sequential ordering of compilation units which makes it easier to understand code dependencies, and makes it awkward to create mutually recursive types (requiring them to be in the same code file separated by `and`, or defined in signature files in advanced).

This might sound like an unwanted restriction, but 9 times out of 10, having mutually recursive types is signs of a code smell. You can almost always model your problem better with a slight indirection through an interface or function, it helps avoid the need for mutation, and makes testing simpler.

Post reply on HN