4 ms·

I find ReasonML a VERY HARD sell when F# is sitting there waiting. If I could get people onboard with an ML, why wouldn't I use F# with it's massive backing eco

by Rapzid 9y ago

I find ReasonML a VERY HARD sell when F# is sitting there waiting. If I could get people onboard with an ML, why wouldn't I use F# with it's massive backing ecosystem and fantastic server side runtime(node has come a long way, but it's no CLR)?

chickenfries 9y ago
I tried getting into F# and for someone not running on Windows without knowledge of the CLR and .NET ecosystem its a hard sell.
- Rapzid 9y ago
  Was this recently? Things change really fast, within the last year or so we got ionide and core clr support. I've read of people preferring the experience of F# in VSCode these days. Just a few weeks ago I got an F# project with TensorFlowSharp up and running on OSX in VSCode with the ionide extension. It JustWorked™. In any case, I'd suggest you give it a crack again if you are interested. The experience has improved greatly and the tooling seems pretty great now on Linux/OSX. I've been following it for 3-4 years though, so I certainly understand how it would seem like a non-starter in the recent past.
- honewatson 9y ago
  I found getting F# dev environment set up on Ubuntu was super easy. That said that I found Merlin in Vim to be better than Jetbrains Rider. With Ocaml/Reason you should be able deploy via native binary. The build times and deployment story are going to be similar to Golang on the backend - if it works. With F# you have to deploy the CLR too.
aaron-lebo 9y ago
Many devs don't really care for the MS ecosystem. Whether this is old illogical bias or based in reality, IDK, but most of the major tech stacks that that work across ecosystems are further along on the JVM, so people go there.
swsieber 9y ago
It's nor that hard of a sell I think... does F# compile down to javascript?
- Rapzid 9y ago
  It does, there have been a couple options for a while but that had some catches but somewhat recently the Fable project came along and appears to be gaining tons of traction(for F# ecosystem) and killing it.
  - swsieber 9y ago
    Thank you. I think I've heard the name Fable in relation to F#, but until this thread today, I had no idea F# compiles down to JS.
- twoquestions 9y ago
  It does, though I've not used it myself so I can't comment on it personally. http://fable.io/ http://fable.io/
yawaramin 9y ago
F# is great for sure. You should definitely use whatever fits your needs best. I'm sure all of us will be happy just to see ML-style languages gaining greater adoption.
lilactown 9y ago
ReasonML is pushing hard on the "it's a better JavaScript" angle, which has a lot to do with it's popularity at the moment. In that regard I think it will be an easier sell than F# as ReasonML grows in maturity. Part of the problem with adopting an ML is that it feels like a huge departure from mainstream software development. From the syntax, to the build tools, to the concepts one uses on a day-to-day basis, it can be hard to slog through to get to the point of feeling productive. ReasonML is focusing on four things to help alleviate this friction from adoption: 1. Providing a more familiar syntax 2. Providing simple, high quality tooling built on top of a familiar ecosystem 3. Providing high quality documentation that focuses on onboarding developers who are coming from these other ecosystems 4. Providing a "killer-app" that can show the power of the language and draw peoples interest - in this case, Reason's integration with React through it's ReasonReact library and support for JSX. I think that these 4 things really make a difference when getting "people onboard with an ML," which is why the ReasonML community is something that I'm betting on for the mid- to long-term future.
lf-non 9y ago
I don't have enough experience with ReasonML but the primary reason I am hesitant to adopt F# in my production applications (which currently use typescript) is because of following reasons: 1. Record types are very inflexible. It is, for example, not trivial to do things like get a new record type by adding a few fields to an existing record types. 2. F# supports only explicit interfaces. Making records implement interfaces requires defining getters and setters for every property. And requires explicit casting when you are sending a record to a function that uses an interface. When you don't control the types (as is often when working with third party libraries) this becomes a major annoyance especially when you are habituated to typescript's structural typing. While I would like to see opaque types in typescript for some use cases, I really think having structural types, implicit interfaces and erased unions by default makes life a lot easier, especially when it comes to interop with wider js ecosystem. At the end of the day it quickly becomes very obvious that where as typescript was built from ground up to embrace javascript ecosystem, F# was not. As a result, when targeting javascript, a lot of design decisions which were based on limitations of CLR being a C# focused object oriented platform come across as bizarre and jarring. For instance why do we need both modules and namespaces ? Why are statically resolved type parameters only supported in inline functions ? I will admit that this can be very much a case of me being more familiar with typescript and not so much with F#. I do have a deep appreciation for both F# and Fable teams who have been incredibly helpful in stackoverflow and gitter. I strongly prefer F#'s syntax despite being a full time JS/TS developer and F#'s type inference is far better than what typescript offers today and at times it feels almost magical. I also think that Fable's approach for generating babel compliant AST and taking advantage of babel ecosystem is brilliant and something I'd like to see in more languages targeting javascript. Nevertheless, the learning is curve with the latter has been significantly steeper and at places the error messages are bizarrely confusing. Thus, I am not yet fully convinced that for a bulk of frontend applications (I mostly work on enterprise applications for data analysis and visualization) the benefits of that learning curve are substantially justified especially if you don't have any existing investment on the .Net side.
christophilus 9y ago
F# is an excellent language. I love tinkering with it. But its compiler is painfully slow compared to OCaml's, and that has a real impact on web development which is generally dependent on a fast tweak/save/refresh cycle. Also, as I'm no longer a Windows developer, I have to say that .NET Core + F# + Mac is still not a great environment.
ernst_klim 9y ago
>why wouldn't I use F# OCaml has functors, GADTs, better object system, nowadays it has an incredible developement pace and a huge amount of native libraries.

by Rapzid 9y ago

chickenfries 9y ago

I tried getting into F# and for someone not running on Windows without knowledge of the CLR and .NET ecosystem its a hard sell.

Rapzid 9y ago
Was this recently? Things change really fast, within the last year or so we got ionide and core clr support. I've read of people preferring the experience of F# in VSCode these days. Just a few weeks ago I got an F# project with TensorFlowSharp up and running on OSX in VSCode with the ionide extension. It JustWorked™. In any case, I'd suggest you give it a crack again if you are interested. The experience has improved greatly and the tooling seems pretty great now on Linux/OSX. I've been following it for 3-4 years though, so I certainly understand how it would seem like a non-starter in the recent past.
honewatson 9y ago
I found getting F# dev environment set up on Ubuntu was super easy. That said that I found Merlin in Vim to be better than Jetbrains Rider. With Ocaml/Reason you should be able deploy via native binary. The build times and deployment story are going to be similar to Golang on the backend - if it works. With F# you have to deploy the CLR too.

aaron-lebo 9y ago

Many devs don't really care for the MS ecosystem. Whether this is old illogical bias or based in reality, IDK, but most of the major tech stacks that that work across ecosystems are further along on the JVM, so people go there.

swsieber 9y ago

It's nor that hard of a sell I think... does F# compile down to javascript?

Rapzid 9y ago
It does, there have been a couple options for a while but that had some catches but somewhat recently the Fable project came along and appears to be gaining tons of traction(for F# ecosystem) and killing it.
- swsieber 9y ago
  Thank you. I think I've heard the name Fable in relation to F#, but until this thread today, I had no idea F# compiles down to JS.
twoquestions 9y ago
It does, though I've not used it myself so I can't comment on it personally. http://fable.io/ http://fable.io/

yawaramin 9y ago

F# is great for sure. You should definitely use whatever fits your needs best. I'm sure all of us will be happy just to see ML-style languages gaining greater adoption.

lilactown 9y ago

ReasonML is pushing hard on the "it's a better JavaScript" angle, which has a lot to do with it's popularity at the moment. In that regard I think it will be an easier sell than F# as ReasonML grows in maturity. Part of the problem with adopting an ML is that it feels like a huge departure from mainstream software development. From the syntax, to the build tools, to the concepts one uses on a day-to-day basis, it can be hard to slog through to get to the point of feeling productive. ReasonML is focusing on four things to help alleviate this friction from adoption: 1. Providing a more familiar syntax 2. Providing simple, high quality tooling built on top of a familiar ecosystem 3. Providing high quality documentation that focuses on onboarding developers who are coming from these other ecosystems 4. Providing a "killer-app" that can show the power of the language and draw peoples interest - in this case, Reason's integration with React through it's ReasonReact library and support for JSX. I think that these 4 things really make a difference when getting "people onboard with an ML," which is why the ReasonML community is something that I'm betting on for the mid- to long-term future.

lf-non 9y ago

I don't have enough experience with ReasonML but the primary reason I am hesitant to adopt F# in my production applications (which currently use typescript) is because of following reasons: 1. Record types are very inflexible. It is, for example, not trivial to do things like get a new record type by adding a few fields to an existing record types. 2. F# supports only explicit interfaces. Making records implement interfaces requires defining getters and setters for every property. And requires explicit casting when you are sending a record to a function that uses an interface. When you don't control the types (as is often when working with third party libraries) this becomes a major annoyance especially when you are habituated to typescript's structural typing. While I would like to see opaque types in typescript for some use cases, I really think having structural types, implicit interfaces and erased unions by default makes life a lot easier, especially when it comes to interop with wider js ecosystem. At the end of the day it quickly becomes very obvious that where as typescript was built from ground up to embrace javascript ecosystem, F# was not. As a result, when targeting javascript, a lot of design decisions which were based on limitations of CLR being a C# focused object oriented platform come across as bizarre and jarring. For instance why do we need both modules and namespaces ? Why are statically resolved type parameters only supported in inline functions ? I will admit that this can be very much a case of me being more familiar with typescript and not so much with F#. I do have a deep appreciation for both F# and Fable teams who have been incredibly helpful in stackoverflow and gitter. I strongly prefer F#'s syntax despite being a full time JS/TS developer and F#'s type inference is far better than what typescript offers today and at times it feels almost magical. I also think that Fable's approach for generating babel compliant AST and taking advantage of babel ecosystem is brilliant and something I'd like to see in more languages targeting javascript. Nevertheless, the learning is curve with the latter has been significantly steeper and at places the error messages are bizarrely confusing. Thus, I am not yet fully convinced that for a bulk of frontend applications (I mostly work on enterprise applications for data analysis and visualization) the benefits of that learning curve are substantially justified especially if you don't have any existing investment on the .Net side.

christophilus 9y ago

F# is an excellent language. I love tinkering with it. But its compiler is painfully slow compared to OCaml's, and that has a real impact on web development which is generally dependent on a fast tweak/save/refresh cycle. Also, as I'm no longer a Windows developer, I have to say that .NET Core + F# + Mac is still not a great environment.

ernst_klim 9y ago

>why wouldn't I use F# OCaml has functors, GADTs, better object system, nowadays it has an incredible developement pace and a huge amount of native libraries.