undefined | Better HN

0 pointsHereBeBeasties6y ago0 comments

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.

0 comments

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

HereBeBeastiesOP6y ago

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!

pbiggar6y ago

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

j / k navigate · click thread line to collapse

0 pointsHereBeBeasties6y ago0 comments

Your vision is extremely compelling and well articulated.

I wish you luck.

0 comments

pbiggar6y ago

Thanks!

HereBeBeastiesOP6y ago

pbiggar6y ago

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

j / k navigate · click thread line to collapse