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?
"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
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)
Sorry for the rant.
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.
Don't get me wrong, I'm a lover of (complex) systems, but not everybody needs them/can maintain them.
Edit: couple => few
"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.
Edit: Regarding your edit to "few", 40-50 years (at least) isn't a few.
Happy to elaborate more if you're interested.
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.
Separate from anything else about Dark, it appears to fundamentally avoid that problem.
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.
[0] https://docs.aws.amazon.com/serverless-application-model/lat...