
How Dark Deploys Code in 50ms - craigkerstiens
https://medium.com/darklang/how-dark-deploys-code-in-50ms-771c6dd60671
======
koliber
It's an interesting concept that flips many things on its head. We're getting
some real hard-to-achieve benefits out of the box, while sacrificing a lot of
things we used to take for granted.

One thing that I notice is that Dark requires a completely walled in
environment to be able to deliver all of its promises. In reality, any real-
life project has to interact with external services, legacy systems, or custom
peripherals which are unlikely to be based on Dark.

How will Dark be able to handle such cases? Current tooling and processes are
able to cope with such things through custom, hand-crafted, and as the article
stated, often fragile, systems and processes. The are a pain, but they get the
job done. They are very versatile by their nature. While they break more often
that we would like to, they can be patched up well enough to band-aid over
rough patches and adjust to surprising externalities. Dark seems to have one
way of doing things, and I am curious how compatible that way is when it comes
to interfacing with external systems.

~~~
btown
It seems that Dark is designed to allow you to wrap external APIs in easy-to-
use interfaces, so it should be at home as part of a larger SOA or ecosystem,
of course with the caveat that it's still being developed. See the footnote at
[https://medium.com/darklang/dark-
residency-7dbc878a5f0a](https://medium.com/darklang/dark-
residency-7dbc878a5f0a) .

~~~
pbiggar
Yes, that's exactly right. Dark speaks HTTP (and at some point, will speak
GRPC, Thrift, etc) so you can access 3rd party services over HTTP (and wrap
them in SDKs in the Dark package manager, same as on npm).

We expect we'll have some built-in support for common things (resizing images
and videos, or generating pdfs for instance; we already support static assets
on a CDN).

~~~
simonebrunozzi
Hey Paul, nice to see you here on HN. Very promising start!

What's the best way to contact you? (I'm $HNusername @ gmail).

~~~
pbiggar
Thank you! I'm at
[https://twitter.com/paulbiggar](https://twitter.com/paulbiggar) or
paul@darklang.com.

------
burlesona
First I’ve heard of Dark. The blog post is cool, but reading it I felt two
main things: (1) no pull reviews would be terrible for a team, and (2)
everything being instantly live in prod and automatically versioned etc sounds
like a nightmare once you move beyond a simple program.

Reading on Darklang.com I see they kind of address this. The ecosystem they’re
building is training wheels for developers, a way to make “coding 100x
easier.”

I can see that working in a sense, and being an entry point that a lot of
people use to make neat toys. I could even see it being a gateway that people
use to get interested in and learn about programming. But I can’t imagine
wanting to build a business with more than one programmer, or any kind of
scale on a completely black box system like that.

I will also say, there’s a problem when it comes to entry-level systems,
trying to teach people to code:

The struggle with the complexity is actually important. Dark isn’t actually
making all the work of building and running a web application go away, it’s
abstracting it all into a platform such that you can’t see it.

Suppose a person gets into coding self-taught and learns to work this way. The
knowledge isn’t going to be very transferrable - ie when they look at other
languages or systems they’re likely to struggle with problems like “what does
prod versus dev mean, I just want my program to run for the world...”

You usually move knowledge between ecosystems by translating “I did it this
way in (toolset A), so what’s the parallel in (toolset b)?” The more you have
an idea of the underlying principles the easier this is to figure out.

That said, Dark certainly looks neat, and I imagine the implementation is
quite cool.

The only other nit I’d pick is the name. To me, its not really a language, but
maybe a development environment, or framework. I suppose it had a language in
it, which I’d probably call DarkScript or something.

~~~
pbiggar
Author and Dark CTO here.

> Reading on Darklang.com I see they kind of address this. The ecosystem
> they’re building is training wheels for developers, a way to make “coding
> 100x easier.”

No no no no no. This is not what we're doing. We're building something for
experienced software engineers. (New developers will be able to use it too and
it should be much much easier for them than learning in other ways, but that's
a secondary audience).

> Dark isn’t actually making all the work of building and running a web
> application go away, it’s abstracting it all into a platform such that you
> can’t see it.

Some of it is being abstracted, but a lot of it being properly removed.
Servers are abstracted, but almost all of actual deployment is actually being
removed.

------
sciurus
How does Dark handle code review?

Even if I was willing to accept the other tradeoffs that come with Dark, I'd
want another human to approve my changes before that 50ms deploy to production
kicks off.

~~~
pbiggar
The model is quite different to how people write code today. Instead of a
process that takes code from your machine and sends it to prod (and thus has a
lot of risk), you code in a sorta sandbox _in prod_. That is then enabled for
users via changing the feature flag setting.

So to do code review, you write the code behind the feature flag, then ask
someone for code review. (There's google-docs style collaboration, so they can
see your code if you permit it). After code review, you can "merge" by
toggling the feature flag, or changing the setting to "let 10% of users see
this" or whatever roll-out strategy you want.

just safely. So you're writing code behind a feature flag (but "in prod"), but
no users can see it.

~~~
theamk
So what protects you from accidentally doing “DELETE TABLE users” on prod?

In traditional design, there will be pre-commit code reviews and staging env
with limited access. But looks like Dark get rids of all of this?

~~~
pbiggar
Good question. The answer to most questions like this is "it'll probably be
the same as now". I know it seems like everything is different, but we're not
really trying to invent much new stuff, only what's required to take stuff
out. Whenever things from today work, we'll keep them. Core review, testing,
ways of preventing deleting everything on prod; they're all valuable.

------
nlawalker
Sounds cool, seems like an interesting set of tradeoffs that nobody else has
tried yet.

From what I've read so far it seems like Dark is a good fit for prototyping,
experiments, and small products and teams that "move fast and break things".
Would you consider it a good fit for large teams and applications, where
different people own different components and reliability is the most
important metric? A lot of the accidental complexity in the "standard issue"
continuous deployment process detailed in the post is there to prevent
accidents and enforce permissions.

~~~
pbiggar
Yeah, all this stuff is actually designed for large teams (though, it'll be a
while before Dark is production-ready enough for them). CD matters because it
allows you deploy in small chunks which is much less risk than deploying in
big chunks.

The feature flag is a thing that you might not need if you're small, but it
completely changes how large teams work. Same with DB migrations: if you have
a small amount of data you can just do a schema migration and the locking wont
affect you too badly.

We'll have a permissions model at some point that will take care of the
ownership problem. We designed Dark to allow extremely fine grained ownership,
for example allow a contractor access to a single HTTP route or function.

Overall, this is kinda similar to how we went about building CircleCI. We
focused on good tooling for companies (eg parallelization and speed) instead
of individual projects (eg build matrices).

------
juandazapata
Given how tightly coupled is Dark with its IDE and deployment environment, I'm
interested in knowing how much VC money have they taken? What if they get
acquired or simply shut down?

It looks like there won't be a migration path, and you'll need to rewrite your
app from scratch using a different language. Again, it would be nice some
transparency around how much VC money they've taken.

~~~
pbiggar
The sustainability of Dark is super important to use. We're not fucking around
with customers' livelihoods.

For our early customers, we have a handshake agreement that we won't leave
them hung out to dry. If Dark was to shut down, we would 100% make sure they
had the time and ability to port their app off. There would be a time cost to
them of course, so it's not perfect.

As we get closer to opening up to the public, we'll be doing a bunch of work
on the sustainability question so we have good answers to the "acquired or
shutdown" problem. We imagine a legal framework to protect customers, but
haven't got the details worked out.

~~~
londons_explore
A legal framework doesn't help much in the "bankruptcy" case. Unless that
legal framework means all IP becomes open source and people can self-host I
guess.

------
voidr
> When you write new code in a function or HTTP/event handler, we send a diff
> of the Abstract Syntax Tree (the representation of your code that our editor
> and servers use under the hood) to our servers, and then we run that code
> when requests come in.

You can achieve the same result with PHP and FTP, however once you start
adding unit tests and branching, that's when things start to take time.

Long builds aren't necessarily a problem if they give you enough in return.

~~~
jrockway
I am not sure people are getting these results with PHP and FTP. Sure, the
build time is zero seconds. But each page load takes 100ms because it's doing
the same work over and over for every request. Yes, even if you cache opcodes.
We have a legacy PHP app and an "echo hello world" request takes 100ms. An
extremely complicated request then takes 102ms to process. It is shockingly
slow, but it is not something you will notice unless you have a lot of
instrumentation, so you might be lead to believe that your performance woes
are caused by something else.

~~~
vrodic
You must be doing something wrong. There's a lot of overhead for frameworks
like Symfony, yes. But it's possible to write reasonably productive and modern
website code where you can get sub 20ms responses (doing auth, fetching from
db, processing and rendering html). I know because I've done that, on PHP 5.4.

~~~
bbmario
Full checkout experience here, 18ms average. PHP 7.3, Symfony.

------
vinceguidry
I'm getting _really_ tired of learning new languages / stacks every few
months. I want _one_ language to write things in. It has to be a pure-OO
language and right now that's ruby. I want to edit that code with _one_ code
editor. Syntax awareness is a nice-to-have but not essential. At the moment my
editor of choice is Sublime Text 3 but to extend it I need to write python
which is unideal. When I start writing websites it'll be hyperstack.

Unless your new language can fix _all_ my issues, be open source, and be my
One True Human Interface to All Things Machine, I'm going to keep building on
ruby, with occasional bash / crystal / rust excursions for speed.

Is your language pure-OO? Do you have gradual typing? Does it run on a common
VM? Am I going to have to rewrite everything I'd ordinarily bring in a library
for? I can accept every single one of your claims but still not be interested
in learning _a whole new stack_ because I can already deliver stuff quickly
enough with the one I've been iterating on for a decade. Especially when it
could end up orphaned in 3 years if it doesn't get enough adoption.

I'm not saying your holy grail can't be holy enough. But it has to be pretty
darn holy.

------
z3t4
Syntax errors are the easiest errors to fix and almost never get into
production.

Zero downtime deployments are very rare, and ads a lot of complexity, so it's
a big trade-off, compared to just uploading the new code and restarting the
service. And having the front-end deal with minor hiccups like service
restarts, because users will have such issues all the time due to being on
mobile networks, trains going through tunnels etc.

You can do as much testing as you want, both manually and automatically, but
you still can't detect all issues as efficient as thousands of users in
production. So just accept that there will be issues, and instead design your
pipeline so that those issues can be fixed within minutes.

~~~
snypox
> Zero downtime deployments are very rare

What do you mean? Rolling deployments are a very basic feature of container
orchestrators.

~~~
z3t4
If you aim for zero downtime there will be a point where the complexity work
against you. for example: load balancer goes down, corrupted state due to two
different versions running simultaneous, a bottleneck causing congestion, etc.

My favorite "load balancing" for web-pages is using "DNS round robin" where
you add several A records, and the browser automatically try another IP if the
request fails.

~~~
sneak
The browser does _not_ try another IP if the request fails; it tries the first
one only (the DNS server chooses a random order for the response), unless
browsers have changed their behavior recently.

DNS round robin is not failover. If one of your four A records points to a
dead box, 25% of your customers are SOL.

~~~
duncaen
[https://en.wikipedia.org/wiki/Happy_Eyeballs](https://en.wikipedia.org/wiki/Happy_Eyeballs)

Browsers even try other IPs and alternate between IPv4 and IPv6 before the
connection is established.

~~~
sneak
I know all about this, but most websites only support v4, and I don’t think
this is used in any way for choosing which A record to use.

~~~
duncaen
Most websites don't have redundant servers but its still there and used by a
lot of big sites.

The whole point of it is to connect to multiple A and AAAA records with a very
short delay (250ms in chrome). The browsers use poll to get notified about the
first established connection and then use it. So if one A/AAAA records IP is
unreachable or slow it will use a another one. There will be no fallout
(except maybe for clients that don't use something like happy eyeballs, but
any browser does that) if you have multiple A/AAAA records and one of them is
down.

------
module0000
Hrm...we don't deploy code in _to prod_ in 50ms, but we certainly deploy to
dev/staging/testing in <1s, and promote to prod once we are 100% sure we want
to do so. We use the boring, industry-standard tooling and process everyone
else uses (Jenkins, k8s, Ansible, nothing bleeding edge). I'm unsure what
advantage their product has that makes it stand out among the battle tested
tools already in use. Would someone elaborate?

disclaimer: working for a l2 network provider, and a mistake costs us
infinitely more than an _" Oh we're sorry!"_ can fix.

~~~
ukd1
The point is all that stuff (jenkins, k8s, ansible) is accidental complexity
that, I presume someone at your company has-to/had-to think about. I think
Dark's angle is it's stuff you shouldn't need to think about in order to solve
the actual problem, and removing as much of that as possible is better.

~~~
alexandercrohde
Okay, I mean conceptually cool, but it's not like an existing startup gonna
throw away all their code and rewrite it to save on dev-ops time.

I guess the value prop is that if you're starting from scratch, and want to
write _your whole app_ in Dark then you can avoid hiring a dev-ops engineer
and iterate faster?

Seems like a stiff trade-off. If it's an interpreted language you're coming
from, setting up envs can be < 30 secs anyways (and same with prod deploys),
so that's faster than you need.

If it's a compiled language you're coming from (e.g. scala/c++) then it's
likely Dark may not match your needs.

Plus I guess this assumes every team in your company is using only dark? Like
what if it's a SOA and a full environment has a node component?

------
adrienjt
How coupled is Dark with the Dark language? I understand that the purely
functional nature of the language makes its integration with the rest of the
platform easier, but the blog post doesn't go into much detail about that.
What would it take to integrate Dark with: a) another (existing) purely
functional language, and b) a general-purpose language, e.g., Go? Could a code
intelligence tool like Sourcegraph help?

~~~
pbiggar
Extremely tightly coupled. That's kinda the point "what can we do if we don't
have to couple dark to anything else" (eg editors, other languages). I can't
imagine how you'd couple Dark to another language, but I also don't see the
point?

~~~
adrienjt
Thank you. My point was risk mitigation, which I discussed in another reply
(which you answered:
[https://news.ycombinator.com/item?id=20399267](https://news.ycombinator.com/item?id=20399267)
)

~~~
pbiggar
Yeah, the bigger picture here is that there's a ton of valid reasons why
people can't use Dark right now. Of course there is, we're a small team with
an early product. Once we show that this is really a better/faster/easier way
to make backends, then we can start working on handling the risks and
constraints of more teams.

~~~
adrienjt
That makes sense. It does look like you're very close to that first objective
though. Congrats! Your blog post very clearly describes what Dark actually is
(which was still unclear before I read it).

------
kccqzy
Twenty years ago, deployment of a new version of a web app means FTP'ing a new
php file to the server.

~~~
pikzel
Which wasn't a bad thing after all. I've had more incidents with deployment
pipelines than with the actual code.

~~~
dharmab
Mostly because people forget that pipelines are code and need documentation,
tests and software engineering practices just like any code.

------
iLemming
I've been seeing a lot of talks about darkland and can't find a single example
of code. Can someone show me at least how does it look like?

~~~
gspetr
from darklang.com:

"Dark is currently in private alpha."

That's probably the primary reason why there's little to no info.

~~~
amelius
They are leaving us in the dark, so to speak.

~~~
quickthrower2
It feels like an ICO launch in that regard. Kind of exciting!

------
toolslive
Back in the day (early 00s), you could do something similar with ZOPE: develop
on a production server, in a private session and you could mock about with
your version of the code, and when you were satisfied push it through for
everybody else. This was because the database that was holding the users,
permissions, ... was also holding the code. It was lightyears ahead of J2EE at
the time. (Now I wonder what happened to it)

~~~
slinkp
Former professional Zope guy here! (I made a living building things with it in
the early-mid 2000s).

What happened to Zope? Well, Chris McDonough (creator of Pyramid, and Zope
veteran) blogged about this in 2011 and from my perspective he got it exactly
right. I still think this history is fascinating and I wish more people knew
it.

[https://web.archive.org/web/20161019153348/http://plope.com/...](https://web.archive.org/web/20161019153348/http://plope.com/Members/chrism/in_defense_of_zope_libraries)

After the history lesson, some of his "lessons learned" bullet points seem
very apropos in the context of Dark, particularly the first two:

* "Most developers are very, very risk-averse. They like taking small steps, or no steps at all. You have to allow them to consume familiar technologies and allow them to disuse things that get in their way."

* "The allure of a completely integrated, monolithic system that effectively prevents the use of alternate development techniques and technologies eventually wears off. And when it does, it wears off with a vengeance."

~~~
pbiggar
Thanks for pointing to that, it's super interesting.

One of the things we designed Dark around was being able to safely and easily
continuously deliver language and framework changes. The Zope 3 project was a
disaster by the sound of it, and I would hope this will allow us avoid a
similar fate. That's the goal.

Also, we're pretty pro-testing (though also type systems, which help too).

------
KirinDave
So... you're 50ms away from a total global outage and/or major feature fault?

Why would I want that? How do I control it for green-blue? For rational
isolation? Is there native support for canary releases?

~~~
toast0
> So... you're 50ms away from a total global outage and/or major feature
> fault?

And 50ms away from restoring service.

The degree of care that needs to be put into a release is related to the
potential damage a bad release can cause and the time to repair.

Reducing time to deploy reduces time to repair for most errors (certainly not
for errors than write bad states, if you write bad data to your database,
that's most likely a long repair regardless of how fast to deploy it was).

If you're building NES cartridges, you should really get it right the first
time, since there's no way to update. If you're making a low cost internet
service, for small changes, it's not unreasonable to try things without a lot
of testing before hand as long as you commit to detecting and rolling back
quickly.

~~~
KirinDave
> And 50ms away from restoring service.

Sure, but fast rollbacks are _much_ easier than fast rollouts.

> Reducing time to deploy reduces time to repair for most errors (certainly
> not for errors than write bad states, if you write bad data to your
> database, that's most likely a long repair regardless of how fast to deploy
> it was).

A uniform fast rollout is almost always worse, and a separate problem from
data recovery or fast rollbacks. But I agree with this paragraph in principle.

> If you're making a low cost internet service, for small changes, it's not
> unreasonable to try things without a lot of testing before hand as long as
> you commit to detecting and rolling back quickly.

When you're doing more than basic presentation of semi-dynamic content, most
CSPs make multi-region deployment very affordable and easy. It's generally a
failure of early engineering departments or an accumulation of technical debt
that makes it otherwise in 2019. Too many folks assume it is something they
should do later rather than get right to start.

Canaries and regional redundancy should be part of every product's basic
launch checklist, imo. People love to say any kind of software engineering
best practice is bad, because they love to pretend software engineering has no
value. But for every flash UX trick or tracking feature someone ships
providing value, that's completely overshadowed by being down when a user
needs you. Reliability not only saves you time at the developer level by
making features more predictable, but it means you need to worry slightly less
about funnel optimization because your user attrition is lower.

------
davedx
How does it compare with hot swapping in other languages and platforms like
Erlang, JVM/.NET hotswap technologies? I'm guessing the built-in safety
functionality from the feature flagging is one thing?

~~~
pbiggar
It's much simpler. Those have complex in-process hot swapping. Dark's "hot
swap" is a write to a DB, then new HTTP requests use the new code.

As we grow and start to look at compilation and optimization, I think we'll
probably get much fancier, but for now we're very into keeping things super
simple.

~~~
davedx
I'm pretty interested in this. Signed up to the mail list. Good luck!

------
taosx
Marketing piece with grand plans...not really

I would argue with you that this is not such a priority for a software
development organization, there are more important things to do.

You got so excited...so fast, I think this community may be doing more bad for
me than good lately.

------
vincentmarle
This sounds extremely exciting and it looks like a lot of thought has been put
into this. I’m looking forward to try it out.

A lot of comments here are coming from an anxiety that is caused by many years
of dealing with fragile deployment processes, but I like the boldness of Dark
to just bypass all that and make the fundamentals safe and solid.

------
bullen
I added the same feature to my Java app server:
[http://github.com/tinspin/rupy](http://github.com/tinspin/rupy) it's a
simpler design which compiles, zips and hotdeploys over HTTP to a classloader.

But it's fast enough as long as you keep each project small.

------
keymone
The problem is granularity of deployment - the smallest piece you can rollout
is, these days, a container with code and dependencies, that has to be build
and threaded through your CI/CD stack before it hits prod.

I like to imagine what would need to happen to reduce(increase?) that
granularity to single function - you change the code, byte-compile it, send
that blob to your backend’s hot code swap port and voila - you’re done. A lot
has to happen behind the scenes though - a change in dependencies would still
require a larger deployment or much smarter code swapping procedure,
caller/callee tree would need to be considered, functions need to be
pragmatically pure (talking to dB is fine, being part of an “object” - not
really), functions need to be extensively specced, etc.

But that would be my backend holy grail.

~~~
icebraining
What are you looking for, that isn't provided by platforms with hot code-swap
(e.g. Erlang) or FaaS systems (e.g. AWS Lambda, OpenFaaS) ?

~~~
keymone
you're thinking of only surface functions/endpoints, those that are invoked
directly from your api route dispatcher. i'm talking about _any_ function in
your source code of a large backend with many endpoints.

think of function `+` - i want to be able to deploy a change to that function
such that no worker process gets respawned.

also imagine every time you call `+` in your application - it goes throught
the whole FaaS shenanigans with serializing, sending rpc over wire, receiving
response, deserializing, dealing with throttling, errors, backoffs. all of
that is ridiculous for `(+ 1 2)`.

and yes, erlang is a good example of an environment where this could work.

------
bufferoverflow
Code deployment is almost always trivial and fast. It's the databases that are
slow and very tricky, especially in distributed systems.

------
jonstaab
Very curious about the data migration piece. It sounds like it's designed to
handle mapping a row of type a to a row of type a prime. What about situations
like a specific combo of type a and c to b and two different records of type
c, and optionally delete a record of type d? We occasionally have migrations
that are only representable as a function of several entire tables, and which
may even leave gaps, e.g. for domain events that affected the system but
weren't logged until a later revision.

------
ricardobeat
EDIT: Ha. My apologies as I just realized my stupidity - I was browsing on
mobile and it turns out out I jumped into the 'What is Dark' post [1] and
never finished the original! The mailing list links are in that one - I
subscribed. This is a lot more interesting, cheers :)

[1] [https://medium.com/darklang/the-design-of-
dark-59f5d38e52d2](https://medium.com/darklang/the-design-of-
dark-59f5d38e52d2)

~~~
pbiggar
The section that describes how it does it in 50ms is called "#deployless".
That describes the mechanics of the deployment. How we made deployless
possible is addressed for the rest of the post after that.

(The mailing list thing is weird, I only see that link at the bottom. Can you
point me at the ones you see in the text?)

------
umvi
Very interesting, but I don't like the idea of abandoning VSCode to learn some
single-purpose IDE

------
oftenwrong
Dark sounds like it would satisfy my preferences well.

\- statically typed, functional language with no null pointers

\- safe deploys and rollbacks

\- structured editing / version control

\- minimal infrastructure management

...etc. A tool that makes writing a correct program, and deploying it without
catastrophe or fuss, easy. I look forward to reading more.

------
pbiggar
Author here - happy to answer any questions!

~~~
djm_
Other languages have large ecosystems of packages that allow users to do
common tasks quickly. I can imagine not having something similar would be a
sticking point to adoption; how does Dark picture the Dark ecosystem working
and competing with other already well-entrenched ecosystems? Thanks!

~~~
pbiggar
There's a couple of ways of handling this. First is that of course we need to
create a package manager and ecosystem, and that will take time (we can
accelerate it by making a great experience, but haven't gotten there yet).

Dark can talk to other HTTP things, so many of the functions that are done by
libraries can be done over HTTP. So you can call other services, even if we
don't have an SDK for that yet. And from there it should be easy to package it
up so there is an SDK.

Finally, it's a question of what you're doing. There's many tasks where the
disadvantage of not having an ecosystem is outweighed by Dark's other
advantages. And as we grow the ecosystem, the disadvantages go away, unlike
the status quo tooling.

------
dcchambers
Very interesting and flips mostly everything about CI and CD on it's head. I
am disappointed the blog post doesn't include any screenshots or actual
examples of the Dark code/editor working. It's kind of hard for me to wrap my
head around how this works at a technical level just reading about it...would
like to see some concrete examples. I went over to the website to look for a
demo/examples but there isn't anything.

------
GordonS
As an aside, that big list of tasks and diagram at the end are perfect to show
next time a client exclaims about how long it takes to get a simple change
into production!

------
devcriollo
They show very little, I'm anxious to be able to see.

~~~
pbiggar
We're talking about the design of Dark in these posts. We plan to show what
Dark looks like in our launch in September.

------
quickthrower2
I think it is fantastic that this kind of innovation is happening. I get sick
of waiting for stuff at work, some kind of build or CI thing. npm i, docker
build or whatever else. I hope the language experience is good, and it's a
reasonable language (static typing!).

It sounds like taking the Go idea of quick builds to the next level.

------
davejstl
What are the server/OS/cloud prereqs for Dark?

~~~
pbiggar
There are none! We run the infrastructure in the cloud (we run it on GCP using
Postgres and k8s, but will likely go multicloud at some point).

Most of the advantages we discuss in this post come from the fact that you're
using the Dark editor, language and infra. I don't believe this would be
possible with a self-hosted solution.

~~~
Deimorz
So anyone using Dark is completely locked-in, to the point that they can't
even take their code into an editor other than yours?

It's a proprietary language, that can only be edited in a proprietary cloud-
based editor, that only runs on proprietary infrastructure?

~~~
pbiggar
Yes, that correct. There are lots of downsides to this, but you also get a lot
of things that we don't think are possible without it.

~~~
Deimorz
I understand the concept, but I don't think the downsides can be so easily
passed by. Some quick thoughts/questions:

\- What happens if Dark-the-company disappears? It doesn't matter how. You're
acquired by Google and shut down, your office is hit by a meteorite, whatever.
Everyone that's ever built anything using Dark would completely lose it? Every
company that's built anything using Dark would have nothing remaining in its
place except--at best--some code that can't run anywhere?

\- How much venture capital have you taken? Do you expect to take more?

\- What if you update the platform and it introduces behavior changes or bugs
into some of your users' applications? Can they rollback and stay on the
previously-working version of Dark (indefinitely), or will they have to rely
on you to resolve the issues?

\- The first mission of the company that you list on your Values page is
"Democratizing Coding". How does making literally every aspect of Dark
completely dependent on your company support that? Will Dark users vote on
company decisions? How can a completely centralized system with a for-profit
owner promote democratization?

~~~
pbiggar
These are the downsides I'm talking about. If you're sensitive to them, don't
use Dark! That's totally fine with us. We're creating a technology with a ton
of advantages that don't exist elsewhere, and that comes with different
tradeoffs.

If you're worried about a meteor hitting SF (and I know that's a metaphor, but
let me run with it), then your risk profile indicates you won't be using new
technology from a new startup (you probably won't even use less risky stuff,
like Rust or Elm).

If every technology had exactly the same constraints, then we'd be stuck with
those constraints forever. This isn't the _right_ way to do it, it's just our
vision of how to solve the problems with coding.

~~~
adrienjt
It's a hard sell. Another risk is that, after I've invested a lot in Dark, you
increase your prices, and I can't switch because I'm dependent on your
product. The switching cost would be rewriting my entire code base (my biggest
investment).

I'd like to have the option to reuse my code to mitigate those risks. Two
possibilities: a) If the Dark IDE and infrastructure were compatible with a
common language, I could use "regular" build and deploy tools if I wanted (I'd
weigh the pros and cons vs. your price increase), or b) if the Dark
infrastructure had an open source API (not necessarily an open source
implementation, but like what SQL is for databases, or the S3 API for object
storage), I could implement my own alternative infrastructure or shop for one.

(a) seems difficult technically and (b) means risking commoditization on your
end.

~~~
pbiggar
> Another risk is that, after I've invested a lot in Dark, you increase your
> prices, and I can't switch because I'm dependent on your product. The
> switching cost would be rewriting my entire code base (my biggest
> investment).

This would also kill the company.

We are actually looking at ways to mitigate this risk, as we do agree that
being locked in is a real risk. We also have to provide sustainability to the
business, as Dark failing as a business isn't helpful for our customers
either. We're thinking about this, but nothing concrete yet.

------
akhilcacharya
Is Dark intended to be a Lisp? I'm surprised by the fact that the team didn't
include language examples (from what I can gather)

~~~
pbiggar
No, it's an ML. (You're right that we haven't published samples, we think
people get distracted by syntax and we want to focus on the goals at the
moment)

~~~
akhilcacharya
Oh cool! That makes me quite a bit more interested.

------
sddhhanover
Can I take Dark out for a spin?

~~~
pbiggar
Right now, we're in private alpha. If you have a product or service that you
want to build, fill out
[https://darklang.com/subscribe](https://darklang.com/subscribe) and our CEO
Ellen will get back to you to discuss and schedule an onboarding. We're not
doing tire kicking yet though :)

~~~
sddhhanover
Entered my email awhile ago... just updated the mailchimp profile
(daniel@orthly.com) to include my use-case. Let me know! Would love to provide
feedback - what you're working on sounds awesome

------
jdtangney
One question: Security

------
blumomo
That's quite a dark name for such a bright idea.

------
unfunco
It sounds like a convoluted version of Geocities.

