What Is Dark?(medium.com) |
What Is Dark?(medium.com) |
What's the business model? E.g. open tooling, pay for hosting/monitoring/optimization?
We operate the infra, so we charge for it like aws, firebase, etc. We plan to be pretty cheap, charge for usage, and have a generous free tier.
I guess my two concerns about solutions like this are always A) vendor lock-in B) whether it's too big of a project for any one company and requires a community of contributors to realize the vision.
In the short term it doesn't really matter because clearly being able to build an app is a huge step up from not being able to build an app regardless (which is why companies like Bubble.is are doing so well), but in the long term it seems like there are 10 - 15 companies working on this so eventually there will be more options and those factors will be key differentiators.
We haven't decided on transactional consistency yet - if there are particular goals there, I'd love to hear them. Ostensibly, we want to allow users to design the right distributed system for themselves, and provide ways of saying "we want this DB to prioritize availability over consistency", for example. But we haven't yet decided how to do that or what to support at launch, nor where the bounds of a transaction will be.
We have a DB migration tool. The DB has a current type, and you specify the new type, and add rollforward and rollback functions. That creates a new name for the datastore: any use of the old name uses the old type, and the new name uses the new type (both on the same datastore, applying rollforward and rollback as necessary for the interface you need). Once you've removed all the references to the old name, you mark the migration as complete, and we'll handle the underlying transformation of the data behind the scenes.
The history of RPC is...checkered. It's possible that every attempt to make remote process calls as simple as local function calls has resulted in terrible abstractions that leak like a sieve.
My suggestion (for what it's worth) is to bake the notion of message passing into the language, and make it as simple as possible.
Can you link to something about message passing? I'm familiar with a concept with this name, but I don't quite see what you mean.
While waiting for the whole blog post, do you have any elements to share?
That said, it has a lot of similarities to LightTable, especially regarding coding with live values.
A current thought is perhaps allowing you to export your application compiled to Node or similar if you decide to stop using Dark. (Data is already easy to export, so we're mostly worried about code).
This is probably going to be the next blog post I write about this, because it's pretty front and center to the business.
This is the first time I've heard the concern of the project being too big for one company. I personally don't worry about it because it's so hard to move a small team in the same direction that I don't think a large community of volunteers will be a better fit.
I guess another option would be having Dark function more as an app-store-like intermediary between the hardware and software. E.g. telling users they need X, Y, and Z infrastructure and letting them deploy it to whatever cloud they wanted, and having dark just charge for orchestrating that and for providing whatever other services.
In terms of a community, I guess I meant more in terms of getting developers to create libraries for data processing, in terms of things like HTML parsers for scraping webpages and other stuff that is essential for choosing a language but where it's hard to see how it would be viable for one company to build out all that stuff. Unless the plan is just to let folks run code in other languages.
Yes, I think that's right. There's a lot of folks who have strong feelings about this but who aren't necessarily our target user. I know that's going to cause a lot of problems but what can you do :-/
> I guess another option would be having Dark function more as an app-store-like intermediary between the hardware and software.
Yeah, this very much isn't what we're trying to build, or the business we want to be in :)
> In terms of a community, I guess I meant more in terms of getting developers to create libraries for data processing
Gotcha! Yes indeed, there will be a package manager very much like npm/cargo/rubygems, for just this sort of thing. We plan to make it extremely easy to create and share packages.
That's a good point, in the sense that even if less technical people don't care about certain issues, they're often not going to adopt the product without first soliciting advice from people who do care about those issues. So that just means potentially needing to build out a lot of stuff knowing that people won't actually use it for a long time.
Sort of like our product and the OAuth issue, which we're finally on track to (mostly) solve with a Gmail add-on but it's obviously been several years at this point.