Why F#?

For me, Haskell's image and ideal of purity are what made it difficult when I started out. I tried learning the language by reimplementing a program I'd previously done imperatively, that was (in hindsight) obviously hard to do in a plain pure way, ended up learning about zippers and knot-tying to do something in a less efficient and more confusing way than just using something like STArray because I had this idea from reading about Haskell that this was not only a good way to do things, but would be magically fast because GHC. (It was not.)

These days I'd just do such a task more-or-less imperatively in Haskell, and I would be well guided by the types in doing so. But I also feel like you have to make a few such mistakes if you want to get a good intuition and taste for when it's good do things purely and when imperatively.

I honestly don't remember as it was +/-6 years ago. I had started learning Haskell and got to that conclusion. Maybe that I am now more versed in FP I would arrive at another conclusion? I don't know.

Another thing that was hard to grasp for me were the special operators like =<<, ., $, etc. I was using Xmonad, but those operators create a barrier to understanding exactly what happened in the file.

In the end, F# was in my (personal) experience much more approachable, and it let me learn the functional concepts along the way.

What about libraries though? They might force you to use certain monads rather than IO?

Haskell taught me the important differences between IO and parity and forever influenced the way I program.

Even so the complexity here and the sheer number of mind bending concepts makes me not want to use it.

You gotta remember people are often picking languages based on what they can easily find out about it and extrapolating/guessing about what problems they'll run into with their expected use.

A few years ago on here I had an interesting conversation with someone who wasn't going to use rescript for something because they didn't like how it handled object types. I can't remember ever using an object type in rescript; we all just convert js objects to record type in the extern binding. But that's not information easily available to someone who has never used the language.

Same thing here I think. If you don't already have familiarity with this paradigm, it's hard to imagine what using an IO monad for side effects is like. It's not easy to tell how hard it'll be to learn it, how much it may affect the rest of your code, etc. It's easy to imagine someone (shit even me a few years ago) going "eh I'll take the language with the big easy escape hatches just in case."

I should have mentioned in the message, but I was looking for a strongly typed language. I was an avid-user of dynamically-typed languages, but that particular Ruby on Rails app became unmaintainable, and part of the culprit was due to the dynamic typing. I hoped that using a statically typed language would make it easier to maintain a complex app in the long term. And I must say that it totally materialised, to the point that I don't want to develop in dynamically typed languages anymore.

Here's an example: as I said in my original message, I was a complete stranger to the dotnet ecosystem, and I learned the F# language at the same time. And I decided to develop the app as a library project to be used by the web app. I completely missed the prevalence of the async approach in the dotnet, and all my code was synchronous. One day, about half-way in the project, I realised I needed to switch to async code. Had this happened in a dynamically typed project, it would have been hell for me. Maybe it's me that can't grasp a project well enough, but I need the type-guardrails to find my way in large refactorings. And with the strong types, large refactorings can be done confidently. They don't replace tests, but make the refactoring process much more smooth.

The app is open source and its code is at: https://gitlab.com/myowndb/myowndb It doesn't have a lot of users, not the least due to lack of marketing and polishing the user experience. But I am satisfied of what I learned developing it!

I'm sure it can be the better choice, but for me it was not. It seems there was some incompatibility between me and Scala. I find it such a complex language and I never managed to wrap my head around it. As I said F# was my last choice at the start of my evaluation, and Scala was high on the list due to the Java ecosystem. But in the end it didn't work out for me.

F# on the JVM would be great though!

I think Clojure is the better option if you want to do FP using the JVM ecosystem. The problem (for me, anyway) I've run into with Scala is that it supports both functional programming and object-oriented programming. Every code base I've worked on in Scala has ended up being a hodgepodge of both, which I find annoying.

However, the best functional programming language is, of course, Elixir. :D

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.

Same with Nim. It works surprisingly well with AI tools. I think both have more straightforward syntax so it’s easy to generate. I’m curious how more complex languages do like C++ / Rust.

Last time I tried C++ with Copilot it was terrible.

Firstly a strong desire to self-host: write the build system in the language itself.

Secondly, often very differently shaped requirements. The dotnet SDK tries to keep its build specification (.csproj) files editable by Visual Studio, which is why most of the stuff in them is just XML properties.

You probably could build C#/F# with Bazel but that's not what Microsoft chose, and you kind of need to stay aligned with them and the large amount of MSBuild files in the SDK.

Because there are differences that go beyond just the language syntax. The build processes are very different for C++ vs. C#, vs. F#, etc.

C++: invoke compiler for all compilation units, invoke linker to combine object files into executable

C#: invoke compiler once with all source files listed

F#: same as C# AFAIK, except file order matters!

Not Dune exactly, but having to run 'eval $(opam env)' in the terminal every time you open an OCaml project rather than the default being npm-like, where you can just open the directory and use the package manager command without having to think about it.

I personally find the way these features were shoehorned into the C# syntax an eyesore, I have quite some C# experience, and I think the language is getting more and more convoluted and noisy, with ever less coherent syntax.

On the other hand many of these features are really convenient and handy in F#. Adding many of the oh-my-gamedev-such-speed features from C# to F# also makes its syntax less pleasant to work with.

Personally I also think that the C# async model is terrible, and was a grave mistake. The F# async model with computation expressions, and explicit control over their execution context was a better approach, and I'm really sorry the hack-something-together to unblock the event loop WPF/frontend-dev usecase won over the more disciplined backend-focused approach.

Perl is mature, too.

Maven is awful. SBT is awful. Gradle is awful. I've used them all professionally, and the best I can say about them is that you can get the job done with them.

Newer languages and newer build systems are much better experiences, because of decades more hindsight and because language designers think about tooling from the start. Java was designed with the assumption that all software projects were built with Make, and with no ambition to improve on that. There was no Java-specific build tool until Ant was released as a standalone tool circa 2000.

> What is wrong with CMake for C++?

Granted, most of what's wrong with CMake is the problem it solves. Probably there's no solution that wouldn't be at least close to as awful as CMake. But it is objectively a hideous experience compared to any language created in the last 15 years.

How long are Scala compilation times for a Hello World CLI, a Hello World basic webapp and for a reasonably sized production size code base?

My guess is that it's much longer than for the equivalent Java apps.

> What is wrong with CMake for C++?

It doesn't manage dependencies.

Lets settle on a finally good enough. I can give honest compliments on learning from the past problems and from the better examples in the indsutry.

You may not remember the early .net core times with yeoman and other then-current javascript ecosystem originated things applied in really cumbersome, half-assed ways, with lacking docs and always being in flux for years. The project.json era was terrible.

Also msbuild was way worse 10-15 years ago...

Mono with automake was special circle of hell IMO, I have very small exposure but it was really unproductive and painful.

    > Anyone who is still uncomfortable with F# after 1 month - well that's a strong signal that the dev isn't a fast learner.

For myself, I feel that I have "full" command of C# as a programming language, but also how to structure projects, how to isolate modules, how to decouple code, how to set up a build system from scratch for C#, how do deploy and scale applications built with C#, what the strengths and weaknesses are, etc. My definition of "comfort" would entail a broader understanding of not just the syntax, but of the runtime ecosystem in which that code operates.

The problem is, many recruiters don't work with this mindset. If they're hiring a Java developer, and they get a CV from someone who has 1 year of Java experience and 5 years of C# experience, they see 1 year of experience, and immediately put it on the "unqualified" pile.

For me, my discomfort with F# is due to not knowing if what I’m doing is the correct/idiomatic way of doing things. With C# I have learned all the ways I should not do things…so it’s easier/faster to just use C#.

Hi Isaac ;) Of course you can train people. But in my experience they take a lot longer to learn than you suggest.

As someone who quite likes f#: It seems like a chicken and egg problem, not many companies doing f# because not many devs know it and not many devs learning it because not many companies are doing it.

I certainly wish I were doing f# professionally, but I only ever found 1 job listing for it, and that was in vienna while I am located like 200km away from it :(

Speaking of elm: I really like elmish for the frontend, when I need to make a dynamic page in the first place. Maybe that could be to your interest? (It transpiles to react under the hood via fable, which you can webpack into a drop in bundle. But I digress)

Jobs are kind of rare. I have to learn F# hoping maybe I will find a job in one or two years. And if I find it, they might want someone with F# work experience.

It's statically typed and inferred.

With regards to your example, the print/printfn (equivalent of Write/WriteLine) functions are a bit funny in F#. They don't actually take bound string values directly. You need to specify the type (which could be a string, a number, obj, etc)

https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

F# is a statically typed language with gradual typing and full type inference.

Given

  let hello value =
      printfn "%A" value
    
  hello "world"
  hello 2

It's never been a better time to try Scala if you're interested in the FP side. It's still very much "not opinionated" but the community and ecosystem have benefited from a certain convergence and given up on the "better Java" front which is served by Kotlin more adequately. Of course you can still consume any Java library when needed but it's best to avoid it if possible. Today you can pick between several ecosystems:

- Typelevel libraries: modern and more welcoming take on ScalaZ ideas, rich and mature, extensible libraries that are written in "tagless final" style.

- ZIO: concrete "super monad" with 3 type parameters, shuns the Haskell baggage and category theory lingo but pretty much the same concepts, compile-time autowiring dependency injection, a bit less mature.

- Kyo: new effects system on the block, pushing Scala 3's type system to the limit to stack effects using an "auto-flattening" monad (sorry if I butchered the description).

- Li Haoyi's own ecosystem that sticks to the standard library and JVM built-in mechanisms whenever possible, focused on Python style expressiveness, only more functional and with stronger types.

- I'd skip Akka/Pekko libraries but it's still an interesting piece of software if you need actor based, stateful cluster sharding.

Martin Odersky and the LAMP are focused on "capabilities" and we should eventually see something like direct-style algebraic effects, or like Kyo but without monads.

Also we have much better build systems than before (Scala-CLI, Mill, sbt has improved a lot too), binary backwards compatibility since Scala 3, and a very capable LSP backend if you don't like IntelliJ IDEA.

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.

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

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

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.

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.

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

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

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

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

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

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

That could be shortened to

names.ForEach(name=>Console.WriteLine($"Hello, {name}! Enjoy your C#"));

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

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.

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

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

If we consider number of jobs, it's probably on par with Rust.

I'm aware, but you need to understand the .NET ecosystem to get anything practical done (at least when I was using it in 2017). All the books written on it (I own 3) are also the same way and assume you're a skilled C# dev.

F# depends heavily on existing C# libraries and those are all OOP.

Except that there's a huge number of libraries written in C# that are available to F# (since both run on the CLR), and you have to do OOP in F# to use them.

FP and classes are not mutually exclusive

Why not? It does it very well, better than C# in my opinion. At least that was the case ten years ago when I last used C# and played with F#.

oop is just another tool in your toolbox; if f# provides it and it's the best way to express a given algorithm you should definitely go ahead and use it. oop got a bad name due to people trying to shoehorn it into places it was not the best way to express something, and it seems like you're making the inverse mistake here.