← Back to context

Comment by eknkc

3 days ago

As far as I can tell F# is one of those things where every single user is extremely happy. This happens rarely and I really am curious about the thing but never had time to get into it. I'm also pretty well versed in the .net ecosystem so it's probably gonna be easy.

Any tips? What kind of workflows might benefit the most if I were to incorporate it (to learn..)?

45 comments

eknkc

Reply
pjc50  3 days ago

The funny thing is that you can write very similar code in C#, so maybe you don't need to switch which language you're using as a CLR frontend.

    using System.Linq;
    using System;

    var names = new string[] {"Peter", "Julia", "Xi" };
    names.Select(name => $"Hello, {name}").ToList().ForEach(greeting =>   Console.WriteLine($"{greeting}! Enjoy your C#"));

LINQ is such a good library that I miss it in other languages. The Java stream equivalent just doesn't feel as fluent.

  • psychoslave  2 days ago

    As far as fluency goes, that’s not very impressive.

        %w{Peter Julia Xi}.map{"Hello, #{it}"}.each{puts "#{it}! Enjoy your Ruby"}

    That’s of course trivial examples. And while Ruby now have RBS and Sorbet, it’s yet another tradeoff compared to a syntax that has upfront static analysis as first class citizen in mind.

    That is, each language will have its strong and weak points, but so far on "fluency" I’m not aware of anything that really beat Ruby far beyond as Ruby does compared to other mainstream programming languages.

    • int_19h  2 days ago

      Ruby is dynamically typed, which makes "fluent" API design that much easier at the cost of maintainability elsewhere. If you want to compare apples to apples, you need to compare F# to other statically typed languages.

      4 replies →

  • issafram  2 days ago

    You're being way too nice. Java stream is nowhere near as easy to use as LINQ. I'd say that LINQ is easily one of the top 10 coding features that Microsoft has ever created.

    • DeathArrow  2 days ago

      I think LINQ is inspired by SQL. You can do whatever you can with SQL, it's just that the data source might differ IEnumerable with some in memory data, IQueryable with some DB. Or you can use async enumerable and your data source can be whatever web API or protocol.

  • bob1029  3 days ago

    You can write a vast majority of your C# codebase in a functional style if you prefer to.

    All the good stuff has been pirated from F# land by now: First-class functions, pattern matching, expression-bodied members, async functional composition, records, immutable collections, optional types, etc.

    • int_19h  2 days ago

      I wouldn't say "all" - C# doesn't have discriminated unions yet, which is kind of a big one, especially when you're also looking at pattern matching. A

      6 replies →

    • guhidalg  3 days ago

      I don't know if there's a name for it but essentially F# is where the language designers can push the boundaries and try extremely new things that 99% of users will not want or need, but eventually some of them are such good ideas that they feed back into C#.

      Maybe that's just research, and I'm glad that Microsoft hasn't killed F# (I do work there, but I don't write F# at work.)

      1 reply →

  • klysm  3 days ago

    This isn’t a great example of what linq is good at. There’s no reason to do ToList there, and the ForEach isn’t particularly idiomatic

    • pjc50  3 days ago

      Yeah, I hit the problem that there isn't a null-type equivalent of Select() for Action<T>, nor is there a IEnumerable.ForEach (controversial), so that's a bit of a hack. But I wanted to make it as close to the original example as possible.

    • bob1029  2 days ago

      > There’s no reason to do ToList there

      In this case, I would move it to the very end if we are concerned about the underlying data shifting when the collection is actually enumerated.

      Forgetting to materialize LINQ results can cause a lot of trouble, oftentimes in ways that happily evade detection while a debugger is attached.

      3 replies →

  • kkukshtel  3 days ago

    Modern C# collection expressions make the definition of names closer to F#:

      string[] names = ["Peter", "Julia", "Xi"];

    I know working on "natural type" of collections is something the C# team is working on, so it feels possible in the future that you'll be able to do this:

      var names = ["Peter", "Julia", "Xi"];

    Which I think would then allow:

      ["Peter", "Julia", "Xi"].Select(name => $"Hello, {name}").ToList().ForEach(greeting =>   Console.WriteLine($"{greeting}! Enjoy your C#"));

    • pjc50  3 days ago

      I did try that initially and got

          <source>(5,1): error CS9176: There is no target type for the collection expression.

      .. which I took to mean that, because .Select is an extension method on IEnumerable, the engine was unable to infer whether the collection should be a list, array, or some other type of collection.

      It seems reasonable to have it default to Array if it's ambiguous, maybe there's a downside I'm not aware of.

      1 reply →

  • voidUpdate  3 days ago

    I love LINQ, maybe a little too much. I can end up writing monster oneliners to manipulate data in just the right way. I love list comprehensions in python too, since they can work in similar ways

  • gibibit  2 days ago

    For reference, Rust provides a similar experience

        let names = ["Peter", "Julia", "Xi"];
    names
        .map(|name| format!("Hello, {name}"))
        .iter()
        .for_each(|greeting| println!("{greeting}! Enjoy your Rust"));

munchler  3 days ago

F# shines on the back end, where its functional-first style is very adept at crunching data. Think about data flows in your system: Any place where you use LINQ in C# today to select/filter/transform data might be even better in F#. Parsing is also a great F# use case (e.g. parser combinators), although a fairly narrow niche.

JohnyTex  2 days ago

Personally I think F# is excellent for writing ye olde CRUD applications, especially as the business logic becomes more complex. F# is really good at domain modeling, as creating types comes with minimal overhead. C# has improved a lot in this area (eg record types) but it’s still got a long way to go.

I wrote a tutorial about how to get up and running with web dev in F# that might be of interest: https://functionalsoftware.se/posts/building-a-rest-api-in-g...

  • DeathArrow  2 days ago

    Thank you, for someone interested in using F#, that is great.

    I see you use Giraffe but I wonder how hard would it be to use Web API or to mix F# projects with C# projects in the same solution.

piokoch  3 days ago

"As far as I can tell F# is one of those things where every single user is extremely happy" Isn't it because language has rather small community of passionate people, who are devoted to their language of choice?

F# popularity is somewhere between CHILL, Clipper and Raku langs, that are probably as obscure as F# for typical software dev.

  • psychoslave  2 days ago

    I know Raku from Perl fame, and F# because it’s Microsoft, but CHILL and Clipper are totally new to me, so in my own humble experience these two latter look far more obscure. :D

  • int_19h  2 days ago

    I'm pretty sure that there's more production code written in F# than in all those other three combined.