3 ms·

I think the fact it maintains the "backend/frontend" separation makes it an awkward product solution imo. Dark being a proprietary language means most "experie

I think the fact it maintains the "backend/frontend" separation makes it an awkward product solution imo. Dark being a proprietary language means most "experienced" or "full-time" software engineers probably won't touch it. You can get pretty close to "deployless" with FaaS services now anyways in whatever language you like. So if this is being targeted toward low-experience/no-experience developers that just want to get something running, how is it addressing the problem much better than all the no-code/low-code solutions? For that market, I don't think having them even deal with a separate "backend" and "frontend" is a good idea, they should just be dealing with logic only and have that whole concept abstracted away.

ithkuil 7y ago
It seems that darklang goes one step further than your average faas: every new code you write is deployed as you write it without any explicit deploy action, but the design of the Lang/IDE ensures new code is always behind a feature flag that makes that new behavior visible only to you until you decide to expand the audience until eventually reaching 100% of the users. You can do that with any language and any serverless stack around, but it still requires work. I'm struggling often to make my teams accept that this little extra setup work will let you iterate faster and often it's not that obvious that it would, since the overhead of the process is non-zero (for some value of zero). I can't wait to try darklang; I'm really curious. I just need to think of a pet-project that would be suitable for the beta.
- carlosdp 7y ago
  That progressive deployment is neat and all, but I'm not convinced that's a problem that actually existed. More importantly, I'm definitely not convinced it's a big enough feature to drive a significant amount of developers to sacrifice the ecosystem benefit from using a popular/open-source language to use a proprietary language that only works on one proprietary cloud host. Like how is that a 10x improvement on modifying a Lambda function in something like Netlify and clicking "Deploy"? And just "Rollback" if it goes wrong? For most products, which have relatively small user counts, they don't gain much from gradual rollouts.
  - ithkuil 7y ago
    I do share that feeling of unease that comes from non only from the lock-in but also from the departure from the text-only environment I'm so used and probably many other things that might be practical showstoppers for dark adoption. Right now I'm looking at it for what it is: food for thought. For me this gradual deploy matters because: 1. it generalizes local development and production and possibly also staging/testing environments in between. I don't have to setup some docker-compose environment that sets up the whole shebang locally. I don't have to setup complex CI systems that spin up an env for integration tests. And I don't have to bend over backwards to ensure that both local and automated test envs are reasonably similar so I can troubleshoot when stuff fails only on CI. 2. even if I don't have that many users, and even if my uptime is not that important; I still don't want to unduly break the application. Somebody will be watching and complaining, if only your boss. What usually happens is that people tend to batch changes and have periodic pushes to production. I've seen products with relatively small user bases have very time consuming release processes. Starting weekly, then biweekly, then monthly. The more the pain, the less frequently you ended up doing them . The less frequently you ended up doing them the more painful they become. Then you end up with somebody dedicated on that because this "release engineering" is becoming clearly a bottleneck. And you do more of it, because now it's somebody's job.
    - iq22hi 7y ago
      Does dark provide graphql api?
- jimbokun 7y ago
  "... but the design of the Lang/IDE ensures new code is always behind a feature flag that makes that new behavior visible only to you until you decide to expand the audience until eventually reaching 100% of the users." Ah, so "Dark" as in "dark launch"?
- ilaksh 7y ago
  Nice username.
pbiggar 7y ago
> I think the fact it maintains the "backend/frontend" separation makes it an awkward product solution imo. When we were thinking about the scope for Dark, we briefly thought about trying to remove all the complexity for frontend too. However, when thinking about how Meteor went, and specifically about how much stuff is going on in the frontend world, we thought it would be simpler to understand if we stopped at the HTTP boundary. Bear in mind that there are tons of applications that dont have frontends, especially ones that are just APIs.
- carlosdp 7y ago
  Sure I can see that logic. But how many people are writing APIs and either 1) aren't experienced enough to figure out how to write a Lambda function (using a wrapper FaaS like Netlify), or 2) are experienced and are willing to sacrifice the ecosystem you get from open-source/widely adopted languages/frameworks for a marginal amount of convenience over something like Netlify, where they can use whatever language they already know. Maybe I don't see it and it's actually a lot of people. But in all my time working on APIs, I've never heard of someone writing an API who wasn't already a decently experienced developer. Typically the front-end facing solution would come first for them, because why would they build something people like themselves would have trouble figuring out how to use? Which is where most no-code/low-code solutions are targeted for that reason.
  - btown 7y ago
    Think instead about a frontend or app developer who wants a simple backend that Just Works and can talk to the outside world painlessly (and there are tons of cases where something like Firebase wouldn't suffice). They're not worried about closed-source or lock-in because that's simply not going to move the needle on their project's success at that stage. It could be huge for that market.
    - carlosdp 7y ago
      Do you need a brand new language to solve that problem though? That sounds like something solved by a FaaS platform that exposes a database and other common primitives out of the box, of which plenty are popping up all over the place. If we're talking about a front-end dev, they're probably using React, in ES/Typescript. Any backend product targeting these devs would be nuts to not start by offering a JS environment, I would think. Hence why every FaaS thus far starts with a Node env.

ithkuil 7y ago

It seems that darklang goes one step further than your average faas: every new code you write is deployed as you write it without any explicit deploy action, but the design of the Lang/IDE ensures new code is always behind a feature flag that makes that new behavior visible only to you until you decide to expand the audience until eventually reaching 100% of the users. You can do that with any language and any serverless stack around, but it still requires work. I'm struggling often to make my teams accept that this little extra setup work will let you iterate faster and often it's not that obvious that it would, since the overhead of the process is non-zero (for some value of zero). I can't wait to try darklang; I'm really curious. I just need to think of a pet-project that would be suitable for the beta.

carlosdp 7y ago
That progressive deployment is neat and all, but I'm not convinced that's a problem that actually existed. More importantly, I'm definitely not convinced it's a big enough feature to drive a significant amount of developers to sacrifice the ecosystem benefit from using a popular/open-source language to use a proprietary language that only works on one proprietary cloud host. Like how is that a 10x improvement on modifying a Lambda function in something like Netlify and clicking "Deploy"? And just "Rollback" if it goes wrong? For most products, which have relatively small user counts, they don't gain much from gradual rollouts.
- ithkuil 7y ago
  I do share that feeling of unease that comes from non only from the lock-in but also from the departure from the text-only environment I'm so used and probably many other things that might be practical showstoppers for dark adoption. Right now I'm looking at it for what it is: food for thought. For me this gradual deploy matters because: 1. it generalizes local development and production and possibly also staging/testing environments in between. I don't have to setup some docker-compose environment that sets up the whole shebang locally. I don't have to setup complex CI systems that spin up an env for integration tests. And I don't have to bend over backwards to ensure that both local and automated test envs are reasonably similar so I can troubleshoot when stuff fails only on CI. 2. even if I don't have that many users, and even if my uptime is not that important; I still don't want to unduly break the application. Somebody will be watching and complaining, if only your boss. What usually happens is that people tend to batch changes and have periodic pushes to production. I've seen products with relatively small user bases have very time consuming release processes. Starting weekly, then biweekly, then monthly. The more the pain, the less frequently you ended up doing them . The less frequently you ended up doing them the more painful they become. Then you end up with somebody dedicated on that because this "release engineering" is becoming clearly a bottleneck. And you do more of it, because now it's somebody's job.
  - iq22hi 7y ago
    Does dark provide graphql api?
jimbokun 7y ago
"... but the design of the Lang/IDE ensures new code is always behind a feature flag that makes that new behavior visible only to you until you decide to expand the audience until eventually reaching 100% of the users." Ah, so "Dark" as in "dark launch"?
ilaksh 7y ago
Nice username.

pbiggar 7y ago

> I think the fact it maintains the "backend/frontend" separation makes it an awkward product solution imo. When we were thinking about the scope for Dark, we briefly thought about trying to remove all the complexity for frontend too. However, when thinking about how Meteor went, and specifically about how much stuff is going on in the frontend world, we thought it would be simpler to understand if we stopped at the HTTP boundary. Bear in mind that there are tons of applications that dont have frontends, especially ones that are just APIs.

carlosdp 7y ago
Sure I can see that logic. But how many people are writing APIs and either 1) aren't experienced enough to figure out how to write a Lambda function (using a wrapper FaaS like Netlify), or 2) are experienced and are willing to sacrifice the ecosystem you get from open-source/widely adopted languages/frameworks for a marginal amount of convenience over something like Netlify, where they can use whatever language they already know. Maybe I don't see it and it's actually a lot of people. But in all my time working on APIs, I've never heard of someone writing an API who wasn't already a decently experienced developer. Typically the front-end facing solution would come first for them, because why would they build something people like themselves would have trouble figuring out how to use? Which is where most no-code/low-code solutions are targeted for that reason.
- btown 7y ago
  Think instead about a frontend or app developer who wants a simple backend that Just Works and can talk to the outside world painlessly (and there are tons of cases where something like Firebase wouldn't suffice). They're not worried about closed-source or lock-in because that's simply not going to move the needle on their project's success at that stage. It could be huge for that market.
  - carlosdp 7y ago
    Do you need a brand new language to solve that problem though? That sounds like something solved by a FaaS platform that exposes a database and other common primitives out of the box, of which plenty are popping up all over the place. If we're talking about a front-end dev, they're probably using React, in ES/Typescript. Any backend product targeting these devs would be nuts to not start by offering a JS environment, I would think. Hence why every FaaS thus far starts with a Node env.