Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why F#?

batsov.com

Post reply on HN
Print view View original

101–110 of 424 posts

Re: Why F#?

#101

Post by shortrounddev2 »

rockyj wrote: post #29

I did try F#, but I was new to .NET ecosystem. For 1 "hello world" I was quite surprised by how many project files and boilerplate was generated by .NET, which put me off. I am all for FP, immutable, and modern languages. But then where are the jobs and which companies care if you write good code? Now everyone wants languages which are easy to use with AI, while reducing workforce and "increased productivity". I have…

I like F#'s syntax when all you're doing is pure logic. But when you have to interface with any IO like a database or REST call or something, you have to abandon the elegance of ML syntax and use these ugly computation blocks. In C# you can do something like this:

    var post = await _postService.getById(id);
in F# the equivalent is basically

    let getPostById id = async {
        let! post = blogPostService.getPostById id
        return post
    }

    let post = getPostById 42 |> Async.RunSynchronously
But not really, because RunSynchronously isn't the same thing as `await`. Realistically if you wanted to handle the result of an async computation you would need to create continuations. F# isn't the only ML-family language to suffer from this; Ocaml does as well. It always seemed to me like the pattern with any asynchronous operations in F# is to either:

1. Do all logic in ML-syntax, then pass data into a computation block and handle I/O operations as the last part of your function, then return unit OR

2. Return a C#-style Task and handle all I/O in C#

Either way, ML-style languages don't seem like they're designed for the kind of commercial CRUD-style applications that 90% of us find ourselves paid to do.

Re: Why F#?

#102

Post by johnnyjeans »

pdimitar wrote: post #36

People will do anything except actually try Elixir. :D ...I mean: pipes, immutability, transparent mega-parallelism... helloooo? I tried F# some years ago (after I was fired from a shop that decided they will go all-in on Java and F# and dropping everything else overnight) and I was not impressed. I mean the language is really nice but the C# baggage and runtime was just a bit much. And I was not left convinced that…

> Elixir

For me, it's Erlang. I just really like its horn clause syntax, it's so clean and readable. I know a common complaint is lack of piping (and even though you can implement it trivially, the order of arguments for some functions makes it of dubious use) but it's a small price to pay.

> I mean the language is really nice but the C# baggage and runtime was just a bit much

This was my experience with F#. Frankly, I've never been happy with my experience with CLI on Linux, and the toolchain inherits a lot of baggage from its C# heritage. Microsoft's toolchains have a very distinct workflow to them. F# has some interesting aspects to it like active patterns (something I wish was more common in the ML-family), but tbh I'm more than happy with ocaml.

Re: Why F#?

#104

Post by kkukshtel »

pjc50 wrote: post #22
eknkc wrote: post #3

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

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 s…

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#"));

Re: Why F#?

#105

Post by shortrounddev2 »

twodave wrote: post #60
neonsunset wrote: post #55

Earlier quoted context omitted.

As sibling comment pointed out, it's just .fsproj manifest and Program.fs file. What boilerplate do you speak of? It's on the opposite end boilerplate-wise to projects made in e.g. Java or TypeScript. For F#, projects are needed to make full applications or libraries. Otherwise, you can simply write F# scripts with .fsx and execute them via 'dotnet fsi {SomeScript.fsx}'. (obviously you can also specify dotnet fsi as…

I suspect they were either referring to pre-.NET Core days before the new project formats came out or they're creating projects in Visual Studio and checking all the optional boxes. There indeed did used to be a lot more required boilerplate to get some code running. Now you can run a .NET project quite nicely in VS Code with 2 total files.

Well also if you're using Visual Studio it will generate solution files as well, not just fsproj. I grew up doing C/C++ so boilerplate project/IDE/make files as well as build objects are something I expect to see. I think people who work in primarily JIT'd/interpreted languages are used to just having a directory tree full of source files and having some CLI tool manage everything for them. Maybe a dependency list file as well, but that's about it. Python is like this, and javascript CAN be like this

Re: Why F#?

#106

Post by homebrewer »

jen20 wrote: post #91
8s2ngy wrote: post #83

Earlier quoted context omitted.

I understand your perspective. I like to view niche languages as a medium for learning. For instance, I enjoy using Rust in my personal projects—even if many of these projects may never be released—because the lessons on immutability, functional programming constructs, and trait-oriented programming significantly enhance my day-to-day work. Therefore, I believe that learning niche languages, even in the absence of a…

I'm not sure I'd call Rust a "niche language" any more (perhaps in ~2018) - it's in common use across many big technology companies.

It is extremely niche outside of this bubble.

Re: Why F#?

#107

Post by raphinou »

F# was for me the best functional language when I looked at rewriting a Ruby on Rails app. I wanted to go with a functional language, as it seems to better fit my thinking and reasoning, and I looked at Haskell, Ocaml, Scala, F#.

Being a stranger to Microsoft technologies, F# was the least likely to be chosen, but easily became the first choice. Haskell's purity made it hard to adopt (for me), Ocaml's ecosystem is subpar (there wasn't even a clear choice for a library to interact with postgresql, I couldn't install the latest version due to its reliance on an obscure tool whose name I forgot and didn't get help on the forum), and Scala is seems complex....

F# was surprisingly easy to get started with. The community is mis-managed by a corporate-minded approach (requiring people to become member of the F# software foundation to get access to the official slack!), but its members are friendly, smart and ready to help. The ecosystem is great with access to all the dotnet libraries (some complain there's a mismatch as most of those are developed for use with C#, but I rarely got in trouble for using them).

There are also great libs and frameworks available. Like https://github.com/SchlenkR/FsHttp to easily interact with http servers, to the point that I find it easier to use than a dedicated library. Or https://github.com/CaptnCodr/Fli , to run commands. And last but not least, https://www.websharper.com/ is the best web framework I have encountered across all ecosystems. Their reactive approach to web ui really allows me to develop complex interfaces in a maintainable way.

This became a longer message than I thought, probably due to my enthousiasm for the language. For complete transparency, the situation is not perfect, and in my experience the tooling is not the best.

If you want more info, I blogged about it a couple of months ago: https://www.asfaload.com/blog/consider-fsharp/

Re: Why F#?

#108

Post by smoothdeveloper »

shortrounddev2 wrote: post #101
rockyj wrote: post #29

I did try F#, but I was new to .NET ecosystem. For 1 "hello world" I was quite surprised by how many project files and boilerplate was generated by .NET, which put me off. I am all for FP, immutable, and modern languages. But then where are the jobs and which companies care if you write good code? Now everyone wants languages which are easy to use with AI, while reducing workforce and "increased productivity". I have…

I like F#'s syntax when all you're doing is pure logic. But when you have to interface with any IO like a database or REST call or something, you have to abandon the elegance of ML syntax and use these ugly computation blocks. In C# you can do something like this: var post = await _postService.getById(id); in F# the equivalent is basically let getPostById id = async { let! post = blogPostService.getPostById id return…

In C#, you can't use the await keyword in a non async method, so I find the argument short sighted.

Re: Why F#?

#109

Post by munchler »

speed_spread wrote: post #75
munchler wrote: post #20

Earlier quoted context omitted.

F# is up to version 9 now, and has only improved over time, IMHO. Type providers are a very small part of the story and can be avoided entirely if you want.

Why would type providers be avoided? It seemed to me like a nice metaprogramming feature, akin to what Zig does with comptime types (except runtime?)

Type providers are very powerful but involve running arbitrary external software at compile-time (e.g. a SQL Server or Postgres database). This can be difficult to set up and configure reliably in a multi-person project.

Re: Why F#?

#110

Post by shortrounddev2 »

smoothdeveloper wrote: post #108
shortrounddev2 wrote: post #101

Earlier quoted context omitted.

I like F#'s syntax when all you're doing is pure logic. But when you have to interface with any IO like a database or REST call or something, you have to abandon the elegance of ML syntax and use these ugly computation blocks. In C# you can do something like this: var post = await _postService.getById(id); in F# the equivalent is basically let getPostById id = async { let! post = blogPostService.getPostById id return…

In C#, you can't use the await keyword in a non async method, so I find the argument short sighted.

I don't see how that changes things. You'd have to async it all the way to the top but the syntax is still cleaner than F#. If you're using an Asp.Net controller you just declare the handler as async Task and it's fine. Even program main methods can be async these days
Post reply on HN