> offset the deploying mechanism and control (probably to varying degrees) to a third party that’s dependent on another third party

This sounds exactly like working inside any big company, and all that pre-canned infrastructure is a huge benefit to any project

It will be interesting to see what they've built in the cold light of day, and whether it delivers. I'm apparently not nearly as pessimistic as others on this thread

Pre-canned infrastructure is generally fine, this requires you use their programming language and their text editor. The article and website make no mention of if your code is stored in version control you can mirror, or if there are any plans to open source it (it appears to be a complete black box, which is fitting for a product called Dark). You also rely on their infrastructure, so it truly is putting all your eggs in the basket of a single startup.

Any time something is tauted as magic, or there’s an example that is ridiculously simple to deploy, anything beyond that is impossible.

I guess I’n with the pessimistic people. I just cannot see it ending well.

For small things you don’t want to think about or tiny/solo teams, I could see a use case for this. But the product has to be really, __really__, fantastic for bigger groups to consider the control trade off.

I’m not bashing on the product, I’m heavily apprehensive of the model for the situations I’m involved in. I can say with certainty it’d never make its way into my current place of employment for several reasons.

The game is never to target the big teams. But make the development leaner for coming generation and smaller teams that they basically own the complete idea. This dependency play is what Google always does. Create the infrastructure, let others do the hardwork. Though I am skeptical too of the efficiency of the tradeoffs.

Agreed. It only sounds maybe 1 step removed from where aws lambda’s are now. You fiddle with the code in the lambda IDE, and submit for deployment. Is this really that much different?

Lambda is the antithesis of frictionless development, most of your life is invested in figuring out the Lambda way to do things, just like App Engine before it

"I just need to run this function every 10 minutes"

.. (3 blog posts later)

.. (1 lunch break later)

.. (5 Git commits across 3 repos containing a mix of CloudFormation, CloudWatch and Terraform, 3 new IAM policies and 12 S3 buckets with completely unmemorable names)

.. 5pm, oh shit, I haven't actually written the function yet

Dark founder here. Yes, completely agree with this. To a certain extent, Dark is aimed at being what lambda/serverless should have been.

The thing that frustrates me about Lambda (and really all of AWS) is that we're just dealing with a bit of code and bit of data. Even in 1999 when I had just started coding I could write something that runs every 10 minutes. But now it's super challenging. Why is it so hard to take a request, munge it, send it somewhere, and then respond to it. That should be trivial! (and in Dark, it is)

You think what they should have been was making people use a custom unproven language and a completely different text editor? Why would anyone want to eliminate their choice in two areas that have been commoditized so well?

haha, I've been burned by app engine too - well put.

I'm working on DETA – it abstracts away Lambda/S3/CF/CW/TF. Would you be interested in a quick chat?

I hate acronyms so much :'(. To anyone reading this, please write the full term at least once before using an obscure acronym. It's a pain to decipher, creates confusion, and results in miscommunication. I have no idea what DETA is for and google doesn't help at all. My best guess is "Deployment Estimate Time of Arrival", which doesn't make any sense...

Sorry for the rant.

Sorry that you didn't like our name. It's not actually an acronym. It's inspired by Commander "Data" from Star Trek TNG.

They're probably referring to the "CF/CW/TW" part.

> .. it abstracts away ...

Isn't that what people in this thread are speaking against? It may abstract something away, but with the downsides of learning this new (probably leaky) abstraction, increased third-party reliance, more magic, etc.

We believe people tend to opt for the less complex solution over time. This evolution happens slowly and may upset many people but in the end, simplicity wins. Caching, SQL, Load Balancers didn't exist a few decades ago and now we spend months of our limited time trying to tame the cloud machine.

Don't get me wrong, I'm a lover of (complex) systems, but not everybody needs them/can maintain them.

Edit: couple => few

"Multi-level storage system having a buffer store with variable mapping modes" (1972) mentions caching. The term doesn't require explanation in the paper so was obviously in reasonably wide use already https://patents.google.com/patent/US3820078A/en

"Sequel: A structured English Query language" (1975) https://dl.acm.org/citation.cfm?id=811515

"Vertical Migration for Performance Enhancement in Layered Hardware/Firmware/Software Systems" (1978) describes how to do live/live migrations behind load balancers. https://www.computer.org/csdl/magazine/co/1978/05/01646957/1...

All of these technologies is way older than you think.

Thank you for the very useful links.

Caching, SQL and Load Balancers definitely existing a couple of decades ago...

Edit: Regarding your edit to "few", 40-50 years (at least) isn't a few.

What is a DETA?

DETA[0] is a scalable 'cloud computer' built out of a set of managed services and SDKs that removes time spent by you and your team on infra configuration, security, and maintenance.

Happy to elaborate more if you're interested.

[0]https://deta.sh/

Dirty Eccentric Telecom Asshats?

When you've written the Terraform boilerplate once, making a second lambda that runs every ten minutes is really smooth.

I think they actually do much more, they go really deep, it's like your project is huge ast, deployed when saved/compiled/typechecked, it's like big, persisted ast tree; i think this is how they store things - as ast, ast deltas, there are no text files at all. I'm not even sure if you can save your sourcecode if it doesn't compile. Compiled (and "locked") code means deployed code. I don't know how they do deployment of single code as multiple instances - maybe they don't support it at all? ie. everything is stateless with context comming in as input? I don't know. Everything seems "dark" about this project (no reference, no examples, no playground, your code belongs to them, can't use git etc.). But it's interesting, will keep an eye open for this one.

This is the right approach to do this kind of stuff!

The problem with dark is that it's a language and it's 'hidden and proprietary' - unfortunately, it's too dark to know what it actually is so we can't but assume. I hope I'm wrong and it's less of a language and more of an editor.

I'm working on a similar sideproject where you define your data in a tree-like shape then generate stuff from that with events in between. Kind of AST but more of an Architecture Syntax Tree. The advantages are exactly what you said and dark claims - compiled code is deployed code, otherwise it is just a data tree.

This enables automatic versioning, caching, generation and provides a better UX for development where your types are infered, your tests obvious, your errors are clear as a day and you basically can't fuck up.

Yes, this is pretty close! There are multiple instances in the cloud - when a HTTP request comes in we look up your program from the DB and run it.

Most times I've worked with Lambda (or other competing cloud functions) it's been difficult or infeasible to run my function locally. Which means I can now ONLY test my code manually after a minute or so of deploy time.

Separate from anything else about Dark, it appears to fundamentally avoid that problem.

With Azure Functions, the runtime[1] is open source, and the development tooling for VSCode makes it easy to run them locally [2], starting up in a few seconds. You pass in your database keys etc as environmental variables, and it integrates nicely with the IoT Hub tooling so you can debug the whole device sends message -> function gets hit flow in one window.

However, I have had this break in places before, and not really been able to figure out why from what is going on under the hood, needing to restart various parts to get it working. Checking the contents of the database is annoyingly manual, requiring a seperate GUI only tool[3] and hitting the refresh button a lot, a "watch" window would be much nicer. Profiling once deployed is also difficult, I ended up having to inject timestamps at various different places to try and measure end to end latency.

If Dark can give better tooling for debugging once deployed, it would be a definite advantage.

[1] https://github.com/Azure/azure-functions-host [2] https://docs.microsoft.com/en-us/azure/azure-functions/funct... [3] https://azure.microsoft.com/en-in/pricing/details/data-explo...

To find out the surprising fact that Azure IoT makes no promises about maximum latency at all, not even a "soft" guarantee without SLA penalties.

I've done a fair number of Azure Functions - mostly triggered from messages on storage queues and running locally under Visual Studio they mostly run fine with an occasional glitch where the function won't trigger - easy enough to stop it and run again. I don't find it a huge problem though.

The Serverless framework provides offline functionality (https://github.com/dherault/serverless-offline) to do this - I've found it works pretty well.

For Lambda, SAM Local [0] exists. Not to say that it magically addresses all the local development cases, but it's there.

[0] https://docs.aws.amazon.com/serverless-application-model/lat...

Can't speak for Lambda, but Azure Functions is trivial to run/test locally.

Have you tried localstack (https://github.com/localstack/localstack) to run AWS lambda locally?

I only work with Azure, so no.

You are right. Reported this submission as spam.

It is a closed invite-only product.

They try to mislead saying that the only downside is learning a new language. Every good programmer loves to learn a new language. The actual, real downside is license/lock-in/ownership.

...Their website is hosted on Medium, not gitlab/hub. I rest my case.

Agree with the rest... every other solution is FOSS. A closed proprietary tool has a big mountain to climb.

> Every good programmer loves to learn a new language.

Er... no. I am still seeing new ways to leverage C after 40 years on it. Creating a new language is the ultimate self-indulgence.