11 ms·

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, t

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?

tutfbhuf 7y ago
Yes.
pbiggar 7y ago
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.
- nikolay 7y ago
  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.
  - mhenrixon_ 7y ago
    ”You’re wrong” is a sure way to get people to just walk away from a discussion.
    - nikolay 7y ago
      There's no need for a discussion when stating facts.
      - yrtoren 7y ago
        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.
        pbiggar 7y ago
        This is similar to our thinking at the moment.
        bsaul 7y ago
        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.
        nikolay 7y ago
        And that's why Kubernetes is so popular today - nobody likes the AWS lock-in.
- deleted 7y ago
  [deleted]
- Deimorz 7y ago
  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?
  - pbiggar 7y ago
    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.
    - adrienjt 7y ago
      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.

tutfbhuf 7y ago

Yes.

pbiggar 7y ago

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.

nikolay 7y ago
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.
- mhenrixon_ 7y ago
  ”You’re wrong” is a sure way to get people to just walk away from a discussion.
  - nikolay 7y ago
    There's no need for a discussion when stating facts.
    - yrtoren 7y ago
      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.
      - pbiggar 7y ago
        This is similar to our thinking at the moment.
      - bsaul 7y ago
        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.
      - nikolay 7y ago
        And that's why Kubernetes is so popular today - nobody likes the AWS lock-in.
deleted 7y ago
[deleted]
Deimorz 7y ago
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?
- pbiggar 7y ago
  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.
  - adrienjt 7y ago
    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.