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:
While these are the major issues, solving these requires some more fundamental changes. As well as simply making the package manager available, we also need to improve on the tools that developers have for building packages, everything from how packages coexist with other functions, the types available to packages, and how to support collaboration on those packages.
Similarly, there is a bunch of tooling needed before we can build a good user authentication story. Dark needs the ability to define HTTP middleware (we need to decompose the existing HTTP framework into middleware), as well as better types. Each of these changes then depends on further changes — you need a good language to have good APIs. …
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 backend web services and APIs. Implementation-wise, it’s basically an interpreter hooked to a webserver and a DB. The language is a statically-typed functional, immutable language which is garbage collected.
Dark users can write arbitrary code that runs on our server, including making HTTP calls to slow and badly-behaving 3rd-party web servers. …
I was very recently the holder of three opinions:
Unsurprisingly, all of these appear to be wrong. This post is about the first two.
In the journey to get to product/market fit with Dark, I’m taking a slightly different strategy than we took before, which I’m calling “Hard Things First”. Repeatedly with Dark we spent significant time coming up with hacks to work around previous hacks which themselves were working around previous hacks. That made for a codebase where people can only contribute is well-defined ways, as going outside the box was to invite madness. …