9 ms·

Exploring ReasonML and functional programming

211 points by jasim 9y ago

frou_dh 9y ago
Rauschmayer is a good writer - He's been running a great JS blog for many years (http://2ality.com/ http://2ality.com/)
nafizh 9y ago
Why should someone unfamiliar with functional style programming be learning ReasonML rather than say, something like, haskell? Looking for concrete, technical answers.
- duckfruit 9y ago
  You wouldn't choose it over haskell every time, but for the limited subset of times where you need to write frontend code ReasonML has distinct advantages. ReasonML is basically OCaml that compiles to JS, designed to make interoperation with Javasascript easy. There are compile to JS projects for Haskell too, but the ease of interoperability with popular JS libraries like react and support from facebook's open source tooling chain make it a much better choice for most frontend projects IMHO -- unless you're already a haskell expert in which case go with what you already know!
  - aassddffasdf 9y ago
    That's not correct. What you've described is Bucklescript (which has OCaml syntax). ReasonML is an attempt to "improve" the OCaml syntax to something more familiar to folks coming from C-style family of lanauges. ReasonML can be used with both the Bucklescript compiler (which compiles to JS) -or- the standard OCaml one (which compiles to native).
    - yawaramin 9y ago
      While that is technically true, most people nowadays use them interchangeably especially because Reason is focusing so much on its web story, so I wouldn't expect people to make this distinction very often.
      - aassddffasdf 9y ago
        The frequency which this distinction is made in the general populace matters not in the least to me. What matters to me is reality/truth. Either people get on board with it or they butcher it. I have a bit more faith in them than you do it seems. Only time will tell which of us is correct.
- Barrin92 9y ago
  when I started out to learn functional style programming I wanted to build a real project. I tried several languages out and I settled with F# because I just didn't like the enforced purity of Haskell and laziness as a default. It just cost me so much time to constantly think about IO that I was barely figuring out what I wanted to write. It seemed impractical to me and now with some more experience I still think it is. Ocaml type languages strike a better balance in my opinion if you're interacting with the world.
  - willtim 9y ago
    I can assure you that, with practice, Haskell can be a very practical language. Having IO in the types lets one reason about where the effects are happening, which is especially important when trying to solve real world problems with functional techniques (i.e. transforming unreliable streams of data).
- jasim 9y ago
  You cannot go wrong by picking any statically typed functional language - Reason, Elm, F#, PureScript, Haskell, or even Idris. All of these languages share a similar style of programming that revolve around data that is described through a rich type system and program execution modelled as a series of pure functions that transforms values from one type to another. For someone new to the Typed FP world though, Reason or Elm would be an easier starting point. Both communities are geared towards newcomers and have first-class support for front-end development. My brief foray into Elm was very pleasant, and it is a community with great taste and aesthetics. Evan Czaplicki is wise beyond his age and is building a language that will last a long time. One reason why I would reach for ReasonML than Elm however is Reason's zero-overhead interop with Javascript. You can do this right in the middle of your code `[%%bs.raw console.log ("hey")];` and nobody will complain. This interop allows Reason to utilize the vast NPM ecosystem - so you can gradually adopt Reason in your front-end codebase. Your ReactReason code can use your plain React components and vice versa, and you can even use the bs-express library to write NodeJS applications with ExpressJS. Elm aims to remain pure because it allows them to build a more solid ecosystem in the long run. It is a great choice as well, just that the shorter-term trade-offs make it slightly more difficult to work with existing Javascript code. One angle in which Reason would be a better beginner language than Haskell is the number of concepts you have to understand before you can be truly productive with it. The shift from an imperative, dynamic world to a functional, statically typed world is already difficult enough. Reason/OCaml makes this transition easier because with it you can program in the familiar imperative style when you want, unlike Haskell where you need to rely on the elegant but takes-some-effort-to-grok Monads to tackle the Awkward Squad of I/O (https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...). And this might be controversial opinion - but the historical roots of Haskell as a language for bleeding-edge academic experimentation has lead to a certain kind of fragmentation that demands more effort from newcomers than a made-for-industry language would need. PureScript and Idris however have standardized on many of these things and might not share the same concerns. You still have to content with its laziness and purity. These are both practical and aesthetic choice in how to program, and they are very fun to explore. You just need to get started on some language in the statically typed FP camp to appreciate this long, deep rabbithole!
- weavie 9y ago
  Haskell will take months of brain twisting before you really understand what is going on and can do anything productive. ReasonML, you could be up and running within a week. (Timescales are just a random guess, but you get the idea..) Plus ReasonML isn't strictly functional. You can have side effects and mutation if you need. Obviously the purists may view this as a negative, but being able to eg. just get a random number without going through a ton of hoops can make things a bit less frustrating - especially if you are unfamiliar with functional. Once you have a good grasp of functional through ReasonML, Haskell will feel a lot less daunting.
- chillee 9y ago
  I view this as more of a general, why should somebody learn Ocaml instead of Haskell? There's a couple of reasons. #1. Ocaml's type system is nearly as expressive as Haskell's and includes several features that Haskell's does not. Polymorphic variants and functors being notable ones. #2. Laziness is very hard to get right in practice. I'm sure Haskell enthusiasts will not be very happy with that statement, but I think it's true. It's the reason why one of the biggest users of Haskell (and the most notable example of Haskell in industry), Standard Chartered, uses their own Haskell compiler that's strict by default. #3. Less productive in practice. For example, long build times are a huge problem in practice. See https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_remedy_the_soul/ https://www.reddit.com/r/haskell/comments/45q90s/is_anything... for comments from the Haskell community, including GHC maintainers. Really though, I don't think you can really go that wrong with either. Transferring from each language to the other one isn't very difficult, and they're both excellent languages.
  - chillee 9y ago
    I wrote this on my phone a couple hours ago, and I wanted to add a couple qualifiers that might be misleading to people. Laziness being hard to deal with isn't the only reason Standard Chartered uses their own compiler that's strict by default. However, they have noted that they do think strict haskell is a lot easier to deal with.
    - tome 9y ago
      > they have noted that they do think strict haskell is a lot easier to deal with That's news to me. Where did they note that? Lennart Augustsson explicitly says "I don't think strict or lazy matters that much in practice; they both work fine". http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-evaluation-in.html http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-...
      - chillee 9y ago
        I was basing off of this CUFP report regarding Standard Chartered's use of Haskell. http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf > Their experience with strict semantics has been positive. Particularly useful is the ease of obtaining meaningful stack traces, tracking resource usage, debugging and exception propagation. The chief downside of strict semantics, in their experience, is the increased difficulty of modular composition FWIW, I am a bit jealous of how laziness makes it easier to achieve function composition, and that was something that I wish was easier in strict semantics.
- yawaramin 9y ago
  Because Reason fully supports imperative and OOP style. You don't need to use functional style if you don't want to (of course, aside from using other people's code). Here's some classic OOP: class animal = {pub speak = "Animal noise";}; class cat = {inherit class animal; pub speak = "Meow!";}; class dog = {inherit class animal; pub speak = "Bark!";}; let speakTwice(animal: animal) = animal#speak ++ ", " ++ animal#speak; print_endline(speakTwice(new dog)); /* Bark!, Bark! */
  - chillee 9y ago
    I guess it would be remiss to not mention that most Ocaml users shy away from the object oriented side of the language. Not because it's not well done (it is), but because modules work a lot better for many of the uses cases you'd want classes for.
    - pjmlp 9y ago
      Yeah, mainly because in most OOP languages, classes/interfaces are just a kind of glorified modules anyway.
ballenf 9y ago
FYI for anyone who was fuzzy on the license/patent situation with the project: https://github.com/facebook/reason/commit/e8fb73ec6ff7c3136715a3c628769e3d5906c4f0 https://github.com/facebook/reason/commit/e8fb73ec6ff7c31367... (As of 12/2017, relicensed to straight MIT from BSD+patent.) Rauschmayer's work here makes me interested in the language and motivated to learn it. After reading more, only wish I'd explored for a recent project where I was working to implement a lot of functional patterns in native JS. Any thoughts about ReasonML vs "straight" OCaml? (Or does that question even make sense?)
- aaron-lebo 9y ago
  Someone can correct me, but Reason is just a syntax on top of Ocaml's compiler. Bucklescript and Reason even share the same site design. there's not much of a choice beyond what you like more, as they use the same libraries, tools, etc. Does anyone know where this new wave of interest came from?
  - yawaramin 9y ago
    Community. The Reason team focused on building it, and neatly embraced and nurtured BuckleScript in the process. It's a symbiotic relationship and the community has a reputation for being very newbie-friendly to boot.
- tom_mellior 9y ago
  > Any thoughts about ReasonML vs "straight" OCaml? I've heard of (and from) web developers who say that they find OCaml impossible to read, but that ReasonML is easy and pleasant for them. So part of this is what you are used to, and another is subjective preference.
- yawaramin 9y ago
  It's a good question. Reason includes some major syntactic conveniences that make the JavaScript interop more pleasant to work with. One of the biggest ones is that it introduces a first-class syntactic JavaScript object literal (i.e. a Reason/BuckleScript value which will compile down to a JavaScript literal) and which makes writing JS objects much more pleasant. There are other conveniences as well, including the fact that Reason comes with a tool (refmt) that can autoformat your code to a standard style, wiping out style guide arguments etc.
f1mint 9y ago
http://www.f1mint.com/technology http://www.f1mint.com/technology
lewisinc 9y ago
Someone will have to explain why I might pick ReasonML over Elm for front-end development. Elm's community seems very focused on making front-end development as intuitive and hassle-free as possible. ReasonML seems like Facebook just wanted to leverage a pre-existing community but couldn't bring themselves to adopt the syntax so rewrote it in-house.
- drunner 9y ago
  No runtime. ReasonML is a language that has decent interop capabilities with javascript through the bucklescript compiler. You can use it to write drop in ready code segments into an existing codebase. Hello world in ReasonML will get you a single line javascript output. Last I looked, the Elm bundle is in the 10s of kbs for something like that because you get the whole architecture. Add is ReasonReact and it's a little more comparable obviously.
- monkmartinez 9y ago
  I am not advocating anything in particular as I am in the process of choosing the next language to learn. That said, I have watched some talks by Cheng Lou and some others about ReasonML. Elm is just "Elm"... that isn't a bad thing and it seems like it is more mature at the moment. ReasonML is Ocaml that plays nice on any screen anywhere thanks to Bucklescript. It also plays nice as a systems language. That is, unikernels... I am not even sure what they are, but they sound awesome and I want that.
- weavie 9y ago
  ReasonML has a much more advanced module system via Functors. As far as I know Elm has nothing like this. Despite a fair few arguments over incorporating type classes into Elm, the creator is pretty dead set against the idea. This does make Elm a lot more approachable, but after a while can feel quite restrictive. There is bucklescript-tea, which is the Elm architecture in for Bucklescript (and thus also Reason). It is pretty much an exact match, so technically there isn't really anything you are missing out on by going with Reason. In reality the Elm community is more mature which means there is more documentation and libraries available. However bucklescript does interface to javascript a LOT easier - which does open up a much wider ecosystem of javascript libraries.
platinumrad 9y ago
Maybe not the right place to ask, but "Better standard library" appears in the section detailing future improvements that ReasonML might bring to the OCaml ecosystem. How do they plan on doing this, given that the major standard library camps seem relatively entrenched in OCaml today? Which one does the ReasonML community favor/intend to contribute to?
- seliopou 9y ago
  Base[1] is a good candidate for an OCaml standard library. It's got tons of functionality, results in binaries with small footprints, is cross-platform, and has a fairly stable API. It's also code that has been and continues to be battle tested every day in production systems at Jane Street. I'm biased, as I'm one of the maintainers, but trust me it's good, it's good. [1]: https://github.com/janestreet/base https://github.com/janestreet/base
  - AceJohnny2 9y ago
    How does Base compare to Core? https://github.com/janestreet/core https://github.com/janestreet/core
    - 0xCMP 9y ago
      Seems like Core depends on Base (https://github.com/janestreet/core/blob/master/core.opam https://github.com/janestreet/core/blob/master/core.opam)
    - seliopou 9y ago
      Core depends on Base. The parts where they differ include: more data structure, and bindings for system calls and other functionality available from libc. There's also core_kernel, which is core but without the libc support.
  - yminsky 9y ago
    We also just released improved docs for Base. Still more to do, but much better than before: https://ocaml.janestreet.com/ocaml-core/latest/doc/base/ https://ocaml.janestreet.com/ocaml-core/latest/doc/base/
k__ 9y ago
This man is a machine. Love his stuff! Now async/await and Reason is good to go ;)
hnzix 9y ago
I'm looking for a language for cross-platform mobile app development using React/Expo. Can anyone give their opinion on ReasonReact vs Clojurescript Reframe? I like the familiar syntax of ReasonML, but Clojurescript has LISP mojo and is more mature (more learning resources etc).
- yawaramin 9y ago
  I don't know what the status of ClojureScript Reframe is, but there is an unofficial, in-progress ReasomML binding to Expo. You can contribute to that if you want https://github.com/fxfactorial/bs-expo https://github.com/fxfactorial/bs-expo (note that @fxfactorial, i.e. Edgar, works at Expo but is writing the Reason binding unofficially–for now at least). The ReasonReact binding is high-quality and provides a lot of power (state management, routing) right out of the box. You can get started with that right now if you wish.
- lilactown 9y ago
  It depends. IMO Cojure is a much more mature and stable foundation for building apps today - ReasonML is a good bet for the next 5 years, though. My team recently weighed Clojure(Script) & ReasonML and chose Clojure, because we need to ship and it's not going anywhere.
malloryerik 9y ago
How would you compare ReasonML with ClojureScript, why or when should one be used over the other, what are the strengths and weaknesses of each in areas like JS interop, productivity, maintainability, creative prototyping and exploring, and so on?

211 points by jasim 9y ago

Rauschmayer is a good writer - He's been running a great JS blog for many years (http://2ality.com/ http://2ality.com/)

Why should someone unfamiliar with functional style programming be learning ReasonML rather than say, something like, haskell? Looking for concrete, technical answers.

duckfruit 9y ago
You wouldn't choose it over haskell every time, but for the limited subset of times where you need to write frontend code ReasonML has distinct advantages. ReasonML is basically OCaml that compiles to JS, designed to make interoperation with Javasascript easy. There are compile to JS projects for Haskell too, but the ease of interoperability with popular JS libraries like react and support from facebook's open source tooling chain make it a much better choice for most frontend projects IMHO -- unless you're already a haskell expert in which case go with what you already know!
- aassddffasdf 9y ago
  That's not correct. What you've described is Bucklescript (which has OCaml syntax). ReasonML is an attempt to "improve" the OCaml syntax to something more familiar to folks coming from C-style family of lanauges. ReasonML can be used with both the Bucklescript compiler (which compiles to JS) -or- the standard OCaml one (which compiles to native).
  - yawaramin 9y ago
    While that is technically true, most people nowadays use them interchangeably especially because Reason is focusing so much on its web story, so I wouldn't expect people to make this distinction very often.
    - aassddffasdf 9y ago
      The frequency which this distinction is made in the general populace matters not in the least to me. What matters to me is reality/truth. Either people get on board with it or they butcher it. I have a bit more faith in them than you do it seems. Only time will tell which of us is correct.
Barrin92 9y ago
when I started out to learn functional style programming I wanted to build a real project. I tried several languages out and I settled with F# because I just didn't like the enforced purity of Haskell and laziness as a default. It just cost me so much time to constantly think about IO that I was barely figuring out what I wanted to write. It seemed impractical to me and now with some more experience I still think it is. Ocaml type languages strike a better balance in my opinion if you're interacting with the world.
- willtim 9y ago
  I can assure you that, with practice, Haskell can be a very practical language. Having IO in the types lets one reason about where the effects are happening, which is especially important when trying to solve real world problems with functional techniques (i.e. transforming unreliable streams of data).
jasim 9y ago
You cannot go wrong by picking any statically typed functional language - Reason, Elm, F#, PureScript, Haskell, or even Idris. All of these languages share a similar style of programming that revolve around data that is described through a rich type system and program execution modelled as a series of pure functions that transforms values from one type to another. For someone new to the Typed FP world though, Reason or Elm would be an easier starting point. Both communities are geared towards newcomers and have first-class support for front-end development. My brief foray into Elm was very pleasant, and it is a community with great taste and aesthetics. Evan Czaplicki is wise beyond his age and is building a language that will last a long time. One reason why I would reach for ReasonML than Elm however is Reason's zero-overhead interop with Javascript. You can do this right in the middle of your code `[%%bs.raw console.log ("hey")];` and nobody will complain. This interop allows Reason to utilize the vast NPM ecosystem - so you can gradually adopt Reason in your front-end codebase. Your ReactReason code can use your plain React components and vice versa, and you can even use the bs-express library to write NodeJS applications with ExpressJS. Elm aims to remain pure because it allows them to build a more solid ecosystem in the long run. It is a great choice as well, just that the shorter-term trade-offs make it slightly more difficult to work with existing Javascript code. One angle in which Reason would be a better beginner language than Haskell is the number of concepts you have to understand before you can be truly productive with it. The shift from an imperative, dynamic world to a functional, statically typed world is already difficult enough. Reason/OCaml makes this transition easier because with it you can program in the familiar imperative style when you want, unlike Haskell where you need to rely on the elegant but takes-some-effort-to-grok Monads to tackle the Awkward Squad of I/O (https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...). And this might be controversial opinion - but the historical roots of Haskell as a language for bleeding-edge academic experimentation has lead to a certain kind of fragmentation that demands more effort from newcomers than a made-for-industry language would need. PureScript and Idris however have standardized on many of these things and might not share the same concerns. You still have to content with its laziness and purity. These are both practical and aesthetic choice in how to program, and they are very fun to explore. You just need to get started on some language in the statically typed FP camp to appreciate this long, deep rabbithole!
weavie 9y ago
Haskell will take months of brain twisting before you really understand what is going on and can do anything productive. ReasonML, you could be up and running within a week. (Timescales are just a random guess, but you get the idea..) Plus ReasonML isn't strictly functional. You can have side effects and mutation if you need. Obviously the purists may view this as a negative, but being able to eg. just get a random number without going through a ton of hoops can make things a bit less frustrating - especially if you are unfamiliar with functional. Once you have a good grasp of functional through ReasonML, Haskell will feel a lot less daunting.
chillee 9y ago
I view this as more of a general, why should somebody learn Ocaml instead of Haskell? There's a couple of reasons. #1. Ocaml's type system is nearly as expressive as Haskell's and includes several features that Haskell's does not. Polymorphic variants and functors being notable ones. #2. Laziness is very hard to get right in practice. I'm sure Haskell enthusiasts will not be very happy with that statement, but I think it's true. It's the reason why one of the biggest users of Haskell (and the most notable example of Haskell in industry), Standard Chartered, uses their own Haskell compiler that's strict by default. #3. Less productive in practice. For example, long build times are a huge problem in practice. See https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_remedy_the_soul/ https://www.reddit.com/r/haskell/comments/45q90s/is_anything... for comments from the Haskell community, including GHC maintainers. Really though, I don't think you can really go that wrong with either. Transferring from each language to the other one isn't very difficult, and they're both excellent languages.
- chillee 9y ago
  I wrote this on my phone a couple hours ago, and I wanted to add a couple qualifiers that might be misleading to people. Laziness being hard to deal with isn't the only reason Standard Chartered uses their own compiler that's strict by default. However, they have noted that they do think strict haskell is a lot easier to deal with.
  - tome 9y ago
    > they have noted that they do think strict haskell is a lot easier to deal with That's news to me. Where did they note that? Lennart Augustsson explicitly says "I don't think strict or lazy matters that much in practice; they both work fine". http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-evaluation-in.html http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-...
    - chillee 9y ago
      I was basing off of this CUFP report regarding Standard Chartered's use of Haskell. http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf > Their experience with strict semantics has been positive. Particularly useful is the ease of obtaining meaningful stack traces, tracking resource usage, debugging and exception propagation. The chief downside of strict semantics, in their experience, is the increased difficulty of modular composition FWIW, I am a bit jealous of how laziness makes it easier to achieve function composition, and that was something that I wish was easier in strict semantics.
yawaramin 9y ago
Because Reason fully supports imperative and OOP style. You don't need to use functional style if you don't want to (of course, aside from using other people's code). Here's some classic OOP: class animal = {pub speak = "Animal noise";}; class cat = {inherit class animal; pub speak = "Meow!";}; class dog = {inherit class animal; pub speak = "Bark!";}; let speakTwice(animal: animal) = animal#speak ++ ", " ++ animal#speak; print_endline(speakTwice(new dog)); /* Bark!, Bark! */
- chillee 9y ago
  I guess it would be remiss to not mention that most Ocaml users shy away from the object oriented side of the language. Not because it's not well done (it is), but because modules work a lot better for many of the uses cases you'd want classes for.
  - pjmlp 9y ago
    Yeah, mainly because in most OOP languages, classes/interfaces are just a kind of glorified modules anyway.

ballenf 9y ago

FYI for anyone who was fuzzy on the license/patent situation with the project: https://github.com/facebook/reason/commit/e8fb73ec6ff7c3136715a3c628769e3d5906c4f0 https://github.com/facebook/reason/commit/e8fb73ec6ff7c31367... (As of 12/2017, relicensed to straight MIT from BSD+patent.) Rauschmayer's work here makes me interested in the language and motivated to learn it. After reading more, only wish I'd explored for a recent project where I was working to implement a lot of functional patterns in native JS. Any thoughts about ReasonML vs "straight" OCaml? (Or does that question even make sense?)

aaron-lebo 9y ago
Someone can correct me, but Reason is just a syntax on top of Ocaml's compiler. Bucklescript and Reason even share the same site design. there's not much of a choice beyond what you like more, as they use the same libraries, tools, etc. Does anyone know where this new wave of interest came from?
- yawaramin 9y ago
  Community. The Reason team focused on building it, and neatly embraced and nurtured BuckleScript in the process. It's a symbiotic relationship and the community has a reputation for being very newbie-friendly to boot.
tom_mellior 9y ago
> Any thoughts about ReasonML vs "straight" OCaml? I've heard of (and from) web developers who say that they find OCaml impossible to read, but that ReasonML is easy and pleasant for them. So part of this is what you are used to, and another is subjective preference.
yawaramin 9y ago
It's a good question. Reason includes some major syntactic conveniences that make the JavaScript interop more pleasant to work with. One of the biggest ones is that it introduces a first-class syntactic JavaScript object literal (i.e. a Reason/BuckleScript value which will compile down to a JavaScript literal) and which makes writing JS objects much more pleasant. There are other conveniences as well, including the fact that Reason comes with a tool (refmt) that can autoformat your code to a standard style, wiping out style guide arguments etc.

f1mint 9y ago

http://www.f1mint.com/technology http://www.f1mint.com/technology

lewisinc 9y ago

Someone will have to explain why I might pick ReasonML over Elm for front-end development. Elm's community seems very focused on making front-end development as intuitive and hassle-free as possible. ReasonML seems like Facebook just wanted to leverage a pre-existing community but couldn't bring themselves to adopt the syntax so rewrote it in-house.

drunner 9y ago
No runtime. ReasonML is a language that has decent interop capabilities with javascript through the bucklescript compiler. You can use it to write drop in ready code segments into an existing codebase. Hello world in ReasonML will get you a single line javascript output. Last I looked, the Elm bundle is in the 10s of kbs for something like that because you get the whole architecture. Add is ReasonReact and it's a little more comparable obviously.
monkmartinez 9y ago
I am not advocating anything in particular as I am in the process of choosing the next language to learn. That said, I have watched some talks by Cheng Lou and some others about ReasonML. Elm is just "Elm"... that isn't a bad thing and it seems like it is more mature at the moment. ReasonML is Ocaml that plays nice on any screen anywhere thanks to Bucklescript. It also plays nice as a systems language. That is, unikernels... I am not even sure what they are, but they sound awesome and I want that.
weavie 9y ago
ReasonML has a much more advanced module system via Functors. As far as I know Elm has nothing like this. Despite a fair few arguments over incorporating type classes into Elm, the creator is pretty dead set against the idea. This does make Elm a lot more approachable, but after a while can feel quite restrictive. There is bucklescript-tea, which is the Elm architecture in for Bucklescript (and thus also Reason). It is pretty much an exact match, so technically there isn't really anything you are missing out on by going with Reason. In reality the Elm community is more mature which means there is more documentation and libraries available. However bucklescript does interface to javascript a LOT easier - which does open up a much wider ecosystem of javascript libraries.

platinumrad 9y ago

Maybe not the right place to ask, but "Better standard library" appears in the section detailing future improvements that ReasonML might bring to the OCaml ecosystem. How do they plan on doing this, given that the major standard library camps seem relatively entrenched in OCaml today? Which one does the ReasonML community favor/intend to contribute to?

seliopou 9y ago
Base[1] is a good candidate for an OCaml standard library. It's got tons of functionality, results in binaries with small footprints, is cross-platform, and has a fairly stable API. It's also code that has been and continues to be battle tested every day in production systems at Jane Street. I'm biased, as I'm one of the maintainers, but trust me it's good, it's good. [1]: https://github.com/janestreet/base https://github.com/janestreet/base
- AceJohnny2 9y ago
  How does Base compare to Core? https://github.com/janestreet/core https://github.com/janestreet/core
  - 0xCMP 9y ago
    Seems like Core depends on Base (https://github.com/janestreet/core/blob/master/core.opam https://github.com/janestreet/core/blob/master/core.opam)
  - seliopou 9y ago
    Core depends on Base. The parts where they differ include: more data structure, and bindings for system calls and other functionality available from libc. There's also core_kernel, which is core but without the libc support.
- yminsky 9y ago
  We also just released improved docs for Base. Still more to do, but much better than before: https://ocaml.janestreet.com/ocaml-core/latest/doc/base/ https://ocaml.janestreet.com/ocaml-core/latest/doc/base/

k__ 9y ago

This man is a machine. Love his stuff! Now async/await and Reason is good to go ;)

hnzix 9y ago

I'm looking for a language for cross-platform mobile app development using React/Expo. Can anyone give their opinion on ReasonReact vs Clojurescript Reframe? I like the familiar syntax of ReasonML, but Clojurescript has LISP mojo and is more mature (more learning resources etc).

yawaramin 9y ago
I don't know what the status of ClojureScript Reframe is, but there is an unofficial, in-progress ReasomML binding to Expo. You can contribute to that if you want https://github.com/fxfactorial/bs-expo https://github.com/fxfactorial/bs-expo (note that @fxfactorial, i.e. Edgar, works at Expo but is writing the Reason binding unofficially–for now at least). The ReasonReact binding is high-quality and provides a lot of power (state management, routing) right out of the box. You can get started with that right now if you wish.
lilactown 9y ago
It depends. IMO Cojure is a much more mature and stable foundation for building apps today - ReasonML is a good bet for the next 5 years, though. My team recently weighed Clojure(Script) & ReasonML and chose Clojure, because we need to ship and it's not going anywhere.

malloryerik 9y ago

How would you compare ReasonML with ClojureScript, why or when should one be used over the other, what are the strengths and weaknesses of each in areas like JS interop, productivity, maintainability, creative prototyping and exploring, and so on?