7 ms·

I'm excited by almost everything about this. I think it could be transformational in some categories of software engineering, but I do have a big concern... >

I'm excited by almost everything about this. I think it could be transformational in some categories of software engineering, but I do have a big concern... > I think the biggest downside of Dark is definitely that you’re learning a new language... But this is not it. Learning new languages isn't that hard, and a language so well designed for an ecosystem would likely be a pleasure to use. They are probably giving this as their "big downside" because it's not actually their big downside. The real big downside is proprietary lock-in. My tools right now are open source, developed in the open, things I can contribute to or at least understand at a fundamental level. "Python" can't go out of business, "Postgres" won't get acquihired and shut down with 30 days notice, and Docker images can run on plenty of hosting providers where there's lots of competition. While I might bet a company on a new technology I'm not going to bet a company entirely on the whim of a company, who may pivot, get bought, shut down, raise prices, etc. Hosting is the closest I'd get to this level of lock-in, but if that changes I don't have to rewrite all of my code, reproduce business logic, and also rewrite from a high level language like Dark to something that doesn't provide any of the same primitives.

pbiggar 7y ago
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 7y ago
  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 7y ago
    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.

pbiggar 7y ago

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