Dark emerges with ‘deployless’ software model

I made a mistake mentioning Prometheus - it's the least important point in my post. I get that you may provide something for monitoring (performance and tracing, at least) that's more baked into the whole AST/graph model and that sounds really very compelling. And obviously end developers won't need to monitor the systems/services because as far as they're concerned there aren't any. It feels a bit like electric cars - a bunch of new (and hard) problems arise, but it's compelling as a bunch of older (also hard) problems just cease to be. Huzzah. I'll certainly agree with you that the potential upsides here are very large and very compelling.

But the need for things like code review tooling, test coverage reporting and mocking frameworks (yes, I will want to isolate stuff via mocks) aren't going to just disappear with this kind of model. They're far from exotic use cases for the kind of business customers you will need to scale this and get real adoption and thus positive cashflow, more of a necessity. It's a real leap of faith to think it's worth rebuilding so much of these kinds of ecosystems that have taken thousands of man years to evolve and develop for existing languages. And if you don't have plans to provide that sort of thing you'll be missing out on most of the market, I would have thought. Yes, you'll get hobbyists but surely they won't provide the volume or reliable subscription-style revenue you'll surely need to make this sustainable?

Unless of course your endgoal here is being bought out by Google, in which case fair play. This is cutting edge thinking and tech, full of nice hard problems to work on and lovely "oh but if we just don't have that then we don't need this either, or can do this like that instead" type insights to be made. Cool stuff, but it still won't get me to bet the farm on it. I really do wish you well though!

Thanks for the well considered reply!

> Around some of the specifics: we've no intention of pivoting.

I'm afraid I think this is a naive approach, and I'd encourage you to design for the assumption that the company will fail to deliver on the original promise in some sense, not because I don't believe in Dark, but simply because of the realities of running a startup.

> Our intent is to be "within 2x of running the same app written in Node on AWS".

This is a nice goal, but as someone who writes Python/Django/JS/etc and deploys on a mix of bare metal and AWS, I know that we have very significant savings over the average AWS-native deployment (with all the costs that come with lock-in, the spending culture that AWS encourages).

The thing that would encourage me most here would be a self-hosting or partial self-hosting solution. Maybe you provide AMIs for AWS, or docker images, etc. If we can run where we want, and optimise costs in ways we want, that's great.

Being hosted brings other complexities when you start to add more complex services. If for example we want to add an instance of Postgres (perhaps the Dark database doesn't have great spacial data storage options and we want to use PostGIS, perhaps we want something that takes different options from CAP), we need to deploy that somewhere. I'd hope we can write Dark code to talk to it, but we ideally want that software on the same network, same region, same datacenter, etc. We can't do that if you host it, so being able to self-host would have a number of advantages.

> Would it solve your problem if you were able to export a mostly similar working node/python/go app from your Dark program?

Maybe, but again, we have ~500k lines of code in the business currently. If there was any difference in business logic, or any unexpected behaviour in any of this, that could cause significant damage to the company. Maybe if you export tests too that might mitigate the issue, but tests are just code, and if the transpiler isn't perfect (for what definition, who knows?), then tests would be subject to the same transpilation bugs.

An export of Dark code, a working version of the Dark runtime (minus tooling and some secret sauce perhaps), a set of tests, a basic CI/CD pipeline (not a 50ms one), and a set of Kubernetes configs... that might be enough, as it would work the same and essentially be just another regular web app. However, that would lose the benefits of Dark and its ecosystem, and so may end up just being more tech debt. It wouldn't be bad for the case where Dark the company shuts down, but for a company who need to transition off Dark for some reason, they still end up with a monolith of tech debt.

All of this is a long way around to say that I think I would be more excited about Dark if it were fundamentally an open platform. I don't know how you make a business model out of that (consulting? enterprise? support? none are a slam dunk), but knowing that the technology stands on its own without the company, and is still convincing with the features touted regardless of what happens with the company or if the technology took a different direction, would be much more reassuring.

Thank you for answering the questions!

With the staging/deletion, I meant a scenario like this: I'm working on some feature which deletes an item I own. But in a delete condition I put "or" instead of "and" (in a non-obvious place) and the function will delete all records instead when it's run.

In the current development model, this will be caught by:

- me testing it locally (then fixing it and reloading test db)

- maybe reviews

- potentially CI/CD

But with what I understand about Dark, this will be close to auto-published on save, and the first person to try the code will delete all entries from a live table/collection.

Backups are ok, but not a solution in this case (you can't just roll back money transactions for example), and the downtime is not great. What system in Dark prevents this from happening in the first place?

We'll be showing it off in September (come to the launch: https://darklang.com/launch), and the only way before that is to get onboarded into the alpha. But if you don't know why you need it, it's probably not a good fit for you just yet.

> And if you don't have plans to provide that sort of thing you'll be missing out on most of the market

Realistically, we're not going to have all those things at launch, but we will have them later.

I don't think you're correct to say that it's not possible to get revenue without supporting every single thing that a customer might possibly need.

The people who are good matches for using Dark are people who don't mind that they're missing, including companies who are willing to pay. When we add them later, the people who needed those can start using it.