chenglou

Fwiw OCaml is a GC language and can run on PIC: http://www.algo-prog.info/ocapic/web/index.php?id=ocapic

Not that I'm aware of. Though it'll be a shame if React is a one-off. Can't comment on the rest.

Nah I'm the Reason janitor. I declined joining the Reason team because I thought joining messenger was a better way to help Reason move in directions products folk understood; it paid off =)

Anyways, since I'm basically doing Reason 24/7 I kinda consider myself to be on the team.

Btw Bloomberg kindly donated the BuckleScript project. It's now under its own independent organization on Github.

Honestly I believe modeling such thing in JS as an initial iteration would have drastically changed what ReactJS is today, and likely for the worse. No proof of that, aside from the fact that iterating it in SML gave the rather paradigm-shifting ReactJS we know today.

Can't speak for Jordan but I'm guessing that the answer is "it just felt right". So you can consider ReactJS as a manual program extraction from SML.

I'm not sure whether the original one was ever fully finished. I think there was a blocker from the React reconciler that SML couldn't solve in its type system? It needed GADT and existential, which is why he moved onto OCaml. Related: https://drup.github.io/2016/08/02/difflists/

So in a sense, we knew for a while now that ML would work out, somewhat demonstrated by the real-world usage of React. The technical merits are there; the social ones, definitely not. Thus Reason, which you can view as ReactJS finally going back to its root through ReasonReact, and with the social aspect properly being worked on.

Thanks for the support. It's hard though, isn't it? We get the same arguments on a weekly basis. Folks categorically refuse to check out OCaml because of its syntax. At one point the Reason creator decided to just go and satisfy the familiarity aspect through syntax change (still ongoing; the above snippet will get better too).

It scales easier to settle the debate by just fulfilling the demand rather than encountering each such argument and spend literally years debating about them.

Hey! It's weird: it's not the first time we get questions like yours and I'm not sure where such confusion comes from! Reason and React are two things. Reason's a syntax on top of OCaml, the programming language. ReactJS' a UI library. Messenger.com _is_ written in React, lots of which are, specifically, in ReasonReact, which is Reason bindings for ReactJS (the rest, plain ReactJS).

Reason's open-source, as well as ReasonReact(https://github.com/reasonml/reason-react). Using BuckleScript the OCaml-to-JS compiler, we compile to normal JS code with minimal runtime.

Here's why we made it: https://reasonml.github.io/guide/what-and-why

That section's still in JS

You (and I) are definitely in the minority here. "Go back and do a computer science degree" is probably the opposite wish of lots of software engineers, in terms of quantity.

From what I know, there are at least three classes in some universities (forgot the names) whose professors/TAs told me they were teaching Reason to decent success. Reason's also used in this users study: https://arxiv.org/pdf/1708.07583.pdf. Reason removes the unfamiliarity part in order for them to get to the core of the research, which is still done in OCaml.

Don't lose hope! =)

You're reading the wrong blog post btw; this is about messenger.com adoption.

Happy to discuss that other blog post somewhere else (discord.gg/reasonml)

Pretty much. The goal of Reason is to make some weighted compromises* in order to allow folks (like you?) to have an easier time convincing your colleagues that OCaml's a good bet, disregarding their past experiences with similar languages. For example, being scarred by FP assignments back from university is one of the top feedbacks. If we show that ReasonReact allows folks to write apps just the same, plus a familiar syntax that makes the first tries easier, then you yourself can skip over all these bikesheddings and help your colleagues further.

* Having a different syntax isn't without cost for the existing OCaml community, but so far most have been very supportive

We do contribute to upstream, and we've even hired a few renown OCamlers (can't say more atm, sorry). As a matter of fact I've kept a list of Reason's contributions, PRs or otherwise. I'll publish it in due time.

It's not the Reason sections; if you've seen BuckleScript's output you'd know that the JS artifacts are almost like hand-written code. I've checked almost every diff.

Not sure how much I can say, but the leak is somewhere in the subscriptions, which isn't in Reason. Ironically the goal is to convert that section to Reason so that refactoring can finally be done (I've left that part out of the blog post just in case). Messenger produced the grandfather of Flux; it's not the easiest thing to refactor.

Hello! Reason team member here.

With that kind of exposure comes some pretty negative snarks & unrelated criticisms that are hard to counter in a post/tweet. I've left a few replies on this thread but I'll still try my best to answer the questions here =) (but before that, please do give https://reasonml.github.io/guide/what-and-why a look).

Right. Though the Ads thing the post mentions uses Reason natively (aka ocamlopt). Not on the server, but as a tool for the front end.

Ocaml's two decades old. We're doing the very opposite of inventing a new language. I'm on the team and I personally am not capable of creating a language (not to mention recreate an entire ecosystem?) at the same level as OCaml.

Yes, the first prototype of React was written in SML; we then moved onto OCaml.

Jordan transcribed the prototype into JS for adoption; the SML version of React, however great it might be, would have died in obscurity. The Reason project's biggest goal is to show that OCaml is actually a viable, incremental and familiar-looking choice. We've been promoting this a lot but I guess one blog post and testimonial helps way more.

There's inevitably gonna be a bit of doubt at the viability of Reason at first; but to make an argument from authority: Jordan and the team made ReactJS take off even though everyone hated it at first (browse the first HN/Reddit threads; they weren't rosy). I was there to witness it too. I'd like to say we're rather experienced at handling the social aspect required to make such project take off potentially, at least. Technically speaking, deferring to OCaml is a safe bet.

What it means for Elm/ClojureScript: https://reasonml.github.io/guide/what-and-why#dont-like-reas...

We've explicitly listed Elm & ClojureScript on our Why page as good alternatives to check. I've personally used both. The world is big enough for more of such languages.

The transition will be seamless and already planned, no worries.

Btw, for more justification on the syntax change, I've written a short answer here: https://www.reddit.com/r/reasonml/comments/6v2olv/new_syntax...

It's unrelated. We're trying to track it down still. Sorry about that

I'm constantly surprised how most people settle with single-line autocompletion (or no autocompletion) in the shell. _The_ plugin that helped me learn shell and be super productive is Auto-fu: https://github.com/HerringtonDarkholme/auto-fu.zsh (forked from https://github.com/hchbaw/auto-fu.zsh)

BAM, autocomplete menu in your shell.

The setup isn't straightforward; I've written a small guide here: https://gist.github.com/chenglou/03505022bc4598fcb80e523f868...

I struggled with git when I first used it. But when you have an autocomplete menu giving you the right commands and sub-commands at each turn it's pretty hard _not_ to learn git (the default porcelain anyway).

Seriously, why am I defending a good autocomplete in the shell, go try it =)

Yeah. Some existing algorithms are more easily expressed with mutability, and for FFI it's very needed; I think some community-wide messaging regarding this is good enough. Constraining them at the type level might make adoption a bit harder.

We're just a syntax for OCaml; we don't change how it runs. Same GC. Reason's mMuch less sophisticated than you think, but also much fewer unknowns. https://reasonml.github.io/try/

The goal of Reason (and of BuckleScript) is so that people can convince their coworkers that OCaml isn't an esoteric unmaintainable language. BuckleScript is JavaScript: The Good Parts: The Good Parts.

1. I feel like I shouldn't feel ashamed when saying this, but here: mutation, imperative code & side-effect are kinda nice, and very much needed for a straightforward interop with e.g. existing JS/Obj-C/Java (hint hint) code. For example, notice how BS externals are erased & inlined. Most of our ffi doesn't have a conversion cost. An excellent ffi can be a deal maker, considering that if you're serious about migrating your codebase to a new language, you'd be using more ffi than idiomatic code for a while. Early on, I've had folks accidentally modify the output JS artifacts on messenger.com because they thought I wrote the JS code myself; they were generated by BS.

2. Also, speaking of native compilation: we're not reference counting but _some_ predictability when working with UI code is needed. The GC has to be fast and collect things within 16ms (and now, 8ms since iPad Pro is often 120fps). The ocaml gc achieves that.

Those aren't my findings: those are the findings of the creator of React, who also created Reason.

3. Finally, and to corroborate with what we wrote on that page: if you go ask your "normal JS colleagues", you'll realize most folks don't _actually_ know the semantics of JS. They like JS because it _looks_ familiar. Is TypeScript "just JavaScript"? Does it matter if JS folks can pick it up and be equally productive quickly? OCaml/BS semantics map over to JS well enough that we can just change the syntax into something familiar, and you'd likey end up writing the code you'd usually write in JS, albeit backed by a type system that needs to make no excuse in terms of quality.

Hope that helps? Tell me if that makes sense.

(Tail recursion has been a problem for a single person so far afaik; you do have imperative loops)

BS full rebuild for a project with 300 takes around 3s. Incremental per-file compilation is below three digits of ms.

Adjusting the perception that switching to OCaml is bumpier is exactly why we've made/partnered with BuckleScript on Reason: https://reasonml.github.io/guide/what-and-why

If you have some time, please give that intro page a read. Hopefully that intro page explains what we're achieving. If you'd like more nuanced opinions, we're always in Discord (discord.gg/reasonml).

Hope to see you around =)

Worth noting that ReasonReact is made by the same person who made React. The whole Reason effort is, actually.

I personally work on it too and have been using it on messenger.com

Saving water or such is a mentality and you might not be able to measure it through a simple people * saving/person. If everyone's wasteful there'd be way less incentive to nudge industries into changing. Where would the change be coming from?

More philosophically speaking, if there's an equation of life with all the variables and we apply it here by taking all the "saved effort thanks to not promoting water consciousness in regular households" and dumping it into whichever area we'd think is ideally efficient, it wouldn't be _too_ surprising if holistically, the result comes out less favorable of this approach vs just telling regular folks to save water. For example, consider that it might take tenfold the effort to convince an agricultural company CEO to change approach; if ninefold the effort doesn't reach the activation energy to convince such person then you're better off telling nine people to stop the waste.

In general, I have the feeling that many decisions can wrongly be made to look stupid if we recalculate it using the select few variables we care about.

Tup is pretty darn amazing. I've never had such a high success rate while writing build rules under it. "Once it builds, it has no bug". Not to mention the great speed to begin with.

Is there any similar build system? I know of https://github.com/droundy/fac, but it's not cross-platform

Late reply, but we have such guide here: https://reasonml.github.io/guide/javascript/converting

You can also check the community's work: https://reasonml.github.io/community/

Fwiw, OCaml algebraic effects are being implemented: http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multico...

(And then there's https://reasonml.github.io, which I work on)

And imo much better implemented! I use both the Google keyboard and the default; Google's cursor swiping is one dimensional. Swipe back and forth to move around a line. The default one is two dimensional. You can swipe through columns too!