Dark Blog

Congrats on Dark for making it this far!

Relevent timeline:

https://blog.darklang.com/dark-announces-3-5m-in-seed-financing/ (2019)

https://blog.darklang.com/dark-and-the-long-term/ (2020 - in which the team is fired to extend runway I guess to today)

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." So where do we go from here? Right now, the team is just me. I am committed to realizing the full vision of what Dark should be. Dark is financially healthy for many years, and there is time to think and to plan. I plan to involve the community much more in Dark’s growth, and slowly rebuild the team at a pace appropriate to the product’s maturity, focusing on a small, tight team that can wear many hats. Then there was a pivot to a rewrite of the whole thing, which I think was just Paul at the time:

Start of a new rewrite: https://blog.darklang.com/dark-v2-roadmap/ (2020)

Two years later: https://blog.darklang.com/backend-rewrite-complete/ (2022)

seemingly a new pivot to "all in" on AI?: https://blog.darklang.com/gpt/ (2023)

No news, one year later https://blog.darklang.com/an-overdue-status-update/ (2024)

Would be interesting to the Dark team to revisit this post, which is a look at PL funding models:

https://blog.darklang.com/how-to-fund-caramel/

Building programming languages is hard especially when you're not…

The problem with OCaml is not multicore. If it had an easier to use build system and a larger community (so more libraries), it could be great for server-side software. But dune is way harder to use than Cargo and you can often miss libraries. Here's an example of Dark moving away from OCaml to F# https://blog.darklang.com/leaving-ocaml/, which doesn't have as much this problem because you can use C# stuff. Scala also doesn't suffer as much from it, part of it because it was really popular at some point, and part of it because you can use Java anyways.

I hope at some point we'll have this "garbage collected Rust", but for now OCaml, Scala and F# all have a worse developer experience than Rust. I could add Haskell to that too.

I've been thinking for some time that something like Go but based on a ML would fill this "garbage collected Rust" niche quite well. Maybe something built over Rust itself to leverage all the ecosystem? You could write all of the glue code in this language, have access to a large ecosystem of libraries and have an option for high performance code. This would also complement Rust nicely: I know that OCaml has a really fast compiler, which would be a breath of fresh air for the community.

That's a pretty weird takeaway considering the long and detailed post on OCaml's issues that motivated a full rewrite: https://blog.darklang.com/leaving-ocaml/

> One of my biggest annoyances was how often OCaml folks talk about Fancy Type System problems, instead of how to actually build products and applications. In other communities for similar languages (ReasonML, Elm, F#), people talk about building apps and solving their problems. In OCaml, it feels like people spend an awful lot of time discussing Functors.

In whatever case, it appears that the author's preference was F# > Rust > OCaml.

I don't have a problem with garbage collectors in general, but that's only one facet in deciding a language. There are lots of more important facets, and OCaml fares pretty poorly at these (e.g., tooling, ecosystem, community, pace of improvement, mindshare, etc).

And for language toolchains in particular, I wouldn't lock myself into a language with suboptimal performance--it's too hard to back out of that decision later, and it's easy enough to recoup some of that pace of development from Rust by just refcounting everything today if necessary (optimize it later).

I spent some time last night looking at it. Just to affirm what you're saying, there's hardly any information on their frontpage unless you go venturing into videos and blog posts.

Dark is basically a language that's designed to be serverless out of the box. They've baked their own engine into the language as well as dependencies for various cloud providers, databases (postgres was highlighted a lot), etc so that you can build serverless applications quickly while having no knowledge of operating systems, infrastructure, or really even computer science.

It reminds me of a number of the languages out there that are low-code or no-code. A regular programmer probably wouldn't even recognize some of the syntax and symbolization this language uses.

Here's some examples: https://blog.darklang.com/spin-up-a-slack-app-in-seconds-with-dark/
Most of us have probably built a Slack app by now (or bot) so this is a good example to compare with IMO.

Dark has a mission of appealing to 1B people and they say the first step is to appeal to developers.

Ultimately it was a no-brainer to choose F#.

Their current code base is in OCaml. Porting code from OCaml to F# sounds about as painful as moving from Python 2 to 3[1], which while painful, is waaay better than a total re-write. F# has much better libraries and ecosystem (because it is built on .NET). Their frustration was with the libraries and ecosystem of OCaml, not its syntax[2]. So, if they switch to F#, much of their core logic remains syntactically the same, and simply needs reworking (rather than rewriting). They also have to retool/call .NET libraries instead of C/OCaml ones, of course, but this is really the point of the move anyway.

So: better libraries for what they're doing, not a total rewrite (just a re-work), preserve the overall codebase's structure, less disruption. It just makes good business sense to me.

[1]: https://stackoverflow.com/questions/4239121/code-compatibility-between-ocaml-and-f

[2]: https://blog.darklang.com/leaving-ocaml/

It looks like Dark is trying to be a new language, a backend server, a CI solution, and an IDE! Then there is a blog post that everyone churns:

> Currently, we get 10 user signups a day, and on average, 0 of them stick. We do have developers who love Dark, but not enough.
https://roadmap.darklang.com/goals-of-dark-v2

I think the company should focus on just one of those things and it would still be an enormous lift given their size.

> The problems and fixes are across the product. One problem is that undo is slow, another is that you can't put a minus sign in front of an integer, another is that we need to define how namespaces will work in the package manager. The fixes range from adding tooltips in the UI, to adding a type-checker, to making the package manager public.

https://blog.darklang.com/dark-v2-roadmap/

Ayeeeee... this is like trying to carve Mount Rushmore using a spoon.