1. 21

  2. 18

    Isn’t this a way for a company to have compete control over your backend? I don’t even like using AWS specific feature.

    I can’t imagine not being able to at least move my app off the managed infrastructure when its long term plans no longer include existance.

    1. 13

      Adding to this, I’m skeptical of the entire premise that “backends are needlessly complicated” to start with. Most of my time is spent in application-specific business logic. No magic anything is going to change that.

      The claim that “Dark is frontend agnostic” is only true if “frontend” means “SPA”, because all Dark does is give you a Rest API.

      The entire thing seems like a solution in search of a problem.

      1. 9

        I would say modern backends are needlessly complicated. The business logic is a tiny part of it, and there is all this yak shaving to make it run reliably.

        Good post by the Dark founder. It’s a few years old but the problem is still there IMO:




        I mean 10 years ago I sat next to the App Engine team and they were solving this problem too. You’re supposed to write your business logic, and hit a button, and then your code “just runs”. That is not how it works “in the cloud”.

        Somehow the problem has gotten worse.

        If you don’t notice the problem, it’s probably because your company has a good sys admin / devops team and you don’t work in that role.

        A recent thread about Sandstorm’s paid service shutting down reminded me of these issues:


        On a related note, I am on call 24/7 for Oasis. It rarely breaks, but when it does, I have trouble fixing it in a timely fashion. For one example, in January, an unexplained Google Cloud hiccup forced me to transfer Oasis to another zone, which it wasn’t designed for (whoops, yeah, it’s not multi-homed, we never got that far). It was down for hours. Luckily it was a weekend and I was at home, or it could have been days. In another incident, I discovered that GMail had been routing all my monitoring alerts (and e-mail to support@, security@, contact@, etc.) directly to spam for months.

        1. 9

          This seems like a self-created problem to me. “Doctor, my vision has degraded after I stabbed myself in the eye, what gives?”.

          My GoatCounter.com service runs on a $20/month Linode VPS. This is massive overkill, as the $5/month works well too but I wanted some headroom and $15/month is next to nothing. I benchmarked the $5/month one and it could handle about 800 requests per second.

          Setting up a simple Alpine Linux VPS is not harder than setting up Docker (which is … also Alpine Linux); probably the biggest difference is that you need to run ntpd on the VPS. The deployment is a 50-line shell script. I could do the Continues Deployment thing by running it in Travis, but I’m lazy and don’t feel like doing database migrations “the right way” in the current beta. I restart it all by ssh-ing to the machine.

          All of this clearly isn’t perfect or a good solution for everyone, but it works fine for small and even medium teams, is extremely simple to set up, cheap, and most importantly: easy to understand.

          If you don’t notice the problem, it’s probably because your company has a good sys admin / devops team and you don’t work in that role.

          I was actually doing a lot devops stuff at my last company, not because it was my job but because no one else was doing it. I stopped doing it after the kool kids came in with k8s and docker-compose and whatnot and since then it’s been a mess. It’s now well over a year later, and the current sys/devops people have only just gotten a real handle on things (or so I heard, I no longer work there but am still in touch with several people).

          The amount of time spent on the entire effort is phenomenal, and what have we gained? I don’t know, because we were already doing CI/CD before with AWS. The sysops people say it’s “easier”, and everyone else is like 🤷 because they have no idea what is going on any more.

          I’m reminded by the law of triviality (made famous in by phk’s bikeshed email), these days it seems all this devops stuff is like the nuclear power plant, and that everyone just shrugs it off as “I guess we need it, I don’t understand it”. Perhaps we need a new verb as the opposite of “bikeshedding”: “powerplanting”.

          Now, that doesn’t mean that these tools don’t solve real problems or aren’t useful, but that doesn’t mean they solve your problems or are useful for you. I wrote a thing about that a while ago: https://arp242.net/dont-need-k8s.html

          Going back to this Dark thing: do you think that will scale well to large teams? Because I suspect it won’t, so in that sense, I don’t see how it improves on just a simple shell script deployment. If it was a service which offered super-easy creation of webapps in some standard language/framework (say, NodeJS, Rails, Django, whatever) then sure, seems like a cool thing to prototype, demonstrate, or learn things. But it’s their own platform, so that advantage is kind of gone.

          You also still need to muck about with npm locally for the frontend (and they claim “backend is hard”, HAH!), so it’s not even a “one stop solution”.

          1. 2

            I’m generally with you – my site is a bunch of static HTML built with Python and shell scripts: https://www.oilshell.org/

            It’s on shared hosting (which works great), and the only other hosting I use for is a Linode VPS.

            That’s for personal stuff. But or many years I worked on big clusters for a living, i.e. Borg, which is essentially the predecessor to Kubernetes, so I know the other side too.

            It does seem like Kubernetes is often being misapplied, and I can name a number of things about its design that I don’t like. But like you said your post, it doesn’t mean it’s useless. I can imagine some problems for which it’s probably the best solution right now, if an imperfect one.

            I probably don’t have any problems that Dark solves either (since I spent 20 years learning about all this stuff), but that doesn’t mean that nobody has them. One reason I think it’s interesting is that it’s contrarian – i.e. “at least it’s different”. It could be 100% wrong, or wrong for 90% of problems and right for 10% of problems. Who knows, but it’s good to try.

            I think people are probably benig dismissive here because of the marketing, and that’s to some degree understandable. But I like seeing different ideas being tried.

            Saying it’s a “solution in search of a problem” is overly dismissive – maybe it’s just not a problem you’ve ever had, which is fine.

            Edit: I would also say Sandstorm is a great use case / problem space for people who care about open source and “devops” complexity. There are a bunch of open source web apps out there, and they are pretty big and have a lot of dependencies. IMO it would be better to reuse all that work that people did writing open source web apps. But most people don’t do that – even experienced programmers. They just use the cloud because it’s easier than setting up your own.

            I’d challenge anybody to stand up all the apps that are inside Sandstorm (Etherpad, etc.) and make them run reliably “the old way” (i.e. on a VPS). It’s a lot of work. The new way isn’t great, and is to some degree based on a lot of misunderstanding, but the old way is also bad. My intention is for Oil to solve some of those problems. Shell is good at gluing things together that weren’t meant to be glued together, and for patching over problems in production in a simple way.

            FWIW from 2010-2015 I was working on a side project that involved hosting R apps. R apps have a lot of dependencies (CRAN, Fortran), and you don’t want to rewrite that code, because there’s a lot of specialized domain knowledge. This was pre-Docker and pre-Kubernetes. IMO those two technologies “did it wrong” for many common use cases, but I appreciate how hard the problem is, having worked on it. That work led to Oil, e.g. because I was building containers from scratch with shell scripts, writing git hooks with shell, etc.

            All that was a long-winded way of saying the “simple, old way” also has a lot of problems. Docker and Kubernetes don’t really pull their weight, but they’re doing something !

          2. 4

            I’d say you’re right, generally backends are needlessly complicated, but that’s only because some engineers chose to do it that way…

            Some just don’t - they don’t use docker, k8s, whizbang whatever - and they don’t present at conferences about it or write blog posts about it because it’s not particularly sexy. They just boringly build something that runs a business effectively and take nice long mostly worry-free vacations.

            1. 1

              I wouldn’t go that far… See my sibling response, which took a bunch of editing to get down to the point.

              Conclusion was: Docker and Kubernetes don’t really pull their weight, but they’re doing something ! I wish there was something better for sure.

        2. 1

          I think this could be a godsend for client heavy apps with small backends. Sure, the vendor could have “complete control”, but if they were ever to hypothetically abuse that position, you should be able to spend 1 week to port to your own custom stack. For many apps, being able to build/deploy a reliable backend service near instantly sounds amazing. If your backend is something like eBay, yeah, this probably isn’t for you.

          Here’s an HN comment that provides a good case study: https://news.ycombinator.com/item?id=20986346

        3. 16

          Dark is a holistic programming language, editor, and infrastructure for building backends. You write in the Dark language, using the Dark editor, and your program is hosted on Dark’s infrastructure.

          It sounds like they took everything I want in a programming language ecosystem and then did the opposite.

          1. 12

            This just seems like Total Vendor Lock-in as a Service.

            1. 2

              It’s just for your backend. I think of it as just a better Firebase/Lambda/GCF/AF.

            2. 6

              I’m intensely skeptical of products like this, and yet I can’t help but be impressed and excited for Dark’s future. It reminds me a little bit of VR - it’s definitely not there yet, but you can see the tantalizing future in the distance.

              In particular I like the declarative/FP inspired way of coding. I’m not sold on the viewing of code on a flat pane you sort of scroll across. I think I’d prefer a more traditional single file, single function/group of things, based approach. Perhaps different ways of presenting this information, but still showing the links between components.

              It looks very raw right now, but I’m looking forward to seeing what’s in store.

              1. 1

                I like the idea of the plane. I’ve toyed with that pattern myself a bit (and like how Apple Numbers is playing around with it too), and there’s exciting potential there, just haven’t seen a killer implementation yet.

              2. 9

                To pick a positive viewpoint, I thought what they built was really cool. There’s a very smalltalk machine like aspect to it. The integration between editor and runtime, and with tracing and inspection, is all very cool. Having worked on an ActivityPub server recently, something like this would have been a great aid in development, handling unexpected requests and responses.

                1. 5

                  I just wonder how it relates to https://www.unisonweb.org/