7 ms·

Does anyone else see the irony here? The Dark engineers switched their core language with another because the open source ecosystem wasn't broad enough to cover

Does anyone else see the irony here? The Dark engineers switched their core language with another because the open source ecosystem wasn't broad enough to cover their needs. And yet they're asking their customers to make the same bet on their proprietary language and platform. I mean just look at this FAQ[1]. There isn't a clear path out of vendor-lock in, a terms of service, or even a guarantee that the platform won't disappear without notice. - [1] https://darklang.com/language https://darklang.com/language

throwaway894345 6y ago
I agree with this criticism, but I wonder how they could monetize without locking in users. I suppose they could open source their toolchain so anyone could stand up their own Dark framework on-premise and maybe they sell support and/or a managed service and/or "enterprise features" (whatever those are in this context)? Maybe these things will come sometime after the private-beta (perhaps they're just getting a better feel for their product's value proposition before committing to opening any particular piece of it up)?
- siwatanejo 6y ago
  I think it's easy to monetize: make the BCL dual license AGPL+proprietary
- goldenshale 6y ago
  Or maybe this is why Dark is a bad business endeavor in the first place. I would never bet my company's future on something like this, and the toolchain doesn't seem sufficiently powerful to warrant the risk. Sorry, but this is no Clojure. Instead of a proper comment syntax you define a dummy variable to a string? Ghetto.
pimterry 6y ago
It's interesting to contrast with Docker, who similarly pitched an exciting new development model & ecosystem. In Docker's case, it was indeed non-proprietary, built on existing standards, and has now got to the stage where you can now swap Docker out for competing alternatives to avoid lock-in entirely. On the other hand, while that model went great for Docker the technology, it has not gone well for Docker the business. I imagine Dark might see Docker as a cautionary tale of why _not_ to go down that road.
- raiyu 6y ago
  The problem for Docker wasn't that per say, Docker itself was the free part that got everyone interested it's just that their paid for tier went head to head with Kubernetes and lost. Had Kubernetes not existed they would be doing just fine economically as they would be the dominant platform. They got beat by competition.
  - edjrage 6y ago
    Honest question as an outsider: What did Docker introduce that wasn't better addressed by other technologies? E.g. wasn't reproducibility the main point and already properly solved by nix? By the way, it's "per se"
    - SSLy 6y ago
      You don't have to use the nix lang, Dockerfiles are much easier to get started working with.
    - isogon 6y ago
      Dockerfiles are far simpler than the Nix language. Likewise, sure, FreeBSD had jails first (and for a long time!), but they are more difficult to set up. Docker allowed reproducibility to be accomplished by a person who likes the idea of it, but will shelve it if it doesn't work within an evening. This describes me, for example. I think it took off for that reason.
      - nendroid 6y ago
        Nix has a multitude of drawbacks the biggest being learnability.
        pbronez 6y ago
        god yes. Friggin' Nix is such a great idea, but such a pain to start using...
mumblemumble 6y ago
Is lock-in that big of a concern for people who are using serverless? I have no direct experience here, but my understanding was that all the major serverless platforms are built on proprietary APIs. That said, this item from the FAQ is nice to see; I'd love to see more vendors not just making promises along these lines, but making them binding: > if the worst should happen, we will open-source Dark ... We're committed to codifying the specifics in a legal framework
- imglorp 6y ago
  Yeah lockin is a problem in general for serverless if you need all the cloud vendor's extras. For example, lambda doesn't make sense without IAM, VPC, etc and you often want things to hook to it like SQS, API Gateway, database, cognito, etc. Instead of lockin, you can run serverless in your own framework though, such as Kubeless or Knative, which could be deployed on prem or in a more generic cloud deployment.
  - yellowapple 6y ago
    Doesn't that kind of defeat the point of "serverless", though? I mean, I guess if that's how you like to structure your code then go for it, but the primary marketing pitch I've ever heard was around it, you know, absolving developers of the need to worry about servers. I guess if you've got a large enough environment that you have dedicated devs pushing things to Kubeless/Knative instances maintained by dedicated ops/sysdmins, then maybe that's the niche there?
    - jacques_chester 6y ago
      It depends on what you think "serverless" means. Is it solely about the developer experience? Or is it about the economic ownership of hardware? Or both?
      - imglorp 6y ago
        I was referring specifically to lambda-style "functions as a managed service", which might be a better term than serverless. Managed instance would be serverless by the economic definition.
nine_k 6y ago
This is not about being open-source, but about being popular. OCaml is a fine language, but it's not a wildly popular one. Should the authors have started with, say, Python or JS, they won't have the problem with support from third parties. Please note how their choice was between open-source Rust and proprietary (CORRECTION: also open-source already) F#, both descendants of the ML family. When you pick a language and start to feel you're overgrowing its ecosystem, you either migrate off of it (as in the post), or start developing it to help it move in the direction you want. In the case of OCaml, Jane Street and Facebook chose the latter route. UPDATE: Thanks for reminding that F# has been open-sourced: https://github.com/dotnet/fsharp/ https://github.com/dotnet/fsharp/
- lostmsu 6y ago
  F# is not proprietary. https://github.com/fsharp/fslang-suggestions https://github.com/fsharp/fslang-suggestions
OutsmartDan 6y ago
At this point, Darklang just seems like an over glorified side project. I cannot see any real business creating an entire backend system out of darklang- the learning curve, vendor lock-in, and volatility of the project is not worth the risk.
smt88 6y ago
> because the open source ecosystem wasn't broad enough to cover their needs I don't really think this matters. Dark is intending to be "batteries included" and relieve developers of the need for a huge ecosystem with multiple libraries for everything. > And yet they're asking their customers to make the same bet on their proprietary language and platform. I always use very popular open-source stacks. That said, if given the choice between a tiny FOSS language and a tiny proprietary one (that might be profitable), I'll always choose the latter. Small languages are extremely vulnerable to extinction regardless of who maintains them. But if at least one person's full-time job is to maintain a language, I feel much more confident than if 1-5 people are maintaining it part-time.
- beojan 6y ago
  Proprietary doesn't mean it's anyone's full time job.
- NOGDP 6y ago
  > Dark is intending to be "batteries included" and relieve developers of the need for a huge ecosystem with multiple libraries for everything. If it's actually going to be 'batteries included' in any meaningful way, then it will have to piggy-back off of one or more of these 'huge ecosystems', which invariably leads to the ability to integrate external pieces of these systems when needed. Which just makes it a wrapper around existing 'huge ecosystems'. There's a reason why established languages such as Java, C#, C++, JavaScript, etc. have multiple libraries for the same problem - these libraries have different features, tradeoffs, designs etc. Same reason why existing projects get forked and new projects get started. Same reason these 'huge ecosystems' have frameworks, design patterns, idioms, best practices, etc. Competition, innovation, new designs, new ways of solving existing problems is a good thing. I don't see dark as anything more than a very new framework, with lofty promises and zero evidence towards the idea that it will be better than existing systems in any way. > Small languages are extremely vulnerable to extinction regardless of who maintains them. But if at least one person's full-time job is to maintain a language, I feel much more confident than if 1-5 people are maintaining it part-time. A tiny FOSS language at least has a chance of getting some maintenance/bug fixes from the community. What happens when your proprietary language dies for lack of traction? Also, nothing prevents a person working full-time on a FOSS language.
marta_morena_28 6y ago
> The Dark engineers What do you mean. The whole page talks about "I" and "me". That's going to go well...
- freehunter 6y ago
  There used to be a company and a team of engineers. Recently they laid off everyone and it’s down to just a one-person show now.
  - nullsense 6y ago
    So, heading in a positive direction then?
  - perrygeo 6y ago
    Sounds like a great time for a backend rewrite!

throwaway894345 6y ago

I agree with this criticism, but I wonder how they could monetize without locking in users. I suppose they could open source their toolchain so anyone could stand up their own Dark framework on-premise and maybe they sell support and/or a managed service and/or "enterprise features" (whatever those are in this context)? Maybe these things will come sometime after the private-beta (perhaps they're just getting a better feel for their product's value proposition before committing to opening any particular piece of it up)?

siwatanejo 6y ago
I think it's easy to monetize: make the BCL dual license AGPL+proprietary
goldenshale 6y ago
Or maybe this is why Dark is a bad business endeavor in the first place. I would never bet my company's future on something like this, and the toolchain doesn't seem sufficiently powerful to warrant the risk. Sorry, but this is no Clojure. Instead of a proper comment syntax you define a dummy variable to a string? Ghetto.

pimterry 6y ago

It's interesting to contrast with Docker, who similarly pitched an exciting new development model & ecosystem. In Docker's case, it was indeed non-proprietary, built on existing standards, and has now got to the stage where you can now swap Docker out for competing alternatives to avoid lock-in entirely. On the other hand, while that model went great for Docker the technology, it has not gone well for Docker the business. I imagine Dark might see Docker as a cautionary tale of why _not_ to go down that road.

raiyu 6y ago
The problem for Docker wasn't that per say, Docker itself was the free part that got everyone interested it's just that their paid for tier went head to head with Kubernetes and lost. Had Kubernetes not existed they would be doing just fine economically as they would be the dominant platform. They got beat by competition.
- edjrage 6y ago
  Honest question as an outsider: What did Docker introduce that wasn't better addressed by other technologies? E.g. wasn't reproducibility the main point and already properly solved by nix? By the way, it's "per se"
  - SSLy 6y ago
    You don't have to use the nix lang, Dockerfiles are much easier to get started working with.
  - isogon 6y ago
    Dockerfiles are far simpler than the Nix language. Likewise, sure, FreeBSD had jails first (and for a long time!), but they are more difficult to set up. Docker allowed reproducibility to be accomplished by a person who likes the idea of it, but will shelve it if it doesn't work within an evening. This describes me, for example. I think it took off for that reason.
    - nendroid 6y ago
      Nix has a multitude of drawbacks the biggest being learnability.
      - pbronez 6y ago
        god yes. Friggin' Nix is such a great idea, but such a pain to start using...

mumblemumble 6y ago

Is lock-in that big of a concern for people who are using serverless? I have no direct experience here, but my understanding was that all the major serverless platforms are built on proprietary APIs. That said, this item from the FAQ is nice to see; I'd love to see more vendors not just making promises along these lines, but making them binding: > if the worst should happen, we will open-source Dark ... We're committed to codifying the specifics in a legal framework

imglorp 6y ago
Yeah lockin is a problem in general for serverless if you need all the cloud vendor's extras. For example, lambda doesn't make sense without IAM, VPC, etc and you often want things to hook to it like SQS, API Gateway, database, cognito, etc. Instead of lockin, you can run serverless in your own framework though, such as Kubeless or Knative, which could be deployed on prem or in a more generic cloud deployment.
- yellowapple 6y ago
  Doesn't that kind of defeat the point of "serverless", though? I mean, I guess if that's how you like to structure your code then go for it, but the primary marketing pitch I've ever heard was around it, you know, absolving developers of the need to worry about servers. I guess if you've got a large enough environment that you have dedicated devs pushing things to Kubeless/Knative instances maintained by dedicated ops/sysdmins, then maybe that's the niche there?
  - jacques_chester 6y ago
    It depends on what you think "serverless" means. Is it solely about the developer experience? Or is it about the economic ownership of hardware? Or both?
    - imglorp 6y ago
      I was referring specifically to lambda-style "functions as a managed service", which might be a better term than serverless. Managed instance would be serverless by the economic definition.

nine_k 6y ago

This is not about being open-source, but about being popular. OCaml is a fine language, but it's not a wildly popular one. Should the authors have started with, say, Python or JS, they won't have the problem with support from third parties. Please note how their choice was between open-source Rust and proprietary (CORRECTION: also open-source already) F#, both descendants of the ML family. When you pick a language and start to feel you're overgrowing its ecosystem, you either migrate off of it (as in the post), or start developing it to help it move in the direction you want. In the case of OCaml, Jane Street and Facebook chose the latter route. UPDATE: Thanks for reminding that F# has been open-sourced: https://github.com/dotnet/fsharp/ https://github.com/dotnet/fsharp/

lostmsu 6y ago
F# is not proprietary. https://github.com/fsharp/fslang-suggestions https://github.com/fsharp/fslang-suggestions

OutsmartDan 6y ago

At this point, Darklang just seems like an over glorified side project. I cannot see any real business creating an entire backend system out of darklang- the learning curve, vendor lock-in, and volatility of the project is not worth the risk.

smt88 6y ago

> because the open source ecosystem wasn't broad enough to cover their needs I don't really think this matters. Dark is intending to be "batteries included" and relieve developers of the need for a huge ecosystem with multiple libraries for everything. > And yet they're asking their customers to make the same bet on their proprietary language and platform. I always use very popular open-source stacks. That said, if given the choice between a tiny FOSS language and a tiny proprietary one (that might be profitable), I'll always choose the latter. Small languages are extremely vulnerable to extinction regardless of who maintains them. But if at least one person's full-time job is to maintain a language, I feel much more confident than if 1-5 people are maintaining it part-time.

beojan 6y ago
Proprietary doesn't mean it's anyone's full time job.
NOGDP 6y ago
> Dark is intending to be "batteries included" and relieve developers of the need for a huge ecosystem with multiple libraries for everything. If it's actually going to be 'batteries included' in any meaningful way, then it will have to piggy-back off of one or more of these 'huge ecosystems', which invariably leads to the ability to integrate external pieces of these systems when needed. Which just makes it a wrapper around existing 'huge ecosystems'. There's a reason why established languages such as Java, C#, C++, JavaScript, etc. have multiple libraries for the same problem - these libraries have different features, tradeoffs, designs etc. Same reason why existing projects get forked and new projects get started. Same reason these 'huge ecosystems' have frameworks, design patterns, idioms, best practices, etc. Competition, innovation, new designs, new ways of solving existing problems is a good thing. I don't see dark as anything more than a very new framework, with lofty promises and zero evidence towards the idea that it will be better than existing systems in any way. > Small languages are extremely vulnerable to extinction regardless of who maintains them. But if at least one person's full-time job is to maintain a language, I feel much more confident than if 1-5 people are maintaining it part-time. A tiny FOSS language at least has a chance of getting some maintenance/bug fixes from the community. What happens when your proprietary language dies for lack of traction? Also, nothing prevents a person working full-time on a FOSS language.

marta_morena_28 6y ago

> The Dark engineers What do you mean. The whole page talks about "I" and "me". That's going to go well...

freehunter 6y ago
There used to be a company and a team of engineers. Recently they laid off everyone and it’s down to just a one-person show now.
- nullsense 6y ago
  So, heading in a positive direction then?
- perrygeo 6y ago
  Sounds like a great time for a backend rewrite!