Dark Matters

First impressions

Dark is a new programming language / editor / continuous delivery / infrastructure solution. It aims to combine all of that. Yesterday, the company behind it released two videos that shed some light on everything they have been working on. In this post, I’ll quickly jot down my first impressions.

I first learned about the existence of Dark after Sarah Drasner (follow her) tweeted this:

I’m a sucker for new languages. I should know better, but I always hope for the golden hammer that will make everything simple again, so I’m like:

In hindsight, it is quite a bit more than any of that.

The language I was waiting for

Before I get into some of the things it’s offering, I have been waiting quite a while now for a new language that:

• Will be a comfortable home for anybody who — like me — got shamed out of using CoffeeScript.
• Uses whitespace in a meaningful way.
• Has just one valid way of writing it.
• Blends in nicely with the JavaScript ecosystem: I want my code to run both in the browser and on the server.
• Has no classes, but instead has variants and records like in ReasonML.
• Supports pattern matching.
• Promotes immutability.
• Is expression-based.
• Always returns the last expression in a sequence.
• Supports options and results in a way that is similar to Scala.
• Is extremely fast to compile. (I’m looking at you TypeScript and Scala.)
• Supports the model behind JSON as a first-class data-type, preventing you from having to jump through hoops to simply access some properties or to build a JSON structure. (I’m looking at you, all statically typed programming languages except TypeScript, but including Scala and ReasonML.)
• Does not require any configuration at all. (I’m looking at you Babel and TypeScript.)

The language I got

So, whenever a new programming language is getting introduced, I always hope it’s exactly that. Now, Dark doesn’t seem to be quite that, although, just by looking at the syntax, there is some overlap. Some of the things that I picked up from the video:

• Option and Result types instead of null and exceptions. (Yay)
• Records and enums instead of object orientation. (Yay)
• Functional. (Yay)

Now, with the release of the videos, the team did not release a language specification, which would have been nice. But then again, perhaps they couldn’t, because Dark is tightly integrated with the editor — which itself again is tightly integrated with the deployment process.

What else did I get?

Let’s talk about that a little more, because — as I said — Dark is more than a language. It’s trying to solve a much bigger problem, which is hiding the complexity of everything that we have to deal with to get our code in production.

In a previous article I wrote, I mentioned that — perhaps — there is an abstraction layer and programming model that would allow us to collapse the entire suite of things we need to know about now into that abstraction layer, allowing us to focus on the things we care about most: shipping working software to our customers. Dark is aiming for exactly that.

This changes a bunch of things:

• Dark doesn’t need integration with Git. It handles versioning on its own, and it cleverly bakes a concept of feature flags into the platform, which presumably takes away the need of having feature branches. It did leave me with one question: how does it handle concurrent updates to your code?
• Dark is taking care of deployment. You don’t know where it’s going, you don’t know what it is using for running your code, Dark will just take care of it. And since it is in control of it all, it also can capture the data of anything executing your code, and bring that back to the editor. As a result, inside your editors, you can how actual invocations pass through your code, which is very helpful.
• If the service running your code is getting invoked and it doesn’t know how to handle it, it will automatically suggest implementing that endpoint, and then basically write the outlines of that code for you.

My thoughts

So far, I have just seen the two videos that were released yesterday, and I briefly went through some blog posts in which the team explains some of the design considerations of the language. That’s a disclaimer. I’m sure my opinion will change once I get to see more of it.

• Just being able to implement HTTP handlers and worker callbacks seems a little too limited for my taste. I haven’t seen any way to break down complexity in a sensible way. Which is all the more relevant because:
• Dark has no way of integrating with other languages. The only way to integrate with other code written in another language is by integrating it using HTTP.
• Which makes you wonder how you’re going to be able to do anything that has a bit more algorithmic complexity. In my past, I wrote some services to decode PDF and TomTom map data. How on earth would you do it based on Dark?
• In the demo video, Ellen Chisa demonstrated how to store and retrieve data. Dark is not only taking care of deploying your code but also offers data storage and the interface to interact with it. But in my experience, there is no single type of database that fits all my needs. How am I supposed to deal with that? And if I would be able to call out to databases hosted in the cloud, would that require going through the APIs provided by the platform?
• All of that made me wonder to what extent you would even be able to stay within the environment controlled by Dark. And if you would take the suggested approach, and rely on HTTP to integrate with other services, how would Dark code not quickly become the configuration of an HTTP gateway?
• Dark is currently limited in its scalability.
• Dark is owned by a commercial company, and it’s not freely available.
• Given all of the above, you start wondering about the sweet spot for a solution like Dark. And I hate to say it, but it reminded me a lot of SalesForce. Think about it: with SalesForce, you already have a system that offers you a solution to build APIs on top of the data stores they manage. Just like Dark, it takes care of version management in the platform itself. And just like Dark, it allows you to quickly deploy your code to production, all from a SalesForce controlled development environment.
• The big difference between SalesForce and Dark is that I would prefer to never use SalesForce for anything real, but I’m strangely attracted to (the) Dark (side).

If anyone would ever compare a product I’m building to SalesForce, I would be offended, so I can imagine the above coming across in the wrong way and overly negative.

The truth is, I am not that negative at all. I admire the ambition and the approach, I love what I have seen from the language, I love the attempt to knock out some bits of complexity that are merely getting in the way of getting things done quickly, and perhaps anything that comes out of that automatically resembles SalesForce. I will have to think about that. (And SalesForce should consider investing in Dark. Or otherwise, IBM, to have something to replace API Connect. There you go, some free investment advice. You’re welcome.)

So in summary, I think it’s too early to tell if Dark is going to cut it for me in the long run. I would love to see a language specification and would love even more having the opportunity to give it a shot.

If you’re interested and if you want to learn more about the language and you’re looking for people who are much better at it than I was, then you should probably watch the videos listed here.