8 ms·

Yep. We’re using F# React on the front-end, Giraffe on the back-end. DustyTables for Data Access. It’s great - can recommend.

tartoran 6y ago
Is the market for F# picking up now in 2020? At my current job we're not using F# but I'd like to eventually move to a place that does. I am learning on my own at the moment and am wondering how open the potential hiring companies would be with novices in F# who otherwise have good experience in other languages.
- JaggerJo 6y ago
  From my experience it’s still not easy to find an F# Job. It’s a niche, but it exists and is growing. If you want one and are willing to take a few compromises you’ll find one.
  - nextos 6y ago
    I see a decent number of openings in the City of London quite regularly for finance and insurance positions. Also OCaml and sometimes Haskell. Even Rust has started popping up recently. I find this a bit intriguing because the library support for linear algebra, probability and statistics is pretty slim both in .NET and OCaml. The latter has OWL, which is very cool, but it's mostly a 1-person project. Do they develop all this support in house? For example, in insurance you may need things like Gumbel or Fréchet maximum likelihood estimators. That's not so easy to implement on your own, especially not without some linear algebra and optimization primitives available. On the other hand, I love these languages, and I wish there was a strongly typed contender to Python, R or Julia. Whenever I develop a data-oriented application, it feels like I need to prototype in one language and in order to scale or develop the whole infrastructure, I need to switch to another language. Julia has solved some of these problems, but I don't see a team implementing tons of business logic in a medium sized application using Julia.
    - pjmlp 6y ago
      Usually on the .NET ecosystem such stuff just gets bought. https://www.quantconnect.com/blog/top-numerical-libraries-for-c/ https://www.quantconnect.com/blog/top-numerical-libraries-fo...
    - KurtMueller 6y ago
      F# is your strongly typed contender to Python.
      - nextos 6y ago
        Sure, it's a lovely language. But I find the lack of some basic linear algebra, probability and statistics libraries frustrating. As pjmlp said in a parent thread, those are closed source and usually bought. I guess a lot of the .NET ecosystem is like that. It's a shame, because MS has some open-source jewels like Z3 or Infer.NET.
        KurtMueller 6y ago
        Hopefully F# gets big enough that people will write those libraries - I think people deserve a better Python.
        mdm12 6y ago
        MS is making a conscious effort to push into the ML space with libraries such as ML.NET https://dotnet.microsoft.com/apps/machinelearning-ai/ml-dotnet https://dotnet.microsoft.com/apps/machinelearning-ai/ml-dotn... . IMO, the combination of a strongly-typed language with features such as type inference, data providers and discriminated unions/pattern matching make F# a perfect fit for this space. It's just unfortunate that they had to go through the .NET Framework -> .NET Core journey before focusing on the ML ecosystem... But, the F# PM has recently given talks recognizing that they want to go into the space that Python is dominating, so it's a clear goal of the F# team (https://www.youtube.com/watch?v=_QnbV6CAWXc https://www.youtube.com/watch?v=_QnbV6CAWXc). I hope they're successful!
        6y ago
- Scuds 6y ago
  this is part of the greater lament of FP languages in industry. You might have to be satisfied with a kind of FP flavored C#, which in newer versions of the language isn't all that bad The thinking is that there's a million C# devs, a hundred thousand VB devs, and ten thousand F# devs. If you want to work in F# come up with your own OSS projects or champion it at work.
merb 6y ago
what about efcore does it work in f#? or is it bad practice to use mutable code/objects in f#? i do not want to go back to plain sql...
- JaggerJo 6y ago
  It’s a .Net library so it works (or should work) with F#. What sometimes leads to problems is F#’s record and discriminated union types. Not sure how they are handled by EF Core. Going back to plain SQL is just great. You know exactly what SQL gets executed. No Magic. With DustyTables it’s also not too much boilerplate.
  - banashark 6y ago
    Design-time support is still via a non-released package. So you'll write models/etc in C# and use EF from F#. There are ways to get design-time constructs working in F#, but it's not plug-and-play like from the C# side.
    - angio 6y ago
      You can write models in F# (with CLIMutables everywhere), but then you need to put models in a separate project, then add a C# project for migrations, and finally reference both projects from your ASP.NET app.
  - ben509 6y ago
    Apparently C# 7 can match discriminated unions quite well[1], with the caveats being: 1. you need a dummy type[2] for empty parts of the union. 2. it still can't enforce exhaustive matching. [1]: https://stu.dev/pattern-matching-fsharp-union-types-in-csharp/ https://stu.dev/pattern-matching-fsharp-union-types-in-cshar... [2]: Maybe () would work?

tartoran 6y ago

Is the market for F# picking up now in 2020? At my current job we're not using F# but I'd like to eventually move to a place that does. I am learning on my own at the moment and am wondering how open the potential hiring companies would be with novices in F# who otherwise have good experience in other languages.

JaggerJo 6y ago
From my experience it’s still not easy to find an F# Job. It’s a niche, but it exists and is growing. If you want one and are willing to take a few compromises you’ll find one.
- nextos 6y ago
  I see a decent number of openings in the City of London quite regularly for finance and insurance positions. Also OCaml and sometimes Haskell. Even Rust has started popping up recently. I find this a bit intriguing because the library support for linear algebra, probability and statistics is pretty slim both in .NET and OCaml. The latter has OWL, which is very cool, but it's mostly a 1-person project. Do they develop all this support in house? For example, in insurance you may need things like Gumbel or Fréchet maximum likelihood estimators. That's not so easy to implement on your own, especially not without some linear algebra and optimization primitives available. On the other hand, I love these languages, and I wish there was a strongly typed contender to Python, R or Julia. Whenever I develop a data-oriented application, it feels like I need to prototype in one language and in order to scale or develop the whole infrastructure, I need to switch to another language. Julia has solved some of these problems, but I don't see a team implementing tons of business logic in a medium sized application using Julia.
  - pjmlp 6y ago
    Usually on the .NET ecosystem such stuff just gets bought. https://www.quantconnect.com/blog/top-numerical-libraries-for-c/ https://www.quantconnect.com/blog/top-numerical-libraries-fo...
  - KurtMueller 6y ago
    F# is your strongly typed contender to Python.
    - nextos 6y ago
      Sure, it's a lovely language. But I find the lack of some basic linear algebra, probability and statistics libraries frustrating. As pjmlp said in a parent thread, those are closed source and usually bought. I guess a lot of the .NET ecosystem is like that. It's a shame, because MS has some open-source jewels like Z3 or Infer.NET.
      - KurtMueller 6y ago
        Hopefully F# gets big enough that people will write those libraries - I think people deserve a better Python.
      - mdm12 6y ago
        MS is making a conscious effort to push into the ML space with libraries such as ML.NET https://dotnet.microsoft.com/apps/machinelearning-ai/ml-dotnet https://dotnet.microsoft.com/apps/machinelearning-ai/ml-dotn... . IMO, the combination of a strongly-typed language with features such as type inference, data providers and discriminated unions/pattern matching make F# a perfect fit for this space. It's just unfortunate that they had to go through the .NET Framework -> .NET Core journey before focusing on the ML ecosystem... But, the F# PM has recently given talks recognizing that they want to go into the space that Python is dominating, so it's a clear goal of the F# team (https://www.youtube.com/watch?v=_QnbV6CAWXc https://www.youtube.com/watch?v=_QnbV6CAWXc). I hope they're successful!
        6y ago
Scuds 6y ago
this is part of the greater lament of FP languages in industry. You might have to be satisfied with a kind of FP flavored C#, which in newer versions of the language isn't all that bad The thinking is that there's a million C# devs, a hundred thousand VB devs, and ten thousand F# devs. If you want to work in F# come up with your own OSS projects or champion it at work.

merb 6y ago

what about efcore does it work in f#? or is it bad practice to use mutable code/objects in f#? i do not want to go back to plain sql...

JaggerJo 6y ago
It’s a .Net library so it works (or should work) with F#. What sometimes leads to problems is F#’s record and discriminated union types. Not sure how they are handled by EF Core. Going back to plain SQL is just great. You know exactly what SQL gets executed. No Magic. With DustyTables it’s also not too much boilerplate.
- banashark 6y ago
  Design-time support is still via a non-released package. So you'll write models/etc in C# and use EF from F#. There are ways to get design-time constructs working in F#, but it's not plug-and-play like from the C# side.
  - angio 6y ago
    You can write models in F# (with CLIMutables everywhere), but then you need to put models in a separate project, then add a C# project for migrations, and finally reference both projects from your ASP.NET app.
- ben509 6y ago
  Apparently C# 7 can match discriminated unions quite well[1], with the caveats being: 1. you need a dummy type[2] for empty parts of the union. 2. it still can't enforce exhaustive matching. [1]: https://stu.dev/pattern-matching-fsharp-union-types-in-csharp/ https://stu.dev/pattern-matching-fsharp-union-types-in-cshar... [2]: Maybe () would work?