"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.
I had similar experience with Elm. I didn't have app like Messenger, but it takes a little longer to start, but it is rock solid and refactoring is a breeze.
It also shows how deeply "it compiles and runs without bugs, it's awesome" is ingrained into software developers.
I could write a 100-page essay on all the ways the web-version of messenger fails in subtle and not so-subtle ways, and how it cannot keep the pace of development with the mobile version.
The dev team hasn't received bug reports though. Must be nice.
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.
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!
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). If not, sorry about that.
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.
> 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.
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.
Hmm, I'd argue that since any language is effectively compiled to zeroes and ones under the hood, by that logic no type system can protect you. A good type system is there to guide you, and verify that your code is going to be ok even once types are erased.
Transpiled/compiled/whatever you want to call it, the type system can prevent dumb and smart programmers from making a whole class of errors. In my experience OCaml has prevented so many errors I would have made in JavaScript, including but not limited to:
- Non-exhaustive select/case statements - missing one of the possibilities causes undefined behaviour. It might not even be a case of carelessness or forgetting - just that a new option gets added by someone unfamiliar with the codebase and doesn't realize they need to update a bunch of select statements.
- Changing the name of a field on an object across the codebase, and forgetting to update every single instance. OCaml won't even compile until you've fixed them all.
- Null and undefined weirdness. Just search any large JS github repo for "null"/"undefined" and see how many issues are related. With OCaml, you'll almost never see them because you're forced the deal with the possibility before your code will even compile.
I believe that a type checker isn't necessary until you can no longer hold the entire codebase in your head. For me, that means once my program goes over about 150 LOC, I need the compiler to help me out.
The problems you mention aren't related
to transpilation or even JavaScript. They're due to TypeScript being a backwards-compatible superset of JS.
TS is, among other things, JS plus type annotations, but it also relies on the same underlying type system as JS, and TS types, as I understand it, are completely erased at runtime. For example, interfaces don't exist in JS, and classes are prototype-based. So it inherits those flaws, and doesn't patch over them with some kind of runtime, and you end up with a leaky abstraction.
I don't know anything about Reason's JS interaction to say if it's similarly leaky.
Reason is not transpiled language, it’s frontend replacement to ocaml compiler pipeline. Bucklescript, a different project, is backend replacement that emits Javascript instead of binaries. They can be used together, but don’t have to.
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.
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?
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]
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.
Can't speak for the creator, but generally speaking OCaml is much more widely adopted than SML (although still tiny market share overall). A few corporate players like Facebook and Jane Street have started adopting OCaml, and subsequently the libraries available for OCaml are far superior to SML. As far as I know, SML only remains in use today in academic circles.
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.
> 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. ;)
IMHO "functional scripters" with a penchant for fewer parens, braces etc and a tendency towards ML-style should seriously embrace PureScript, it's such a terrific project, just gets way too little hype. That's not to rain on ReasonML of course here, which I observed for a while as a very cool transpilation project and kudos to the devs! I'd take a reason project over JS/TS/Ecma any day still
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?
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.
You would think so, but personally when I picked up Elm it was extremely handy, and then faded into the background. I expected it to be annoying as an experienced dev, but I actually appreciated it initially and then it wasn’t annoying or even on my radar: my brain skipped right over it.
Once you’re more experienced with the language, you’re typically using your editor to handle the error checking, so the extra “noise” is ignored in the parsing of it.
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.
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?
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!
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.
[+] [-] myth_drannon|8 years ago|reply
That's truly amazing.
Interesting how Elm is inspiring other frameworks and languages. First Redux and now Reason's error messages.
[+] [-] Cyph0n|8 years ago|reply
Sounds like an amazing accomplishment for the Messenger team.
[+] [-] desireco42|8 years ago|reply
[+] [-] brandonbloom|8 years ago|reply
[+] [-] kibwen|8 years ago|reply
[+] [-] _pmf_|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] dmitriid|8 years ago|reply
I could write a 100-page essay on all the ways the web-version of messenger fails in subtle and not so-subtle ways, and how it cannot keep the pace of development with the mobile version.
The dev team hasn't received bug reports though. Must be nice.
[+] [-] jordwest|8 years ago|reply
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|8 years ago|reply
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|8 years ago|reply
[+] [-] chenglou|8 years ago|reply
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). If not, sorry about that.
[+] [-] lf-non|8 years ago|reply
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
[+] [-] wtetzner|8 years ago|reply
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.
[+] [-] erokar|8 years ago|reply
[+] [-] maxpert|8 years ago|reply
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.
[+] [-] jordwest|8 years ago|reply
Transpiled/compiled/whatever you want to call it, the type system can prevent dumb and smart programmers from making a whole class of errors. In my experience OCaml has prevented so many errors I would have made in JavaScript, including but not limited to:
- Non-exhaustive select/case statements - missing one of the possibilities causes undefined behaviour. It might not even be a case of carelessness or forgetting - just that a new option gets added by someone unfamiliar with the codebase and doesn't realize they need to update a bunch of select statements.
- Changing the name of a field on an object across the codebase, and forgetting to update every single instance. OCaml won't even compile until you've fixed them all.
- Null and undefined weirdness. Just search any large JS github repo for "null"/"undefined" and see how many issues are related. With OCaml, you'll almost never see them because you're forced the deal with the possibility before your code will even compile.
I believe that a type checker isn't necessary until you can no longer hold the entire codebase in your head. For me, that means once my program goes over about 150 LOC, I need the compiler to help me out.
[+] [-] lobster_johnson|8 years ago|reply
TS is, among other things, JS plus type annotations, but it also relies on the same underlying type system as JS, and TS types, as I understand it, are completely erased at runtime. For example, interfaces don't exist in JS, and classes are prototype-based. So it inherits those flaws, and doesn't patch over them with some kind of runtime, and you end up with a leaky abstraction.
I don't know anything about Reason's JS interaction to say if it's similarly leaky.
[+] [-] mirekrusin|8 years ago|reply
[+] [-] yorwba|8 years ago|reply
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.
[+] [-] djur|8 years ago|reply
[+] [-] dsissitka|8 years ago|reply
https://github.com/facebook/reason/pull/1299#issuecomment-32...
[+] [-] k__|8 years ago|reply
OCaml looks rather foreign to the regular JS dev and the last versions of Reason looked more like JS, but still had a few strange parts.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] myegorov|8 years ago|reply
[+] [-] jordwalke|8 years ago|reply
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.
[+] [-] wcrichton|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] hellofunk|8 years ago|reply
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|8 years ago|reply
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. ;)
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] drdiablo|8 years ago|reply
[+] [-] scottmf|8 years ago|reply
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...
[+] [-] dualogy|8 years ago|reply
[+] [-] yogthos|8 years ago|reply
[+] [-] DC-3|8 years ago|reply
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|8 years ago|reply
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.
[+] [-] girvo|8 years ago|reply
Once you’re more experienced with the language, you’re typically using your editor to handle the error checking, so the extra “noise” is ignored in the parsing of it.
[+] [-] dmix|8 years ago|reply
[+] [-] nutate|8 years ago|reply
Thanks for your work folks, ReasonML is just getting started.
[+] [-] laylomo2|8 years ago|reply
[+] [-] 4714|8 years ago|reply
Thats funny.
[+] [-] santoriv|8 years ago|reply
[+] [-] spleeder|8 years ago|reply
[+] [-] ratherbefuddled|8 years ago|reply
[+] [-] krat0sprakhar|8 years ago|reply
[+] [-] forkLding|8 years ago|reply
[+] [-] amirmc|8 years ago|reply
[+] [-] mattferderer|8 years ago|reply
[+] [-] jonahx|8 years ago|reply