All posts

What if type inference felt like a real-time conversation, instead of emailing code back and forth?

With type inference, compilers are faced with a difficult task: intuiting what types a user had in mind (but didn’t write down) while writing some code. It all falls apart when the types that the algorithm assigns are different from those the user expected, and especially so when the type error reported is far away from the site of mental mismatch.

Unison is doing a lot of interesting things, and as I recently implemented an alternative runtime in rust, I have some insight into what’s going on under the hood 😉. Here’s my attempt to sum things up.

I’m excited to review Hypermerge, as it was developed by the folks from Ink & Switch who wrote the Local-First Software article. It is designed as a fully peer-to-peer data storage system, and is electron/nodejs-only (no browser support).

The underlying data structure implementation, Automerge, is based the academic research paper A Conflict-Free Replicated JSON Datatype, and can be used independently – in fact there are a couple of different “networking” layers available – but Hypermerge is by far the most well-developed and “production ready”.

remoteStorage.js is a an offline-first solution that’s been around for quite some time, and stands out for having a formal protocol spec, first drafted in 2012. It would be really cool if it took off, but unfortunately there are only one or two commercial providers, and the only stable open-source server implementation is in PHP. There’s one written in rust that has been unmaintained since early 2018, and a nodejs one that has a big warning up top about being experimental & alpha-stage. Still, I figured it would be interesting to see how it stacks up according to my local-first database criteria. You can also look at the evaluation of gun-js to see how it compares.

Gun.js is an open-source project I’ve had my eye on for several years now, every once in a while checking back to see how it’s progressed, and whether the project I’m working on at the time is a good fit for it.

Gun stands out as one of the few players that’s actually delivering a peer-to-peer / decentralized system that works on a large scale.

Using my criteria for a local-first database, here’s how it stacks up:

I’ve been wrestling with the issue of “data storage that syncs and works offline” for a number of years now, and have gotten 80% of the way on a few different implementations, but always ultimately get stymied by the little things, like “how do I make it not break”.

Recently, I’ve been re-energized in my search by the wonderful Local-first software article by Ink & Switch, and then by James Long’s dotConf talk, CRDTs for Mortals.

So, you’re writing a destributed system local-first app, and you’re sending events back and forth between various clients and the server. One thing you’d really like to be able to do is determine the order in which events happened – this is important for the “last” part of “last-write-wins” CRDTs, for example. So you add a timestamp to each event as it’s created, and all is well.

One of the things that keeps coming up as a pain point in Reason development is the boilerplate involved in parsing & generating JSON. Whether you’re using JSON for a REST api, or an on-disk file format, JSON is ubiquitous, and if you’re coming from JavaScript, you’re used to it also being painless! Because the data objects you’re working with are immediately serializable to JSON and back.

Milk 🥛 is a new tool I developed that generates serialization and deserialization code for your Reason/OCaml types, including types from arbitrary external packages, and it manages migration when the types change.

I just spent the past two weeks building a GUI Rust app to help you generate a 3-d model of terrain from around the world, that can then be used for 3-d printing, rendering, or whatever you like.

One thing that you’ll run into when interfacing with complex javascript objects in Reason, is that dealing with optional objects can be a huge pain. The most common place to run into this is when using the excellent graphql-ppx syntax plugin (often together with reason-apollo), because the result of a graphql query is a large complex javascript object, with many parts of it that are optional.

I’m planning to do some fancy social science analysis of the results, but first I’ll just give you a dump of the summary data that came out of this.

First of all, there were 398 responses! Thanks to everyone who contributed :)

I’m working on a new ReasonReact project that will need a stateful server, and I thought it might be nice to write that in Reason too :) but what’s the best way to deploy it? And by “best” I mean “easiest, with a free-to-try option”. After looking around a little, I settled on Zeit’s now.sh.

What did I end up with? A 10mb docker image with a server inside!

I recently released a tool that will manage all of this stuff (see the accompanying blog post), but I figure it’s good to document what I went through for future ocaml cross-compilation spelunkers.

I launched the first cross-platform mobile native game written in Reason a few weeks ago 🎉, to the Android and iOS app stores, with a free web version and a macos desktop bundle (source code all on github).

Getting there required lots of fiddling with cross-compilers and build systems, and so I made a tool that will take away much of the pain involved, so you can get started immediately and get your game into the world. NB: This is still super experimental but I’m really excited about it and want to get y’all in on the fun.

Lots of people have come into the discord channel asking about how to elegantly deal with async things. We’ve got Promise.then_ and good old callbacks, but having a syntax like async/await can really make things nicer when you have a lot of async going on. So far in the web clients I’ve made, there hasn’t been enough asynchrony to really feel that pain, but I thought it would be an interesting challenge to tackle anyway.

After jumping into ReasonReact, I soon came to the question “How do I do higher-order components?” I had some duplicated logic in several components regarding data fetching, and I wanted to use this familiar React tool to refactor.

To illustrate, we’ll be making a “fetches something from the network” wrapper component. We’ll start with a “mixed component” that we’ll then try to refactor.

Are you a big fan of React, and want to know more about Reason/OCaml? I made this for you!

This tutorial was updated on April 20, 2019 for reason-react version 0.7.0, and React hooks! If you want to see what it was like before hooks, here's the previous version

Reason is a project that adds a JavaScript-style syntax and a bunch of conventions and tooling to OCaml. The goal is to make this awesome language, with its powerful type system and robust multi-platform compiler, accessible to a broader audience. It's backed by the good folks at Facebook who invented and built React, and so naturally having best-in-class React interop has been a high priority.

This tutorial aims to give you a nice introduction to the syntax and type system of Reason, through the ReasonReact library. We'll be building a simple Todo list application.

Someone came into our discord channel a few days ago asking “Is Reason suitable for migrating a large production JavaScript codebase incrementally?” I answered “Yes, but wait 6 months.”

What’s the current status? At the moment, we’re mostly in the realm of “enthusiasts who are OK with being on the bleeding edge, and want to help build out the foundation in their spare time.”

A couple of people have shown up in the discord channel asking whether Reason has macros, and the answer is “sort of.” I think we can do better.

I just wrote my first Reason project that compiled to native, and you can too! Luckily for you, my first native project was a cli tool to help people get started with native Reason development 🙌.

A couple of people have asked me how to get up and running recently, so I thought I’d put something together. If you’re looking for a “just clone this repo & go”, here’s a very simple boilerplate I put together for this post, or you can check out the reason-react-example repository.

So you’re all ready to write some Reason but you need to call a JavaScript function? Or maybe you can’t figure out how to write something in OCaml-land and wish you could just bail for a minute & write it in JavaScript? Fortunately, both of those are fairly easy to pull off.

Last week, my coworker Charlie asked what it would take to automatically detect and purge unused aphrodite styles in our codebase.

If asked 2 years ago, I probably would have gone with a regex and a string-munging python script, but I’d just spent the past few nights messing with babel plugins, and figured I could probably get pretty far with relatively little work. As it happened, I was impressed by how easy it was using the tools that babel provides.

As a bonus, it also works with React Native because they have the same API, and it could probably be extended to other libraries without too much work.

I’ve expressed multiple times that I really want to get into clojurescript, but I keep running into barriers.

My background: I’m an experienced JS dev, and for my personal projects I use the latest & greatest of React, Flow, Babel, and Webpack, which makes for a pretty rocking experience. Given my background, lots of my hesitation could just be the fact that staying in my comfort zone of javascript is easy, though it may be far less simple than the experience provided by clojurescript.

By the end of this post, I hope I will have convinced myself to face my fears and dive into clojurescript anyway :D

Reactive Programming is getting a lot of attention these days, and it promises to reduce frustration, bugs, and greenhouse gas emissions. Unfortunately, there’s a sizeable learning curve involved while you try and get your head to think in streams instead of imperative sequential processes.

For the web-based everything notebook that I’m working on, I’ve been writing backend hookups to various programming REPLs, including IPython and Gorilla. I wanted to be able to evaluate rust code as well in this notebook environment, and so I set about writing a simple server that would compile up a string in rust when asked. This proved do have a couple of gotchas, so I thought I’d air my thoughts here.

My blog used to use Hyde, a python clone of the popular jekyll platform. When Ghost came out, I quickly switched over, due in main part to the great editor and beautiful themes. I used buster to serialize the blog so that I could still serve it as a static site. I had two main regrets, though. 1) using buster to scrape ghost was a hack. 2) My posts were locked in an sqlite db, where git could only do a binary diff.

I recently switched from ghost to hexo, and the biggest thing missing for me was the editor interface. So I made one. Currently, it’s mostly a clone of the Ghost interface, but I have some ideas for making it even more awesome.

Go and Rust seem like natural competitors. They are both trying the role of a C-like low-level language with modern affordances, safety, and nice, clean concurrency. And they’re each backed by a major player in the browser race - go by Google, rust by Mozilla.

A while ago, I made a cellular automata simulator in Go, inspired by this video about a “rock, paper, scissors” simulation, where there are three “species” of cells which consume each other.

Last week I rewrote this in Rust,

The perceptron is one of the most primitive learners, and is also of the easier ones to understand intuitively. I’ll first give some background, and then an animation in javascript with 2D data, and an implementation in python, with graphs of it running on some traditional datasets.

A few months ago I saw @scanlime’s “Zen Photon Garden” on hacker news, and was really impressed. In short, you draw walls/mirrors with your mouse, and it ray-traces light from a central source. Very beautiful and “zen”. However, as a programmer, drawing lines by hand was far too inaccurate. So I forked it and added a scriptable interface for adding walls.