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