12 ms·

A set of efficient persistent immutable data structures for Reason and OCaml

86 points by gfosco 10y ago

ubercow 10y ago
Is anyone here using Reason in any meaningful way? Even just a side project. If so, what are you using it for and how do you like it.
- kornish 10y ago
  Not using it, but jumping in to share an anecdote – I saw the Reason announcement months and months ago and decided to use it as a jumping-off point into the OCaml ecosystem. It took about a week of writing Reason before I realized I was spending so much time reading OCaml (all the libraries were written in it) before I just switched to OCaml proper. Haven't looked back - the syntax takes a few days to pick up, but is hardly the most difficult part of writing a program. Hopefully they can capitalize on the "Build" and "Share" part of their value prop [0] because "Syntax" appears (to most) to be the least valuable improvement. As a disclaimer, I could be totally wrong, never having worked at a FB-size organization – that onboarding time probably adds up quickly. Come to think of it: can anyone think of a successful transpiled language that doesn't actually provide new semantics? Coffeescript is the closest thing that comes to mind, but it's dying out as ECMAScript absorbs its most appealing features. [0]: http://facebook.github.io/reason/#reason http://facebook.github.io/reason/#reason Edit: forgot about Elixir, which seems to be doing quite well – but that introduces new semantics like homoiconicity + macros and protocols.
  - cies 10y ago
    There's some neat stuff in the Reason syntax, apart from the make-it-less-weird-for-those-coming-from-JS/Java/C#/etc., for instance: JSX[0] and named curried functions[1]. Both are fitting in really nice when doing FE dev't like with `react-reason`[2]. If you are interested in this, I recommend some talks. First one by Cheng Lou, a main contributor of Reason and FB employee on React Conf 2017[3]. And a talk by Sean Grove[4] on Reason in general. With the power of FB behind this new techonolgy (they have currently written 25% of messenger.com in Reason), this might well become very big. A general purpose strongly typed functional prog lang, that has a vast ecosystem, now an approachable syntax, and compiles to both native and JS. Sounds good nuh? [0]: https://facebook.github.io/reason/#diving-deeper-jsx https://facebook.github.io/reason/#diving-deeper-jsx [1]: https://facebook.github.io/reason/#diving-deeper-curried-functions https://facebook.github.io/reason/#diving-deeper-curried-fun... [2]: https://github.com/chenglou/reason-react-example/blob/master/src/todomvc/app.re https://github.com/chenglou/reason-react-example/blob/master... [3]: https://www.youtube.com/watch?v=_0T5OSSzxms https://www.youtube.com/watch?v=_0T5OSSzxms [4]: https://www.youtube.com/watch?v=8LCmLQ1-YqQ&t=517s https://www.youtube.com/watch?v=8LCmLQ1-YqQ&t=517s
    - thedufer 10y ago
      Can you explain how named curried functions differ from ocaml's named arguments? It looks exactly the same, other than the syntax.
      - chenglou 10y ago
        They are the same. I don't think cies was implying they were different.
        thedufer 10y ago
        The wording seems to pretty clearly say otherwise, but I appreciate the confirmation that I'm not missing anything.
      - jordwalke 10y ago
        They're not different than OCaml's, but Reason's JSX is an interesting / useful application of labeled arguments that appeals to React developers.
      - cies 10y ago
        My bad. They're the same (as others noted). Was not familiar with them.
  - mirekrusin 10y ago
    > (...) Coffeescript is the closest thing that comes to mind, but it's dying out as ECMAScript absorbs its most appealing features. (...) CoffeeScript seems to be doing well, they're working on version 2.0 (currently in alpha) aka coffeescript@next [1] with async/await (with similar approach as they did with generators where only `yield` keyword is used and the function is implicitly lifted to generator, similarly using `await` implicitly lifts function to async, so there's no need to mark function as async explicitly - very good idea IMHO), ES2015 classes and some other changes. CoffeeScript is still what it was before - making code easier and more pleasurable to read and write: less verbose, everything is an expression, existential operator, better switch, comprehensions, prototype access operator, chained comparisons, block regex, implicit returns, range loops... [1] http://coffeescript.org/v2/ http://coffeescript.org/v2/
  - jordwalke 10y ago
    Also note that there are some language features which are surprisingly syntactic - which are well within the scope of Reason : For example, some basic facilities for export/import as well as async transformations. These are all being discussed/proposed in the Reason channel, and they can be implemented in an opinionated syntax without needing to fragment the OCaml ecosystem - providing full interop between existing OCaml packages / tools. Once/if a build system is standardized in the OCaml community, there are even more interesting features and tools that can be built, and can be given first class syntactic treatment from within Reason.
- chenglou 10y ago
  I work alongside the Reason team. We're using it on messenger.com. 25% converted over already. 4 bugs during conversion, and only a single runtime bug in the converted part since last half.
  - zem 10y ago
    messenger.com is written in ocaml? that's pretty neat!
    - chenglou 10y ago
      Converted. From reactjs to reason-react https://github.com/reasonml/reason-react https://github.com/reasonml/reason-react Which imo is a bigger achievement! Being able to gradually convert a js codebase over is one of our main goals.
      - zem 10y ago
        indeed! i would love to read a blog post about the conversion.
    - Touche 10y ago
      The front-end or back-end? The front-end isn't what I would call an endorsement of whatever framework/language is chosen.
      - chenglou 10y ago
        Ooooouh that's harsh lol. Sorry for your experience. We're trying to improve it but we're a tiny team that also maintains other features.
        Touche 10y ago
        I didn't mean to offend, and I understand. But it's 1.4mb of JavaScript that takes 4 seconds to load on my high-end Macbook.
  - 10y ago
- 49531 10y ago
  messenger.com is 25% Reason
- tyoverby 10y ago
  I tried using Reason for a side project. Getting the build tools and the package manager for ocaml took too long so I gave up.
  - chenglou 10y ago
    If you're still willing to give it a second chance, we've got https://github.com/chenglou/reason-react-example https://github.com/chenglou/reason-react-example which uses only npm Sorry for the crappy initial experience.
    - tyoverby 10y ago
      I did see that, but I discounted it because I wanted to make a serverside (native, not serverside-js) application, and I assumed that the reason-react-example was only for making compile-to-javascript applications.
      - tekknolagi 10y ago
        If you'd like, I can help you get set up on Discord: http://discord.gg/reasonml http://discord.gg/reasonml
      - jordwalke 10y ago
        Just so we don't miss the opportunity to learn - would you mind stating what you would find valuable in a toolchain for building a server side native system? What kind of things about project management/install appeal to you?
        Flow 10y ago
        When will ReasonML use the latest OCaml? Maybe it doesn't matter much, but it's still quite an old version.
        jordwalke 10y ago
        We are compatible with 4.03 and 4.04 via opam!
kornish 10y ago
Question for jordwalke or any Facebookers around: how's Reason's adoption inside of Facebook relative to OCaml? The hypothesis around the syntax seems to be that it's more approachable for Javascript programmers – are you noting a significantly faster onboarding time?
- jordwalke 10y ago
  The feedback we've gotten from web developers is that it's easier to learn, and the integration that we've done for web makes it much easier to be instantly productive. Many say they would have not even taken a look at OCaml if there wasn't a group of developers caring about improving the overall ergonomics and front end experience. "relative to OCaml". Many people don't know, but a ton of Facebook's critical infrastructure has been developed on OCaml for a long time: projects such as Infer, Hack, Flow and many others. So there's a ton of existing projects that might be hard to catch up to in the short term and thats okay in my mind, because those projects are using the right tool for the job at hand. Even though the syntax they use might be a little more off-putting to new contributors, I think they're getting the big things right. One benefit to Reason is that it stands to make sure that more developers who are starting new projects, get the big things right - syntax is just one of many means to that end. We want to fully interop with the OCaml ecosystem and we go through great lengths to ensure that Reason can be used with any OCaml project. I would love to focus even more on that once the ReactJS story is in a really good place.
  - jordwalke 10y ago
    The most common (constructive) feedback we currently receive is that once people want to dive into some advanced stuff, they need more material than the brief tutorials, and the primary book is written in OCaml syntax / toolchain. I would love it if we could have custom Real World OCaml "renditions" that allow custom automated presentation of syntax in the online book, as well as some focus on web development workflows.
    - tekknolagi 10y ago
      Isn't there a Chrome extension that automatically converts OCaml snippets to Reason syntax?
Drup 10y ago
Oh, great, yet another library of data structures that introduce incompatible abstractions with both the standard library and the 3 other big libraries of data structures[1,2,3], that is exactly what the OCaml ecosystem needs! :D More seriously, though, at least the naming convention is consistent. It looks a bit heavy on signature-indirection. I would really prefer if they used a standard iterator (gen[5] and sequence[6], for example, or the future one in the stdlib[7]) and settled for one serialization method (such as sexp) and get formatters everywhere. Also, please use ocamldoc or odoc[4] for your documentation. The one generated here is really terrible, even for OCam^W Reason standards. [1]: https://github.com/c-cube/ocaml-containers/ https://github.com/c-cube/ocaml-containers/ [2]: http://batteries.forge.ocamlcore.org/ http://batteries.forge.ocamlcore.org/ [3]: https://github.com/janestreet/base https://github.com/janestreet/base [4]: https://github.com/ocaml-doc/odoc/ https://github.com/ocaml-doc/odoc/ [5]: https://github.com/c-cube/gen/ https://github.com/c-cube/gen/ [6]: https://github.com/c-cube/sequence/ https://github.com/c-cube/sequence/ [7]: https://github.com/ocaml/ocaml/pull/1002 https://github.com/ocaml/ocaml/pull/1002
- bordoley 10y ago
  Hi Drup, The intent of Immutable-re is to provide a complete set of persistent immutable collections that complement the standard library and core. The initial release is limited to common Map, Set, and Vector types, but we have intent to add additional collections such as BiMaps, Multisets, and Multimaps. There is of course some overlap with the stdlib collections (SortedSet vs. OCaml Set, SortedMap vs. OCaml Map) but even in these cases, the Immutable-re implementations have slightly different characteristics from their stdlib counterparts, which provide added value. The public API is designed to be very Reason like, and familiar to web developers with experience in JavaScript, Java and C#, hence the naming conventions and camlCase. I've also considered adding an OCaml compatibility layer, which provides a more familiar API for OCaml developers. While the public API itself is heavily dependent upon signature indirection, these signatures are purely for documentation and not heavily depended upon within the implementation, which means the OCaml compat API may not include them at all. Regarding the choice of APIs for sequences, the current Sequence type is intentionally opaque and is internally designed to be compatible with the proposed standard OCaml Sequence (https://github.com/ocaml/ocaml/pull/1002 https://github.com/ocaml/ocaml/pull/1002). If/when, that PR lands, we will switch our internal implementation to be compatible with OCaml's while maintaining the same public API. Finally you are completely correct regarding documentation generation. Unfortunately refmt does not currently support outputting OCaml mli files including comments. This left me with the choice of hand rolling docs as I did or shipping ocamldocs lacking any comments explaining the types and functions. I chose the former. Thanks for your feedback.

86 points by gfosco 10y ago

Is anyone here using Reason in any meaningful way? Even just a side project. If so, what are you using it for and how do you like it.

kornish 10y ago
Not using it, but jumping in to share an anecdote – I saw the Reason announcement months and months ago and decided to use it as a jumping-off point into the OCaml ecosystem. It took about a week of writing Reason before I realized I was spending so much time reading OCaml (all the libraries were written in it) before I just switched to OCaml proper. Haven't looked back - the syntax takes a few days to pick up, but is hardly the most difficult part of writing a program. Hopefully they can capitalize on the "Build" and "Share" part of their value prop [0] because "Syntax" appears (to most) to be the least valuable improvement. As a disclaimer, I could be totally wrong, never having worked at a FB-size organization – that onboarding time probably adds up quickly. Come to think of it: can anyone think of a successful transpiled language that doesn't actually provide new semantics? Coffeescript is the closest thing that comes to mind, but it's dying out as ECMAScript absorbs its most appealing features. [0]: http://facebook.github.io/reason/#reason http://facebook.github.io/reason/#reason Edit: forgot about Elixir, which seems to be doing quite well – but that introduces new semantics like homoiconicity + macros and protocols.
- cies 10y ago
  There's some neat stuff in the Reason syntax, apart from the make-it-less-weird-for-those-coming-from-JS/Java/C#/etc., for instance: JSX[0] and named curried functions[1]. Both are fitting in really nice when doing FE dev't like with `react-reason`[2]. If you are interested in this, I recommend some talks. First one by Cheng Lou, a main contributor of Reason and FB employee on React Conf 2017[3]. And a talk by Sean Grove[4] on Reason in general. With the power of FB behind this new techonolgy (they have currently written 25% of messenger.com in Reason), this might well become very big. A general purpose strongly typed functional prog lang, that has a vast ecosystem, now an approachable syntax, and compiles to both native and JS. Sounds good nuh? [0]: https://facebook.github.io/reason/#diving-deeper-jsx https://facebook.github.io/reason/#diving-deeper-jsx [1]: https://facebook.github.io/reason/#diving-deeper-curried-functions https://facebook.github.io/reason/#diving-deeper-curried-fun... [2]: https://github.com/chenglou/reason-react-example/blob/master/src/todomvc/app.re https://github.com/chenglou/reason-react-example/blob/master... [3]: https://www.youtube.com/watch?v=_0T5OSSzxms https://www.youtube.com/watch?v=_0T5OSSzxms [4]: https://www.youtube.com/watch?v=8LCmLQ1-YqQ&t=517s https://www.youtube.com/watch?v=8LCmLQ1-YqQ&t=517s
  - thedufer 10y ago
    Can you explain how named curried functions differ from ocaml's named arguments? It looks exactly the same, other than the syntax.
    - chenglou 10y ago
      They are the same. I don't think cies was implying they were different.
      - thedufer 10y ago
        The wording seems to pretty clearly say otherwise, but I appreciate the confirmation that I'm not missing anything.
    - jordwalke 10y ago
      They're not different than OCaml's, but Reason's JSX is an interesting / useful application of labeled arguments that appeals to React developers.
    - cies 10y ago
      My bad. They're the same (as others noted). Was not familiar with them.
- mirekrusin 10y ago
  > (...) Coffeescript is the closest thing that comes to mind, but it's dying out as ECMAScript absorbs its most appealing features. (...) CoffeeScript seems to be doing well, they're working on version 2.0 (currently in alpha) aka coffeescript@next [1] with async/await (with similar approach as they did with generators where only `yield` keyword is used and the function is implicitly lifted to generator, similarly using `await` implicitly lifts function to async, so there's no need to mark function as async explicitly - very good idea IMHO), ES2015 classes and some other changes. CoffeeScript is still what it was before - making code easier and more pleasurable to read and write: less verbose, everything is an expression, existential operator, better switch, comprehensions, prototype access operator, chained comparisons, block regex, implicit returns, range loops... [1] http://coffeescript.org/v2/ http://coffeescript.org/v2/
- jordwalke 10y ago
  Also note that there are some language features which are surprisingly syntactic - which are well within the scope of Reason : For example, some basic facilities for export/import as well as async transformations. These are all being discussed/proposed in the Reason channel, and they can be implemented in an opinionated syntax without needing to fragment the OCaml ecosystem - providing full interop between existing OCaml packages / tools. Once/if a build system is standardized in the OCaml community, there are even more interesting features and tools that can be built, and can be given first class syntactic treatment from within Reason.
chenglou 10y ago
I work alongside the Reason team. We're using it on messenger.com. 25% converted over already. 4 bugs during conversion, and only a single runtime bug in the converted part since last half.
- zem 10y ago
  messenger.com is written in ocaml? that's pretty neat!
  - chenglou 10y ago
    Converted. From reactjs to reason-react https://github.com/reasonml/reason-react https://github.com/reasonml/reason-react Which imo is a bigger achievement! Being able to gradually convert a js codebase over is one of our main goals.
    - zem 10y ago
      indeed! i would love to read a blog post about the conversion.
  - Touche 10y ago
    The front-end or back-end? The front-end isn't what I would call an endorsement of whatever framework/language is chosen.
    - chenglou 10y ago
      Ooooouh that's harsh lol. Sorry for your experience. We're trying to improve it but we're a tiny team that also maintains other features.
      - Touche 10y ago
        I didn't mean to offend, and I understand. But it's 1.4mb of JavaScript that takes 4 seconds to load on my high-end Macbook.
- 10y ago
49531 10y ago
messenger.com is 25% Reason
tyoverby 10y ago
I tried using Reason for a side project. Getting the build tools and the package manager for ocaml took too long so I gave up.
- chenglou 10y ago
  If you're still willing to give it a second chance, we've got https://github.com/chenglou/reason-react-example https://github.com/chenglou/reason-react-example which uses only npm Sorry for the crappy initial experience.
  - tyoverby 10y ago
    I did see that, but I discounted it because I wanted to make a serverside (native, not serverside-js) application, and I assumed that the reason-react-example was only for making compile-to-javascript applications.
    - tekknolagi 10y ago
      If you'd like, I can help you get set up on Discord: http://discord.gg/reasonml http://discord.gg/reasonml
    - jordwalke 10y ago
      Just so we don't miss the opportunity to learn - would you mind stating what you would find valuable in a toolchain for building a server side native system? What kind of things about project management/install appeal to you?
      - Flow 10y ago
        When will ReasonML use the latest OCaml? Maybe it doesn't matter much, but it's still quite an old version.
        jordwalke 10y ago
        We are compatible with 4.03 and 4.04 via opam!

kornish 10y ago

Question for jordwalke or any Facebookers around: how's Reason's adoption inside of Facebook relative to OCaml? The hypothesis around the syntax seems to be that it's more approachable for Javascript programmers – are you noting a significantly faster onboarding time?

jordwalke 10y ago
The feedback we've gotten from web developers is that it's easier to learn, and the integration that we've done for web makes it much easier to be instantly productive. Many say they would have not even taken a look at OCaml if there wasn't a group of developers caring about improving the overall ergonomics and front end experience. "relative to OCaml". Many people don't know, but a ton of Facebook's critical infrastructure has been developed on OCaml for a long time: projects such as Infer, Hack, Flow and many others. So there's a ton of existing projects that might be hard to catch up to in the short term and thats okay in my mind, because those projects are using the right tool for the job at hand. Even though the syntax they use might be a little more off-putting to new contributors, I think they're getting the big things right. One benefit to Reason is that it stands to make sure that more developers who are starting new projects, get the big things right - syntax is just one of many means to that end. We want to fully interop with the OCaml ecosystem and we go through great lengths to ensure that Reason can be used with any OCaml project. I would love to focus even more on that once the ReactJS story is in a really good place.
- jordwalke 10y ago
  The most common (constructive) feedback we currently receive is that once people want to dive into some advanced stuff, they need more material than the brief tutorials, and the primary book is written in OCaml syntax / toolchain. I would love it if we could have custom Real World OCaml "renditions" that allow custom automated presentation of syntax in the online book, as well as some focus on web development workflows.
  - tekknolagi 10y ago
    Isn't there a Chrome extension that automatically converts OCaml snippets to Reason syntax?

Drup 10y ago

Oh, great, yet another library of data structures that introduce incompatible abstractions with both the standard library and the 3 other big libraries of data structures[1,2,3], that is exactly what the OCaml ecosystem needs! :D More seriously, though, at least the naming convention is consistent. It looks a bit heavy on signature-indirection. I would really prefer if they used a standard iterator (gen[5] and sequence[6], for example, or the future one in the stdlib[7]) and settled for one serialization method (such as sexp) and get formatters everywhere. Also, please use ocamldoc or odoc[4] for your documentation. The one generated here is really terrible, even for OCam^W Reason standards. [1]: https://github.com/c-cube/ocaml-containers/ https://github.com/c-cube/ocaml-containers/ [2]: http://batteries.forge.ocamlcore.org/ http://batteries.forge.ocamlcore.org/ [3]: https://github.com/janestreet/base https://github.com/janestreet/base [4]: https://github.com/ocaml-doc/odoc/ https://github.com/ocaml-doc/odoc/ [5]: https://github.com/c-cube/gen/ https://github.com/c-cube/gen/ [6]: https://github.com/c-cube/sequence/ https://github.com/c-cube/sequence/ [7]: https://github.com/ocaml/ocaml/pull/1002 https://github.com/ocaml/ocaml/pull/1002

bordoley 10y ago
Hi Drup, The intent of Immutable-re is to provide a complete set of persistent immutable collections that complement the standard library and core. The initial release is limited to common Map, Set, and Vector types, but we have intent to add additional collections such as BiMaps, Multisets, and Multimaps. There is of course some overlap with the stdlib collections (SortedSet vs. OCaml Set, SortedMap vs. OCaml Map) but even in these cases, the Immutable-re implementations have slightly different characteristics from their stdlib counterparts, which provide added value. The public API is designed to be very Reason like, and familiar to web developers with experience in JavaScript, Java and C#, hence the naming conventions and camlCase. I've also considered adding an OCaml compatibility layer, which provides a more familiar API for OCaml developers. While the public API itself is heavily dependent upon signature indirection, these signatures are purely for documentation and not heavily depended upon within the implementation, which means the OCaml compat API may not include them at all. Regarding the choice of APIs for sequences, the current Sequence type is intentionally opaque and is internally designed to be compatible with the proposed standard OCaml Sequence (https://github.com/ocaml/ocaml/pull/1002 https://github.com/ocaml/ocaml/pull/1002). If/when, that PR lands, we will switch our internal implementation to be compatible with OCaml's while maintaining the same public API. Finally you are completely correct regarding documentation generation. Unfortunately refmt does not currently support outputting OCaml mli files including comments. This left me with the choice of hand rolling docs as I did or shipping ocamldocs lacking any comments explaining the types and functions. I chose the former. Thanks for your feedback.