Paul Biggar - Darklang

Changes from the Dark rewrite

IF YOU USE DARK IN PRODUCTION, PLEASE READ THIS POST! We are approaching the end of the Dark backend rewrite (see previous updates: 1, 2, 3), which we are now tracking on GitHub. While there are still many tasks to be done, we're making progress and the end is in sight.

f#

How's the Dark rewrite going?

A few months ago I started to rewrite the Dark backend in F#. I'm currently about 60% of the way through the rewrite. All of the major components have been partially transitioned, and it's a question of finishing everything out. I'll discuss below some of the interesting technical things that

Why Dark didn't choose Rust

Welcome again HN! Dark is a programming language, structured editor, and infrastructure—all in one—whose goal is to make it 100x easier to build backend services. Check out the website, our What is Dark post, and How Dark deploys in 50ms for more. Thanks for checking us out! This

Dark's new backend will be in F#

Welcome HN! Dark is a programming language, structured editor, and infrastructure—all in one—whose goal is to make it 100x easier to build backend services. Check out the website, our What is Dark post, and How Dark deploys in 50ms for more. Thanks for checking us out! Part of

Leaving OCaml

Part of a 3 part series. Followups on F#, Rust I built the first demo of Dark in Python, in about two weeks. A few months later when I started productizing it, I rebuilt it in OCaml. Back in 2017, when I was considering the language and platform to use

Dark v2 Roadmap

tl;dr there's a Dark v2 roadmap now. There are a number of things missing for Dark to be able to have product market fit: Dark lacks SDKs for 3rd party APIsDark lacks a good user account/authentication storyWhile these are the major issues, solving these requires some more fundamental

benchmarks

FizzBoom benchmark (call for participation)

I've been working recently on a benchmark, to try and see how to get the most performance from the Dark backend. I've reimplemented the core of Dark in various languages and web frameworks, notably in OCaml, F# and Rust. As a reminder, Dark is a language and platform for building

Architecture

Adventures in Async

I was very recently the holder of three opinions: Rust is magic fairy dust that can fix all my problemsAsync is magic fairy dust that can fix all my problemsGraphQL is magic fairy dust that can fix all my problemsUnsurprisingly, all of these appear to be wrong. This post is

How to add a new feature to Dark

On Saturday, we had our third contributor meetup, this one was organized by Shahriyar Nasir (thanks Shah!). This time, we did mob coding to add a Tuple type to Dark, and we recorded the whole thing. A tuple looks like this: let x = (somevar, "a string", 567)A tuple allows

rust

First thoughts on Rust vs OCaml

I'm about two weeks into Rust now, so this feels like a good time to write a critique, before I get Stockholm Syndrome'd. My main motivation in learning Rust is that I have to maintain some of Dark's Rust code. There was a recent outage related to that code, and

Directions and roadmaps

There was a wonderful post just now that I saw on HN as I was procrastinating writing this post. It was by Tim Bray, and it covered my favorite topic, which is just how batshit cloud services have gotten, this time Traffic Director on GCP. I don't have anything more

Kubernetes

A fun bug

I'm always interested in stories about Accidental Complexity—when you waste time dealing with the endless layers of tooling that's required to make a web application today. I'm also super into using Observability (which I'll call to ability to introspect live systems, though that's not exactly right). Fortunately for these

Development

Evolving Dark’s tracing system

One of the things that makes Dark truly unique is what we call "Trace-driven development". The best way to write a HTTP handler in Dark is to start by making a request to the non-existent handler, then: using the 404s list to create the handlerusing the actual trace value to

Startup

First Dark contributor meetup

On Friday we had our first contributor meetup. Thirteen folks showed up to a zoom call to discuss how to contribute to Dark. Obviously, the point of the conversation was to get to know each other. We're all hanging out in the #contributors channel, but the room isn't super chatty

Development

Dark devlog #3: onboarding

An annoying thing about coding is that some days you're on fire, producing masterpieces, knocking down obstacle after obstacle. And some weeks, you're trapped figuring out bugs that ultimately come down to having a semi-colon out of place. Most of the time for me, the difference between the two is

Development

Dark devlog #2: what next?

After spending the last week on some extremely urgent things on my plate (helping the team get jobs, moving, infra stability, costs, and legal and transition work), I have time to get back to the product. There's still not a clear sense of what to work on next. The positioning

Startup

Dark devlog #1: fresh start

So right now Dark is made up of 100,000 lines of code, a hosted service with 6000 users, a 1600 member Slack community, 39 people who have contributed or intend to contribute to our repo, and 500ish "real" projects. And—as of recently—just me to build it. This

Startup

Dark and the long term

TL;DR: We’re taking a longer term approach to building Dark. As part of this, we’ve made the difficult decision to shrink Dark’s team, and to change how we build both the product and the company. Over the last few weeks I’ve been thinking hard about

Backend Development

Shortcutting a standard library

Coauthored by Julian Ceipek We recently decided to significantly expand Dark’s standard library. While our standard library has a lot of functionality for the Dark “framework”, including HTTP, worker/queue, and datastore functions, we were a little short on normal functions you’d expect from a “batteries included” language,

Sql

Compiling Dark to SQL

How do we make programs in Dark fast, while keeping complexity for developers really low? We recently shipped a new Dark feature that compiles Dark code to SQL. This post goes into the nitty gritty details of how and why we built it. First, let’s see it in action:

Continuous Delivery

How Dark deploys code in 50ms

Speed of developer iteration is the single most important factor in how quickly a technology company can move. Unfortunately, modern applications work against us: our systems are required to be live updated, silently and without downtime or maintenance windows. Deploying into these live systems is tough, requiring complex Continuous Delivery

Programming

Real problems with functional languages

And their influence on Dark After two decades of coding professionally in a dozen languages, I’ve come to a conclusion about static and dynamic types: Static types help you ensure that your changes work, especially for changes that span large parts of the program. This leads to long-term productivity

Programming

Tablecloth: a new standard library for OCaml & ReasonML

Tablecloth is an ergonomic, cross-platform, standard library for use with OCaml and ReasonML, which provides easy-to-use, comprehensive and performant modules, that have the same API on all OCaml / ReasonML / Bucklescript platforms. Tablecloth is not intended to replace your current standard library. Instead, it’s intended to be a smooth layer

Coding

What is Dark?

Dark is a holistic programming language, structured editor, and infrastructure, for building backend web services. It’s aimed at frontend, backend, and mobile engineers. Our goal is to make coding 100x easier, which we believe will allow a billion people to build software. This is a huge challenge, that requires

Elm

Philip2: an Elm-to-ReasonML compiler

In November, Dark made a decision to move off of Elm, and port our frontend to Bucklescript (aka OCaml, dba ReasonML). Being over 10kLOC, and having active development, it would have been error prone and difficult to port it manually. Instead, we wrote an Elm-to-OCaml compiler to translate it semi-automatically,