20 ms·

Why you should learn F#

272 points by aloisdg 8y ago

sevensor 8y ago
I have a seasonal project that spins up around this time every year. Last year, I chose F# for a (relatively small) component of the project and I was not disappointed. I don't have access to the customer's systems, and usually with Python there's a bit of back and forth where I have to fix bugs that only customer is able to trigger. My F# program worked flawlessly the first time and has caused no complaints. I'm excited about writing more F# this year.
deleted 8y ago
[deleted]
Nelkins 8y ago
That "famous slide" really rings true for me. F# allowed me to forget (or at least not worry about) a TON of OO design patterns. Data goes in, transformation happens, data comes out. I do like that F# is very practical about OO though.[0] I feel that the language often strikes a balance of programming paradigms that enables me to be very productive. [0] https://eiriktsarpalis.wordpress.com/2017/03/20/why-oo-matters-in-f/ https://eiriktsarpalis.wordpress.com/2017/03/20/why-oo-matte...
winkelwagen 8y ago
I've been diving into f# in 2018. I came from c# world, and it really made me a better developer. Really recommend the language. Think it has a great balance between functional programming and OO if it is really needed. I really do think it's easier to write better .net programs with f# then c#. Think this article point out some great stuff. That said, it's quite hard to actually get to use it in production at the places I've worked. My college's are scared of it (that is pretty reasonable, considering c# is a good stable language and my team is confident that what we develop will make the customers happy). One thing that makes me hesitant to really try to get this adopted in my company is the tooling. My experience hasn't been great. It works, but it has been pretty unreliable. Some documentation was more focused on the "pre dotnet core" era of f#. I know i've been spoiled, but stuff like debugging, tooling and refactor tools can't touch Visual Studio. There are some decent options, Jetbrains Rider and VS Code are a couple of them. Small things, like creating a record type while typing is inconvenient. type Customer = { Id: int; Name: string; Age : int; } While typing an instance of the record let c1 : Customer = {Id = 1; gives you a bunch of compiler warnings, I know I'm not done, Compiler knows there are more properties. But without looking at the record type it's hard to see what order things are. I'm not sure if this is just OCaml thing, but C kind of languages are better at predicting what you want to create. It's weird that with the very predictable Hindley–Milner type system it can't provide the developer with good information. I know it's a small thing, but when working with large projects, I don't want to look everything up, I have the compiler have my back. I'll really think Microsoft should help the Fsharp Foundation more, seeing what an amazing language f# is. But it really could use some more love from MS. Perhaps they should help the community be more confident that they can solve the business problems they run into. I hope Microsoft would say: "Hey this is how you create The Boring Line Of Business App, with all the bells and whistles you normally need". From how to deal with Dependencies in large projects (No, a couple of (amazing) conference video's of Mark Seemann do not give me enough confident that after 6 months of development it still is manageable) Until the Tooling is done, I just keep enjoying the language and learn how to become a better developer with it.
- maxxxxx 8y ago
  "That said, it's quite hard to actually get to use it in production at the places I've worked. My college's are scared of it (that is pretty reasonable, considering c# is a good stable language and my team is confident that what we develop will make the customers happy)." That's my problem too. I would like to give F# a go but at work it seems close to impossible to implement. Most people don't see the need and if there is a problem it will be blamed on F#. It's hard to win there if management doesn't fully support it.
  - brabara 8y ago
    Why not start introducing F# via unit tests?
urda 8y ago
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.
- winkelwagen 8y ago
  I've really enjoyed https://www.manning.com/books/get-programming-with-f-sharp https://www.manning.com/books/get-programming-with-f-sharp Think it gives a good overview of the language and it's easy to read. Considering that after a day of working I'm not that sharp anymore it was a good read for me. Also mentioned in the article, but Scott Wlaschin book really show the strengths of the language. Most of his stuff is great actually, but his website (FSharp for fun and profit) is not the most coherent read, I love using it as reference. I also recommend his conference talks, it has quite a bit wide range of topics. https://pragprog.com/book/swdddf/domain-modeling-made-functional https://pragprog.com/book/swdddf/domain-modeling-made-functi... There are also few courses on pluralsight, but cannot remember which ones I really enjoyed.
  - urda 8y ago
    > Considering that after a day of working I'm not that sharp anymore it was a good read for me. That's a great consideration you made, and I'm in the same boat. I'll check it out thanks!
- deleted 8y ago
  [deleted]
- Nelkins 8y ago
  This site is a goldmine: https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/
- dgudkov 8y ago
  >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.
crimsonalucard 8y ago
I 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?
- rspeele 8y ago
  F# does not support dependent typing. And in general, because it has to interop smoothly with .NET code written in C# and VB.NET, F# is not nearly as hardcore on functional purity as something like Haskell or Agda, and correspondingly cannot guarantee as much safety through its type system. It is a wonderfully pragmatic language though and does guide the user towards more reliable software patterns than C# does. It sort of bridges the gap to be something you can actually use in production today, whereas the dependently typed languages are still in the realm of experimentation and toy projects for now.
- rienbdj 8y ago
  You are probably thinking of ‘F*’
- bjoli 8y ago
  Dependent typing generally doesn't play well with type inference (leading to things being all kinds of undecidable). I doubt it will ever make it's way into f#. GADT might, which provides a subset of the nice things of DT, but is much much easier to implement. F* has dependent types though.
- javcasas 8y ago
  You are thinking of OCaml and Coq.
mcintyre1994 8y ago
I've previously used Ocaml at my last job and use Scala at my current one, it's interesting that F# (just judging from this blog post) looks more similar to Ocaml than to Scala - like they've more aggressively pulled out syntax and embraced partial application etc. I'd always assumed F# was to C# what Scala is to Java - and I think that probably does represent their design goals, so I wonder what the different considerations were that led to them being relatively quite far apart.
- pjmlp 8y ago
  F# is the evolution of ML.NET developed at Microsoft Research.
  - smcl 8y ago
    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.
    - jweir 8y ago
      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 https://en.wikipedia.org/wiki/ML_%28programming_language%29
      - smcl 8y ago
        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.
    - pjmlp 8y ago
      I got it a bit wrong. It was Caml.NET. https://www.microsoft.com/en-us/research/project/f-at-microsoft-research/ https://www.microsoft.com/en-us/research/project/f-at-micros...
algorithmsRcool 8y ago
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 more responsibility to the compiler to verify your program. I cannot overstate how important this is to maintaining correct software overtime. If you guard your touches with non F# code, you need far fewer unit tests and probably even less runtime checks because you already know if the types are right, so is the logic. And when you need to write unit tests, the functional style makes your tests very easy to write. 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.
- contravariant 8y ago
  >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.
  - ambulancechaser 8y ago
    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 to set up a new constructor for Delivery that includes all of these properties. There is no unspoken agreement about that, you can set it in the model.
    - algorithmsRcool 8y ago
      > There is no unspoken agreement... Yes! That is exactly right, F# give you the tools to express your actual model with little/no ambiguity.
vumgl 8y ago
(no/less functional) C --> Java --> C# --> Scala --> F# ---> Haskell (more/all functional) - form a talk by Martin Odersky
- Timothycquinn 8y ago
  Do you know which talk this is discussed? I'm interested in watch his stuff.
phillipcarter 8y ago
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/ https://docs.microsoft.com/dotnet/fsharp/ F# on JavaScript with Fable: https://fable.io/docs/ https://fable.io/docs/ More F# in the browser with WebSharper: https://try.websharper.com/ https://try.websharper.com/ F# on Azure Notebooks (a hosted Jupyter notebook service that's free): https://notebooks.azure.com/Microsoft/projects/2018-Intro-FSharp/html/Introduction%20to%20FSharp.ipynb https://notebooks.azure.com/Microsoft/projects/2018-Intro-FS... And of course, the now legendary (at least among the F# community), F# for Fun and Profit: https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/
- dustinmoris 8y ago
  Thanks, I'll add these links to my blog post later tonight!
- AdeptusAquinas 8y ago
  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.
eterps 8y ago
Now release a native F# variant with rustup/cargo like tooling and a REPL and I'm sold.
- zamalek 8y ago
  Cargo[1]. REPL[2]. [1]: https://ardalis.com/how-to-add-a-nuget-package-using-dotnet-add https://ardalis.com/how-to-add-a-nuget-package-using-dotnet-... [2]: https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/fsharp-interactive/ https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/fsh...
  - phillipcarter 8y ago
    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.
    - davidgrenier 8y ago
      I care about this a lot. All my respects for the efforts in that direction.
- kej 8y ago
  It's trailing behind C# (as always), but the plan is to support F# in CoreRT, which will get you your native builds.
jweir 8y ago
A gripe about F# on MacOs - how to install it, count the ways - 6. https://fsharp.org/use/mac/ 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/programming/free/analyzing-visualizing-data-f-sharp.csp https://www.oreilly.com/programming/free/analyzing-visualizi...
- phillipcarter 8y ago
  The FSSF site needs updating (which is happening). This explosions of options is quite a detractor, and they're aware of it as they are doing a redesign. You can see a more simplified version of how to get started here: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/ https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/
- jjtheblunt 8y ago
  brew install fsharp or similar worked fine for me.
  - nobleach 8y ago
    Did you get fsi with that? That was the one thing that made me eventually install Mono.
- knocte 8y ago
  Yeah, the fact that Mono is inheriting all BCL code from .NETCore nowadays, but is still not .NETCore (because it has its own runtime) is a bit confusing. That being said, the best/easiest way to use .NET in the Mac is just install "Visual Studio for Mac" (the Community edition is completely free), which will under the hood install all you need (Mono, .NET Core, etc).
daxfohl 8y ago
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.
- davidgl 8y ago
  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/ https://docs.microsoft.com/en-us/dotnet/fsharp/style-guide/, and use just functions for DI internally where it makes sense.
- jadbox 8y ago
  It sounds like your (more or less) just using classes for just namespacing functions and allowing bundles of functions to get brought in?
  - dvlsg 8y ago
    I've definitely structured f# modules that way. The module exposes one function that "injects" the dependency into multiple other functions, and then returns them as a blob. I'm not sure if that's "the fsharp way" (i suspect it isn't) and maybe I'll look back on it some day and cringe, but it's working pretty well for some of my (admittedly small) side projects I'm tinkering with right now.
ken 8y ago
"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?
- phillipcarter 8y ago
  .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.
  - dustinmoris 8y ago
    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!
- hacker_9 8y ago
steelframe 8y ago
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.
- quickthrower2 8y ago
  Maybe they want to do F# in their job, in which case they successfully filtered you out. Although it might have been smarter for them to ask about F# in an earlier round, or pre interview.
bnt 8y ago
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)?
- smush 8y ago
  This has been previously mentioned but F# gets all of the goodies that come with being a .NET language. Elixir comes from Ruby land and thus has a framework called Phoenix(?) which also has its fans. The big difference is that F# is a statically typed functional language, while Elixir is a dynamically typed functional language. Comparison of static vs dynamic types -> https://hackernoon.com/statically-typed-vs-dynamically-typed-languages-e4778e1ca55 https://hackernoon.com/statically-typed-vs-dynamically-typed... I personally opted for F# because of the domain modelling tools and the offloading of various caveats and edge cases onto the compiler's stack rather than the meatspace stack, but Elixir has many fans for a good reason no doubt, but I'll defer to someone with more experience working with it to weigh in.
  - nickpeterson 8y ago
    Did you mean to say Elixir comes from Ruby? Surely you mean Erlang?
    - Multicomp 8y ago
      I think the poster got Crystal and Elixir confused. I do sometimes tbh
    - skosch 8y ago
      Elixir obviously is Erlang under the hood, but its syntax was inspired by Ruby's simplicity. José Valim, the creator, was also a Ruby contributor IIRC.
- keithnz 8y ago
  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. There are no lightweight isolated processes in .NET Elixir also has macros ( a very sharp double edged sword ) which can make frameworks nice to use. F# is stronger typing which is nice and often has the trait if it compiles, it works. Though the normal downsides of dynamic typing in Elixir are not so bad. But the best thing is to try both and make up your own mind
cgrealy 8y ago
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<int> Sort(List<int> values); } public class QuickSort : ISortAlgorithm { public List<int> Sort(List<int> values) { // Do QuickSort return values; } } public class MergeSort : ISortAlgorithm { public List<int> Sort(List<int> values) { // Do MergeSort return values; } } public void DoSomething(ISortAlgorithm sortAlgorithm, List<int> values) { var sorted = sortAlgorithm.Sort(values); } public void Main() { var values = new List<int> { 9, 1, 5, 7 }; DoSomething(new QuickSort(), values); } No, no, no, no, nope. public static class MergeSort { public static List<int> Sort(List<int> values) { // Do MergeSort return values; } } public void DoSomething(Func<List<int>, List<int>> sortAlgorithm, List<int> values) { var sorted = sortAlgorithm(values); } public void Main() { var values = new List<int> { 9, 1, 5, 7 }; DoSomething(QuickSort.Sort, values); } No interface necessary. Or immutability: "public struct Customer { public string Name { get; } public string Address { get; } public Customer(string name, string address) { Name = name; Address = address; } } So far so good, but unless someone knows C# very well one could have easily gotten this wrong." Really?? This is beginner stuff. I 100% agree that null sucks, functions should not need to be in classes and immutability is great, but this kind of strawman doesn't help his point.
- keithnz 8y ago
  I agree, it feels like the author is going out of their way to write really really verbose C#
- algorithmsRcool 8y ago
  You are right about the first example (although the F# version looks nicer =D) But that struct example is less than great. Just last night I had a readonly C# struct like that, that I used as a dictionary key and wondered why my perf tests took a nose dive when the Dictionary hit a few dozen entries. My boneheaded mistake was i forgot to override GetHashCode and Object.Equals. Great my perf was looking decent, but even then I was allocating 32 bytes of memory on every lookup. I forgot I needed to also implement IEquatable<> to prevent boxing on calls to Object.Equals. My little 2 item struct is 3 lines of definition and 7 lines of boiler plate to get it right. and my GetHashCode impl is suboptimal. F# records do all of that for you. every time. automatically.
Annatar 8y ago
I don't touch anything that runs on CLR or a JVM: waiting for the world to compile is unacceptable. For functional programming, I'll just continue learning ANSI common Lisp which compiles straight to machine code, thank you very much.
- avisser 8y ago
  Any reason in particular why it's "unacceptable"?
  - Annatar 8y ago
    It's slow and bloated. For someone who grew up coding intros and cracking protections in machine code on C=64 and the Amiga, such bloat simply won't fly. It's an abomination. I hate wasting my life away waiting for slow software.
    - nickpeterson 8y ago
      If it makes you feel better, the JVM and dotnet communities agree and have been working on strategies to reduce the bloat a lot. They also offer a ton of other resources to help tune things to your liking. I'm sure you can hand write a piece of C or Common Lisp that is very fast. But I'm sure you would also acknowledge that people that are good at JVM/Dotnet could probably write a pretty fast piece of code in them as well. So at a certain point you have to start weighing other things, like productivity, safety, tooling, libraries, etc. I find if I really dislike something, I try learning it, and at the end I find that I may not prefer it, but I always learn something from the experience. Think of it as an exercise in sharpening your debate arguments against proponents of these platforms.
      - Annatar 8y ago
        I had a semester of Java and AWT programming at the university. The professor was really good. My final project got a good grade. But after it was over, I knew I'd never touch Java again: any language where I needed to instantiate three different objects just to output a single message to the screen is crap. Available libraries or lack thereof were never criteria by which I judge a language. Chalk that one up to competing against other coders on the scene. If someone disasembled one's intro code and found that one were using pieces of someone else's code, one instantaneously lost face and would never be able to live it down. It was plagiarism. 35 years later those same people still get derided and laughed at. It's considered extremely lame, because it means one wasn't capable of writing one's own routines. This is elitist in the extreme and those are the stakes for making it to the elite programming circle that is the scene. I'm perfectly fine with that, under the motto "it's lonely at the top". And that's as it should be. IT doesn't need more programmers producing so much bloated garbage; it needs the best programmers producing small, light and fast software that's a joy to use to its users. So for me, having been tempered by such an elitist, competitive environment, library availability is never important. I understand that open source is different and I understand the advantage of not duplicating code, so if it's already been written and if it is good, clean code I'll use it, but I've no qualms about rolling my own. I would never allow for library availability to influence my choice of a programming language: the language must stand on its own, including how easy it is for the system administrator to install and upgrade my application during its software managent lifecycle. As programmers we should never make it easy or convenient for ourselves at the expense of complicating users' life or wasting their time. Never ever is that excusable.
agsdfgsd 8y ago
No, if you are a functional developer from haskell, you will not be impressed by F#. Why add silly things like this to your sales pitch if F# is your first functional language, and you're still pretty new to it?
cflyingdutchman 8y ago
If 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.
- AchieveLife 8y ago
  Has the culture improved since the acquisition? Last time I interviewed there I was treated like dirt.
  - cflyingdutchman 8y ago
    I'm genuinely sorry that you had a bad interview experience, feel free to email me more details so that I can make sure the feedback is routed to the right people. Over several years now, I've been very happy with the engineering quality and culture; I feel lucky to work with the people here.
deleted 8y ago
[deleted]
atombender 8y ago
F# 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 run a compiled F# program you have to have Mono installed? It does look like you can get AOT compilation with Mono [1], but the limitations (e.g. no generics, apparently) seem too onerous. [1] https://www.mono-project.com/docs/advanced/aot/ https://www.mono-project.com/docs/advanced/aot/
- AdeptusAquinas 8y ago
  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.
  - atombender 8y ago
    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/self-contained-linux-apps.md https://github.com/dotnet/core/blob/master/Documentation/sel...
    - chusk3 8y ago
      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.
      - 8y ago
moron4hire 8y ago
I really wish Unity3D would relinquish control of my Visual Studio Solution files and have a much nicer path to including its libraries as a dependency manually so I could start using some of the other languages in the CLR ecosystem. I've managed to get it to work before by very carefully searching for the DLLs in the Unity install directory and compiling my own DLLs into a Plugins folder in my Unity project, but it's very brittle. It's not obvious which set of DLLs to import (there are lots of different versions of each, for various rhyme platforms), and I upgrade new Unity versions frequently, so the location is a moving target. And Heaven help you if you want to depend on something that is only released as a script bundle in a Unity Package (like every VR SDK out there right now). And given how Unity's braindead YAML metafile system works, you're pretty sure to break your component references in your scenes and prefabs with even the most minor of rearchitecturings. Unity having its own build pipeline is a huge impediment. It all but forces you to write custom scripts that do some of the most basic things, as if we live in the Node hellscape of Gulp/Grunt/Webpack. And none of it is documented well enough to get it right without hours of ping-pong with test runs.
zenzen 8y ago
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 https://quorumlanguage.com/evidence.html
PsylentKnight 8y ago
Regarding 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/ https://safe-stack.github.io/docs/intro/
- chusk3 8y ago
  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.
thedirt0115 8y ago
I don't know F#, but I do know C#, and it feels like the author is trying to make C# look more difficult/verbose than it needs to be to make F# look better. Here is an alternative version of the "Everything is a function" section's IPasswordPolicy thing: https://ideone.com/3Savt9 https://ideone.com/3Savt9 I even went a little overboard with the function that takes a list of functions and returns a single composed function -- I could've also written a one-off that uses "&&" like the F# version: bool isValidCustom(pw) { return f1(pw) && f2(pw) && ...; } Am I missing something? Why did the author make the C# version so complex??
- algorithmsRcool 8y ago
  Well you're right of course. But my only thought here is that Dustin's code looks like idiomatic C#, but yours does not. You can do function composition in C# but I've virtually (heh) never seen it. Classes and Interfaces are the default abstractions in C# land even if there are other available.
- rjblackman 8y ago
  I haven't read the article in depth, but the authors example is written according to SOLID principles where composition is decoupled via interfaces and dependency injection. I think the author is trying to show the difference between highly decoupled code examples in c# and f#. In f# you compose with functions, in c# you compose with object instances.
- cgrealy 8y ago
  Actually you can make it even more concise with an inferred array var isValidShort = createPasswordPolicy(new [] { Test.MinimumLength(8), Test.MustHaveDigits, Test.MustHaveUppercase, });
dzonga 8y ago
Like I mentioned in another thread > Been learning F# the last two months. Wanted to learn Ocaml first. But F# is the sweet spot, beautiful functional syntax . Can leverage the now open .Net Ecosystem + pretty fast for doing financial stuff that I wanna do.
sidcool 8y ago
There's a thread every few months about 'Why You Should Learn X', and I feel overwhelmed by it. I liked the one about Rust and got into the Rust boat. Now I have no time and energy to learn F#. That's both frustrating and debilitating. Personal Opinions.
garfieldnate 8y ago
Honestly I was super psyched to get into F# after finishing Dan Grossman's programming languages class, but I abandoned it pretty quickly because setup was so difficult on my Mac. 1) Multiple versions of .Net available (.Net Core, Mono...) and different tutorials and documentation would apply only to one or the other. 2) I went with .Net Core because the community seemed to have decided on that, but there is no easy way to do a cross-platform GUI in F# using .Net Core. 3) I just couldn't find find a simple tutorial taking me from beginner to intermediate using a cross-platform toolchain and development environment. I stumbled around with Visual Studio Code for a while, ran into some compatibility issues with hundreds of lines of errors messages... I'm sure it would have been fantastic if I had had an F# person help me get set up and started, but the setup curve was too steep to be enjoyable (actually, setting up is never enjoyable. I just want to get to the good part of coding stuff!).

272 points by aloisdg 8y ago

I have a seasonal project that spins up around this time every year. Last year, I chose F# for a (relatively small) component of the project and I was not disappointed. I don't have access to the customer's systems, and usually with Python there's a bit of back and forth where I have to fix bugs that only customer is able to trigger. My F# program worked flawlessly the first time and has caused no complaints. I'm excited about writing more F# this year.

deleted 8y ago

[deleted]

Nelkins 8y ago

That "famous slide" really rings true for me. F# allowed me to forget (or at least not worry about) a TON of OO design patterns. Data goes in, transformation happens, data comes out. I do like that F# is very practical about OO though.[0] I feel that the language often strikes a balance of programming paradigms that enables me to be very productive. [0] https://eiriktsarpalis.wordpress.com/2017/03/20/why-oo-matters-in-f/ https://eiriktsarpalis.wordpress.com/2017/03/20/why-oo-matte...

winkelwagen 8y ago

I've been diving into f# in 2018. I came from c# world, and it really made me a better developer. Really recommend the language. Think it has a great balance between functional programming and OO if it is really needed. I really do think it's easier to write better .net programs with f# then c#. Think this article point out some great stuff. That said, it's quite hard to actually get to use it in production at the places I've worked. My college's are scared of it (that is pretty reasonable, considering c# is a good stable language and my team is confident that what we develop will make the customers happy). One thing that makes me hesitant to really try to get this adopted in my company is the tooling. My experience hasn't been great. It works, but it has been pretty unreliable. Some documentation was more focused on the "pre dotnet core" era of f#. I know i've been spoiled, but stuff like debugging, tooling and refactor tools can't touch Visual Studio. There are some decent options, Jetbrains Rider and VS Code are a couple of them. Small things, like creating a record type while typing is inconvenient. type Customer = { Id: int; Name: string; Age : int; } While typing an instance of the record let c1 : Customer = {Id = 1; gives you a bunch of compiler warnings, I know I'm not done, Compiler knows there are more properties. But without looking at the record type it's hard to see what order things are. I'm not sure if this is just OCaml thing, but C kind of languages are better at predicting what you want to create. It's weird that with the very predictable Hindley–Milner type system it can't provide the developer with good information. I know it's a small thing, but when working with large projects, I don't want to look everything up, I have the compiler have my back. I'll really think Microsoft should help the Fsharp Foundation more, seeing what an amazing language f# is. But it really could use some more love from MS. Perhaps they should help the community be more confident that they can solve the business problems they run into. I hope Microsoft would say: "Hey this is how you create The Boring Line Of Business App, with all the bells and whistles you normally need". From how to deal with Dependencies in large projects (No, a couple of (amazing) conference video's of Mark Seemann do not give me enough confident that after 6 months of development it still is manageable) Until the Tooling is done, I just keep enjoying the language and learn how to become a better developer with it.

maxxxxx 8y ago
"That said, it's quite hard to actually get to use it in production at the places I've worked. My college's are scared of it (that is pretty reasonable, considering c# is a good stable language and my team is confident that what we develop will make the customers happy)." That's my problem too. I would like to give F# a go but at work it seems close to impossible to implement. Most people don't see the need and if there is a problem it will be blamed on F#. It's hard to win there if management doesn't fully support it.
- brabara 8y ago
  Why not start introducing F# via unit tests?

urda 8y ago

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.

winkelwagen 8y ago
I've really enjoyed https://www.manning.com/books/get-programming-with-f-sharp https://www.manning.com/books/get-programming-with-f-sharp Think it gives a good overview of the language and it's easy to read. Considering that after a day of working I'm not that sharp anymore it was a good read for me. Also mentioned in the article, but Scott Wlaschin book really show the strengths of the language. Most of his stuff is great actually, but his website (FSharp for fun and profit) is not the most coherent read, I love using it as reference. I also recommend his conference talks, it has quite a bit wide range of topics. https://pragprog.com/book/swdddf/domain-modeling-made-functional https://pragprog.com/book/swdddf/domain-modeling-made-functi... There are also few courses on pluralsight, but cannot remember which ones I really enjoyed.
- urda 8y ago
  > Considering that after a day of working I'm not that sharp anymore it was a good read for me. That's a great consideration you made, and I'm in the same boat. I'll check it out thanks!
deleted 8y ago
[deleted]
Nelkins 8y ago
This site is a goldmine: https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/
dgudkov 8y ago
>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.

crimsonalucard 8y ago

I 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?

rspeele 8y ago
F# does not support dependent typing. And in general, because it has to interop smoothly with .NET code written in C# and VB.NET, F# is not nearly as hardcore on functional purity as something like Haskell or Agda, and correspondingly cannot guarantee as much safety through its type system. It is a wonderfully pragmatic language though and does guide the user towards more reliable software patterns than C# does. It sort of bridges the gap to be something you can actually use in production today, whereas the dependently typed languages are still in the realm of experimentation and toy projects for now.
rienbdj 8y ago
You are probably thinking of ‘F*’
bjoli 8y ago
Dependent typing generally doesn't play well with type inference (leading to things being all kinds of undecidable). I doubt it will ever make it's way into f#. GADT might, which provides a subset of the nice things of DT, but is much much easier to implement. F* has dependent types though.
javcasas 8y ago
You are thinking of OCaml and Coq.

mcintyre1994 8y ago

I've previously used Ocaml at my last job and use Scala at my current one, it's interesting that F# (just judging from this blog post) looks more similar to Ocaml than to Scala - like they've more aggressively pulled out syntax and embraced partial application etc. I'd always assumed F# was to C# what Scala is to Java - and I think that probably does represent their design goals, so I wonder what the different considerations were that led to them being relatively quite far apart.

pjmlp 8y ago
F# is the evolution of ML.NET developed at Microsoft Research.
- smcl 8y ago
  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.
  - jweir 8y ago
    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 https://en.wikipedia.org/wiki/ML_%28programming_language%29
    - smcl 8y ago
      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.
  - pjmlp 8y ago
    I got it a bit wrong. It was Caml.NET. https://www.microsoft.com/en-us/research/project/f-at-microsoft-research/ https://www.microsoft.com/en-us/research/project/f-at-micros...

algorithmsRcool 8y ago

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 more responsibility to the compiler to verify your program. I cannot overstate how important this is to maintaining correct software overtime. If you guard your touches with non F# code, you need far fewer unit tests and probably even less runtime checks because you already know if the types are right, so is the logic. And when you need to write unit tests, the functional style makes your tests very easy to write. 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.

contravariant 8y ago
>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.
- ambulancechaser 8y ago
  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 to set up a new constructor for Delivery that includes all of these properties. There is no unspoken agreement about that, you can set it in the model.
  - algorithmsRcool 8y ago
    > There is no unspoken agreement... Yes! That is exactly right, F# give you the tools to express your actual model with little/no ambiguity.

vumgl 8y ago

(no/less functional) C --> Java --> C# --> Scala --> F# ---> Haskell (more/all functional) - form a talk by Martin Odersky

Timothycquinn 8y ago
Do you know which talk this is discussed? I'm interested in watch his stuff.

phillipcarter 8y ago

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/ https://docs.microsoft.com/dotnet/fsharp/ F# on JavaScript with Fable: https://fable.io/docs/ https://fable.io/docs/ More F# in the browser with WebSharper: https://try.websharper.com/ https://try.websharper.com/ F# on Azure Notebooks (a hosted Jupyter notebook service that's free): https://notebooks.azure.com/Microsoft/projects/2018-Intro-FSharp/html/Introduction%20to%20FSharp.ipynb https://notebooks.azure.com/Microsoft/projects/2018-Intro-FS... And of course, the now legendary (at least among the F# community), F# for Fun and Profit: https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/

dustinmoris 8y ago
Thanks, I'll add these links to my blog post later tonight!
AdeptusAquinas 8y ago
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.

eterps 8y ago

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

zamalek 8y ago
Cargo[1]. REPL[2]. [1]: https://ardalis.com/how-to-add-a-nuget-package-using-dotnet-add https://ardalis.com/how-to-add-a-nuget-package-using-dotnet-... [2]: https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/fsharp-interactive/ https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/fsh...
- phillipcarter 8y ago
  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.
  - davidgrenier 8y ago
    I care about this a lot. All my respects for the efforts in that direction.
kej 8y ago
It's trailing behind C# (as always), but the plan is to support F# in CoreRT, which will get you your native builds.

jweir 8y ago

A gripe about F# on MacOs - how to install it, count the ways - 6. https://fsharp.org/use/mac/ 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/programming/free/analyzing-visualizing-data-f-sharp.csp https://www.oreilly.com/programming/free/analyzing-visualizi...

phillipcarter 8y ago
The FSSF site needs updating (which is happening). This explosions of options is quite a detractor, and they're aware of it as they are doing a redesign. You can see a more simplified version of how to get started here: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/ https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/
jjtheblunt 8y ago
brew install fsharp or similar worked fine for me.
- nobleach 8y ago
  Did you get fsi with that? That was the one thing that made me eventually install Mono.
knocte 8y ago
Yeah, the fact that Mono is inheriting all BCL code from .NETCore nowadays, but is still not .NETCore (because it has its own runtime) is a bit confusing. That being said, the best/easiest way to use .NET in the Mac is just install "Visual Studio for Mac" (the Community edition is completely free), which will under the hood install all you need (Mono, .NET Core, etc).

daxfohl 8y ago

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.

davidgl 8y ago
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/ https://docs.microsoft.com/en-us/dotnet/fsharp/style-guide/, and use just functions for DI internally where it makes sense.
jadbox 8y ago
It sounds like your (more or less) just using classes for just namespacing functions and allowing bundles of functions to get brought in?
- dvlsg 8y ago
  I've definitely structured f# modules that way. The module exposes one function that "injects" the dependency into multiple other functions, and then returns them as a blob. I'm not sure if that's "the fsharp way" (i suspect it isn't) and maybe I'll look back on it some day and cringe, but it's working pretty well for some of my (admittedly small) side projects I'm tinkering with right now.

ken 8y ago

"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?

phillipcarter 8y ago
.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.
- dustinmoris 8y ago
  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!
hacker_9 8y ago

steelframe 8y ago

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.

quickthrower2 8y ago
Maybe they want to do F# in their job, in which case they successfully filtered you out. Although it might have been smarter for them to ask about F# in an earlier round, or pre interview.

bnt 8y ago

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)?

smush 8y ago
This has been previously mentioned but F# gets all of the goodies that come with being a .NET language. Elixir comes from Ruby land and thus has a framework called Phoenix(?) which also has its fans. The big difference is that F# is a statically typed functional language, while Elixir is a dynamically typed functional language. Comparison of static vs dynamic types -> https://hackernoon.com/statically-typed-vs-dynamically-typed-languages-e4778e1ca55 https://hackernoon.com/statically-typed-vs-dynamically-typed... I personally opted for F# because of the domain modelling tools and the offloading of various caveats and edge cases onto the compiler's stack rather than the meatspace stack, but Elixir has many fans for a good reason no doubt, but I'll defer to someone with more experience working with it to weigh in.
- nickpeterson 8y ago
  Did you mean to say Elixir comes from Ruby? Surely you mean Erlang?
  - Multicomp 8y ago
    I think the poster got Crystal and Elixir confused. I do sometimes tbh
  - skosch 8y ago
    Elixir obviously is Erlang under the hood, but its syntax was inspired by Ruby's simplicity. José Valim, the creator, was also a Ruby contributor IIRC.
keithnz 8y ago
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. There are no lightweight isolated processes in .NET Elixir also has macros ( a very sharp double edged sword ) which can make frameworks nice to use. F# is stronger typing which is nice and often has the trait if it compiles, it works. Though the normal downsides of dynamic typing in Elixir are not so bad. But the best thing is to try both and make up your own mind

cgrealy 8y ago

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<int> Sort(List<int> values); } public class QuickSort : ISortAlgorithm { public List<int> Sort(List<int> values) { // Do QuickSort return values; } } public class MergeSort : ISortAlgorithm { public List<int> Sort(List<int> values) { // Do MergeSort return values; } } public void DoSomething(ISortAlgorithm sortAlgorithm, List<int> values) { var sorted = sortAlgorithm.Sort(values); } public void Main() { var values = new List<int> { 9, 1, 5, 7 }; DoSomething(new QuickSort(), values); } No, no, no, no, nope. public static class MergeSort { public static List<int> Sort(List<int> values) { // Do MergeSort return values; } } public void DoSomething(Func<List<int>, List<int>> sortAlgorithm, List<int> values) { var sorted = sortAlgorithm(values); } public void Main() { var values = new List<int> { 9, 1, 5, 7 }; DoSomething(QuickSort.Sort, values); } No interface necessary. Or immutability: "public struct Customer { public string Name { get; } public string Address { get; } public Customer(string name, string address) { Name = name; Address = address; } } So far so good, but unless someone knows C# very well one could have easily gotten this wrong." Really?? This is beginner stuff. I 100% agree that null sucks, functions should not need to be in classes and immutability is great, but this kind of strawman doesn't help his point.

keithnz 8y ago
I agree, it feels like the author is going out of their way to write really really verbose C#
algorithmsRcool 8y ago
You are right about the first example (although the F# version looks nicer =D) But that struct example is less than great. Just last night I had a readonly C# struct like that, that I used as a dictionary key and wondered why my perf tests took a nose dive when the Dictionary hit a few dozen entries. My boneheaded mistake was i forgot to override GetHashCode and Object.Equals. Great my perf was looking decent, but even then I was allocating 32 bytes of memory on every lookup. I forgot I needed to also implement IEquatable<> to prevent boxing on calls to Object.Equals. My little 2 item struct is 3 lines of definition and 7 lines of boiler plate to get it right. and my GetHashCode impl is suboptimal. F# records do all of that for you. every time. automatically.

Annatar 8y ago

I don't touch anything that runs on CLR or a JVM: waiting for the world to compile is unacceptable. For functional programming, I'll just continue learning ANSI common Lisp which compiles straight to machine code, thank you very much.

avisser 8y ago
Any reason in particular why it's "unacceptable"?
- Annatar 8y ago
  It's slow and bloated. For someone who grew up coding intros and cracking protections in machine code on C=64 and the Amiga, such bloat simply won't fly. It's an abomination. I hate wasting my life away waiting for slow software.
  - nickpeterson 8y ago
    If it makes you feel better, the JVM and dotnet communities agree and have been working on strategies to reduce the bloat a lot. They also offer a ton of other resources to help tune things to your liking. I'm sure you can hand write a piece of C or Common Lisp that is very fast. But I'm sure you would also acknowledge that people that are good at JVM/Dotnet could probably write a pretty fast piece of code in them as well. So at a certain point you have to start weighing other things, like productivity, safety, tooling, libraries, etc. I find if I really dislike something, I try learning it, and at the end I find that I may not prefer it, but I always learn something from the experience. Think of it as an exercise in sharpening your debate arguments against proponents of these platforms.
    - Annatar 8y ago
      I had a semester of Java and AWT programming at the university. The professor was really good. My final project got a good grade. But after it was over, I knew I'd never touch Java again: any language where I needed to instantiate three different objects just to output a single message to the screen is crap. Available libraries or lack thereof were never criteria by which I judge a language. Chalk that one up to competing against other coders on the scene. If someone disasembled one's intro code and found that one were using pieces of someone else's code, one instantaneously lost face and would never be able to live it down. It was plagiarism. 35 years later those same people still get derided and laughed at. It's considered extremely lame, because it means one wasn't capable of writing one's own routines. This is elitist in the extreme and those are the stakes for making it to the elite programming circle that is the scene. I'm perfectly fine with that, under the motto "it's lonely at the top". And that's as it should be. IT doesn't need more programmers producing so much bloated garbage; it needs the best programmers producing small, light and fast software that's a joy to use to its users. So for me, having been tempered by such an elitist, competitive environment, library availability is never important. I understand that open source is different and I understand the advantage of not duplicating code, so if it's already been written and if it is good, clean code I'll use it, but I've no qualms about rolling my own. I would never allow for library availability to influence my choice of a programming language: the language must stand on its own, including how easy it is for the system administrator to install and upgrade my application during its software managent lifecycle. As programmers we should never make it easy or convenient for ourselves at the expense of complicating users' life or wasting their time. Never ever is that excusable.

agsdfgsd 8y ago

No, if you are a functional developer from haskell, you will not be impressed by F#. Why add silly things like this to your sales pitch if F# is your first functional language, and you're still pretty new to it?

cflyingdutchman 8y ago

If 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.

AchieveLife 8y ago
Has the culture improved since the acquisition? Last time I interviewed there I was treated like dirt.
- cflyingdutchman 8y ago
  I'm genuinely sorry that you had a bad interview experience, feel free to email me more details so that I can make sure the feedback is routed to the right people. Over several years now, I've been very happy with the engineering quality and culture; I feel lucky to work with the people here.

deleted 8y ago

[deleted]

atombender 8y ago

F# 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 run a compiled F# program you have to have Mono installed? It does look like you can get AOT compilation with Mono [1], but the limitations (e.g. no generics, apparently) seem too onerous. [1] https://www.mono-project.com/docs/advanced/aot/ https://www.mono-project.com/docs/advanced/aot/

AdeptusAquinas 8y ago
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.
- atombender 8y ago
  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/self-contained-linux-apps.md https://github.com/dotnet/core/blob/master/Documentation/sel...
  - chusk3 8y ago
    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.
    - 8y ago

moron4hire 8y ago

I really wish Unity3D would relinquish control of my Visual Studio Solution files and have a much nicer path to including its libraries as a dependency manually so I could start using some of the other languages in the CLR ecosystem. I've managed to get it to work before by very carefully searching for the DLLs in the Unity install directory and compiling my own DLLs into a Plugins folder in my Unity project, but it's very brittle. It's not obvious which set of DLLs to import (there are lots of different versions of each, for various rhyme platforms), and I upgrade new Unity versions frequently, so the location is a moving target. And Heaven help you if you want to depend on something that is only released as a script bundle in a Unity Package (like every VR SDK out there right now). And given how Unity's braindead YAML metafile system works, you're pretty sure to break your component references in your scenes and prefabs with even the most minor of rearchitecturings. Unity having its own build pipeline is a huge impediment. It all but forces you to write custom scripts that do some of the most basic things, as if we live in the Node hellscape of Gulp/Grunt/Webpack. And none of it is documented well enough to get it right without hours of ping-pong with test runs.

zenzen 8y ago

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 https://quorumlanguage.com/evidence.html

PsylentKnight 8y ago

Regarding 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/ https://safe-stack.github.io/docs/intro/

chusk3 8y ago
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.

thedirt0115 8y ago

I don't know F#, but I do know C#, and it feels like the author is trying to make C# look more difficult/verbose than it needs to be to make F# look better. Here is an alternative version of the "Everything is a function" section's IPasswordPolicy thing: https://ideone.com/3Savt9 https://ideone.com/3Savt9 I even went a little overboard with the function that takes a list of functions and returns a single composed function -- I could've also written a one-off that uses "&&" like the F# version: bool isValidCustom(pw) { return f1(pw) && f2(pw) && ...; } Am I missing something? Why did the author make the C# version so complex??

algorithmsRcool 8y ago
Well you're right of course. But my only thought here is that Dustin's code looks like idiomatic C#, but yours does not. You can do function composition in C# but I've virtually (heh) never seen it. Classes and Interfaces are the default abstractions in C# land even if there are other available.
rjblackman 8y ago
I haven't read the article in depth, but the authors example is written according to SOLID principles where composition is decoupled via interfaces and dependency injection. I think the author is trying to show the difference between highly decoupled code examples in c# and f#. In f# you compose with functions, in c# you compose with object instances.
cgrealy 8y ago
Actually you can make it even more concise with an inferred array var isValidShort = createPasswordPolicy(new [] { Test.MinimumLength(8), Test.MustHaveDigits, Test.MustHaveUppercase, });

dzonga 8y ago

Like I mentioned in another thread > Been learning F# the last two months. Wanted to learn Ocaml first. But F# is the sweet spot, beautiful functional syntax . Can leverage the now open .Net Ecosystem + pretty fast for doing financial stuff that I wanna do.

sidcool 8y ago

There's a thread every few months about 'Why You Should Learn X', and I feel overwhelmed by it. I liked the one about Rust and got into the Rust boat. Now I have no time and energy to learn F#. That's both frustrating and debilitating. Personal Opinions.

garfieldnate 8y ago

Honestly I was super psyched to get into F# after finishing Dan Grossman's programming languages class, but I abandoned it pretty quickly because setup was so difficult on my Mac. 1) Multiple versions of .Net available (.Net Core, Mono...) and different tutorials and documentation would apply only to one or the other. 2) I went with .Net Core because the community seemed to have decided on that, but there is no easy way to do a cross-platform GUI in F# using .Net Core. 3) I just couldn't find find a simple tutorial taking me from beginner to intermediate using a cross-platform toolchain and development environment. I stumbled around with Visual Studio Code for a while, ran into some compatibility issues with hundreds of lines of errors messages... I'm sure it would have been fantastic if I had had an F# person help me get set up and started, but the setup curve was too steep to be enjoyable (actually, setting up is never enjoyable. I just want to get to the good part of coding stuff!).