Announcement: Reason Q&A session this Friday 5pm PST

#1

Hey everyone! I’ll be doing a Reason freeform Q&A session this Friday 5PM PST on Google Hangout. Everyone’s welcomed to join and ask questions. Hangout link will be posted in Discord, Twitter and Discourse near that time. See you then!

#2

Starting in 5 minutes! https://hangouts.google.com/call/0I-dVZfiUeH7d9K9UWT1AEEE

#3

That was way too late for Europe, is there a recording?

#4

Great idea. Definitely suggest recording these in the future!

#5

Or maybe just a breakdown about what has been discussed?

#6

That’s a good point. The main discussion Q&A (from memory, @chenglou correct me if I’m wrong) were:

  • Why BuckleScript vendors and patches the upstream OCaml compiler for the build process, instead of using the upstream directly: this is because BuckleScript makes some changes to the way some type information is carried across compile phases, in order to output more idiomatic JavaScript. For example, it preserves the types of booleans instead of converting them to int (0/1) like upstream OCaml so that output JS can be true/false.
  • Someone said: sometimes Reason doesn’t feel ‘different enough’ from JavaScript. chenglou: that’s good! We want there to be that feeling of familiarity.
  • How we can market Reason at work in the face of ‘safe’ incumbents like TypeScript: (to some extent) try to build apps instead of writing yet more tutorials. Working code, that people can run and try out, speaks more than another tutorial that they have to take at face value. Also, TypeScript took years to get where they are now. People used to ask the same thing–why should I use TypeScript. Finally, a big help in marketing is being able to show that BuckleScript output does not add strange, heavyweight runtime code. It’s sometimes almost exactly the same, line for line, as hand-written JS code. There’s a story about how after chenglou checked in some of the first BuckleScript output, someone tried to edit it because they thought it was hand-written.
  • We looked at some details of how Belt data structures are implemented: using simple, efficient AVL (binary) trees instead of sophisticated structures like HAMTs (incidentally, JavaScript is a bad fit for HAMTs because you continuously pay the cost of hashing data which JS is not efficient at. But with binary trees you just do comparisons, which it is really good at). Console-logging data structures like Belt int map shows how simple it is: it prints out just as an object with some props that show that it’s a binary tree.
  • Finally, a recommendation, to not necessarily point newcomers at Belt straight off the bat. Let them have a gradual learning curve, by using the Js bindings for the familiar JS libraries. Belt can enter the picture when they feel the need for efficient immutable data structures.