
Reason 3 - bpierre
https://reasonml.github.io/community/blog/#reason-3
======
myth_drannon
"Messenger used to receive bugs reports on a daily basis; since the
introduction of Reason, there have been a total of 10 bugs (that's during the
whole year, not per week)!"

That's truly amazing.

Interesting how Elm is inspiring other frameworks and languages. First Redux
and now Reason's error messages.

~~~
brandonbloom
I'm not saying that Reason doesn't deserve some of the credit, but surely some
of this must be attributable to relative maturity of Messenger. Right?

~~~
chenglou
(Hey Brandon!)

The JS part of messenger.com bugs a lot more.

------
jordwest
Just want to say I'm really excited about Bucklescript and the collaboration
with Reason.

I started using the Reason syntax, but soon ended up migrating my project to
vanilla OCaml as I found the syntax less JavaScript-like and easier to follow
when thinking functionally vs imperatively. Also, there are many more
tutorials out there (currently) for OCaml than there are for the Reason
syntax.

As I understand it the two syntaxes are pretty much interchangeable, both use
the same underlying AST, the same compile-to-JS backend (Bucklescript) and can
even be auto-converted using `refmt`.

Also, if it's important to you, only the Reason project seems to still be
encumbered by Facebook's patent grant, while the Bucklescript project was
originally started by Bloomberg and now seems to be an independent project
without the additional patent clause.

Both projects are really exciting as a practical way to bring type safety into
the browser, with ridiculously fast compile times and tiny bundles.

~~~
rlp
For learning Reason, I found this page invaluable:
[https://reasonml.github.io/try](https://reasonml.github.io/try)

You can put in Reason or OCaml and it will spit out the other. I used it to
work through Real World OCaml in Reason.

------
GreaterFool
Why oh why the brackets? Obfuscates currying too much.

    
    
        let make ::message ::extraGreeting=? _children => ...
        let make = (~message, ~extraGreeting=?, _children) => ...
    

Plain OCaml:

    
    
        let make ~message ?extraGreeting _children = ...
    

Fortunately bucklescript is a completely separate project. After this change I
might ditch Reason and just write OCaml. There were some little improvements
with Reason vs OCaml but now OCaml appears to be a clear winner!

~~~
chenglou
I've given an answer to currying at
[https://news.ycombinator.com/item?id=15573956](https://news.ycombinator.com/item?id=15573956)

BuckleScript's author and I collaborate on a daily basis, btw. So you're
definitely welcome to use _just_ BuckleScript. I'm not too sure your reaction
is genuine happiness for vanilla OCaml, but if it really is, then our
mission's accomplished ([https://reasonml.github.io/guide/what-and-why#why-
reason](https://reasonml.github.io/guide/what-and-why#why-reason)). If not,
sorry about that.

------
lf-non
Has someone done a comparision of Reason+Bucklescript with Fable[1] ?

F# has embraced the OCaml syntax while at the same time cleaning out many of
the warts (+., do end etc.). It also now has good tooling available on all
platforms.

Despite being a full time javascript/typescript developer I find F# syntax
much more appealing and easy to grok than Reason's js inspired syntax.

[1] [http://fable.io](http://fable.io)

~~~
wtetzner
> F# has embraced the OCaml syntax while at the same time cleaning out many of
> the warts (+., do end etc.). It also now has good tooling available on all
> platforms.

Unfortunately, it also drops my favorite thing about OCaml, which is the
module system.

I also like that there are different operators for ints and floats. It makes
it very clear when you've accidentally mixed the two.

~~~
xfer
You can't accidentally mix floats and ints, it's a typed language.

~~~
wtetzner
It's typed, but the types can be fully inferred. If you didn't specify the
types of your function, it could end up being inferred as float -> float ->
float instead of int -> int -> int.

The different operators are a concise way to tell the type-checker that you're
working with floats.

~~~
xfer
No it won't be inferred as float->float->float if there is an int literal or
whatever base type you pass to the function. Check typeclasses for how this
works.

------
maxpert
It's good to see languages like these showing up. Would love to code something
complicated before I have a detailed opinion. With my experience in Typescript
(another typed language claiming to make code better with some heavy React,
Angular 4 projects); more than occasionally you have to escape into JS world
(the dreaded <any> cast); thing that could have been done simpler with modern
ES6 syntax needs some heavy lifting and rope jumping.

Since it's all JS under the hood, the type system is an illusion that language
plays tricks on you. This makes it hard for people to understand how JS works
or functions; without prior knowledge. Just to quote example one of my team
mate had an interface in Typescript, and he was not able to understand why
cant he do `x instanceof Foo`. Long story short is you can't have good
"Typescript" programmer without being good JS developer. Which I believe will
be the case here too. Yes it makes auto-complete better and documents really
well; but improves code is debatable.

Don't get me wrong; I am not against it. All I am mentioning is the flip side
that nobody will mention. OCaml is really powerful and cool kids are going to
experience it with this effort, may be bring in new features/inspiration for
next ES. But IMHO just a transpiled language can give you better constructs to
express code; but it can't prevent a dumb programmer from making errors. I
will for sure give this a shot and blog about it.

~~~
yorwba
It should be possible to implement the instanceof operator for arbitrary types
using essentially the same logic as the type checker. (Caveat: I don't know
whether any TypeScript-specific properties make this impossible, since I have
never used it.)

For each object, there is some function that takes no input and returns that
object, by simply constructing the recursion-free parts of the object graph
and then filling in any cycles. (TypeScript allows mutation, right?)

Then the question of `x instanceof Foo` becomes "is the function returning x
typeable as () -> Foo". Of course that check is going to be much much more
expensive than the simple comparison of the class tag other languages use, so
I can understand why it's not part of the language.

~~~
wtetzner
The type checker has access to the source code (and any type annotations).
That information isn't available at runtime, so I'm not sure how you'd be able
to run the type checker at runtime.

~~~
yorwba
You don't need the _original_ source code, any code producing the object you
want to check will do. If the object has a field "field" with value "value",
then the code

    
    
      function () { return {field: "value"}; }
    

produces a value of type Foo precisely when the original object was of type
Foo, even if the code producing it was much more complex.

I don't see why that wouldn't work. If you have a specific example where that
approach fails, I'd like to know about it.

~~~
wtetzner
But I don't know where you'd get that source code from at runtime though? I'm
sure there are languages that contain enough runtime information, but, as an
pertinent example, there isn't a way to tell that you have an object with
certain fields in OCaml at runtime. It's just a block at runtime. All of the
names are gone, as they were only used at compile time.

~~~
yorwba
I was assuming the TypeScript/JavaScript scenario, where TypeScript objects
are implemented as JavaScript objects and their structure is available at
runtime. Of course it does not work if you do not have that reflection
capability.

~~~
lilactown
You can provide your own type guards:
[https://www.typescriptlang.org/docs/handbook/advanced-
types....](https://www.typescriptlang.org/docs/handbook/advanced-types.html)

Doing this in the general case, I assume, is probably not practical.

------
djur
Both the blog post and the release notes remark that the change to function
definition and application syntax would get a lot of attention, but neither of
them even hint at a reason for such a significant change. The PRs implementing
the change don't seem to provide a rationale, either. Does anyone have more
background as to why this change was made?

~~~
dsissitka
[https://www.reddit.com/r/reasonml/comments/6v2olv/new_syntax...](https://www.reddit.com/r/reasonml/comments/6v2olv/new_syntax_after_pr_1299/dly4aa7/)

[https://github.com/facebook/reason/pull/1299#issuecomment-32...](https://github.com/facebook/reason/pull/1299#issuecomment-323335204)

------
myegorov
Does anyone know why the React/Reason creators switched from SML to OCaml?

    
    
      Reason's creator also created ReactJS, whose first prototypes were written in SML, 
      a distant cousin of OCaml. We've transcribed ReactML into ReactJS for wide adoption.[0]
    

[0] [https://reasonml.github.io/guide/what-and-
why/](https://reasonml.github.io/guide/what-and-why/)

~~~
jordwalke
Hi, I’m the original inventor of React and I really like SML, however SML just
didn’t have a few of the escape hatches or advanced features that were needed
to implement a very usable, extensible, and type safe React interface or
implementation, so I eventually explored the OCaml type system and I found
that it has many of those missing links. One surprise was that when showing it
to fellow UI developers, I would constantly be met with confused looks and
after digging into people’s feedback, I found that most developers weren’t
seeing the same thing that I was seeing on the screen so they weren’t able to
see the ideas expressed in the code. The syntax was very commonly cited as a
major point of friction. I don’t see anything wrong with OCaml’s syntax but my
opinion alone doesn’t matter because a major goal of software is to
collaborate with other people - who matter.

To fix the problem, a couple people from various parts of Facebook got
together and started building/testing Reason together, and eventually we
shipped what is likely the largest (in terms of machines (billions)) OCaml
deployment ever via Reason React.

There’s still many pieces of OCaml beyond syntax that should be improved and
we would like to continue fixing all the blockers to adoption that we can.
Thankfully the rest of the OCaml community has the same goal and are doing
great things at deeper parts of the toolchain and compiler. Our story started
from the UI use case so our work and messaging so far has centered around it.

~~~
faitswulff
> The syntax was very commonly cited as a major point of friction. I don’t see
> anything wrong with OCaml’s syntax but my opinion alone doesn’t matter
> because a major goal of software is to collaborate with other people - who
> matter.

This is a perspective I wish was more prevalent in the programming community.

~~~
rlander
Yes! When first saw Reason I was horrified by the syntax (I really like the ML
family syntax). But then I though about it, and here's my take now: if syntax
is all we're giving up in order for OCaml to reach a far wider audience, then
we're still coming out way ahead of what we had before.

~~~
ch4s3
I think that's the idea. Look at ELixir for example; they added Ruby syntax
and macros onto Erlang and it's bringing tons of folks to the ecosystem.
Sometime syou need to meet people where they are, if you want them to join
your community.

------
hellofunk
The two issues I have with Reason for me are:

1) It is not compatible with advanced optimizations in Google Closure's
compilation process.

2) I've been burned by less than ideal implementations of immutable data
structures for functional programming in the past, particularly in Elm. I
haven't done enough with Immutable-Re to know if it has similar issues, but
all functional data structures are not created the same. I'm spoiled by
ClojureScript's implementation which has never thrown a stack overflow error
for me, unlike Elm. In Elm, if you have a list that gets too large, you have
to manually break it up into different lists and do weird concatenation stuff
that is quite clunky because somehow it's not doing structural sharing quite
right to ensure these things are transparent under the hood. Experienced Elm
users helped explain this to me, and it's not something I like to think about
when writing in a functional style.

So I've been a bit hesitant to embrace just any functional programming
language for serious enterprise work. But I'm very intrigued by Reason and
Bucklescript and am keeping a very close eye on them. I probably won't do more
than toy projects in them any time soon, but it would be great to someday.

~~~
rtfeldman
> In Elm, if you have a list that gets too large, you have to manually break
> it up into different lists

To clarify, for anyone who comes across this later: there was a bug in the Elm
0.18 compiler that was triggered by enormous list _literals_. (Hence the
workaround of concatenating smaller literals.) Nothing to do with the data
structure itself.

After all, it's a singly linked list; there's not a whole lot of variation in
how those are implemented. ;)

~~~
hellofunk
Is Elm using a particular library for its persistent structures, or are they
custom for Elm?

I've read that it has both List and Array, yet neither appears to be ideal for
proper functional programming; List, as you say, is a linked list, yet it is
recommended [0] over Array for functional operations like map, fold, etc --
but you wouldn't normally want linked lists for that sort of thing, esp. if
your maps and folds were part of a larger data transformation of composed
functions. Does Elm offer anything similar to the structure of ClojureScript's
persistent vector?

I have learned that FP without the guts of serious persistent structures is
not so good in practice.

[0] [https://stackoverflow.com/questions/37707577/array-vs-
list-i...](https://stackoverflow.com/questions/37707577/array-vs-list-in-
elm#comment67060087_37707812)

------
scottmf
Are the new parentheses optional? I love modern JS syntax but the Reason
syntax sans parentheses was really growing on me.

Also I’m still hoping for an async/await équivalent. I’d love to use Reason
for Node API stuff but the JS interop with promises isn’t very pretty...

~~~
yogthos
I simply don't understand why people like C style syntax so much.

~~~
chenglou
I made this release, and I also don't understand, and I do mean this _very
honestly_. Aside from familiarity that is.

But the thing to realize is that this syntax change isn't for folks and you
and me. We'll be fine with either.

~~~
bjz_
But the syntax adds a layer of obfuscation over the mechanics of currying. I
thought we were getting somewhere with Elm, Purescript, and Reason adopting it
and making it more widely known, but then we've gone a step backward again. I
kind of feel like we need better communication and education rather than just
doing a band-aid fix that only helps folks in the short term. :(

Did you consider having a 'beginner mode' Reason, then flipping a switch to
compare it to compare it to the non-parened version is?

~~~
chenglou
I'm gonna argue beside the point, but currying has negative semantics and type
system impact in a language with uncontrolled side-effects. It also prevents
some optimizations and new type features.

Don't take my words for it:
[https://github.com/facebook/reason/pull/1299#issuecomment-30...](https://github.com/facebook/reason/pull/1299#issuecomment-309032848)
[https://realworldocaml.org/v1/en/html/imperative-
programming...](https://realworldocaml.org/v1/en/html/imperative-
programming-1.html#side-effects-and-weak-polymorphism)
[https://drup.github.io/2016/08/02/difflists/](https://drup.github.io/2016/08/02/difflists/)
[https://bucklescript.github.io/bucklescript/Manual.html#_cal...](https://bucklescript.github.io/bucklescript/Manual.html#_callback_optimization)

I'm jumping into this conversation early on because too often this point is
raised and turns into an uncharitable interpretation of our motivations, e.g.
"look at these js programmers, not understanding the beauty of currying". Rest
assured that we do (and that we're not just js programmers), and that the
Merlin and BuckleScript authors know very well what they're doing. Hope this
clarifies things a bit.

~~~
bjz_
I'm not talking about you not knowing, I'm more worried about language
designers talking down to programmers for short term gains, rather than trying
to raise them up with tools that will benefit them in the long term.

Interesting about argument syntax + effects. I've mainly used currying in pure
languages. Is it about accidentally calling an effectful function multiple
times? Is the idea here that you are conservatively treating everything as
effectful with the uncurried syntax (before algebraic effects land), then will
make pure stuff curried in order to attract people to use pure functions where
possible?

~~~
yawaramin
There's a distinction between syntax and semantics though. E.g. Go pushes bad
semantics (null values, bad error handling, no generics) in the name of
beginner ease, with no transition path to better semantics. Reason pushes
'bad' (JavaScript) syntax but _good_ OCaml semantics in the name of attracting
JavaScript devs, with a clear transition path to OCaml syntax should they want
to.

~~~
bjz_
Good points. Still weird to have a syntax that is at odds with the underlying
semantics, and hopefully it doesn't sow more confusion than it initially
solves in the long term.

I still can't get my head around why it would be an optimization problem too,
seeing as it would be most using the same underlying AST. Unless they actually
translate the pseudo-parameter lists into actual tuples in the parser,
forbidding raw, single argument passing. :/

~~~
yawaramin
Yes, as far as I know Reason is the first project to try to have auto-currying
semantics with tupled syntax. It's definitely a bit of an experiment.

Not sure what optimisation problem you're referring to, Reason and OCaml
underlying AST are exactly the same. There are no actual tuples unless the
programmer is creating actual tuples.

~~~
bjz_
I was referring to chenglou's comment[1] where he said "It also prevents some
optimizations and new type features."

[1]:
[https://news.ycombinator.com/item?id=15573956](https://news.ycombinator.com/item?id=15573956)

~~~
glennsl
I think what @chenglou was referring to are issues like the "value
restriction" [1] and the need to wrap "uncurried" FFI functions with a
function that "adapts" it to curried form, thereby adding a layer of
indirection.

Reason does not solve these, they're problems inherent to the underlying
language and the choices made. I think the point being made was just that
currying isn't a clear step forward, but causes some problems as well.

[1]: [http://mlton.org/ValueRestriction](http://mlton.org/ValueRestriction)

~~~
bjz_
Yeah, definitely agree that there are trade-offs with currying when mapping it
to a compilation target like JS, and I am consistently impressed by
Bucklescipt's ability to convert the curried versions of functions to regular
JS calls. That said, I do still think that it's worth the trouble!

------
DC-3
> We've found a bug for you

I must admit that if my compiler reported errors like this it would start to
grate pretty quickly. Besides, isn't a bug exclusively something that breaks
at runtime?

E: s/big/bug/

~~~
Latty
As a new user, it is way more useful. As an old user, you skip right past it.

Every Python exception tells you

> Traceback (most recent call last):

Which is a similar boilerplate statement. Except less useful to newcomers.

And if you doubt the need for newcomers to understand that stack traces and
compiler errors are useful, then take a look at new user questions on
StackOverflow - it's incredible how many of them flat out don't include that
information. This kind of thing makes it way more likely the user recognises
this is something useful, and better than that - makes it way more likely they
can apply that information and solve their own problem.

> Besides, isn't a bug exclusively something that breaks at runtime?

I mean, it _would_ be a bug if the type checker hadn't caught it. The runtime
distinction seems completely arbitrary when we are talking about tools take
take runtime errors and make them impossible.

~~~
abecedarius
Technically "we've found a bug" ought to be "we couldn't prove there's no bug
of this sort" and it can be grating, in the same way Clippy helpfully popping
up was grating, to have the latter announced as the former.

------
dmix
I haven't tried Reason but Merlin (whom the creator also built) looks really
nice: [https://github.com/ocaml/merlin](https://github.com/ocaml/merlin)

~~~
AlexCoventry
Yeah, merlin is very useful.

------
nutate
This fixes the exact problems I would often have with ReasonML . On top of
that my coworker hcarty made some nontrivial contributions to it, so I'm super
excited. I am a dyed in the wool C style programmer, but after exposure to
reasonml, I felt (as odd as it seems) able to read regular OCaml syntax
easier. As someone else mentioned, it becomes a matter of what you see in your
mind more than what's on the screen. I read OCaml library docs and have no
trouble putting them into reason code.

Thanks for your work folks, ReasonML is just getting started.

------
laylomo2
As an OCaml developer... I'm feeling just a _little_ jealous of those Reason
error messages. Beautiful!

~~~
chenglou
They're available to vanilla OCaml as well (given the constraints listed in
the post). Add `"bsc-flags": ["-bs-super-errors"]` in your `bsconfig.json` to
turn it on. If you use BuckleScript, that is.

We'll try to make it into a proper compiler plugin, but it's not trivial right
now

~~~
mchaver
Is JSX from ReasonReact usable directly in OCaml/BuckleScript?

~~~
glennsl
Unfortunately not. It's an inseparable part of the Reason syntax. You can
however use either the desugared form:

    
    
      ([@JSX] div(~foo=bar, ~children=[child1, child2], ()));
    

Or a preprocessor that'll give you a JSX-like syntax, but without the type
checking: [https://github.com/cxa/ppx_bsx](https://github.com/cxa/ppx_bsx)

------
4714
"...simpler cousin of JavaScript, minus the historical crufts, plus the
features of ES2030 you can use today"

Thats funny.

------
santoriv
I love the new function syntax with parentheses! Much easier for us lowly
Javascript developers to read at a glance!

~~~
spleeder
The only thing I like about it is the fact that it removes the need for the
`fun` keyword. Otherwise it just adds noise in my opinion.

~~~
chenglou
The removal of `fun` (And unification of @@@) is directly tied to the parens
change; otherwise there'd be parsing conflicts

------
ratherbefuddled
As an aside: How on earth have you managed to create a website where clicking
a simple <a> in the menu doesn't work without cookies/localStorage enabled?

~~~
tym0
It works fine without JavaScript. Why would you expect websites to work
normally if you take random part of JavaScript out?

~~~
ratherbefuddled
I didn't mention javascript. Why should I need to enable cookies/localStorage
to navigate?

------
krat0sprakhar
Are there any recommended reason apps on GitHub that one recommends going
through? I'm interested how a medium/large app in reason is structured.
Thanks!

------
forkLding
Quick question from a newb: whats the reason for using Reason? (Ignore the
pun)

~~~
amirmc
Rationale here: [https://reasonml.github.io/guide/what-and-
why](https://reasonml.github.io/guide/what-and-why)

------
mattferderer
Can anyone speak to Windows support yet? Last I looked their was work being
done to get better OCaml support on Windows which seemed like the big hurdle
that was required. I know there are some workarounds using Windows 10 and Bash
but I'm waiting for something I can easily get my whole team to use.

~~~
chenglou
Here's a big centralized thread for it:
[https://github.com/reasonml/reasonml.github.io/issues/195](https://github.com/reasonml/reasonml.github.io/issues/195)

In short, every part works, but the workflow is a bit contorted atm

------
jonahx
I would love to see a comparison of the pros/cons of Reason vs Purescript by
someone familiar with both.

~~~
christophilus
Subjectively, I think PureScript is the better language (in terms of
aesthetics and expressiveness) also it has overloads so (2 _5) and (2.3_ 3.3)
instead of OCaml's odd (2.3 *. 3.3).

Reason has a much faster compiler, efficient immutable operations, and is
built using tried-and-true tech (OCaml).

~~~
mchaver
I also really like PureScript, but the output from PureScript seems to be a
lot larger than OCaml/BuckleScript and have worse performance.
OCaml/BuckleScript has a really small stdlib that is lacking common functions,
does not support type classes or point free style. A lot of groups end up
making their own stdlib. BuckleScript is probably the more practical option at
the moment.

------
napa15
Installation is broken with bs-platform, do this to fix it (assuming node is
installed in /home/pc/node)

rm /home/pc/node/lib/node_modules/bs-platform/bin/refmt.exe

ln -s /home/pc/node/bin/refmt /home/pc/node/lib/node_modules/bs-
platform/bin/refmt.exe

Is there no source map support? Also: I have to set up requirejs myself to
make Reason code work in the browser? Not only that, it doesnt seem like the
whole "each file is a module" system is actually codified in the output. I see
no require calls that would indicate the right loading order for my generated
.js files.

Generated code has weird comments in it like /* Facebook _/ and /_ Instagram
*/

~~~
yawaramin
There is no source map support because the output JS should correspond almost
1-1 with the input Reason.

Can you give an example of 'I see no require calls'? Require or import calls
should be generated correctly.

~~~
napa15
I dont know what to tell you, I'm using the simplest possible project here. It
just doesnt seem to pick up anything other than the entry.re file. I initially
only had the non-webpack default compilation set up, which does compile all
.re files but has the problem that the modules dont get loaded / no idea which
order should be loaded. So naturally I set up webpack but now it only watches
the entry.re file for some reason. And saying that the output js corresponds
1-1 with reason is really not true at all, especially when compiled into one
big module with webpack.

[https://i.imgur.com/hrxmjWl.png](https://i.imgur.com/hrxmjWl.png)

~~~
yawaramin
I think it only watches one of your files because the other one isn't actually
referenced by any code in the pathway of your entry point. If you reference
some code from your other file, it will be picked up as well.

Yes, I forgot about bundling, sorry, but if you are in debug mode you're not
minifying the bundle JS anyway so whatever you're looking at should still look
a fair bit like the input Reason, especially because the names are only
minimally mangled.

------
idibidiart
Any update on algebraic effects for single-threaded structured concurrency? In
vanilla JS we can implement structured concurrency using generators as
primitives. How do we implement _structured concurrency_ in Reason?

~~~
ihm
To be clear, Reason is just a lexer for OCaml. Any actual language features
would happen in OCaml.

~~~
jordwalke
Currently: lexer, and parser, and AST printer (bidirectional parser you could
say), with a few lightweight ppx macros included for UI development.

------
mhotchen
Since Reason compiles to native Ocaml binaries I'm assuming there would be no
problems using it with MirageOS? Google doesn't bring up any answers other
than an older HN comment[1] suggesting support will come soon.

[https://news.ycombinator.com/item?id=11717213](https://news.ycombinator.com/item?id=11717213)

~~~
Dinoosaure
Because Reason is just a syntax layer over the OCaml syntax, you should write
an MirageOS unikernel with Reason. However, because MirageOS needs lot of
works, lot of people of this community don't have a plan to switch to Reason -
but feel free :) !

After, it's about a convenience easy way to compile your Reason code with an
OCaml code. Reason is just a preprocessing, you should use the `-pp` option
with /your favorite build system in OCaml/ and, I think, it's enough.

~~~
mhotchen
I won't be switching to Reason, it's a small greenfield project :) The
security model of Mirage will really suit this small app and Reason has piqued
my interest for being a little more productive with dev tools and stuff. Also
being able to build a frontend in the same language is appealing.

Thanks for the answer; the other comment alluding to support being recent and
the lack of information had me a bit worried. I guess the lack of information
is because it just works ;)

------
jonathonf
But Reason is already version 9?

(I know there's going to be some overlap between project naming, but Reason is
a fairly well-known product...)

~~~
abritinthebay
I only know of ReasonML, what Reason are you referring to?

~~~
cyberferret
It comes down to domain knowledge. I am a musician, and whenever anyone
mentions 'Reason', I instantly think of the DAW software by that name.

I have been a programmer for as long as I have been a musician, but strangely,
never heard of ReasonML until now!

~~~
scottmf
ReasonML is fairly new but I believe Facebook has big plans for it, so we’re
likely going to hear a lot more about it in the coming months.

------
softwarelimits
Does this bring any interesting new language features which would help with
distributed programming (like e.g. Erlang) or is this just another variation
of syntax and infrastructure?

~~~
yawaramin
The latter.

------
ubertaco
So they've changed yet another piece of core, defining OCaml syntax (the lack
of C-parens everywhere) for the worse, obfuscating currying in the process.
But that's just my opinion, I guess. I don't have to use it.

I do find it ironic that in their announcement, they don't even try to defend
the decision, but instead say, effectively, "if you don't like this change,
you're just bikeshedding", and "if you don't care about syntax, great!" Given
that the entire purpose of Reason is one giant bikeshed about OCaml syntax,
this reads as hypocritical.

They also say, effectively, "no complaining in public allowed, just PM us (so
we don't have to have a real conversation and we can ignore you)", so you
_know_ they're great at working with their community.

~~~
agumonkey
I'd let it slip because it will probably move a massive amount of devs into
the static reasoning mindset. You lose a bit in the process but the gain is
still worth it.

~~~
cwillis3
I don't know. One may be forced to write this silly dialect instead of real
OCaml in a couple of years "because Facebook".

------
eecks
What are reasons competitors?

~~~
glennsl
What are we supposed to be competing for? Reason is a tool that makes
different trade-offs than some other tools. These trade-offs might work for
you or they might not. It all depends on what YOU actually need.

------
pdog
Reason, for me, will always be the digital audio workstation by Propellerhead
Software[1]. It was a masterpiece of user experience design.

[1]:
[https://en.m.wikipedia.org/wiki/Reason_(software)](https://en.m.wikipedia.org/wiki/Reason_\(software\))

~~~
themodelplumber
Reason the music software has always been a fine argument in favor of
skeuomorphic design. We did an industry-wide "ewww" away from that kind of
design but when it comes back with a vengeance it will be because of software
like Reason.

~~~
sametmax
The problem is that skeuomorphic design can become obsolete pretty fast. The
virtual version replace the real object, and the aspect of said object is
forgotten, rendering copying it useless.

------
tomc1985
And here I thought you were referring to Reason, the music production suite :/

~~~
dmix
Same, it really should be referenced as ReasonML. Reason is a major piece of
software that's been around for a very long time.

~~~
jfaat
Also it gets difficult to google things very quickly while trying to get up to
speed.

------
b____b
This syntax is horrible. All the elegant lambda calculus associations are
gone.

Yes, the original OCaml syntax looks quirky during the first two weeks. But it
makes sense after that.

