Hacker News new | past | comments | ask | show | jobs | submit login

There are none! We run the infrastructure in the cloud (we run it on GCP using Postgres and k8s, but will likely go multicloud at some point).

Most of the advantages we discuss in this post come from the fact that you're using the Dark editor, language and infra. I don't believe this would be possible with a self-hosted solution.




So anyone using Dark is completely locked-in, to the point that they can't even take their code into an editor other than yours?

It's a proprietary language, that can only be edited in a proprietary cloud-based editor, that only runs on proprietary infrastructure?


Yes, that correct. There are lots of downsides to this, but you also get a lot of things that we don't think are possible without it.


I understand the concept, but I don't think the downsides can be so easily passed by. Some quick thoughts/questions:

- What happens if Dark-the-company disappears? It doesn't matter how. You're acquired by Google and shut down, your office is hit by a meteorite, whatever. Everyone that's ever built anything using Dark would completely lose it? Every company that's built anything using Dark would have nothing remaining in its place except--at best--some code that can't run anywhere?

- How much venture capital have you taken? Do you expect to take more?

- What if you update the platform and it introduces behavior changes or bugs into some of your users' applications? Can they rollback and stay on the previously-working version of Dark (indefinitely), or will they have to rely on you to resolve the issues?

- The first mission of the company that you list on your Values page is "Democratizing Coding". How does making literally every aspect of Dark completely dependent on your company support that? Will Dark users vote on company decisions? How can a completely centralized system with a for-profit owner promote democratization?


> What if you update the platform and it introduces behavior changes or bugs into some of your users' applications?

They can fix it in 50ms! Don't worry!


These are the downsides I'm talking about. If you're sensitive to them, don't use Dark! That's totally fine with us. We're creating a technology with a ton of advantages that don't exist elsewhere, and that comes with different tradeoffs.

If you're worried about a meteor hitting SF (and I know that's a metaphor, but let me run with it), then your risk profile indicates you won't be using new technology from a new startup (you probably won't even use less risky stuff, like Rust or Elm).

If every technology had exactly the same constraints, then we'd be stuck with those constraints forever. This isn't the _right_ way to do it, it's just our vision of how to solve the problems with coding.


It's a hard sell. Another risk is that, after I've invested a lot in Dark, you increase your prices, and I can't switch because I'm dependent on your product. The switching cost would be rewriting my entire code base (my biggest investment).

I'd like to have the option to reuse my code to mitigate those risks. Two possibilities: a) If the Dark IDE and infrastructure were compatible with a common language, I could use "regular" build and deploy tools if I wanted (I'd weigh the pros and cons vs. your price increase), or b) if the Dark infrastructure had an open source API (not necessarily an open source implementation, but like what SQL is for databases, or the S3 API for object storage), I could implement my own alternative infrastructure or shop for one.

(a) seems difficult technically and (b) means risking commoditization on your end.


> Another risk is that, after I've invested a lot in Dark, you increase your prices, and I can't switch because I'm dependent on your product. The switching cost would be rewriting my entire code base (my biggest investment).

This would also kill the company.

We are actually looking at ways to mitigate this risk, as we do agree that being locked in is a real risk. We also have to provide sustainability to the business, as Dark failing as a business isn't helpful for our customers either. We're thinking about this, but nothing concrete yet.


> If you're worried about a meteor hitting SF (and I know that's a metaphor, but let me run with it), then your risk profile indicates you won't be using new technology from a new startup (you probably won't even use less risky stuff, like Rust or Elm).

no. they're both open source for starters.

furthermore, even if all developers working on these projects vanish from one day to the next, you'll still be able to use the last released version and will have a maintenance window to deprecate the software.

if Dark goes away, you'll be gone at the same date.


You're wrong. Everything is possible as open-source. Often the lock-in is not an option. Not at any price. I hope you realize that soon.


”You’re wrong” is a sure way to get people to just walk away from a discussion.


There's no need for a discussion when stating facts.


Is stating facts not a form of discussion? ;)

I'm an open source fan myself, but given that AWS has a penchant for lifting concepts from open source projects and using it to crush them, and given that AWS is one of the primary targets here, it kinda makes sense to opt for proprietary. Especially at this stage.

Just my two cents.


And that's why Kubernetes is so popular today - nobody likes the AWS lock-in.


i’m sorry but the fact that aws is choosing open source tech ( even if it’s to compete and crush them) is a rather compeling argument for open source techs rather against. This lets Aws say that you could still walk out and keep using your code ( and data) in another infra, at least in theory.


This is similar to our thinking at the moment.


Yes.


>> Most of the advantages we discuss in this post come from the fact that you're using the Dark editor, language and infra. I don't believe this would be possible with a self-hosted solution.

What makes it impossible specifically?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: