There are a lot of claims about why F# is better and not much data to back them up. I'd really like to learn F#, but are there proven benefits to code quality / shipped defects / etc? For example, looking for research like: https://quorumlanguage.com/evidence.html
Why you should learn F#
111–120 of 179 posts
Re: Why you should learn F#
#112If you want to get paid to learn F#, my team is hiring at Jet/WalmartLabs. If you want to learn more, email me at cole@jet.com.
Has the culture improved since the acquisition? Last time I interviewed there I was treated like dirt.
Re: Why you should learn F#
#113F# seems like such an amazing language every time I look at it — a modern version of OCaml, with a clean syntax, some novel ideas, and fewer legacy warts. However, I wish that it had, like OCaml, a native AOT compiler that didn't come with the baggage of the .NET runtime. Some people might consider this a benefit, not baggage, of course. But it's the same reason I'm put off by Scala. From what I understand, to even r…
After being deeply burned by the .NET framework, I consider OCaml significantly superior to F# just because it doesn't depend on .NET or Microsoft.
And yes, somehow the OCaml guys have managed to implement generics and AOT compilation to optimized machine code long before the .NET framework existed, but now this is something "truly hard" on .NET.
Re: Why you should learn F#
#114I heard F# supports this newish thing called dependent typing which allows the type checker to not only check for type correctness but logic correctness as well. I've never worked with dependent typing but is it true? Does the F# really take away the need for all unit testing on a project?
You are thinking of OCaml and Coq.
Re: Why you should learn F#
#115Earlier quoted context omitted.
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.
You can try it out quickly and cheaply, at https://fable.io/repl/
There's no setup required, just start typing some F# code into the online playground and see it run immediately.
Re: Why you should learn F#
#116Regarding F#'s real world usage, today I came across an end-to-end F# stack, SAFE stack.[0]
It looks very intriguing and I would be interested to know if anyone here has experience with it and has thoughts on it.
Re: Why you should learn F#
#117Earlier 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…
Why do you struggle with this in C#, especially given that you are familiar with the F# style? I don't know C#, but in Java I'd write this as: public class Order { final Optional delivery; public Order(Optional delivery) { this.delivery = delivery; } } public class DeliveryDetails { final long deliveryTimeMs; ... public DeliveryDetails (long deliveryTimeMs,...) { this.deliveryTimeMs = deliveryTimeMs; ... } } My IDE w…
that's true, you can recreate it in some sense but you can't get to what F# can guarantee. A big promise of discriminated unions is the ability to make invalid state unrepresentable. Matching on the different type constructors is a fantastic way to only express coherent states.
Re: Why you should learn F#
#118F# seems like such an amazing language every time I look at it — a modern version of OCaml, with a clean syntax, some novel ideas, and fewer legacy warts. However, I wish that it had, like OCaml, a native AOT compiler that didn't come with the baggage of the .NET runtime. Some people might consider this a benefit, not baggage, of course. But it's the same reason I'm put off by Scala. From what I understand, to even r…
After being deeply burned by the .NET framework, I consider OCaml significantly superior to F# just because it doesn't depend on .NET or Microsoft. And yes, somehow the OCaml guys have managed to implement generics and AOT compilation to optimized machine code long before the .NET framework existed, but now this is something "truly hard" on .NET.
My problem with OCaml that while the semantics are top notch, everything else is stuck in the past.
The syntax is quirky, there's a bunch of legacy baggage (does anyone use the OO stuff?), there's no SMP support (though I know this is being worked on), the toolchain feels antiquated (the REPL still, to this day, doesn't come with Readline support built in; rlwrap is required!), etc. Not to mention the lack of modern libraries, frameworks, package management, etc.
Reason and BuckleScript are nice, though. Reason cleans up a lot of my complaints, while still not being quite as elegant as F#. But there's this sense that nobody really wants to make any groundbreaking effort here; there doesn't seem to be any push to make Reason a first-class, new syntax for OCaml, so it's stuck being a web-oriented veener for new users, while old "industrial" users like Jane Street are content to continue with their thing.
Re: Why you should learn F#
#119Regarding F#'s real world usage, today I came across an end-to-end F# stack, SAFE stack.[0] It looks very intriguing and I would be interested to know if anyone here has experience with it and has thoughts on it. [0] https://safe-stack.github.io/docs/intro/
Yep, almost all of my side stuff and an ever-increasing proportion of my work stuff is in SAFE. It's actually built on Dustin's Giraffe library, which itself is built on top of Asp.Net Core. Cross platform, great ergonomics due to Giraffe, and I get to share client side/server side domain models, validations, etc due to the shared F# heritage.
Re: Why you should learn F#
#120Earlier quoted context omitted.
Its part of dotnet core, so you don't need Mono installed. And you can build a self-contained dotnet core application so you don't need core installed to run it. AOT is possible via something like CoreRT, but its still a bit beta and not straightforward. From my experience the only limitation with CoreRT and F# is certain reflection heavy functionality. No problem with generics.
Well, if not Mono, then the .NET Core runtime package, right? It's not self-contained. I read this [1], but it's unclear to me how I build a self-contained binary, or what options are available for AOT. [1] https://github.com/dotnet/core/blob/master/Documentation/sel...
If you build with 'msbuild publish -r debian8.x64' or any of the other valid 'runtime identifiers', the output of the build is an xcooy-deployable folder that contains your binary and all it's dependencies including the runtime. I use this at work to make Debian packages that are standalone.