[pbiggar]

Founder here. Totally fair concern - we're not thrilled about the lock-in either because we want people to try Dark and see that it solves a problem for them. We're looking at ways to improve this - would love ideas, and will be writing up some of our ideas soon.

Around some of the specifics: we've no intention of pivoting. If we discovered that Dark had a massive opportunity to be the AirBnb for market analytics (or whatever) we would 100% ignore it and keep doing what we're doing. Around pricing, we want Dark to be super cheap. Our intent is to be "within 2x of running the same app written in Node on AWS". We saw how much people leave Heroku because of the premium pricing and we don't want that to be us.

The other stuff is valid and we're looking for ideas here. Would it solve your problem if you were able to export a mostly similar working node/python/go app from your Dark program? Would it need kubernetes configs or to run on Heroku? Would you prefer that it be semantically exactly the same but the code is ugly, or with the code having the same look-and-feel but slightly different semantics?

[HereBeBeasties]

Your vision is extremely compelling and well articulated.

I'm not sure I buy the "coalescing multiple things into one makes things simpler" argument - the simplicity comes at the expense of expressiveness, flexibility and optionality. A large, highly-opinionated monolith, right the way across the stack, is bound to have made some design trade-offs and decisions that are either plain wrong (we all make mistakes) or don't fit with however I want to actually use it.

To do this at the AST graph/language level strikes me as both genius and absurd - not only is language design very hard, but you clearly have a massive uphill struggle to provide sufficient library and framework-level code on top of that to be able to start to compete with more mature options. Not to mention things like code review tooling (it's neither text-based, nor even in any form of conventional revision control system, so likely start from scratch). Security controls, auditability, vulnerability management for any library ecosystem that springs up around this, etc. etc.

By rejecting text you are having to reinvent and support a compiler, an IDE, github/gitlab (or equivalent, with their massive functionality set including protected branches and security controls and the like), package management maybe, debugger tooling (on the web), release/rollback systems/UIs, perhaps even monitoring and alerting (because you're promising the users they don't need to run infrastructure/services like Prometheus and the like and your "roll out" process looks so different).

Does Dark really have sufficient expertise around all of that to want to make this stuff totally monolithic? Is it even possible for a startup company to really compete in that sort of global (massively open source) scene?

Convincing people to bet their company on your company, both as an ongoing enterprise and as a place that can get all the inherent trade-offs here well-matched to their individual use-cases is going to be an almost impossible sell. Regardless of how much you assert that you believe in your mission and don't want to ever pivot. You can't blame people for being sceptical, especially when the opening paragraphs essentially say "this is a silver bullet".

I wish you luck.

[pbiggar]

Thanks!

If you want to use all that stuff, you can do that today. You can use GitHub and Go and Phabricator and Prometheus and whatever you want. People who want to a take a conservative approach have a million different options. Honestly, just run your app on AWS, it's got everything you need.

What we're trying to do is something different, removing a ton of stuff that we think we can allow you not need. And maybe it won't work for a whole lot of people - that's fine. Over time we'll fill out more of the product and support more use cases.

[HereBeBeasties]

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!

[pbiggar]

> 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.

[crystaln]

Regardless of what you say as a founder, if the growth is not there and a massive opportunity arises, your investors will push you to pursue it. You won't have much choice, and this is an empty promise you can't keep.

Personally I don't see why anyone would choose such a closed ecosystem in this era when so many great open source options exist, where we can read and edit source code, substitute components, and pivot technically in so many ways impossible with a black box unironically named Dark. There is just way too much risk around hitting the limitations of the platform or corporate shifts. Why bet your biggest investment on something you have no control over? That would be incredibly foolish.

If you want this project to be successful, open source it and maintain your competitive advantage by adding value not monopoly power. If you are actually concerned about lock-in as you say, don't lock customers in.

[btreecat]

Ok, so how do I just look up the langue, tools and play around with it? The website shows no examples of what the language actually is, what tooling actually exists etc.

I got accepted to the private alpha but I can't tell why I should actually use this.

[pbiggar]

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.

[btreecat]

>But if you don't know why you need it, it's probably not a good fit for you just yet

Right, it's def not a failed marketing push as to why your website talks about a programming language, with no actual examples of said programming language.

SMH, get some self awareness buddy.

[danpalmer]

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.