> ... Ellen Chisa, CEO and co-founder at the company, admits that the Dark approach requires learning to use her company’s toolset, but she says the trade-off is worth it because everything has been carefully designed to work in tandem.
So this “deployless” method is really you just offset the deploying mechanism and control (probably to varying degrees) to a third party that’s dependent on another third party. I don’t buy that. There are so many tools that make web application deployment simple and easy without constraining what tools you get to use and what platform you get to run it on.
I’d have to look more at the project itself, but just reading that article I have a number of concerns/questions with this idea. I would be interested in who they are trying to market this to. One size fits all sounds great in theory, but rarely ever works out well in practice.
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
I guess I’n with the pessimistic people. I just cannot see it ending well.
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.
"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
Separate from anything else about Dark, it appears to fundamentally avoid that problem.
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.
> 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.
> I think the biggest downside of Dark is definitely that you’re learning a new language...
But this is not it. Learning new languages isn't that hard, and a language so well designed for an ecosystem would likely be a pleasure to use. They are probably giving this as their "big downside" because it's not actually their big downside.
The real big downside is proprietary lock-in. My tools right now are open source, developed in the open, things I can contribute to or at least understand at a fundamental level. "Python" can't go out of business, "Postgres" won't get acquihired and shut down with 30 days notice, and Docker images can run on plenty of hosting providers where there's lots of competition.
While I might bet a company on a new technology I'm not going to bet a company entirely on the whim of a company, who may pivot, get bought, shut down, raise prices, etc. Hosting is the closest I'd get to this level of lock-in, but if that changes I don't have to rewrite all of my code, reproduce business logic, and also rewrite from a high level language like Dark to something that doesn't provide any of the same primitives.
Around some of the specifics: we've no intention of pivoting. If we discovered that Dark had a massive opportunity to be the AirBnb for market analytics (or whatever) we would 100% ignore it and keep doing what we're doing. Around pricing, we want Dark to be super cheap. Our intent is to be "within 2x of running the same app written in Node on AWS". We saw how much people leave Heroku because of the premium pricing and we don't want that to be us.
The other stuff is valid and we're looking for ideas here. Would it solve your problem if you were able to export a mostly similar working node/python/go app from your Dark program? Would it need kubernetes configs or to run on Heroku? Would you prefer that it be semantically exactly the same but the code is ugly, or with the code having the same look-and-feel but slightly different semantics?
I'm not sure I buy the "coalescing multiple things into one makes things simpler" argument - the simplicity comes at the expense of expressiveness, flexibility and optionality. A large, highly-opinionated monolith, right the way across the stack, is bound to have made some design trade-offs and decisions that are either plain wrong (we all make mistakes) or don't fit with however I want to actually use it.
To do this at the AST graph/language level strikes me as both genius and absurd - not only is language design very hard, but you clearly have a massive uphill struggle to provide sufficient library and framework-level code on top of that to be able to start to compete with more mature options. Not to mention things like code review tooling (it's neither text-based, nor even in any form of conventional revision control system, so likely start from scratch). Security controls, auditability, vulnerability management for any library ecosystem that springs up around this, etc. etc.
By rejecting text you are having to reinvent and support a compiler, an IDE, github/gitlab (or equivalent, with their massive functionality set including protected branches and security controls and the like), package management maybe, debugger tooling (on the web), release/rollback systems/UIs, perhaps even monitoring and alerting (because you're promising the users they don't need to run infrastructure/services like Prometheus and the like and your "roll out" process looks so different).
Does Dark really have sufficient expertise around all of that to want to make this stuff totally monolithic? Is it even possible for a startup company to really compete in that sort of global (massively open source) scene?
Convincing people to bet their company on your company, both as an ongoing enterprise and as a place that can get all the inherent trade-offs here well-matched to their individual use-cases is going to be an almost impossible sell. Regardless of how much you assert that you believe in your mission and don't want to ever pivot. You can't blame people for being sceptical, especially when the opening paragraphs essentially say "this is a silver bullet".
I wish you luck.
Personally I don't see why anyone would choose such a closed ecosystem in this era when so many great open source options exist, where we can read and edit source code, substitute components, and pivot technically in so many ways impossible with a black box unironically named Dark. There is just way too much risk around hitting the limitations of the platform or corporate shifts. Why bet your biggest investment on something you have no control over? That would be incredibly foolish.
If you want this project to be successful, open source it and maintain your competitive advantage by adding value not monopoly power. If you are actually concerned about lock-in as you say, don't lock customers in.
I got accepted to the private alpha but I can't tell why I should actually use this.
> Around some of the specifics: we've no intention of pivoting.
I'm afraid I think this is a naive approach, and I'd encourage you to design for the assumption that the company will fail to deliver on the original promise in some sense, not because I don't believe in Dark, but simply because of the realities of running a startup.
> Our intent is to be "within 2x of running the same app written in Node on AWS".
This is a nice goal, but as someone who writes Python/Django/JS/etc and deploys on a mix of bare metal and AWS, I know that we have very significant savings over the average AWS-native deployment (with all the costs that come with lock-in, the spending culture that AWS encourages).
The thing that would encourage me most here would be a self-hosting or partial self-hosting solution. Maybe you provide AMIs for AWS, or docker images, etc. If we can run where we want, and optimise costs in ways we want, that's great.
Being hosted brings other complexities when you start to add more complex services. If for example we want to add an instance of Postgres (perhaps the Dark database doesn't have great spacial data storage options and we want to use PostGIS, perhaps we want something that takes different options from CAP), we need to deploy that somewhere. I'd hope we can write Dark code to talk to it, but we ideally want that software on the same network, same region, same datacenter, etc. We can't do that if you host it, so being able to self-host would have a number of advantages.
> Would it solve your problem if you were able to export a mostly similar working node/python/go app from your Dark program?
Maybe, but again, we have ~500k lines of code in the business currently. If there was any difference in business logic, or any unexpected behaviour in any of this, that could cause significant damage to the company. Maybe if you export tests too that might mitigate the issue, but tests are just code, and if the transpiler isn't perfect (for what definition, who knows?), then tests would be subject to the same transpilation bugs.
An export of Dark code, a working version of the Dark runtime (minus tooling and some secret sauce perhaps), a set of tests, a basic CI/CD pipeline (not a 50ms one), and a set of Kubernetes configs... that might be enough, as it would work the same and essentially be just another regular web app. However, that would lose the benefits of Dark and its ecosystem, and so may end up just being more tech debt. It wouldn't be bad for the case where Dark the company shuts down, but for a company who need to transition off Dark for some reason, they still end up with a monolith of tech debt.
All of this is a long way around to say that I think I would be more excited about Dark if it were fundamentally an open platform. I don't know how you make a business model out of that (consulting? enterprise? support? none are a slam dunk), but knowing that the technology stands on its own without the company, and is still convincing with the features touted regardless of what happens with the company or if the technology took a different direction, would be much more reassuring.
So, everything that is currently delivered in the real world by technologies like OutSystems, which have an enterprise customer base, 1-click deploys, and that you can actually try for free.
No lunch is free, the small plan is a single dev and max 100 users. Which means, once you go have 101 customers you'll have to charge users at minimum 62,5$/mo just to cover expenses.
I'm not saying that's not cheap for what you get, but the "free" constraints are there.
Before you jump from thinking a specific feature is wrong, to asserting the whole project is a waste of time: please take a moment to consider where your broad assertion might be wrong.
In the words of Sam Altman: "it's easy/fun to say every new startup you hear about is bad. you will usually be right. you will never be successful."
They talk for example about all the great save-is-deploy things and first-class feature flags and I'm still waiting to know how do I not destroy the production database with one typo and how does staging isolation work in this environment. And how do you revert changes? Again, feature flips they talk about are not it.
Happy to answer questions on it though - I answered tons of questions about it in the last HN thread.
Some specifics around your questions:
- it would take more than a type to destroy the production DB. You'd need to type DB::deleteAll, then run it (which you'll need to do as an explicit action, either click the "run this function" button, or enable the feature flag to users). We'll eventually have backups so you can undo, but we don't yet.
- staging isolation: there aren't infra questions here since we run the infra. But we'll probably allow DB clones so you can test this sort of thing.
- reverting: That depends on exactly when you want to revert. If you've made a new flag and you want to not do that anymore, just change the flag condition to "false". You can then cancel the flag, or iterate on it. If you instead want to go back to a previous point in time, we've saved every version and you'll be able to pick from them.
No idea what that tweet is meant to say though. People who are critical about startups are never successful? Really? You can easily argue for the opposite.
If 95% of things fail, you'll be correct 95% of the time by calling each thing a failure.
But you'll never be in the 5% yourself. (sure, an exaggeration to say you'll never be successful, but such is 140 characters)
(Agree with your points re audience. I'd hope people can differentiate between things they don't use and things that are useless)
And now there is a startup which says "let's edit directly on the servers, automated CI is not needed -- the code will always be correct, and we will add version control in the future.. maybe..."
How do you think people will react to this?
The most legit feedback is probably around the proprietary language. Not because learning a new language is that bad, but that a "feature" of most languages is the ecosystem of libraries & frameworks around it. It's possible that Dark is going to be open source one day, because I don't know how they'd build everything themselves.
Sure, all it provides is already technically possible with what exists - but what if the 10% they shave off turns out to be the crucial 10% that carve out a completely new area in programming? Maybe having a fully integrated development experience actually is the "retrospectively obvious" missing thing...
That said, their exclusivity-first approach whose first step essentially is full and complete vendor lock-in makes me skeptical too. I personally don't think they'll be too successful, as the model they're proposing is both uninviting to newcomers and fraught with sustainability perils for any serious long-term project. And that's just from a business perspective, I can't overstate how important I consider open technologies to be.
But I can't get rid of the "future of programming" tingling, which a few people here have alluded to as well. The "open-decentralized-interoperable" bazaar and the "monolithic-integrated" cathedral conflict is as old as time. And while zero-friction infrastructure is a nice selling point, I'm personally more interested in what's allowed by having the language, editor, and apparently the entire ecosystem be developed hand-in-hand from the first step - a lot of fancier features (smart code completion, thorough static analysis, code exploration, automatic diagramming, proper e2e testing) is hard specifically because it needs to built on top of what already exists.
Having a garden with walls this high might actually bring a lot of surprises.
Technically very interesting.
Practically I'm not sure it'll fly, at any complexity project development means in big part playing around locally before pushing ideas up. On dark platform the code seems to be in compiled = deployed state only, or am I wrong? What about documentation, how is testing done, benchmarking, integration tests, if the system goes crazy, is there a way to actually stop it? What about recovery from backups? Reverting to past history code? After reverting is the new code still available so it can be fixed before next deployment?
The scope they're claiming is gigantic, they must be taking compromises somewhere. There's no way is all unicorns and rainbows.
However if they manage to execute it well, the potential is huge - they can create marketplace for libraries/services, they can become appstore+github+aws in one for execution-ready solutions (libraries, services etc), which could be huge.
Wolfram does something similar. Salesforce as well. Dark seems similar but for webdev, it's like serverless/lambda v10.
There's two ways we deal with the gigantic scope:
- do the most important stuff to validate our concepts first, and don't do the other stuff yet. Then people who will tolerate the missing stuff can build on it now, and people who can't deal with today's risk may be happy with the lesser risk that comes in a year from now*
- it's actually easier to build this gigantic scope when it's all tied together. Building an editor that only works for Dark code is far easier than making something like VSCode that needs to support everything.
[*] FYI: right now we don't have testing, benchmarking, integration tests. We do run/monitor the system to control it going crazy (an on-call rotation, pagerduty, escalation, etc). Users can revert to old versions of code. We have a backup of all data stored (though it isn't yet easy to use and needs manual intervention, though we do test the backups frequently).
this strikes me to be odd: why is a SCM all that important? even more important than a language and the ecosystem or as a vendor login already mentioned by several posters?
It's a central integration point for many workflows these days: code review, CI/CD, issue tracking, code quality metrics etc.
If you don't use a standard SCM, you'll have to either do without those tools, or build an integration yourself.
Imagine this, but with any editor or language of your liking, and the option to go deeper into the machine if things go awry. Wait, isn't that how things are right now?
> Infrastructure is time consuming and difficult, especially as services start to scale.
It doesn't have to be, and it's particularly easy when you're starting out. Most of the time it's just premature optimization. When services start to scale, maybe you can invest a little more effort into this area, too, so why use Dark?
With that experience, it would be hard for me to be convinced that something like Dark would be worth the risk. With things like this, you don't always realize the drawbacks until it's too late. Now, for my side project, I'm only really stuck with the database - locking myself into a programming language and even a text editor sounds like a nightmare.
What's old is new again I guess.
We actually did have Visual Studio installed in at least one test server
But yes, these online editor products have been created before and afaik they rarely get significant traction. Yet, even a small user base might make it profitable, so it does make sense, and hence these companies.
Compiling (and basically anything) can be done as a cgi script (https://github.com/RhysU/c99sh), I bet you could go a long way with that on a network drive or with an rsync daemon.
[1] https://medium.com/darklang/how-dark-deploys-code-in-50ms-77...
But Salesforce has a very specific niche, this seems to be for general purpose web dev and I’m pretty sure it will be a hard time getting people to switch.
Microsoft used to pitch their CRM in the same way as an "XRM".
These days I don't care about being in full control of my back-end stack - I just want to build something and ship it with least hassle as possible. I don't want to deal with provisioning, infra as code, containers, orchestration, message queues, load balancing, autoscaling, build configs and sundry.
I just need a statically typed functional language in which I can do that, which Dark is - it seems to have an Elm/OCaml inspired language.
Being fully tied to their platform with no alternative to migrate away to is the least pleasant aspect of the product as it stands today. But the product isn't even public yet - it is a difficult problem space that is badly in need of innovation and simplification - and many things are yet to be figured out. I'd be charitable to that aspect and see what as an industry we can learn from what Dark is doing.
Is there some information about the language somewhere? I don't seem to find any information from the site.
And does Dark even have the same sort of risk? It says your code runs on Google Cloud, which sounds like you get to walk away with your own backend if they shut down. Parse considered AWS an implementation detail, not a feature.
The sunset window was indeed fair and as you described they provided a clear migration path to self-hosted mongo and eventually the open source server.
The main problem was the vendor lock-in where our code base was completely tied to their platform and the migration which cost a lot of developer/ops time was forced upon us. Instead of improving our product we had to spend our time and money on the migration to the open source server that was still in its infancy.
After running the open source Parse server for a while which was not without its issues we decided to rewrite the product in Java/Spring/Postgres and now we are free from the lock-in. If AWS decides to quit we can move it over to Azure or GCP without too much problems.
My original comment was not a stab at Parse but a word of warning for choosing BaaS services. Parse allowed us to ship an MVP that turned into a V1 in very little time. But that productivity came with a hidden cost. A cost that nearly killed the company.
Currently there is very little known about the Dark platform and language. From what I see it looks a lot like a next-generation Parse or Firebase and I am very cautious about adopting something like that again.
Dark is a game changer in my opinion for getting a prototype online as quickly as possible, or a lightweight backend - and I imagine it can and will support much more.
If I'm a startup am I going to choose a language that has no developer base and no experienced devs and no ecosystem, without git, that's closed source so I can avoid hiring some devops manpower?
It seems like only a company with a massive builtin captive audience could pull this off. This makes it feel like they are doing this to be acquired which makes the whole thing even less appealing.
“Everything completely different and proprietary and we don’t have any actual real life examples”
In general when you try to simplify a process you increase the level of abstraction which leads to additional complexity in terms of customization and integration with third party systems and tools. Then you decide that it is a good idea to offer integration with the third party systems and tools and you increase the abstraction even more which increases the complexity even more. Also in the end you wonder if you are in the CD tools business or you are offering your core product.
It is much more productive to develop the product in mind with the tools for deployment that are already available. Unless you want to have a product and a "Services" division that configures and operates your product for the clients...
On the other hand, CD/CI needs to be an enabler and in small startup there is only so much time you can dedicate to it. Any change on this front tends to be disruptive and suck up non trivial amounts of development time. So keep it simple. Follow the principle of the least amount of surprise (for new team members if you hire them). And keep it reasonable. You are going to cut corners here one way or another. Don't obsess about that.
The Dark people seems to want you to buy into their entire stack (editor, language, saas platform, etc.). That sounds like a lot of risky unproven technology to me. Maybe use something more mainstream like heroku?
Including the part about combining everything together into a holistic solution.
It sounds like a terrific idea. Unfortunately most people seem to hate good ideas. Especially if they represent a significant change from the status quo.
And programmers are afraid to touch anything that's "easy" or moves away from colorful text representing complex obscure systems -- because sadly that is actually the only definition of programming that has stuck. And if there isn't enough of that stuff, programmers are worried they may be mistaken for users.
But maybe even though its a structured editor that makes things easier, it will still look like code and "count" psychologically as programming.
Anyway maybe it will actually become popular. Who knows. Good luck.
I think representing programs as text is the simplest form of programs that can be used by humans and computers. And that's why is has stuck.
From my point of view I don’t think I could inextricably bind my projects to a third party without any recourse in case something on their side changes. Deployment is not really a big deal nowadays, unless you work at a huge scale. But if you are working at that scale I don’t really think that you are eager to commit yourself completely to a small startup.
Do you use Dark for part of your business, and traditional tech for the rest, in which case you now have the problem of integrating your traditional stuff with Dark's black-box infrastructure?
Or do you build an MVP on Dark, then migrate on to traditional tech when you grow, in which case you now have the problem of migrating your entire business?
Or do you bet that Dark will pull more rabbits out of their hat, and you won't need to migrate?
They write about feature flags, non-text code and a fully integrated environment. So what they are trying to do is different however these ideas has been around for some time (Smalltalk/Self/some databases) but have been not been adapted by the industry of practical software development.
Probably because the implementation was never really good enough.
[1] https://medium.com/darklang/the-design-of-dark-59f5d38e52d2
(that company is an early adopter mentioned in https://medium.com/darklang/dark-announces-3-5m-in-seed-fina... )
I think importing something (require/import) is referring to deployed code. They blur the line between saved and deployed code. You need to have dedicated language+runtime to support such a different model.
I think their model is roughly - stateless functions only (context/state arrives as input), references (require/import) resolve to hash of ast they import; this hash is deployment "address" of function. In that sense all code is static/immutable/saved/deployed. Every time you import something, you're importing rpc wrapper, ie: 'foo = require('foo')` becomes `Foo = require(hashOf(astOf('foo')))`. I don't know if any of this is correct because there's no documentation, I don't know how they handle things like restarts or is it possible or not to have more than one deployed instances.
It seems like an experiment framework (eg whitelisted customers or IP addresses for alpha testing and percent rollouts) is a min bar for any reasonable implementation in Dark.
I’m also curious what kind of infrastructure you use to affinitize the rollout to particular customers. I’m used to that being coupled to user or device IDs, which I don’t see as a coupled feature of your stack.
Has anyone seen what the language or editor looks like?
sorry i could not resist.
Disallowing some side-effects? Ensuring all valid code follows their rules? Avoiding being dragged along by other languages authors’ changes? Something to do with the deployment pipeline, which implies a runtime requirement?
Dark raised 3.5 million USD from eight funds, which is under half a million each; maybe that amount is so small that a VC will invest it just for fun?
The language design better be exquisite to draw in early adopters. And then it better grow fast to achieve feature parity with all the other server languages.
This is an absurd approach.
Come use our proprietary system, we built it in the dark without embracing customers, hope we don't fail now that it's public, and launch your startup on it so we can make deployments easier.
#STUPID-IDEA
Go use Netlify.com if you want a serverless solution that you can deploy on trivially.
