ReasonML Conference 2018

Three weeks ago i’ve attended ReasonML conference in Vienna Austria. This post is my perception on the conference as well as short summary of the talks. Before going through talks list let’s talk about the conference and what it’s all about.

Intro to Reason

So Reason or ReasonML is basically a new syntax on top of OCaml. It looks very similar to JavaScript, so you write very similar as you would have written in JS. Your code compiles to OCaml and with the help of really great tool BuckleScript to very efficient JavaScript. So why use Reason? Well there are lots of benefits and they demand a separate blog post, but for me the main “selling point” was really powerful type system and superior type inference that covers your code in 100% of types at compile time. Meaning less bugs and because of type inference you actually don’t need to write types. Compiler understands your code and types it for you.

So enough of Reason intro. You can check it here: https://reasonml.github.io/

Also make sure to check Nik Graf course on egghead:

https://egghead.io/courses/get-started-with-reason

So now after you got the basic idea what ReasonML let’s talk about conference format. Conference has an unusual format of 1 workshop day, 1 conference day and 1 hackathon or Vienna tour day (it turned out to be both 😊) included in basic conference ticket price, which was an amazing surprise and big thanks for that to conference organisers and sponsors.

The Workshop day

Rest of the photos

Workshop day took place on 11 of May 2018 and took place at ImpactHub co-working space. I was a bit sceptical at first how workshop of that size can be handled, but surprisingly it went really well. It was divided into two parts. The first part before the lunch was handled by Sean Grove and Jared Forsyth and included basic introduction to ReasonML syntax to get everything up to speed on this amazing language.

Exercises were posted here

Overall experience of all attendees was far higher than speakers anticipated and it lead to the fact Dojos after the lunch were more advanced.

A few words about Dojos. So there is a Dojo format for a workshop that was really new to me and basically the idea is that attendees are divided in groups of three or four and pair program on workshop challenges. The person with less experience is the person that types and others brainstorm the challenges and help him with instructions. It sounds like a weird format but it worked really well.

Dojos were on 3 main topics

• ReasonReact and GraphQL

This was a Dojo I participated in and it involved using ReasonReact and reason-apollo for consuming Github GraphQL api.

• ReProcessing

This Dojo was focused on building several games with ReProcessing library.

• Node.js advanced dojo

This dojo was focused on writing ReasonML on a server side, connecting to frontend via sockets.

The Conference Day

Rest of the photos

The Venue was located at the heart of Vienna at Technical University Vienna. The venue itself was amazing as well as location.

After the intro by Patrick Stapfer

“Today will be an inspiration day, I hope you can take talks with you and get inspired”

Keynote by Cheng Lou

Organised by community for community

Cheng Lou started his keynote by saying thanks to organisers who organised this amazing event.

He explained that with a cool analogy about organising conference. Imagine that you are organising a party but instead of inviting your friends you invite 200 strangers. If people will bail on you in the last moment you will lose a lot so huge risk is involved. He mentioned that organisers already think about 2019 conference.

Following kudos to organisers Cheng Lou continued with mind blowing technical updates

1. Refmt

Refmt is used with ReasonML to format your code. It has in editor integration and really makes your code look better. For Refmt two new changes were introduced:

Preserve empty lines (IwanKaramazow)

Semicolon recovery (let-def) — parser gracefully recovers and no weird error messages for missing semicolons

2. ReasonReact

ReasonReact is now ready for React 16 and more polished 🎉

3. Bucklescript interop

bs.deriving abstract — it generates accessors for fields and creation function for records. The most important that it has no cost at runtime.

4. Reprocessing

Reprocessing library is not getting enough traction when it should. So you definitely should check it out. Library can draw OpenGL, WebGL and it’s cross platform so it even can render to native targets such as iOS and Android

Schmavery/reprocessing

5. Debug

Belt.Debug.setupChromeDebugger() — Let’s you to setup Chrome debugger for both browser and NodeJS without any mode switching.

6. Belt

So for all those who are not familiar with Belt, It’s a library of helpers and data structures. It has Mutable and immutable collections, “blazing” fast, idiomatic JS and it’s tiny all around. A cool think is that main data structures are sorted by default.

Really important announcement is that

Belt can be used as a standard vanilla JavaScript library so if you as a developer (if you have a trouble conveying to your managers) you can start with Belt as vanilla immutable JavaScript and when you enjoy benefits you can convince your boss to switch to Reason.

It turns adopting Reason from perceived as high risk to low risk.

Cheng Lou finalised his Keynote with his wish for the community.

• Execution and craftmanship

He started with various examples from Apple history and SpaceX and the main idea of the wish is that Idea is 10% of work. The rest is execution. 90% of execution are the hardest ones. even the last 10% feels like another 80%.

Lack of execution will be a silent killer for community. React actually went through 10 api iterations before it was released to open source. Execution is what made React great.

• Focus on Product

Focus on product and start adopting Reason. Messenger was the first that adopted Reason. To work in a real big codebase and real problems.

• Find a Mentor/Friend

Find people that understand one abstraction level lower than you do. When coding together is really cool experience

Persuasion power of several people is much stronger

Video is available here:

ReasonReact and a local state

by Cristiano Calcagno

Cristiano started his talk with talking about AST and performance insights. He briefly introduced Reason going over it’s basics.

Key ingredient to ReasonML is type inference that you get from the language itself. ReasonML compiles to readable code and is friendly to JS developers. Due to Bucklescript compiler it compiles really fast and has easy interop with JavaScript

After going through Records, Functions he introduced ReasonReact

ReasonReact wraps your React component with Reason. It was not an easy task. It was important to include not only type safety but to make side effects explicit so Api will indicate where side effects are called. Also Interop with normal React component and incremental adoption are really important too.

So the cool features about ReasonReact are

• state is always initialized with the right type.
• no direct access to state
• state updates maintain type
• component replacement preserves types
• type safe design

Cristiano went through the basics of ReasonReact component creation and it’s intricacies.

DOM is a perfect example of global state. Maximum freedom and minimum of control

GlobalState in ReasonReact can be used by defining a module with state and everything will be controlled by that module you pass your global state to your components.

It’s easy to compose global state if you want but you should be careful about that. And every time everything gets redrawn.

Local State is used with ReasonReact.reducerComponent. The fact that in reducer function pattern matching is used, if a new action is added Reason will throw error of pattern matching not implemented for new action

When you operate with global state, you need to be careful and by default it can be less performant.

Animation in the context of local state

So where is a state in animations

Between started and stopped/interrupted local state is a function of time and position

Particularly spring animations have start value, stiffness and damping. You need to think about local state which is localValue, position, velocity and final value.

Cristiano showed a simple Spring example and moved to more complex example showing spring compositions. The idea passing a function which is a composition of state and interaction without interference

Remote Actions

Remote actions are for components that want to be controlled from outside. Basically you pass send function at didMount to RemoteAction.subscribe. Whenever remoteAction is triggered send function is called. So this is the way of interacting between components without passing props down the tree.

Using RemoteActions you can send action to other components.

Cristian wrapped up with really cool demos that can be seen at talk video on youtube

Building inclusive Open Source Communities

by Laura Gaetano

Laura started with her personal story and how she got into web development and design. At some point she realised that there is a community of like minded people.

The World of Open Source

There is an amazing world of open source out there and it’s great but it has a problem that it’s not diverse enough. Laura walked through various surveys showing that there are lots of underrepresented groups in tech and talked about the fact that unfortunately contributions are not paid and hence currently only people that can afford financially end up contributing, because they contribute only on their free time.

Bias, prejudice and the tech industry

Laura said that lots of tech and products are designed by not covering large portion of population mentioning various shocking examples and emphasised on the fact how it’s important to be aware of that.

Making your project more inclusive

Making your project accessible is hard. Start with writing docs, Readme, license. Ask someone without background to read your Readme and give you feedback on it. Add Troubleshooting guide to your project

Make your project welcoming by creating contributing guide, add contribution labels for good first issues, add instructions how to create Pull Request for newcomers. Add and enforce a Code of Conduct by thinking what Code of Conduct to use and by stating what consequences will be when someone violates code of conduct.

Laura also talked about how it’s important to be cautious and avoid using ableist language and micro agressions. Remember that diversity isn’t just white women and we have to do better by expanding our network to people not like us.

But what happens if we make mistakes. And we potentially can and will make mistakes. She suggests to apologise, don’t justify yourself, learn from it and then move on.

And remember that

Open Source is about people

video is available here:

Down the WebAssembly Rabbit Hole

by @Sander_Spies

Sander started his talk with history of Reason and right after brief introduction he dove into compiler intricacies and how compiler actually works. He divided it into Compiler frontend and compiler backend.

Compiler frontend

So in a nutshell compiler takes you code, transforms it into tokens, parse tree and produce AST and then Typed AST so the flow looks basically like this:

Code -> Tokens -> Parse tree -> AST -> Typed AST

Compiler backend

Compiler backend takes Typed AST and parses it Lambda IR which means it removes higher level abstractions (modules, objects, etc). Then it replaces types with runtime memory model.

Typed AST => Lambda IR

remove higher level abstractions (modules, objects, etc)

replace types with runtime memory model. It will look like this:

Then Lambda IR will compile either to Bytecode or Native meaning on native side it will use CMM IR which will generate CPU specific code(Instruction selection Alloc combining Register allocation, linearisation, instruction scheduling etc)

Future of WebAssembly

So there are various things about web assembly that Sander pointed out.

• Bytecode — Web Assembly can run not only on the web but also on native platform
• Limited set of instructions
• We don’t have any access to stack with web assembly even if we want to
• It has linear memory
• Manual memory management
• Spec is written in OCaml

So how we get from Reason to WASM

Possible entry points

Start at Lambda layer or Bytecode or CMM

CMM — It’s the closest one but it has various assumptions we need to make in WebAssembly which are because we don’t have an access to the stack.

• Garbage Collection
• Exception Handling
• Tail calls

Currently more and more people are involved in Web Assembly such as

Mozilla, JaneStreet, OCaml Labs, Facebook

Sander finalised with the current status of WebAssembly “Rabit Hole” . It can compile CMM to WASM, link object files together, Can compile very basic OCaml applications. There are bunch of TODOs for the future:

• Clean up current code
• Testsuite
• OCaml runtime (GC, memory etc.)
• Get it upstream

video is available here:

State of the Reason Editor integration

by Javier Chávarri

Javier started with the question

“What are the interfaces of programming languages”. Like designers which can argue on user interfaces and have various opinions we as developers have various opinions on syntax, tooling and so on.

What is the editor

It’s a critical part to make computer language accessible. Developer experience is super important. Editors have a lot of power, but with that there is a great responsibility.

How awesome for example when an editor can show types for all functions without adding a type annotation?

State of the editor today

Currently all major editors are working with language server and there is a unified interface for all language to talk to OCaml and Reason

Developer tools work with Reason and OCaml Language server which in turn talks to services

Javier walked through editor features showing how support for refmt, bsb, merlin, introspection and much more.

So what is in the future

• Rewrite of the language server in OCaml
• Improve in-editor feedback if tools binaries are missing
• Native Windows support (no WSL needed)
• Facilitate creation of new projects
• Preview mode that translates OCaml <-> Reason

About boundaries and empathy

Demo, Javier showed was mind blowing. It’s an experiment that basically you can generate bindings via VSCode. It’s called rebind and you can check it here: https://github.com/jchavarri/rebind

video is available here:

Using Reason in traditional Enterprises

by Roman Schiefer

Bringing new technologies to large-scale enterprises is a challenge in which we are involved quite often. In this talk Roman reflected on his current experience with Reason based on a real implementation.

Roman started with generalising on why we would use new technology in general and what are the challenges.

Why it make sense

• Technology-enabled innovation — new technology brings with it innovation
• Creating a better solution — technology evolve so embracing new technology correctly is basically creating a better solution for old or new problems.

What are the challenges

• Large teams/ codebases — We cannot rewrite projects from scratch every time. we need to coordinate between teems properly
• Heterogeneous skills
• No room for failure — after all in large enterprise our failure means potential loss of a lot of money
• Lots of history — legacy code and technical dept are us
• Brownfield(s)

What are the capabilities we are search for?

Developer ergonomics

• Learning / understanding the tech
• Tooling (debugging, linting, editor, completion)
• Public OSS support

Robustness/Stability

For example with React it will work even if you do things wrong, but API is really stable

• Hard to do things wrong
• Works even if you do things wrong
• API Stability

Ecosystem / Interop

• Amount of libs / frameworks (quality /quantity)
• How easy is it to integrate
• Sane default choices

So what Reason brings to the table:

Typesystem(mandatory) in the language itself

Pragmatic Paradigms — new programming paradigms but very practical

Interop — Interop with JavaScript and OCaml world is relatively easy. Meaning we can reuse various npm libraries out there.

Tooling — Reason tooling is just amazing. It comes built in without any additional complicated setups

The implementation

Roman talked about Lunch Lottery for employees that their company have created.

Challenges they had:

Read bucklescript docs prior to Reason is a necessity

Unclear which API to use -> Reason / Bucklescript

No built — in optionals

Stacktraces sometimes unreadable, Warnings in source of dependencies

Formatter removes {} from function bodies if there is only one statement, it’s tedious to add additional statements

Different reason-cli versions across the team lead to errors

video is available here:

Reason coming from F#

by Lance Harper

Lance Harper focused in this talk about difference between ReasonML and F#. He started with F# origin story emphasising on the fact that F# is a “cousin” of OCaml. It’s syntax is designed to closely mirror OCaml.

F# is cloud friendly and can run on Lambdas on all major clouds (AWS, GCF, Azure) which is a big plus.

Lance covered special features of F# and how it resembles ReasonML such features include “units of measurements”, Async Workflows, Type providers and much more

video is available here:

Practical Interpretation of Code Formatting

by Maxim Valcke

Today every major language has some kind of library that helps a developer formatting his or her code. Tools like Prettier, Gofmt and Refmt are setting new standards and have a deep impact on our day to day programming.

But what does it actually mean to format code? Does it mean pressing a magical button to align your code? Is it more than the automatic insertion of trailing commas your colleague always seems to forget? Why are we even doing it? How is it going to impact us as programmers to get better?

So what is a code formatter?

What is actual impact of using refmt in production

• Look at what the best in the world are doing
• Be very curious about the basics
• What is the desired effect? What is the actual effect?

Programming 101

We create programs to direct process, sometimes mind ones to direct them to computers.

Maxim ephasised on the fact that desired effect of code formatting is basically write distraction free and automate syntax related changes.

Programs are made for humans to read (and only incidentally for machines to execute)

What is the actual effect of using Refmt in production

So when we use Refmt in production we can eliminate boring mainenance, automate arbitary syntax changes. For example:

let add a b => a +b;

let add = (a, b) => a + b

What’s next? Follow iwan on twitter and keep updated on refmt current status.

@_iwan_refmt

video is available here:

Having your cake and eating it too — GraphQL in Reason

by Sean Grove

Sean starts with the intro about promise of typed languages and how it’s more difficult to represent incorrect programs. The problem within typed languages is that it’s difficult to know how to represent certain ideas. There are also some programs that are hard to represent, however type system is a beautiful world in it’s own domain and it’s a lot of work to model different kind of domain. Lot of polish and a lot of work is required.

Reason domain is mostly for creating UIs for web, mobile, Syntax(JSX) and as soon as you go to new domain it’s a real challenge.

If you type a library you mostly type what you need. It doesn’t age well and BuckleScript trusts you so if you lied to it, then…well…

Libraries, ecosystems are really important but apps need external dependencies. Let’s see the basic problem

Parsing JSON. It sounds simple but it’s challenging to move JSON to Reason cause you need to pattern match on existence of fields, check their types and so on.

Solution? Meta program!

We can use @bs.deriving jsConverter to convert from JSON to records, but we still rely on server sending JSON.

In reality we need to trust the server to send correct data and we need to know the shape very well even if there is no documentation.

If we have sufficient number of examples we can check all variations and generate all type definitions

ATD (Adaptable Type Definitions) generation is a way to represent type definitions in one place and generate types

By using JSON -> ATD you can get the output of actual GraphQL resolver you can paste on your server

So this sounds like there is a solution, but what if server moved fields, so what next? gather more examples?

It’s a good way to be a paranoiac

3 big problems when Reason meets the outside world:

• Boilerplate converting between JSON data into Records/Objects
• Confidence in the accuracy and safety of conversion
• Server changes

So what do we want?

• Access to all of the data types in an API
• Automatic conversion, access, safety
• Guaranteed contracts between server/client

etc

So it’s time for GraphQL

Sean showed live demo against github GraphQL api showing benefits of GraphQL and graphiql.

GraphQL introspection

Every graphql service has introspection query that returns JSON of it’s own schema. So what we can do is marry between GraphQL Type system and Reason. If we change for example query field from being optional to mandatory we in editor see automatically error.

So Reason tooling now will work between GraphQL definitions on the server to your client.

On the Frontend what do we get

Powerful clients, no overfetching and no underfetching, reduced latency and network calls (huge for mobile), Safe client (won’t even compile if server can’t satisfy query, usage of query results are type-checked, Nullable fields are enforced — no more run-time errors!)

Easy clients

Don’t even think about network coordination

Steps to do that

Frontend

• add graphql_ppx
• add reason-apollo
• yarn send-introspection-query ‘endpoint’ which will save schema

For graphql SDL we use graphql_ppx

Backend

Why in Reason(Native)?

• Productivity
• Safety
• Stability
• Guarantees in compile time

ocaml-graphql-server

There are still lots of things to be done on GraphQL domain of ReasonML for example how to propagate errors, use subscriptions, directives, integration into Apollo Engine. But you should just go and start building GraphQL APIs.

video is available here:

Building native Node.js addons in Reason

by Vladimir Kurchatkin

What are regular Node.js addons? They are dynamically-linked shared objects, written in C++, that can be loaded into Node.js using the require() function, and used just as if they were an ordinary Node.js module

Why would you want addons?

• using language features that are not there in JavaScript
• performance
• ecosystem — if you want something out of javascript like a library in C or C++ which is way better
• access to the platform

What’s inside an addon file — It’s a binary file which is called shared object (.so or .dll) they use .node extension but in general they are similar.

Addons are called in the following manner:

Node.js -> dlopen -> Addon -> node_module_register -> Node.js

So how to build an addon

• V8 API (C++) — it was the main way for quite a while
• Nan (C++ ) — Native extractions for node — it’s a collection of macros and wrappers that help you to build addons in backward and forward compatible way with consistent api. The problem is that sometimes you need to recompile your addons.
• N-API ( C ) — the idea is that if you build your addon on top of it you don’t have to recompile your addons

Binding.gyp — metadata for build system to generate your project and it’s used in node because it’s used in V8 and it’s used in V8 because it’s used in Chrome

addon.cc — It looks like a mess and that you had to do in the old way

after running gyp you get .node file that you can require

Meet OCaml-Node

Disclaimer: New and unstable

• It’s build by using C and OCaml
• N-API
• Jbuilder (Dune)
• Esy — great tool that provides npm like development for OCaml development

Demo

Vladimir live coded basic OCaml Node addon. If you want to setup your own addon you just run

npm init

ocaml-node init

ocaml-node will run esy and generate ocaml addon for you that you can easily include your addon regularly like you include node.js modules.

What’s not to love about Reason?

by Keira Hodgkison

Keira started about how she and bunch of cool people got involved in Reason and how it cool can be. So the question is “what not to love”

If this is your first FP language then you have to know new concepts from Functional programming in general and when you start asking questions on Discord sometimes you will get answers that you will simply won’t understand.

Take breathe

Cheat (write javascript in Reason if you are stuck with bucklescript)

Wishes Jeason was more developed. If you could use Jeason — — to spit out suggestions how you can write your JavaScript with reason it could really help JS developers.

After you reduce your unknowns, you can revisit your unsafe solution before shipping — sometimes a break from the problem is all you need.

It gets easier with time

But what about Reason. JS-like syntax can convince you you’re writing JS but it’s not JS

JS.logging looks like console.log right? Not quite.

for example when logging a list it’s represented as a nested array but log works only few levels deep. So converting to array does the trick

…Spread

we used to use spread in JavaScript but in Reason sometimes we can append and sometimes we cannot so we need just to remember when we can

Foreign Function Interface — Javascript interop

The FFI is kind of hard to parse

Docs

Docs are scattered around in various places and it can be really problematic to follow all the docs

JSON and Async are on a roadmap to fix

So how to become an expert?

Keira referenced the idea that while learning we had that cognitive load theory

Considerable evidence indicates that domain specific knowledge in the form of schemes is the primary factor distinguishing experts from novices in problem- solving skill. Evidence that conventional problem-solving activity is not effective in schema acquisition is also accumulating. It is suggested that a major reason for the ineffectiveness of problem solving as a learning device, is that the cognitive processes required by the two activities overlap insufficiently, and that conventional problem solving in the form of means-ends analysis requires a relatively large amount of cognitive processing capacity which is consequently unavailable for schema acquisition. A computational model and experimental evidence provide support for this contention. Theoretical and practical implications are discussed.

from Cognitive load(John Sweller, 1988)

So our schema is build by perceiving and processing information

Extraneous load — caused by how you consume information. Doesn’t contribute to learning.

Intrinsic load — is the load that contribute learning

Unified documentation will help to reduce our extraneous load.

You can read more about cognitive load here: https://en.wikipedia.org/wiki/Cognitive_load

So the novice need to jump from Reason to React, JavaScript and back cause it looks like JavaScript but it behaves different. At some point if they come back developer will learn OCaml and Bucklescript etc

So to help create schema for people and help create generation write blog posts, contribute, invest in tooling

Why We’re Afraid of Change

by Jared Forsyth

Would you rather have a community like npm, where there are hundreds of thousands of packages, but very few feel stable, or one like opam, with only a few thousand packages and a much more rigorous vetting system? How do language and community decisions affect the pull between security and freedom, safety and agility? Can we design a system that gives us both?

Jared started his talk with talking about dependencies, trust, and the social contract.

He talked about how libraries differentiate between their semantic versioning. Usually semver is author centric. “The only time i care about version numbers is when I’m upgrading”. That should not be the case and it should be treated by library maintainers properly. For example React and Reason-react projects follow the same idea. They approach very meticulously to differentiation between major minor or patch, add deprecation warnings and so on. Reason-react also often includes codemods for breaking changes to ease the upgrade process.

Essentially we want the following differentiation:

• major — dangerous
• minor — safe with codemod
• patch — safe

So how we catch breaking changes?

• type changes(caught at compile time)
• behavior changes(caught in tests)
• untested behavior changes(caught by users)
• breaking changes in a dependency

Elm’s publishing step for examples enforces semver

In Reason publish step we can run previous version test. If you don’t have tests than it’s more tricky.

Better solution

• encourage adding tests
• Limit breaking change or disallow them completely?

“what if we flip the old behavior with codemod that replaces new functionality to deprecated”

As a demo, Jared went through React releases breaking history and suggested how to do that without any breaking changes but with codemods as a result 11 breaking changes turned out to be safe and smooth with codemods.

For a bonus, Jared suggested that we should think about using opaque types to limit breaking changes. As for whats need to be done for Reason in general he suggested that there is a need to

• make a “reason publish” command
• make codemods much easier to do

Closing speech

After the round of applause organisers closed the conference with great closing speach and organisational info about the next day and after party.

Yes there was an afterparty 😊 We all headed to Leopold Cafe and had amazing dinner and round of drinks. It was really great to talk with all awesome people I’ve met. But this was not over. Third day was coming. And guess what, I was also presenting on that day 😊

Third day

Rest of the photos

Third day started at ImpactHub as a round of Open microphone sessions which were also recorded by organisers. List of sessions was pretty big and actually felt up all the time up till lunch. When videos will be up I will add them to this post

• Reason in React Native
• Choosing Reason
• Story time
• Bucklescript debug mode
• Demo next bsb release
• App shell
• Redex
• fastpack
• bsb — native demo
• react context in reason

I started first with Reason in React Native talk and then all other talks followed. People could choose to attend open mic sessions or pair on open source projects and contribute, create something new etc.

After lunch time we splited up into 2 groups and headed to our Vienna tour with our guide Max Stoiber and had a really great time exploring amazing city of Vienna. After several hours of walking sightseing, talking about Reason we were taken by organisers to Heuriger wine tavern where we celebrated 3 amazing days of ReasonML Conference.

Summary

I actually can’t express enough how amazing this conference was. Workshop, conference, hackathon, tour, organisation. Everything was just perfect and exceeded my expectations by far. Great thanks to organisers for making this conference happen. It was just awesome!