8 ms·

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

by rockyj 2y ago

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 been programming for 20 years and know 4-5 languages, in India it was worse but in EU at-least I can make a sustainable living by writing Java / TypeScript. I cannot even find jobs with Kotlin + TypeScript which pay well, forget getting jobs in Elixir / Clojure / F# (there maybe a handful of opportunities if I will relocate for around 70K/year). That is why I have mostly given up on learning niche languages.

djha-skin 2y ago
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.
owenm 2y ago
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.
afavour 2y ago
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.
neonsunset 2y ago
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)
- twodave 2y ago
  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.
  - shortrounddev2 2y ago
    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
    - twodave 2y ago
      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...
8s2ngy 2y ago
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.
- jen20 2y ago
  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.
  - homebrewer 2y ago
    It is extremely niche outside of this bubble.
    - vlovich123 2y ago
      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.
      - johnisgood 2y ago
        Personally I will always prefer C's simplicity to Rust's complexity. Could be just me.
        kstrauser 2y ago
        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.)
sodapopcan 2y ago
> 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.
raphinou 2y ago
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/ https://www.asfaload.com/blog/fsharp-fsx-starting-point/
shortrounddev2 2y ago
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.
- smoothdeveloper 2y ago
  In C#, you can't use the await keyword in a non async method, so I find the argument short sighted.
  - shortrounddev2 2y ago
    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
    - malakai521 2y ago
      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#
tester756 2y ago
>" 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
Foofoobar12345 2y ago
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.
- elcritch 2y ago
  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.
KurtMueller 2y ago
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.

by rockyj 2y ago

djha-skin 2y ago

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.

owenm 2y ago

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.

afavour 2y ago

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.

neonsunset 2y ago

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)

twodave 2y ago
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.
- shortrounddev2 2y ago
  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
  - twodave 2y ago
    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...

8s2ngy 2y ago

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.

jen20 2y ago
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.
- homebrewer 2y ago
  It is extremely niche outside of this bubble.
  - vlovich123 2y ago
    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.
    - johnisgood 2y ago
      Personally I will always prefer C's simplicity to Rust's complexity. Could be just me.
      - kstrauser 2y ago
        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.)

sodapopcan 2y ago

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

raphinou 2y ago

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/ https://www.asfaload.com/blog/fsharp-fsx-starting-point/

shortrounddev2 2y ago

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.

smoothdeveloper 2y ago
In C#, you can't use the await keyword in a non async method, so I find the argument short sighted.
- shortrounddev2 2y ago
  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
  - malakai521 2y ago
    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#

tester756 2y ago

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

Foofoobar12345 2y ago

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.

elcritch 2y ago
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.

KurtMueller 2y ago

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.