23 ms·

Why Use F#?

• chmaynard 8y ago
  Sheesh! What's next? Maybe someone will register a domain to promote the use of two-ply toilet paper.
  • zunzun 8y ago
    It would be more efficient to have a single domain promoting F# on toilet paper, rather than having two separate domains.
  • jazzyjackson 8y ago
    I mean it's not like it's a scarce resource
• AdeptusAquinas 8y ago
  Because if you are a top-notch C# dev, F# is just like you normally code but with less brackets and null reference exceptions. Also, you haven't experienced implicit typing until you have used F#'s ridiculously powerful approach to it (relative to C# anyway).
  • bunderbunder 8y ago
    I'd argue that that's painting with too broad a brush. C# has picked up a lot of features to support functional programming, and has made great strides in reducing boilerplate and clutter, but there are still all sorts of things that F# has and C# either lacks, or requires a lot more verbosity to accomplish the same thing. Pattern matching, for starters. It's not just chained if-statements on steroids; F#'s decision to make partial matching emit a compiler error is a real sea change in terms of the level of compiler support you get in guarding against unintended consequences in an evolving codebase. Type providers. They let you interact with external data sources with about the level of ceremony you get in a dynamic language, but are still statically typed. The SQL type provider is particularly impressive. Not only does it generate your DTOs for you without ceremony, even when you `SELECT *`, even when the schema changes, but, if you make a mistake in an inline SQL query, you'll get red squigglies under exactly the spot in the string where the error is, just like if it had been a syntax error in the F# or C# code. Computation expressions. F#'s equivalent of Haskell's do notation. C# accomplishes similar levels of purpose-specific expressivity in some specific areas - LINQ, async/await, etc - by adding syntactic sugar to the compiler, which means only the C# compiler team gets to do it. Computation expressions let you roll your own. Currying and partial application. You can achieve the same result in C# with higher order programming, but it gets messy quickly. Also, there's an argument to be made that, similar to how objects are heavyweight closures, dependency injection is heavyweight currying.
    • mattferderer 8y ago
      Do you have thoughts on C# 8's increased pattern matching features?
      • bunderbunder 8y ago
        I haven't actually used C#, or any .NET language, since before 7 came out. Based on what I've seen as a sideline observer, though, it looks to me like C#'s pattern matching and destructuring are just syntacitc sugar, and therefore still significantly weaker than what F# has. I don't think you can get to the level of type safety that F#'s pattern matching provides without F#-style algebraic data types. The reason is that a set of algebraic types in F# is effectively bundle of types that are collectively sealed. In C#, you can really only seal the terminal classes in a cluster of types, which means that anyone else can come along and add a new class to the type at a later date, after the initial module is compiled, possibly even at run time. That undercuts your ability to ensure that a branching statement is airtight. I believe C# also still lacks active patterns, which are a pretty killer feature if you're looking to do data-oriented programming.
        • victorNicollet 8y ago
          C# now has active patterns (which feel like the `is` pattern matching) in the ability to declare a variable as you pass it as an out parameter to an extension function, e.g. if (num.IsNotPrime(out var a, out var b)) WriteLine($"{num} = {a} × {b}");
      • platz 8y ago
        any kind of pattern matching without the ability to check for exhaustiveness defeats the safety they provide, which is need to make that comparable in utility and power to inheritance (i.e. so you can actually replace inheritance w/ pattern matching.) Much like how the compiler assists you when writing subclasseses so that you've implemented all the required methods, real Pattern Matching (F#) gives you the same guarantees from the compiler that you've handled all the possible cases appropriately. Exhaustiveness checking is what elevates pattern matching to the other side of the expression problem, which is about getting feedback from the compiler to help you write programs. a glorified switch statement does not help you do that, and so you still have to write subclasses to get compiler feedback.
• BucketSort 8y ago
  Ha, so Microsoft stole Haskell?
  • syndev 8y ago
    Fun fact: Much of the Glasgow Haskell Compiler was written/influenced by Simon Peyton Jones, who is at Microsoft Research.
  • wenc 8y ago
    F# is really more in the ML family of languages.
  • theonemind 8y ago
    F# resembles OCaml more closely, I think.
• s369610 8y ago
  Didn't see a mention of the fact it can compile to and interop with JS via Fable https://fable.io/ https://fable.io/ which is pretty handy
• projectramo 8y ago
  Okay, I have heard many good things about F# so I’ll give the (probably) kind people who work there two tips on how to get more people interested. 1. Release an easy to use web framework that deploys easily. (Rails clone) 2. Release an IDE which can graph from the command line (R studio or Spyder clone) If you already have these (say a subset of .Net or visual studio / vscode) then the tutorials are misleading because they don’t seem the same.
  • duncan-donuts 8y ago
    There’s a dotnet core bootstrap command that can use f#. There’s not as many options as c# but it seems like their working on it.
  • kirse 8y ago
    Best web frameworks: https://github.com/giraffe-fsharp/Giraffe https://github.com/giraffe-fsharp/Giraffe <- thin layer on top of ASP.NET Core https://safe-stack.github.io/docs/intro/ https://safe-stack.github.io/docs/intro/ <- slightly more opinionated but also .NET Core based. I tend to mix F# and C#, Giraffe is great for sticking a slim web API or interface in front of .NET Core applications that use a combination of F# and C#.
    • sparkie 8y ago
      Another suggestion would be websharper. I'm not a web developer, but I have found it extremely simple to write some basic web apps using this.
  • bunderbunder 8y ago
    to #2 - FSharp.Charting should work from the REPL (though I haven't tried it myself). You can get the REPL within an IDE from both Visual Studio and VSCode.
• knocte 8y ago
  I love F# and there's only one thing lacking in its ecosystem: not many opensource projects written in it. And I don't mean libraries, tools & frameworks, there are tons of those; I mean a real app. But I hope I can break the trend myself: http://github.com/knocte/gwallet http://github.com/knocte/gwallet . If you want to learn F# by contributing to a real opensource project, you have a chance now.
  • AdeptusAquinas 8y ago
    I built a 2D platformer in it: https://github.com/ChrisPritchard/MiniKnight https://github.com/ChrisPritchard/MiniKnight Also uses MonoGame, and its all running on dotnet core. Reasonably sizable, though still more of an exercise than production quality.
    • knocte 8y ago
      Nice! I wonder if you could remove the dependency on System.Drawing by using SkiaSharp?
      • AdeptusAquinas 8y ago
        I probably don't need to use bitmaps as maps at all, really; Text files would work just as well. But using System.Drawing cross platform in .net core was an education in itself, so I think worth it :)
• Koshkin 8y ago
  The curly brackets is not “coding noise.”
  • walljm 8y ago
    yes! when they are missing I spend too much time guessing at implied meaning. if makes me uncomfortable, like reading long text in a sans serif font
  • yawaramin 8y ago
    Tell that to Python! ;-)
  • deleted 8y ago
    [deleted]
  • verinus 8y ago
    I think otherwise. Curly braces and semicolons do not serve a purpose. My only beef with F# is multi line expessions...indentation is sometimes weird.
    • kkarakk 8y ago
      curly braces enable code readability, you know where to start reading and you know where to stop reading. the situation is the same with the semicolon. programming languages are written to be read by humans and humans do better with start and stop points. if i've ever blearily looked at code at 3 in the morning,i basically run on autopilot relying on the braces and the semicolons to guide my eyes
      • sparkie 8y ago
        If you use VS or Monodevelop, there's are options you can enable which show indentation margins, which is even better than braces. Seems like a non-issue.
        • Koshkin 8y ago
          Basically, you are discussing an attempt to move away from the purely textual, linear representation of program code (at least, in the way the programmer sees it). Yes, sophisticated tooling becomes very important then. But it is not always available.
• Barrin92 8y ago
  In my opinion it's honestly the best statically typed general purpose programming language. f# and also Ocaml strike for me the right balance between practicality and correctness (strict by default, no insistence on purity), but still immutable, good concurrency story, functional first with the ability to write imperative code easily, great type inference etc.. Given that so many mainstream languages are piece by piece moving into the same direction and adopting the ML family approaches I have no idea why not more people are moving directly to F# or Ocaml.
  • laylomo2 8y ago
    I moved directly from Python to OCaml and I have to say, I’ve never been happier. Special shout outs to Jane Street, as their open source software is really solid and a pleasure to use. The community is small but really smart. Overall I think F# and OCaml really nailed the programming language design sweet spot of powerful and practical.
    • grdvnl 8y ago
      Can you eloborate on what kind of projects you work on which has made the move easy from Python to OCaml. While I love OCaml I have not heard positive things about the library eco-system in terms of variety and maintenance. Perhaps, you could throw some light on that based on your experience, especially after giving up the eco-system Python provides you. This is a sincere question and would love to find good excuses to adopt OCaml as my primary language of choice.
      • ernst_klim 8y ago
        >I have not heard positive things about the library eco-system OCaml has quite a neat ecosystem, though. Especially in terms of quality. There are a few major and a bulk of minor groups that write libraries for different purposes, such as: * MirageOS -- people behind a bunch of a high quality system libraries, there are tls (in pure ocaml) and various cryptography primitives, filesystem drivers, tar, zlib, full tcpip stack, http server, git (in pure ocaml, not a mere binding), irmin (a git-based key-store database with concurrent access), dns and some other [1]. * Ocsigen -- webdevs, authors of Lwt (monadic concurrency library), js_of_ocaml (ocaml to js compiler) and related stuff [2] * Jane Street, Facebook, blumberg -- reason syntax, bucklescript (alternative npm-ecosystem-frienly javascript compiler), various libraries for serialization, containers etc. * Others Opam [3] has quite a comprehensive set of libraries pretty for every purpose: data serialization, interaction with other langs (python, R, beam Erlang/Elixir), servers, db bindings, stuff for system or web programming. Some stuff is absent, but it's definitely not a scorched field, and most of the time the benefits worth writing an absent binding or two. [1] https://github.com/mirage https://github.com/mirage [2] https://github.com/ocsigen https://github.com/ocsigen [3] https://opam.ocaml.org/packages/index-popularity.html https://opam.ocaml.org/packages/index-popularity.html
• keithnz 8y ago
  I played around a lot with F#, and I really like it, but I got to this question of why use F#, and it is actually really hard to come up with a good answer to it, mainly because C# is really good and the real question in .NET is why use F# over C#. If you program with the same mindset of F# in C# then the differences are not super quantifiable. In general terms F# as a language is nicer than C#, but my real question is it good enough that you'd want to covert to it if you are mainly a group of C# programmers, and I reached the conclusion that it's probablly not simply becaus C#, in general, is not really that horrible to start with and a lot more people do things in C# and everything in the .NET world is looked at through the lens of C#. I asked a similar question on the F# communities slack, and beyond a few language features ( that are nice! comprehensions and discriminated unions, and more concise syntax with implicit typing ) it's really hard to find a reason. Part of the problem is there is very little in terms of libraries that are unique for F# that massively jump start you in any particular direction. What's more, quite a lot of F# code that fits in with frameworks that were built in C# often just look like C# written in F#. F# code written with F# oriented libraries are really nice and super concise, but it's a bit of a lonely world.
  • knocte 8y ago
    > If you program with the same mindset of F# in C# then the differences are not super quantifiable. I think they are. F# defaults to immutable stuff. Everytime you write anything in C# and forget the word "readonly", you're opening the door for a race condition. Also F# is much more succinct, things that take dozens of lines in C# are just one line in F#, take a look at this quick guide I wrote: https://github.com/knocte/csharp2fsharp https://github.com/knocte/csharp2fsharp
    • keithnz 8y ago
      While those are nice things, they don't really bite me in the C# world. There's a lot of fuss about it in the F# world, but it really isn't that big of a problem in my experience. I do like the robustness of it, but in practical terms... it's only a minor point in F#s favor
• smt88 8y ago
  I've read on HN that F# doesn't get nearly as much attention and support from Microsoft as C# does, to the point where people expressed concern that F# might be put into maintenance mode. Does anyone reading this feel that way, or was it just FUD?
  • xvilka 8y ago
    There is always an option to switch to OCaml instead. Especially these days it gets more and more attention to improve Windows support.
  • lenkite 8y ago
    F# support always lags behind by a couple of years. Only very recently (as of last week) you could release F# UWP apps. https://github.com/dotnet/corert/issues/6055 https://github.com/dotnet/corert/issues/6055
    • pjmlp 8y ago
      Which still isn't production ready it seems. "One thing I noticed is that the compiler only crashes when building x86. It compiles fine for x64." "Are we stuck on "Allowed but not officially supported" for now or are there any plans towards "Officially supported" ?"
  • pjmlp 8y ago
    Speaking for the tooling attention that is accurate. Somehow F# isn't part of the full .NET team, as such it doesn't get the same attention regarding UI designers (Forms, WPF, UWP), database designers (EF) or deployment targets (IoT Core/.NET Native). There was a Visual Studio release where they decided not to hold back the release, even though it broke a couple of F# tooling. So there is that, on the other hand Microsoft seems to at least be willing to push it as a data science language on Azure.
  • oaiey 8y ago
    MS' Matt Torgeson explained that once. Their investment is aligned with the user base. There are millions C# devs, 100 Thousands of VB.NET devs and 10 Thousands F# devs. But in difference to VB, F# has a independent community with a strong focus on improving F#. All I hear from MS is that they love F# but the workhorse is C#.
• Solar19 8y ago
  I've wanted to learn F#. I'm particularly curious about parsing and text processing, and wonder whether the pattern matching feature would work well for that. It would be great to see an HTML minifier in F#. I've thought about building one as a way of learning the language. An F# based static site generator, similar to Jekyll or Hugo, would also be neat. Compilation of F# is a confusing story to me. If it's still compiling to an IR, and getting JITted at runtime, that seems kind of inefficient in a world where Go exists. There's the CoreRT project, I think, that allows for precompiled .NET applications, but I'm not sure how F# fits in. I also read that all Windows Store/UWP applications are precompiled on Microsoft's cloud. I'm curious about compile-time flags and optimizations for F#, but they're rarely mentioned.
  • keithnz 8y ago
    you might want to look into parser combinators https://fsharpforfunandprofit.com/posts/understanding-parser-combinators/ https://fsharpforfunandprofit.com/posts/understanding-parser... depending on what kind of "text proccessing" you want to do.
  • bunderbunder 8y ago
    > If it's still compiling to an IR, and getting JITted at runtime, that seems kind of inefficient in a world where Go exists. It really depends on your use case. If you're writing programs with very short run times, for example, then the time spent on spinning up the run-time and JITing the bytecode can amount to a significant portion of the program's execution time. If you're writing a program that's going to run for several seconds or minutes (let alone hours, days or weeks), then the milliseconds spent JITing the bytecode just don't matter. It's also true that, since JIT compilation happens just in time, it doesn't really have the luxury of being able to spend a whole lot of time on optimization. Depending on the kind of problem you're working on, that can make a meaningful difference. Fortran or C would still be my languages of choice for serious number crunching. .NET tends to be used more for I/O-bound or non-performance-critical applications, though, where that doesn't really matter, either.
  • AdeptusAquinas 8y ago
    For text processing in F# there is a library called FParsec, which is really powerful: http://www.quanttec.com/fparsec/ http://www.quanttec.com/fparsec/ Regarding JIT and Go, I've built identical programs in both and while Go is faster, its not by as much as you would think (in my example, 60ms vs 40ms). Go is much more verbose to write, but its output exe is all by itself without the hundreds of dlls .NET likes to lug around. F# works with CoreRT just fine, with some small caveats (its sprintf/printfn functions don't work I think). I've modded one of my games to use it: https://github.com/ChrisPritchard/Tetris https://github.com/ChrisPritchard/Tetris
• jchendy 8y ago
  > // no curly braces, semicolons or parentheses Is this a good thing? It feels like saying "It's English without the periods or line breaks or capital letters."
  • bunderbunder 8y ago
    Curly braces - F# is a whitespace-significant language, so contexts are still plenty visible. Semicolons - If that's the main thing telling you where an expression ends, it's time to start taking your code formatting more seriously. Parentheses - Still exist, but only for expression grouping and tuples. It's just that they aren't used as a function application operator. This admittedly takes some getting used to, but starts feeling easy and natural surprisingly quickly. Importantly, function application without parens feels a lot nicer in F# than it does in Scala or Nim. I think the difference is that, in F#, adding parens around a function's argument list would actually change the meaning of the expression, and likely cause a compiler error.† In Scala or Nim, they're (sometimes) optional, which just creates this unnecessarily confusing situation, not entirely unlike optional semicolons in JavaScript. † - If it's a 1-ary function, you'd be fine, because it would interpret the parens as grouping operators around the argument. If it's a 2-ary function, then it would probably cause a compile error, because parens around a space-delimited list are (I'm pretty sure - it's been a while since I last worked in F#) not valid syntax. If you add commas, so that it looks like a C# method call, it would then interpret it as a tuple, which would probably mean a compile error, unless the function has an overload that accepts a tuple of that arity as its first argument, and, even then, only if applying that version of the function doesn't somehow lead to a type error. (Edited for clarity and extra babbling.)
  • BeetleB 8y ago
    It is because those things are simply not needed to parse or understand the code. Everyone indents anyway. So why need braces? Most people write one statement per line. Who needs semicolons. I've often called it the most useless character in programming language history. Whenever I switch from a language that doesn't use them to one that needs them, it's a horrible transition. I have to mentally remember to add this character at the end of most lines. Parentheses for function calls - in some contexts they are helpful. In most, though, they are not needed. Wherever they are needed, you will have them in F#. For people who went from Python 2 to Python 3, you'll know the pain of suddenly needing parentheses for print statements, and for most of those people, you will not see any benefit to adding those parentheses. Extend that to other functions.
• lihaoyi 8y ago
  Having used and enjoyed F#, I ended up programming in Scala which is almost the same language, despite the huge superficial differences: - Indentation delimited blocks vs curlies - CLR vs JVM - Whitespace vs Parenthesis for function calls - Currying by default vs currying optional Despite all this, when you actually start coding, it's remarkably the same: - Immutability by default, transformations rather than mutation - Less classes with embedded implementation logic, more "dumb" records with external functions - Structural pattern matching - Tagged unions - Type inference - Convenient definition of record/struct-like data types with free copy-constructor - Operator overloading - Easy FFI to external libraries in a different paradigm - Easy "dropping down" to mutable, imperative code (e.g. for performance, or interop) - Both have lots of syntactic and semantic warts and corner cases, though few enough you can live with them - Garbage collected, multithreaded, JITed runtime - Both compile to Javascript While every single feature looks totally different on the surface, starting with a totally different syntax, the two languages are more the same than different. If you look at the tutorials linked from that page, all of them can be translated almost line-for-line from F# to Scala (and vice versa: take any random Scala tutorial, and you can trivially translate it line-for-line into F#) Scala brings with it a bigger ecosystem, both in Scala and from the JVM, and better tooling support in general (Both Scala-specific, as well as general JVM tooling which all works with Scala: profilers, debuggers, package managers, ...), and slightly more seamless platform interop (Scala <-> JVM is less jarring than F# <-> C#), which is why I ended up sticking around.
  • soulnothing 8y ago
    I can echo this. I'm working in F# in my day to day. While I like the language. I find the tooling IDE and other essentials are missing. I spent several weeks fighting swagger generation client and server tools. Something that just worked on the jvm. I bounce between Scala and Kotlin. But as a Linux dev I find the JVM far more forgiving.
    • noobdevguy6335 8y ago
      I am new to programming...wanted to import and process tables from https://en.m.wikipedia.org/wiki/Megacity https://en.m.wikipedia.org/wiki/Megacity Was using ionide on vscode But not working because .NET CORE is not supported Returns the suggestion to switch Fsac.Runtime to netcore after I get the error fs0039 HtmlProvider is not defined even though Intellisense recognises it.. ...refer below https://github.com/ionide/ionide-vscode-fsharp/issues/973 https://github.com/ionide/ionide-vscode-fsharp/issues/973
• galkk 8y ago
  I love F#, but it seems like the language is either abandoned or on life support by Microsoft - compare the feature development speed of C# and Typescript against F# and you'll see that.
  • sytelus 8y ago
    This doesn't look like "on life support" to me: https://blogs.msdn.microsoft.com/dotnet/2018/03/06/f-language-and-tools-update-for-visual-studio-2017-version-15-6/ https://blogs.msdn.microsoft.com/dotnet/2018/03/06/f-languag...
  • metta2uall 8y ago
    Lots and lots of new "features" isn't necessarily a good thing.. Also F# already has many of the features that are being added to C# and TypeScript ;) I for one would advise Microsoft to sponsor more work on F# libraries, such as in data analysis & TypeScript interop..
  • bonesss 8y ago
    C# is still rushing to get features that F# has had for years, with no hope on some major fronts. If F# were innovating that much it would indicate that F# was sorely lacking at launch, but it wasn't. F# is based on a much more mature langauge, with mature concepts for handling the secondary and tertiary effects of those features currently coming into C# and Typescript. By adopting that mature language, F# started out "right" and hasn't needed much to fix it. And in terms of work: checkout the templates for F#, the libs for F#, and the thoudands of examples on MSDN in F#... But more specifically, check the amount of low-level improvements, refinements, and user-friendly sugar the team has landed in years of late. There's constant improvement, but of a less "revolutionary" nature as the base design was so mature. People confuse new shiny toys in IDEs with fundamental support. That's not necesarily the important thing... The convergance of functional languages and cloud native development is, in many cases, the important thing to MS, and is another area where F#s tooling/ecosystem is years ahead of the C# equivalents.
• kyleperik 8y ago
  Can someone please explain to me how you can use F# without each aspect of the development process being a Microsoft technology? Not to be rude, I just honestly want to know. There is quite a bit of hype around C#, F#. But every time there is a comparison to other languages it seems to skip over the fact that you much have a windows computer running Visual Studio which is a big disadvantage to some people. Quite honestly, they are great languages. I just don't want to buy in completely to Microsoft
  • nikofeyn 8y ago
    is it microsoft or windows you are against? basically all of the f# toolchain is open source, and it runs perfectly fine on all three major os platforms using either .net framework (windows), .net core (cross-platform), or mono (cross-platform). most people either develop f# in visual studio or using visual studio code. same goes with c#. .net core, which is intended to be fully cross-platform is the future of .net.
    • kyleperik 8y ago
      I understand there exists .net core and mono. I'll give them mono. My problem is I haven't seen a single example of a practical application written in .net core or a company that uses it, everything is .net framework. There just aren't many available alternatives to the frameworks and packages that are those who use .net framework take for granted. I hear what they're saying about it's the future, but I have yet to see the fruit of it. To me .net core seems more like just a buzz word to prove that they like open source and anyone can use their software. But there isn't any way to monitize it so there isn't any reason for them to focus on it.
      • nikofeyn 8y ago
        well, i don't know what to tell you. i am not really here to defend or market for the world's most valuable company. all i know is that my understanding is that .net core is the future of their .net stack and they are doing things that show that. for example, with .net core 3.0, there are desktop packs for uwp, wpf, and windows forms so that you can develop even your windows apps for .net core. so even on windows, .net core is quickly moving to replace .net framework for new projects. of course old projects will likely lag being so attached to the .net framework. that's the case for any technology platform transition. also, on a technical point, .net core is fast, faster than .net framework and mono.
• staticassertion 8y ago
  If I want to learn F# is there a good IRC/slack channel I can get on? I'd like recommendations for libraries. I have a project I could throw at it for fun/ learning. P.S. Can someone explain this? // complex types in a few type Employee = | Worker of Person | Manager of Employee list
  • deleted 8y ago
    [deleted]
  • scriptdevil 8y ago
    Employee, Person and list are types Worker and Manager are constructors Employee is a Sum Type i.e. it can either take a value of (Worker personObject) or (Manager [empObj1, empObj2...]) for instance, an binary tree would be type Tree a = | Leaf of a | Node of (Tree a * Tree a) Now, a Tree Int would be t = Node (Node (Leaf 1, Leaf 2), Leaf 3)
  • platz 8y ago
    abstract class Employee {} class Worker : Employee { public Worker(Person o) {...} } class Manager : Employee { public Manager(Employee[] o) {...} }
    • sparkie 8y ago
      abstract sealed class Employee { enum TAG { Worker, Manager } readonly TAG tag; Employee(TAG t) { tag = t; } public class Worker : Employee { public Worker(Person p) : base(TAG.Worker) { ... } } public class Manager : Employee { public Manager(Employee[] o) : base(TAG.Manager) { ... } } } This is a bit closer to how it is really implemented. The constructors are internal to the outer type because it is sealed, making it a closed type. Interestingly C# rejects abstract & sealed on the same type, although this is accepted on the CLR. Discriminated unions are sometimes called tagged unions because of the way they're implemented. It's typically more efficient to check the tag on the object than it is to test its type. The tag is used when pattern matching over the object.
• month13 8y ago
  Wow, and I was just looking at mixing this in with a API C# dotnet core app I was playing with. Wish it was easier to mix the two, it's pretty nice being able directly interface through dotnet, be even better if I could have fs and cs files next to each other.
  • sparkie 8y ago
    One thing about F# is that the ordering of compilation units is essential. You need to list your files in the order they are to be compiled because you cannot have circular dependencies between the units. This leads to making better decisions about code most of the time. It is still possible to have circular dependencies. Either by including the mutually related types in the same code file separated by the "and" keyword, or by using signature files to define the type signatures ahead of their implementation (which work similar to header/implementation files in C, C++ etc).
• seanmcdirmid 8y ago
  Someone who worked on F# once told me that one reason F#'s uptake was limited was because C# was so good at stealing its best features.
  • btschaegg 8y ago
    > …because C# was so good at stealing its best features. Let's agree on "replicating some of its great features". If you look at what C# makes of them, more often than not, it's a hack. Maybe one that's better than what C# had beforehand, but a hack nonetheless. Example: `async` in F# is not only amazing because of async IO, but its integration is really elegant, too: `async` is basically just a computation expression (if you used haskell: read "do notation"). C# OTOH built in a whole new class of functions that's hardcoded into the language (the same techniques also differentiate C#'s iterator blocks vs. F#'s `seq`). Another example: F# has pattern matching, which is tremendously useful because it is exhaustive (there are squigglies if you forget a case). C# 8 introduces switch expressions that aren't, but will throw an exception at runtime instead (i.e.: the detection code is there anyway[1], it's just used the wrong way). [1]: AFAIK, the autogenerated `default:` IL code is omitted if the compiler can prove that it will never be called. Someone mentions that in the latest "What's new in C#8" videos.
    • kod 8y ago
      Isn't async in f# considerably less efficient than in c#?
      • btschaegg 8y ago
        I think so, yes. However, I'd attribute that to F# having the first implementation and not enough clout to influence the central .NET implementation, like C# did. AFAIK, there's another computation expression builder using Task<T> in FSharpx that performs better. However, since in C#, async functions also seem to boil down to monadic continuations, I see no obvious reason the F# way couldn't be optimized to the same degree (given enough determination and resources). If there's anyone here with insight into the `async` implementation that knows otherwise, I'd really appreciate a comment on this :) Edit: Andrei Alexandrescu had a nice latin phrase on this in a talk at DConf 2018[1]: «Quod licet iovi non licet bovi». There, he's basically arguing the same thing: It is very often more desirable to give the language user a tool they can use themselves instead of reserving it only for the language implementers. [1]: https://dconf.org/2018/talks/alexandrescu.pdf https://dconf.org/2018/talks/alexandrescu.pdf Page 4
• buybackoff 8y ago
  I used to love F# before .NET Core, but then it was broken for two years for any sane design time experience on Core. I even wrote some rant about it with specific concerns I had (http://hotforknowledge.com/2016/10/19/4-functional-for-thought-imperative-for-hacking/ http://hotforknowledge.com/2016/10/19/4-functional-for-thoug...). Two years later.. and very recently the .NET Core story started to work well, tooling improved to quite workable state, and in combination with C# it's very strong mix of practicality/performance + complex flexible abstractions and correctness. Over that time F# has added quite a lot of low-level performance features (on par with C# - Span/Memory<T>, ref structs, struct tuples/unions, voidPtr, etc) and they just work. Build time is probably the main concern now, I have to disable building F# projects when they are in a solution but not touched because even on i7-8700/16GB it's very noticeable. Two weeks ago I needed text parser and picked familiar FParsec. It's one of the fastest one in .NET (including C# ones) and is a mix of C# for low-level stuff and F# for powerful abstractions. I refactored it quite substantially and tooling was finally nice. But my attempts to micro-optimize it yielded only in substantially reduced GC due to the support of value structs and Span<T>, throughput was already quite optimal from .NET perspective (only c.<5% gain probably due to GC), so if used with care F# could be as fast as C# (which BTW is native-like fast when also used with care). I believe such mix is the winning combination: C# is best for low-level high performance stuff, F# is best for complex things such as recursive data structures, analytics and so one. My big concern is that F# community is great but often F#-only focused, e.g. reinventing existing C# libraries just because it's not F#. This isolationism from .NET as a uniform platform led for example to things such as F#'s `async` is better than Task Parallel Library (C#'s async/await machinery) in theory/design, but TPL is so much superior is usability, performance and deep platform integration but F# cannot use it directly. Without native TPL `task{}` F# is not a fully-featured .NET Core citizen but a niche language for specific tasks where it shines, e.g. to write a AST parser for a new query language. Sad that MSFT invests so little in F#, but the language is definitely is alive, is improving and is worth using.
  • verinus 8y ago
    As I understand it, F#'s async funktionality was there first, and C# TPL was modeled after it, but I might be mistaken... Anyhow I am with you that this is one of the problems I have with F#. Interop from F# to C# is generally pretty bad.
• dzonga 8y ago
  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.
• pjmlp 8y ago
  Lack of support in all targets that require .NET Native, no love from the teams that do .NET graphical tooling, a couple of high figures on the community that love to bash C# and VB.NET and the company that makes it possible that F# exists to start with, is what puts me off to invest more time into F#. It is one of the best ML derived languages, but as it is, I rather wait for C# and VB.NET to keep getting features from F#.
  • gaterelic 8y ago
    > a couple of high figures on the community that love to bash C# and VB.NET and the company that makes it possible that F# exists to start with I stopped learning F# myself for this reason in particular. I really enjoy the language but I just cannot stomach the F# community. The .NET community is small enough as it is, and F# is a fraction of a percent of that, but they are extremely vocal others and bully others for what seems like no other purpose than to gain personal popularity and sell books. If this community went away I think the language would do much better, or maybe there would be room for another functional language on .NET that could start fresh without a history of pain. The entire situation is simply sad.
• rusabd 8y ago
  Does anyone know specific teams in Microsoft which are mostly F#? I might start to target them :)
• dkrikun 8y ago
  Seems like a decent alternative to C# on dotnet. Its a pity it feels second-class.
• verinus 8y ago
  imho one of the best sites for learning a programming language if you already know how to program. My biggest problem with F# is the bad tooling. For professional coding you need tools like static analysis, refactoring and so on. with those you can use the knowledge of other to improve your code. R# did a lot for C# in that regard.
• Jenz 8y ago
  I'm impressed :o
• ainar-g 8y ago
  They show the “type-safe printf” example there, but they don't seem to explain anywhere, if I can write my own type-safe variadic function or not. Is printf a built-in that is built with magic not allowed for mere mortals or do they just not dive into the topic because it's complex? Can any F# affectionados elaborate? Also, they only talk about units of measurement in the context of floats. Can I not have integers or rationals with units?
• ssijak 8y ago
  How does F# compare to Haskell? I wan`t to put one staticaly typed functional language under my belt and I do like what I read about F# but I do not like it`s windows/microsoft ecosystem. I`ll probably go with Haskell.
  • oblio 8y ago
    .NET Core works on Linux, Mac. Of course, if you just dislike Microsoft, can't help you there :)
  • sparkie 8y ago
    F# is not strictly tied to Windows, it also works fine on Android, iOS & Linux, and is completely open source. It was open source well before the rest of the .NET ecosystem. Community contributions are larger than Microsoft's own. Haskell has very limited mobile support. In terms of language. F# is easier to learn and more practical to use for everyday programming. Haskell is more of an academic language, and takes a high level of expertise to utilize for real world development. Haskell is a purely functional language which makes great effort to eliminate side-effects altogether. F# on the other hand, is merely functional-first, but allows side effects by explicitly marking things as mutable, or by utilizing existing .NET libraries which have side-effects.
• gambiting 8y ago
  "F# is not cluttered up with coding “noise” such as curly brackets, semicolons and so on. You almost never have to specify the type of an object, thanks to a powerful type inference system." As a C++ programmer, both of those sentences make me shudder. Lack of specified types reduces readability by an order of magnitude, at least for me personally, and especially with complex projects I end up spending a lot of time trying to guess "what is the compiler going to assume this object is"(looking at you, "auto" nonsense in C++)
  • jcelerier 8y ago
    I have seen a lot of people say something like you did, and after one month working in a mostly-always-auto project they can't ever go back to writing types that your compiler knows perfectly well. 99% percent of the time it is the interface that matters, and for the 1% remaining, sure, write your type.
    • IshKebab 8y ago
      It's not the writing of auto that is the problem. I agree with op. I try to avoid auto if the type is short enough to easily type.
      • stinos 8y ago
        But this introduces inconsistency and hurts readability and maintanability: sometimes auto, sometimes not, purley based on some arbitrary limit of amount of characters in the type name? I'm not advocating everything must be auto but surely there's better and more consistent rules than that.
        • IshKebab 8y ago
          I don't think it is an important inconsistency and I don't see why it would hurt maintainability. Maybe you're thinking "you can't change return types easily" but in practice the situations where you can change a return type without altering calling code at all are extremely rare. Also, I agree that there could be a better solution - always use auto, and use an IDE which shows you the type inline. IntelliJ can do this for Rust. But unfortunately no C++ IDE has code intelligence anywhere near good enough to do this reliably.
• insulanian 8y ago
  My favourite F# features: - Single-case discriminated unions. I feel so unprotected when working in C# due to IDs usually being primitive types. You're never sure if you'll accidentally flip two `int` parameters in a method call. - Automatic currying and partial application in combination with piping `|>`. Enables so intuitive and elegant code flow. Performance characteristics are decent as well[1]. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/fsharp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
• hexo 8y ago
  and yet they impose nonsensical CamelCase on us where unsuitable as always, for example - this.IsEven... i'd say IsEven is a type, buuuuuuuuuuuuuuuuut, how can I know here in F#?
  • oblio 8y ago
    That's PascalCase :)
• DanielBMarkham 8y ago
  Big F# fan here. After going through a dozen languages, and listening in/reading scads of debates on languages, I think the author here misses the point. Don't get me wrong: the points he makes are valid, and they make for a great language. Where I think the problem is when discussing languages is that languages are an ecosystem. They're groups of people, tools, message boards, IDEs, meetups, and so forth. F# is great on the things he mentions, but the real strength is the way F# can take a bunch of dotnet guys and slowly move them towards pure functional programming without there having to be a huge learning curve. Like C#? Like your objects and classes? Fine. Do that. Like you FooBar .NET libary? We've got that too. From your favorite IDE to the places you hang out, it's all the same. Just now with functional programming. F#, in my mind, is first and foremost a training language, and I don't mean that in a bad way. It exists in an ecosystem where it naturally helps a bunch of devs learn new stuff. (As opposed to most languages that do some core things, then keep adding crap on top year-after-year) Which brings me to my only criticism of the language: we're growing a community of wannabe Haskell/Erlang guys who are frustrated doing hook-the-wire-up C# in their day jobs. That can lead to language elitism and frustration on everybody's part. I'm not sure how to solve that. It's probably a good thing to have devs interested in upping their game. I think that if you want to move on to a more pristine language, you probably should do that. Understanding F# as an intermediate/training language for those interested in programming in general is a good way to keep needed context. If you expect it to be something that it's not, it's going to lead to frustration.
  • sparkie 8y ago
    Maybe Microsoft don't put the effort into the F# ecosystem because it's like the gateway drug to other platforms, which aren't Microsoft. I ended up moving to Haskell after learning F#. I've since moved back to using F# as my primary language, as I'm a recovered type addict, but it does sometimes feel restrictive in its capabilities.
    • DanielBMarkham 8y ago
      My mission is to help devs, so F# is the best spot for me right now. Having said that, I'm quite interested in the theory, so I'll probably be playing around with Category Theory and Haskell over the next few years. My biggest technical frustration with F# is just what you pointed out: they started down the OCAML route, then pulled back immediately after somebody figured out it would lead devs away from MS. Now all I hear about is how F# will integrate better into existing MS stuff and complaints about how the C# guys are copying F# stuff (and badly). None of that I'm interested in. None of that helps devs. And I believe your and my observation are related: the more MS tries to keep F# in the fold, the more tension it's going to build between devs who want to branch out and those who don't.
• Paraesthetic 8y ago
  I like f# because most of the notes in the scale are black keys, so don't have to move my hands very much to play the whole scale... Of course I know what you're talking about.
• Nelkins 8y ago
  My startup, https://masse.app https://masse.app has it's entire backend running on F# + .NET Core + AWS (Lambda and Fargate). Works great!