Paul Biggar - Darklang

Original and very badly restored version of Ecce Homo by Elías García Martínez

Try out the new Darklang backend

We're completing our migration to the new backend, which we've previously discussed a few times. Progress is going well, and all https://darklang.com requests (including all editor usage) have been served by the new backend for the last few weeks. Volunteer to switch overWe're looking for volunteers to switch

Darklang year in review - 2021

We just slipped into March, so this is as good a time as any to review what happened in Darklang in 2021. While the bulk of this post is technical details about the rewrite, I have included some company details at the bottom too. Enjoy! For context, Darklang is an

Darklang Community Meetup

It's 2022, and we're restarting Darklang community meetups! Update: here's the videoOriginal postWe've spent all of 2021 doing a rewrite of Darklang's backend. We're nearly done, and now it's time to start thinking about the future. Join us on Friday, Feb 4th at 3pm EST, for a community meetup over

Benchmark performance results. See data tables belo

Backend

Benchmarking F#6 Tasks

A lot of new performance-related stuff landed in the F# world recently. As well as the release of .NET 6, F# 6 was recently released, with built-in, highly-optimized "Resumable Code" Tasks. So let's measure it.

How to fund CaramelLang?

and should it be open source? I'm taking a break from reporting on the progress of Darklang (it's slow but steady) to write up some thoughts on an interesting question. This weekend on Twitter, Leandro Ostera asked how could it be possible for him to work on the Caramel programming

The Chariot Race, Alexander von Wagner, 1882, featuring chariots racing in the Roman Colosseum

Optimizing Tasks in F#

I recently went through an optimization exercise. As part of Darklang's rewrite in F#, I needed to make sure that my new code was as fast as the old code - or at least, not horrendously slow. A quick load test revealed the worst: the new code was absolutely, pathetically

rewrite

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,