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 robust job market, is worthwhile.

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.

F# will likely remain niche forever. It’s likely that Rust will not given its growing and accelerating adoption by Microsoft, Google and the Linux Kernel.

It just takes time to defeat the 40+ years of c and c++ dominance.

Personally I will always prefer C's simplicity to Rust's complexity. Could be just me.

I find Rust vastly simpler than C. If the code compiles, it's probably a valid expression of the business logic I encoded. I might've screwed up that logic, of course, and no language can prevent me from messing that up. I know! Many have tried, and I've defeated them with my ability to misrepresent my ideas! But at least with Rust, I'm reasonably confident that the code will actually do the thing I asked it to do. I'm never confident like that with C until I've run it a few hundred times without crashing.

(Yes, I'm familiar with the rich ecosystem around helping devs not write crummy C. I worked at Coverity at one point. If anything, that gave me enormous fear and respect of the hoops you have to jump through to be reasonably sure C code isn't completely broken.)

This seems...a very contrarian sentiment. Imho while C might lead you to create slightly fragile code once in a while, Rust is something like two orders of magnitude more complex.

No I know what he’s saying. C is not “slightly fragile code once in a while”. When you up the complexity of the code and the amount of code and the people working on the code the fragility becomes pervasive.

That's a huge part of it. If I stumble across random Rust code, I can assume that it's using typed data correctly, that it's not accessing freed memory, that it's not allocating but never freeing, that length checks are being enforced, etc. If they weren't, it wouldn't even compile (and the compiler would explain why).

Glancing at random C code tells you nothing about what happens with the data flowing into and out of it.

In my experience with it, rustc has been insistent on making me write code that's actually correct. I could translate that code back to C and have better C code than I would likely have written on my own. If there were something similar to `gcc -Werror -Weverything-rust-would-complain-about` — and if that thing were even possible — I very well might stick with C. Oh, and something as fast and ergonomic and informative as rust-analyzer would be hugely welcome.

Rust is like two orders of magnitude more simple (if you're not going to delve into its darker corners).

You have a single line serialization into/from absolutely anything. You have logging, tracing, cli libraries, error handling - most of those are one liners.

You have enums. Enums are business logic. Enums are often the way the world works.

You press enter and it builds, no pre setups, sub modules, cmake files and whatnot.

Rust like any language can be as simple or as complex as you want it to be. The complexity raises with the performance of the code you write but that’s also true of C. Unlike C that complexity is combined with guarantees that your code won’t crash in weird and unpredictable ways.

I will take C, C++ or Zig over Rust any day. For some people, like me, the Rust way of doing things isn't a good fit. It's not a model I enjoy working with.

I like F#, Haskell, Elixir but not Rust.

According to Stack Overflow developer survey [0] Rust is at 12.5%, roughly a half of C# or Java and a quarter of Python. Also more than twice Ruby. So definitely not niche.

[0] https://survey.stackoverflow.co/2024/technology#most-popular...

In my mind not niche means having jobs, and Rust has no jobs, not in any meaningful amount at least, and none at all in most countries. That puts it deep in the niche category for me.

It's popular in the "let's rewrite X in Rust" community which are very actively posting on HN, Reddit and wherever they can. That gives the impression it is not niche.

But the moment you search Rust on LinkedIn, you can see the truth.

To be clear, that developer survey asked:

    > Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?

It does not ask if you are gainfully employed and using this language for your job.

Also, in the same results, just above Rust, I see:

    > PowerShell 13.8%

<sarcasm> So, I guess that we can safely say that Microsoft PowerShell is still more popular than Rust. </sarcasm>

Powershell is probably more popular, it's used a lot for IT stuff so we never hear about it but it's there.

> According to Stack Overflow developer survey [0] Rust is at 12.5%, ... So definitely not niche.

The annual survey is very popular in the Rust community. Its results are often used for advocacy. Participation by Rust developers is very high. So what you have is a classic case of a selection bias.

MS is starting to use Rust pretty extensively internally. That's a lot of developers outside the "bubble."

Just look at the job market. There are far more jobs for Go programmers and Go isn't particularly huge.

Compared with C/C++, Java, C#, Javascript, Python, Typescript, PHP, all the rest can be considered niche.

I hear you on the opportunity side and I can't see that changing. The good news is in recent releases there's a lot less boilerplate - "dotnet new console -lang F#" results in two files, a short fsproj file and a single line of Hello World.

>" I was quite surprised by how many project files and boilerplate was generated by .NET, which put me off.

With which language are you comparing with?

Because there's afaik csproj and maybe .sln

and both of them are let's be frank - foundational for almost all projects that arent just hello world.

Otherwise you end up with some cmakes or something similar that want to achieve something similar

It is possible to start your project with the script possibilities offered by F# (as mentioned in the blog post). It is absolutely a viable approach and I even blogged about it a couple of months ago: https://www.asfaload.com/blog/fsharp-fsx-starting-point/

I learn them as a fun hobby, with no salary expectations. It keeps the dream alive, and I learn a lot from the Common Lisp community that I do use in my job.

> But then where are the jobs and which companies care if you write good code?

Oh man, that is poignant :( They always say they do in the job description, but it always a different story once you get there.

Opportunities do exist, even when they’re few and far between. I learned Rust in my spare time because I was really interested in it. Then we stumbled across something that would have really benefitted from a cross platform library and lo and behold, I got to use my Rust knowledge, even though the vast majority of my day job doesn’t use it.

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.

`var post = await _postService.getById(id);`

the F# equivalent is

`let! post = _postService.getById id`

You're missing the task {} block

This assumes the context is already a task computation expression, which is what you'd have in asynchronous code.

and the C# is missing the `async Task` boilerplate

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

If your code base is already using async await it's really not an issue.

The point is that it's not actually different from C#, especially once you consider that F# also has task{} blocks that give you a .NET Task directly.

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<IActionResult> and it's fine. Even program main methods can be async these days

The syntax is exactly the same. You have `var x = await` in C# and `let! x =` in F#

The controller handler is also the same. It will be marked with `async` keyword in C# and `task` CE in F#

It's absolutely not exactly the same; let! is only available within a computation block. If you want to return some value from the computation block and return to Functional land without having to pause the thread you need to use a continuation, which C# has built in syntactic sugar for in async/await and F# does not.

`await` can only be used in an `async` function. How is that so different from `let!` only being available in a computation expression?

because an async function doesn't require you to change syntaxes to get them to work

It's actually sort of the other way round. C# has hardcoded syntax for async/await. F#'s syntax for async/await is a fully-general user-accessible mechanism.

They're not so different in that regard. C# `await` can be adapted by making an awaitable and awaiter type[1], which isn't to dissimilar to how a computation expression in F# needs to implement methods `Bind`, `Return`, `Yield`, etc.

In both languages these patterns make up for the absence of typeclasses to express things like a functor, applicative, monad, comonad, etc.

[1]https://ecma-international.org/wp-content/uploads/ECMA-334_7...

A computation block is the equivatent of an async function;

F# is a big language, it is a ML multi paradigm language that interoperates with C# so there is a lot of necessary complexity and many ways to do the same thing. A strong benefit of this is the ability to create a working functional paradigm prototype that can iteratively be refined to a faster version of itself by hot spot optimizing the slower parts with equivalent highly mutable functions while staying within the same language. Similar how one would use python and C++ and over time replace the python code with C++ code where performance is important.

For the specific case of C# use of await it is unfortunate that C# didn't design this feature with F# interop in mind so it does require extra steps. F# did add the task builder to help with this so the 'await' is replaced with a 'let!' within a task builder block.

  let getById(id:int) : Task<string> = failwith "never"
  let doWork(post:string) : unit = failwith "never"
  let doThing() = task { 
    let! post = getById(42); 
    doWork(post); }

Alternatively the task can be converted to a normal F# async with the Async.AwaitTask function.

  let getPostById1(id:int) : Async<string> = async { return! getById(id) |> Async.AwaitTask }
  let getPostById2(id:int) : Async<string> = getById(id) |> Async.AwaitTask 
  let getPostById3 : int -> Async<string> = getById >> Async.AwaitTask

It is best to just use task CE full-time unless you need specific behavior of async CEs.

The author of the original comment, however, does not know this nor tried verifying whether F# actually works seamlessly with this nowadays (it does).

Writing asynchronous code in F# involves less syntax noise than in C#. None of that boilerplate is required, F# should not be written that way at all.

F# is a big language so I think it is to be expected that beginners will not know these things. I don't think the fix is to simplify F# we should just understand that F# is not for everyone and that is ok.

This is perfectly fine, but I think it's better to be unsure about specific language feature than confidently state something that is not correct (anymore).

Personally, I'm just annoyed by never-ending cycle of ".NET is bad because {reason x}", "When was this the case?", "10 years ago", "So?".

Like in the example above, chances are you just won't see new F# code do this.

It will just use task { ... } normally.

I understand that you CAN do this, I'm saying that it makes your code look like shit and takes away some of the elegance of ML

Are you saying you prefer Ocaml to F# or C# to F#? Your example was indeed inelegant but it is also poorly designed as you take 4 lines to reproduce a function that is already built in, people can poorly design code in any language.

I'm saying that I wish computation blocks looked better in F#. Instead of:

    let foo id = async {
      let! bar = getBar id
      return bar
    }

I would prefer

    let async foo id =
      let! bar = getBar id
      bar

or even something like

    let async foo id =
        getBar! id

So that computation blocks don't feel like you're switching to an entirely different language. Just wrap the ugliness in the same syntactic sugar that C# does. As it is, C# can achieve arrow syntax with async methods more elegantly than F# can:

    async Task<string> foo(int id) => await getBar(id);

This, to me, is also part of a larger problem of F# introducing unique keywords for specific language functions instead of reusing keywords, like

    member this.Foo = ...

and

    member val Foo = ...

Your criticism is rather incoherent and it is difficult for me to make sense of it.

You don't even have to use the computation block for that and can use the built in functions as I mentioned earlier and gave 3 examples of.

You're both complaining about extra keywords while trying to make the case of adding yet another one. Thus your complaint boils down to F# not picking the exact keywords that you like - that the language is not specialized to exactly how you want to use it. In language design there are always tradeoffs but I'm unable to see how your suggestions would improve the language in the general case or even in your specific case.

Computation expressions are a generalized concept which are there to add the exact kind of syntactic sugar that you're after. It's better than C# in that you can create your own as a first class concept in addition to using the built in ones. It's there for the exact purpose of creating mini-embedded DSLs, the very thing you're complaining about is the exact point of it.

F# is not for everyone, nor should it be.

> You're both complaining about extra keywords while trying to make the case of adding yet another one

I did no such thing. async is already a keyword in F#, I'm just saying they should drop the brackets and remove the required return statement.

> In language design there are always tradeoffs but I'm unable to see how your suggestions would improve the language in the general case or even in your specific case

It would make the language easier to read, for one, and would reduce the amount of specialized syntax needed for specific features. It would preserve the original ML-style syntax for an extremely common operation and not force users into wrapping anything upstream of an async call in a computation block, which is the ugliest syntax feature of F#

> Computation expressions are a generalized concept which are there to add the exact kind of syntactic sugar that you're after

I understand that, and my argument is they failed to do so. The syntax looks bad. They could keep it for all I care, but they should add even more sugar on top to make it not look so bad.

'async' is not a keyword in F#, it's a builder instance no different to the ones that you can create. It's just built in to the standard library.

The return statement is only required if you want to return something form the computation expression. In your example you use async { let! x = f(); return x}, which can be reduced to async { return! f()}, which can be reduced to f().

The rest is your opinion that I don't agree with.

The distinction in this case is utterly meaningless. This is about the ergonomics of the language. Which are lacking the minute to break out of pure functional land

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

There are multiple alternate asynchronous computation expression implementations which give different ergonomics and behavior (like https://github.com/TheAngryByrd/IcedTasks). There's an entire CE extension to specifically enable this kind of convenience and flexibility too: https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0...

None of this is possible in C#, at least without jumping through many hoops and ending up with extra boilerplate (and this is okay, C# has enough of its own complexity). As cjbgkagh noted, providing this type of control is the whole point and what makes F# so powerful.

I disagree with both of your statements

Please stop insisting on this. Task CE exists since F# 6.0 and handles awaiting the CoreLib Tasks and ValueTasks without any ceremony.

I find it personally better for CRUD applications than C# and I've written my share in both languages. Your syntax comparisons aren't exactly comparable in the sense that you haven't put in the wrapping/boilerplate around the C# code - you can't just await anywhere. You are also using an async which to run needs to know which context - this can be nice when you don't want to run the composed Task/Async on the current sync context. These days you stick to tasks if you want C# like behavior - and there's libraries to take away some SyncContext overload via custom F# CE's if you want.

The equivalent C# to your F# would be

  task { return! _postService.getById(id) }

Which is somewhat pointless anyway - just return the task from postService directly. There's also no need to run the async synchronously then - Async allow you to run the logic on task, thread, sync over and over - a very different model than tasks.

To make C# comparable to your F# code (tasks are not the same so not quite true) you would need to define a method around it, and find a way if you want to run the resulting Task synchronously to do that safely.

  public async Task<Post> GetPostById(id) => await blogPostService.getPostById(id);

  // This is not entirely eq - since tasks are hot
  this.GetPostById(42).Result

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 shebang and integrate these scripts into general scripting on Unix systems - it's very productive)

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

Yeah, overall I agree. And I honestly can't imagine anyone who works with any popular javascript framework would flinch at the addition of a .sln file or /Properties folder lol...

F# is quite usable with AI. All AI models are perfectly capable of generating idiomatic F# code. In fact, because it has a nice type system, if you ask the AI to model the problem well with types before implementing, hallucinated bugs are also easier caught.

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.

I find F# easy to use with AI, mainly because it's statically typed (which results in compiler errors when the LLM generates non-working code) and it's very expressive, which allow me to more easily comprehend what the LLM is trying to do.