7 ms·

I'm very excited about this because it means ReasonML will be able to take advantage of multi cores for server apps :)

by thegreatpeter 7y ago

rienbdj 7y ago
I don't understand the Reason hype when F# / Fable already offers this
- cies 7y ago
  As an outsider. F# seems not to get the full blessing. ReasonML is a big thing at Facebook. F# kind of keeps you on the Microsoft stack. Reason has both OCaml based native and JS based interpreted. Reason integrates very well with JS-land. React bindings are maintained by FB itself. Bit-by-bit transitions from JS to Reason are feasible. Fable, I had to take a look again, but it seems a lot more mature then I remember it was a few years back.
  - pjmlp 7y ago
    To be honest, ReasonML doesn't seem to have not even half of the community than F# has, nor the IDE tooling for that matter.
    - bananabreakfast 7y ago
      Reason is new. F# is not
      - pjmlp 7y ago
        It thought it was supposed to be a big thing.
        yawaramin 7y ago
        I don't know why someone would think that, Reason is actually pretty niche ;-) Of course, I would love to see it go mainstream, but realistically speaking that will need to happen slowly.
  - akra 7y ago
    Would say that keeping you on the Microsoft Stack vs the ReasonML/OCAml stack would be more often an asset than a liability especially for most corporations? The .NET Core stack has a better story than OCAml in terms of popularity, library ecosystem, tooling (VS Code/Rider/VS), technology/cross-platform support and general adoption from what I can see. Fable these days is not too bad either from the guide I recently saw online in building applications with it although haven't tried it myself (https://zaid-ajaj.github.io/the-elmish-book/#/ https://zaid-ajaj.github.io/the-elmish-book/#/).
  - tluyben2 7y ago
    Companies (like banks, enterprises) still often demand, especially for backends, specific language/runtimes and that tech often translates to Java/JVM or C#/.NET. It is getting to be less important, but we definitely encounter it a lot still and you really can suggest there that you ship something built with ‘ReasonML’ (what is a ‘reasonmul?’) (or ocaml); F#/Scala/Clojure you can get away with especially if you ship closed source (which is still also quite normal in those environments).
    - yawaramin 7y ago
      From what I've heard a lot of specialized finance applications run OCaml/Haskell/etc. because of the extreme need for safe and reliable code while also preserving performance.
      - tluyben2 7y ago
        I think 'a lot' is maybe a bit an exaggeration; also, besides maybe Jane Street, it is usually only a small portion of the IT department. But I love to hear more as I am in finance (only encountering Java/.NET basically).
        yawaramin 7y ago
        Well for example, one of the most interesting applications of OCaml in finance (well, fintech) is implemented in OCaml and open source: https://gitlab.com/tezos/tezos https://gitlab.com/tezos/tezos Then there's Bloomberg: https://ocaml.org/learn/companies.html https://ocaml.org/learn/companies.html > Bloomberg employs OCaml in a advanced financial derivatives risk management application Press release from Bloomberg announcing BuckleScript: https://www.bloomberg.com/company/press/open-source-at-bloomberg-introducing-bucklescript/ https://www.bloomberg.com/company/press/open-source-at-bloom... > We are not currently using BuckleScript on the Terminal, but stay tuned… This seems to suggest that they were looking at programming Bloomberg terminal applications in BuckleScript, compiled to JavaScript, at least at one point. There's also LexiFi: https://www.quora.com/Is-the-OCaml-language-used-in-quantitative-finance-What-are-the-applications https://www.quora.com/Is-the-OCaml-language-used-in-quantita... I think if you go looking, it's not hard to find OCaml in finance in certain niches.
  - abhijat 7y ago
    I looked at the FAQ recently and it says for server side one should compile to JS rather than compiling to native: https://reasonml.github.io/docs/en/faq https://reasonml.github.io/docs/en/faq My main interest in reasonml was writing native code. Looks like it will take some time to get to the same level as the JS backend?
    - yawaramin 7y ago
      Yes, it will, especially in terms of ecosystem and integrations with various other technologies in your stack. But in the meantime I would recommend experimenting with it just because when you hit the sweet spot, it can be very productive. One option is a framework I'm working on: https://github.com/yawaramin/re-web/ https://github.com/yawaramin/re-web/
- wtetzner 7y ago
  F# is not the same thing. It's missing some of the best features of OCaml, e.g. the module system. And no, the object stuff they put into it is not a suitable replacement.
  - dfgdghdf 7y ago
    Happy Fable user here. I think it´s easy to find some feature of a language (such as modules) and claim that every language without it is not viable. You could make the same claim about OCaml not having some of F#s best features, such as operator overloading, inline and computation expressions. But this misses the point. If you´re writing a functional-first web application, then the F# solution and the ReasonML solutions are going to look very similar. Regarding server run-times and Microsoft lock-in, this is no longer an issue. DotNET Core is open-source and cross-platform. You can also use Fable to compile F# code for Node.
    - wtetzner 7y ago
      I'm not claiming F# is not viable without the module system, I'm saying F# is not a drop-in replacement for OCaml. There are good reasons people might prefer OCaml. I that that's a reasonable response to this comment: > I don't understand the Reason hype when F# / Fable already offers this My only point is that there are good reasons people would prefer ReasonML/OCaml over F#. I never claimed there were no reasons other people might prefer F#.
    - pritambaral 7y ago
      > DotNET Core is open-source and cross-platform. The only open-source debugger available for .Net Core is a poorly implemented hack by Samsung, because the vendor-provided debugger was never open-sourced. https://blog.lextudio.com/the-rough-history-of-net-core-debuggers-b9fb206dc4aa?gi=b0c48bb0002c https://blog.lextudio.com/the-rough-history-of-net-core-debu...
- deleted 7y ago
  [deleted]
xfer 7y ago
WHat do you mean by reasonml for server apps? If you mean running js(output of bucklescript) then no it will likely not benefit node users.
- anuragsoni 7y ago
  ReasonML can target native platforms transparently by using the OCaml compiler toolchain. dune (OCaml build tool) supports ReasonML out of the box.
- vijaybritto 7y ago
  Checkout reason-native. It directly compiles to native.
- cies 7y ago
  You can compile to native and use the whole OCaml ecosystem over there (in stead of the NPM ecosystem when doing client-side or Node-based-server-side) to write your apps. For instance this fast OCaml http server: https://github.com/inhabitedtype/httpaf https://github.com/inhabitedtype/httpaf And you can even share types between client and server :)
  - xfer 7y ago
    What's the point of using a different syntax if you are going to be interacting,reading,fixing code in ocaml syntax?
    - lilactown 7y ago
      ReasonML is just a different syntax that compiles to the OCaml AST format. If you're writing in ReasonML you'll be interacting, reading and fixing code in ReasonML. There's even a browser extension which converts OCaml syntax to ReasonML and vice versa in docs.
      - tluyben2 7y ago
        I was going to ask; I read some discussions on r/reasonml and seems some people prefer the ocaml symtax and some the reason syntax, but both can compile on both on both sides as far as I understood.

I'm very excited about this because it means ReasonML will be able to take advantage of multi cores for server apps :)

rienbdj 7y ago

I don't understand the Reason hype when F# / Fable already offers this

cies 7y ago
As an outsider. F# seems not to get the full blessing. ReasonML is a big thing at Facebook. F# kind of keeps you on the Microsoft stack. Reason has both OCaml based native and JS based interpreted. Reason integrates very well with JS-land. React bindings are maintained by FB itself. Bit-by-bit transitions from JS to Reason are feasible. Fable, I had to take a look again, but it seems a lot more mature then I remember it was a few years back.
- pjmlp 7y ago
  To be honest, ReasonML doesn't seem to have not even half of the community than F# has, nor the IDE tooling for that matter.
  - bananabreakfast 7y ago
    Reason is new. F# is not
    - pjmlp 7y ago
      It thought it was supposed to be a big thing.
      - yawaramin 7y ago
        I don't know why someone would think that, Reason is actually pretty niche ;-) Of course, I would love to see it go mainstream, but realistically speaking that will need to happen slowly.
- akra 7y ago
  Would say that keeping you on the Microsoft Stack vs the ReasonML/OCAml stack would be more often an asset than a liability especially for most corporations? The .NET Core stack has a better story than OCAml in terms of popularity, library ecosystem, tooling (VS Code/Rider/VS), technology/cross-platform support and general adoption from what I can see. Fable these days is not too bad either from the guide I recently saw online in building applications with it although haven't tried it myself (https://zaid-ajaj.github.io/the-elmish-book/#/ https://zaid-ajaj.github.io/the-elmish-book/#/).
- tluyben2 7y ago
  Companies (like banks, enterprises) still often demand, especially for backends, specific language/runtimes and that tech often translates to Java/JVM or C#/.NET. It is getting to be less important, but we definitely encounter it a lot still and you really can suggest there that you ship something built with ‘ReasonML’ (what is a ‘reasonmul?’) (or ocaml); F#/Scala/Clojure you can get away with especially if you ship closed source (which is still also quite normal in those environments).
  - yawaramin 7y ago
    From what I've heard a lot of specialized finance applications run OCaml/Haskell/etc. because of the extreme need for safe and reliable code while also preserving performance.
    - tluyben2 7y ago
      I think 'a lot' is maybe a bit an exaggeration; also, besides maybe Jane Street, it is usually only a small portion of the IT department. But I love to hear more as I am in finance (only encountering Java/.NET basically).
      - yawaramin 7y ago
        Well for example, one of the most interesting applications of OCaml in finance (well, fintech) is implemented in OCaml and open source: https://gitlab.com/tezos/tezos https://gitlab.com/tezos/tezos Then there's Bloomberg: https://ocaml.org/learn/companies.html https://ocaml.org/learn/companies.html > Bloomberg employs OCaml in a advanced financial derivatives risk management application Press release from Bloomberg announcing BuckleScript: https://www.bloomberg.com/company/press/open-source-at-bloomberg-introducing-bucklescript/ https://www.bloomberg.com/company/press/open-source-at-bloom... > We are not currently using BuckleScript on the Terminal, but stay tuned… This seems to suggest that they were looking at programming Bloomberg terminal applications in BuckleScript, compiled to JavaScript, at least at one point. There's also LexiFi: https://www.quora.com/Is-the-OCaml-language-used-in-quantitative-finance-What-are-the-applications https://www.quora.com/Is-the-OCaml-language-used-in-quantita... I think if you go looking, it's not hard to find OCaml in finance in certain niches.
- abhijat 7y ago
  I looked at the FAQ recently and it says for server side one should compile to JS rather than compiling to native: https://reasonml.github.io/docs/en/faq https://reasonml.github.io/docs/en/faq My main interest in reasonml was writing native code. Looks like it will take some time to get to the same level as the JS backend?
  - yawaramin 7y ago
    Yes, it will, especially in terms of ecosystem and integrations with various other technologies in your stack. But in the meantime I would recommend experimenting with it just because when you hit the sweet spot, it can be very productive. One option is a framework I'm working on: https://github.com/yawaramin/re-web/ https://github.com/yawaramin/re-web/
wtetzner 7y ago
F# is not the same thing. It's missing some of the best features of OCaml, e.g. the module system. And no, the object stuff they put into it is not a suitable replacement.
- dfgdghdf 7y ago
  Happy Fable user here. I think it´s easy to find some feature of a language (such as modules) and claim that every language without it is not viable. You could make the same claim about OCaml not having some of F#s best features, such as operator overloading, inline and computation expressions. But this misses the point. If you´re writing a functional-first web application, then the F# solution and the ReasonML solutions are going to look very similar. Regarding server run-times and Microsoft lock-in, this is no longer an issue. DotNET Core is open-source and cross-platform. You can also use Fable to compile F# code for Node.
  - wtetzner 7y ago
    I'm not claiming F# is not viable without the module system, I'm saying F# is not a drop-in replacement for OCaml. There are good reasons people might prefer OCaml. I that that's a reasonable response to this comment: > I don't understand the Reason hype when F# / Fable already offers this My only point is that there are good reasons people would prefer ReasonML/OCaml over F#. I never claimed there were no reasons other people might prefer F#.
  - pritambaral 7y ago
    > DotNET Core is open-source and cross-platform. The only open-source debugger available for .Net Core is a poorly implemented hack by Samsung, because the vendor-provided debugger was never open-sourced. https://blog.lextudio.com/the-rough-history-of-net-core-debuggers-b9fb206dc4aa?gi=b0c48bb0002c https://blog.lextudio.com/the-rough-history-of-net-core-debu...
deleted 7y ago
[deleted]

xfer 7y ago

WHat do you mean by reasonml for server apps? If you mean running js(output of bucklescript) then no it will likely not benefit node users.

anuragsoni 7y ago
ReasonML can target native platforms transparently by using the OCaml compiler toolchain. dune (OCaml build tool) supports ReasonML out of the box.
vijaybritto 7y ago
Checkout reason-native. It directly compiles to native.
cies 7y ago
You can compile to native and use the whole OCaml ecosystem over there (in stead of the NPM ecosystem when doing client-side or Node-based-server-side) to write your apps. For instance this fast OCaml http server: https://github.com/inhabitedtype/httpaf https://github.com/inhabitedtype/httpaf And you can even share types between client and server :)
- xfer 7y ago
  What's the point of using a different syntax if you are going to be interacting,reading,fixing code in ocaml syntax?
  - lilactown 7y ago
    ReasonML is just a different syntax that compiles to the OCaml AST format. If you're writing in ReasonML you'll be interacting, reading and fixing code in ReasonML. There's even a browser extension which converts OCaml syntax to ReasonML and vice versa in docs.
    - tluyben2 7y ago
      I was going to ask; I read some discussions on r/reasonml and seems some people prefer the ocaml symtax and some the reason syntax, but both can compile on both on both sides as far as I understood.