Restack: Full-Stack ReasonML | Hacker News Reader

Restack: Full-Stack ReasonML

github.com

141 pointsingve36 comments

I was very interested in reasonml and had high hopes it would gain a lot of traction, but for an outsider, there doesn't seem to be a lot of activity on reasonml itself, the last release is from 18 months ago and if I'm not mistaken, there's no public repo of reasonml itself. Despite this you see projects like onivim 2 and esy using it, making me wonder if I'm missing something. Anyone here knowing what the state of reasonml development is?

ReasonML is just the language syntax so once it has reached reasonable stability, there won’t be as much development. Most activities happen in BuckleScript compiler (OCaml to JS) and there have been a lot of substantial releases in the last 6 months. https://bucklescript.github.io/blog/

After the last release, there was some talk about async syntax. Is that abandoned? Is it really so that the reasonml language is considered basically done now?

This is the PR to follow: https://github.com/facebook/reason/pull/2487

Plans for this feature morphed into support for OCaml's new programmable let binding syntax. With the PR above merged, you'll be able to write code such as

    let.async users = getUsers();

I originally thought this seemed unnecessary, but I'm using a variant of this already, and it's so much better. And I love that Reason's approach is extensible as well!

So reason is like coffeescript for ocaml.

More like Elixir for OCaml perhaps?

It makes the good stuff in OCaml more readily available to developers with different expectations such as syntax (JS) and package management (npm).

Kinda, but with less hassle. You don't need to output ocaml files as both the native build tool (dune) and the js compiler (Bucklescript) support it out of the box.

More like ratfor, but this time with less raison d'être.

Reason language development is happening at https://github.com/facebook/reason/

Like huy-nguyen said, this is a tooling & ecosystem effort on top of OCaml ecosystem, and the language syntax is a small part of the effort. It's a bit scattered, but apart from ReasonReact, there is also https://reason-native.com/ and Esy that are parts of this bigger picture.

Both OCaml and Reason communities are also quite active in producing tooling and libraries, I'd suggest following the relevant forums. I believe Reason's development momentum is not centralized around a core Reason repo/org and a team.

The ReasonML ecosystem is evolving at a fast pace and finding adoption in the most unlikely of places (Most recently a team inside SAP for some of their front-end).

However, one of the better things about Reason for me is that it is based on OCaml, which has been a rock-solid language for more than two decades. Its pace of evolution is quite measured - for example the algebraic effects work that has been happening is based on a formal academic foundation, and the implementation is often lead by researchers who wrote the actual papers.

The biggest issue I can imagine when a company adopts Reason is availability of bindings to Javascript libraries. In practice this has not been much an issue for me - once you get grips with the way bindings are done in BuckleScript, creating a binding is just another thing to do.

The other issue is significant upfront learning cost for the Typed functional paradigm. But it is the kind of fundamental learning that pays dividend for a long time, quite unlike learning libraries or frameworks that simply keep coming and going.

I find that Reason and Elm does solve for this constant library/framework trivia-treadmill of the Javascript ecosystem admirably, helping teams achieve enough technical expertise so they can effectively create most of the building blocks they need by themselves.

Yes, the have their blogging somehow spread across the sub projects.

But it seems it's catching up to TypeScript and left all its competitors behind. https://2019.stateofjs.com/javascript-flavors/

I'm not sure how you missed it, but right from the main Reason web page(https://reasonml.github.io/) there is a link to the Github repo for one of the ReasonML syntax (https://github.com/facebook/reason) which has a link to the latest Release on npm which was four months ago. Where did you get the 18 months figure? (You might have stumbled upon some old docs). There is also an important PR in progress for async syntax extension, which will form the next release.

That Reason repo is just for the parser which is only one of the many pieces of infrastructure under the Reason umbrella (an important one though). Also follow BuckleScript, and esy for example.

I think that may have been from https://github.com/facebook/reason/releases

Reason/OCaml is truly a secret weapon, beating the averages and all. The reach this language has is incredible. Whether you work on React UIs, REST/GraphQL servers, desktop apps, Unix systems programming, or even unikernels, it never feels like the wrong tool for the job and is always fun all the way through.

It’s nice, but not that nice. The type system is primitive compared to modern alternatives and the use of functors for generics is clumsy. Also multicore still isn’t a thing, despite it being just around the corner for years. If the type system was as powerful as, say, Scala and multicore worked OCaml would be my go-to language. But at this point, I think F# would be a better choice for new projects. And you also get to use Akka.net with it, which could be a major value add.

I see functional languages with primitive type systems a pro not a con.

We need simple languages like ReasonML more than something like Scala or Haskell if they are to be embraced more widely.

Luckily, the only big competitor Reason has to mess with at the moment is TypeScript.

Why is that? Because they both are among the only choices targeting enough platforms to be considered suitable for full-stack development?

See https://2019.stateofjs.com/javascript-flavors/

If by "generics", you are referring to the sort of parametric polymorphism that you have in .NET and Java, then no, you don't use functors for that.

    # let foo x = x;;
    val foo : 'a -> 'a

You need to use functors if you want higher-kinding, but they're generally useful beyond that, and I wish more typed languages had an SML style module system. F# doesn't have one, and has always had a punier type system.

No offense but it's hard to take you seriously when you call OCaml type system primitive.

Also OCaml obviously has generics independently of functors. Polymorphic functions and types are literally everywhere.

What do you mean the type system is primitive? Compared to what?

OCaml was my first serious language, and while I think it's a bit weak for "programming in the large" (cumbersome types, typeclasses, lack of type annotations sometimes hurts) I'm still incredibly fond of it. Unfortunately, I haven't had much experience using it recently, as most of my work is in Python / Scala etc.

I'm assuming you're a current, up-to-date user, so I'd like to ask you:

- what are the current reasonable options for a StdLib? Last I checked, the default lib was still very poor, while JaneStreet's I found barely documented.

- Multicore I guess I can forgive, it's not like there are any other modern GC languages that make multi-threading particularly easy (with the possible exception of Java).

- What's an example of a recent codebase written in "modern" OCaml / Reason?

I've been writing a lot for Reason and OCaml last few years, but the majority of it target BuckleScript and React. My front-end bias alone means it's a better stack than any other alternatives mentioned in this thread (and I even find it more productive than TypeScript), so take it with a grain of salt.

I do use ocaml-graphql-server and such a lot to write small services, but I often don't interact with databases or build complex backends that would require a bigger back-end webdev ecosystem. Most of my native development happens far from the cloud, and mostly around CLI and GUI tools for which I adore OCaml and recently Reason (https://github.com/revery-ui/revery).

> cumbersome types, typeclasses, lack of type annotations sometimes hurts

I've grown to really like the explicitness of OCaml actually. Nothing implicit or circular, and I can just read a module from top to bottom. The lack of type annotations don't bother me as much with tools such as Merlin, and I find that the amazing type inference lets me prototype code as fast as dynamic languages.

> - what are the current reasonable options for a StdLib? Last I checked, the default lib was still very poor, while JaneStreet's I found barely documented.

I use Containers (https://github.com/c-cube/ocaml-containers/), Lwt, and a few other small libraries like Rresult and Bos pretty heavily. For a big application with many contributors I'd still suggest giving Core another try as it's very well thought out and extensive (compared to npm-style dozens of dependencies you need to introduce with different API designs). I must say that even though I'm pretty used to reading type signatures and jumping to interface files for documentation (and even prefer it to tutorial style docs in markdown), and wouldn't say Core's documentation is _poor_, I agree with you at some level. Because of how it's built and split up across different packages and modules, it gets pretty tiring having to power through many levels of indirection every time you want to look something up.

> - Multicore I guess I can forgive, it's not like there are any other modern GC languages that make multi-threading particularly easy (with the possible exception of Java).

I find that, compared to some other languages I've used, my naive and readable implementation in OCaml last much longer before I need to optimize it. I do use Lwt_preemptive threads that call C code and subprocesses often, but usually because of the nature of the problem I'm solving and not as a parallelization technique.

> - What's an example of a recent codebase written in "modern" OCaml / Reason?

Most open source projects I can think of are libraries and tools such as compilers, but here are some real-world applications off the top of my head:

- https://github.com/onivim/oni2 (native, desktop)

- https://github.com/SVdotCO/pupilfirst (bucklescript, react)

- https://github.com/Schniz/fnm (native, CLI)

Some of the cool stuff I saw in the wild:

https://github.com/osener?language=reason&tab=stars

https://github.com/osener?language=ocaml&tab=stars

Hope this helps! I think with the recent convergence around tools such as dune, opam, esy, it is a great time to start writing OCaml again.

Here is a non-trivial production web application (a learning management system) that runs Rails on the back-end, GraphQL for network communication, and Reason on the front-end: https://github.com/svdotCO/pupilfirst

> it's not like there are any other modern GC languages that make multi-threading particularly easy (with the possible exception of Java).

Go is another exception, goroutines are a core part of the design.

BEAM languages too.

Multicore will eventually come, however in the age of Spectre and Meltdown, alongside in-process exploits and browsers going into multi-processes for security and stability reasons, I don't find that bad about multi-process usage.

And there is always Lwt as well.

Regarding your mention of Java, count .NET and Erlang there as well.

> Multicore I guess I can forgive, it's not like there are any other modern GC languages that make multi-threading particularly easy (with the possible exception of Java)

Couldn't agree more, Scala with Monix/cats-effect/fs2 excels at writing highly efficient parallel and concurrent programs

> I think it's a bit weak for "programming in the large"

Really have to disagree with this one, for programming in the large the best tool you have is modularization, and OCaml's module implementation is second to none.

> (cumbersome types,

This is usually an indication of trying to program OCaml 'like Haskell' or some other language, instead of learning the OCaml way.

> typeclasses,

Matter of opinion but I honestly think not having return-type polymorphism, and having a slightly more explicit model, actually works in OCaml's favour–faster compile times, more explicit type errors, less 'magical-looking' code that's easier to follow.

> lack of type annotations sometimes hurts)

Sometimes–but the idiom is very much to put type annotations in separate interface files, which I think is the best of both worlds–implementations look clutter-free and almost dynamic; and interfaces are explicitly typed and documented.

> Last I checked, the default lib was still very poor,

I encourage checking again, the default standard library has received a lot of updates. Of course there may be a difference of philosophy here, the OCaml standard library is not Go-style. In other words, it's not going to ship a JSON decoder and an HTTP server. But very high-quality packages are available on OPAM nowadays so IMHO this is not really a big deal.

> Multicore I guess I can forgive,

OK, great! ;-)

> What's an example of a recent codebase written in "modern" OCaml / Reason?

Well I'm working on an OCaml/Reason web framework written in a pretty modern OCaml style: https://github.com/yawaramin/re-web

> it's not like there are any other modern GC languages that make multi-threading particularly easy

Where does golang fit, in this picture?

I forgot about Go. They actually did some really great work on their GC! Plus decent support for lightweight & actual threads. I just so strongly dislike the language itself (mainly because of the poor type system) that I must have suppressed it :)

Unikernels... is that what they mean by “full stack”! I thought it would be just JS and some kinda web server.

'Fullstack' seems to mean something different to different people. In some sense it's valid to call a kernel-to-frontend stack fullstack. In another sense it's valid to call just a webserver-to-frontend fullstack. Depends :-)

It's worth noting that although OCaml give you the very cool option of deployment with unikernels, it's perfectly possible (and more straightforward) use regular binaries or containerised binaries instead.

Reply on news.ycombinator.com