> If you build your application in Dark’s language inside of Dark’s editor, the reward is you can deploy it automatically on Dark’s infrastructure on Google Cloud Platform without worrying about all of the typical underlying deployment tasks.
> ... 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.
> 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.
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?
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...
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.
"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
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.
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.
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.
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.
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.
I'm excited by almost everything about this. I think it could be transformational in some categories of software engineering, but I do have a big concern...
> 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.
Founder here. Totally fair concern - we're not thrilled about the lock-in either because we want people to try Dark and see that it solves a problem for them. We're looking at ways to improve this - would love ideas, and will be writing up some of our ideas soon.
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?
Your vision is extremely compelling and well articulated.
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".
If you want to use all that stuff, you can do that today. You can use GitHub and Go and Phabricator and Prometheus and whatever you want. People who want to a take a conservative approach have a million different options. Honestly, just run your app on AWS, it's got everything you need.
What we're trying to do is something different, removing a ton of stuff that we think we can allow you not need. And maybe it won't work for a whole lot of people - that's fine. Over time we'll fill out more of the product and support more use cases.
I made a mistake mentioning Prometheus - it's the least important point in my post. I get that you may provide something for monitoring (performance and tracing, at least) that's more baked into the whole AST/graph model and that sounds really very compelling. And obviously end developers won't need to monitor the systems/services because as far as they're concerned there aren't any. It feels a bit like electric cars - a bunch of new (and hard) problems arise, but it's compelling as a bunch of older (also hard) problems just cease to be. Huzzah. I'll certainly agree with you that the potential upsides here are very large and very compelling.
But the need for things like code review tooling, test coverage reporting and mocking frameworks (yes, I will want to isolate stuff via mocks) aren't going to just disappear with this kind of model. They're far from exotic use cases for the kind of business customers you will need to scale this and get real adoption and thus positive cashflow, more of a necessity. It's a real leap of faith to think it's worth rebuilding so much of these kinds of ecosystems that have taken thousands of man years to evolve and develop for existing languages. And if you don't have plans to provide that sort of thing you'll be missing out on most of the market, I would have thought. Yes, you'll get hobbyists but surely they won't provide the volume or reliable subscription-style revenue you'll surely need to make this sustainable?
Unless of course your endgoal here is being bought out by Google, in which case fair play. This is cutting edge thinking and tech, full of nice hard problems to work on and lovely "oh but if we just don't have that then we don't need this either, or can do this like that instead" type insights to be made. Cool stuff, but it still won't get me to bet the farm on it. I really do wish you well though!
> And if you don't have plans to provide that sort of thing you'll be missing out on most of the market
Realistically, we're not going to have all those things at launch, but we will have them later.
I don't think you're correct to say that it's not possible to get revenue without supporting every single thing that a customer might possibly need.
The people who are good matches for using Dark are people who don't mind that they're missing, including companies who are willing to pay. When we add them later, the people who needed those can start using it.
Regardless of what you say as a founder, if the growth is not there and a massive opportunity arises, your investors will push you to pursue it. You won't have much choice, and this is an empty promise you can't keep.
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.
Ok, so how do I just look up the langue, tools and play around with it? The website shows no examples of what the language actually is, what tooling actually exists etc.
I got accepted to the private alpha but I can't tell why I should actually use this.
We'll be showing it off in September (come to the launch: https://darklang.com/launch), and the only way before that is to get onboarded into the alpha. But if you don't know why you need it, it's probably not a good fit for you just yet.
>But if you don't know why you need it, it's probably not a good fit for you just yet
Right, it's def not a failed marketing push as to why your website talks about a programming language, with no actual examples of said programming language.
> 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.
I've played with some early betas of Dark and I must say being deployless may make a good headline, but there are many more-exciting features. There's visual programming, a concise OCaml-style language, a unique pub-sub mechanism baked right in, and integrated database support. It's a really fresh approach.
> deployless may make a good headline, but there are many more-exciting features. There's visual programming, a concise OCaml-style language, a unique pub-sub mechanism baked right in, and integrated database support.
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.
Hi! Let me push back slightly on "visual programming". Dark looks and feels like writing textual code. There are some built-in visualizations, especially around code organization and infrastructure, but it's much more like coding in python in vscode than using Github actions.
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."
I'd really like to be positive about it, because there's an interesting concept hiding inside, but... They neither let me play with it, not address the very basically questions I'd ask. It's purely marketing material for a product at this point.
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.
Founder here. This is fair. Dark is still quite early, and while we're talking about it, it's currently got a lot of sharp and ugly parts that we want to tidy up before we go public.
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.
With the staging/deletion, I meant a scenario like this: I'm working on some feature which deletes an item I own. But in a delete condition I put "or" instead of "and" (in a non-obvious place) and the function will delete all records instead when it's run.
In the current development model, this will be caught by:
- me testing it locally (then fixing it and reloading test db)
- maybe reviews
- potentially CI/CD
But with what I understand about Dark, this will be close to auto-published on save, and the first person to try the code will delete all entries from a live table/collection.
Backups are ok, but not a solution in this case (you can't just roll back money transactions for example), and the downtime is not great. What system in Dark prevents this from happening in the first place?
> this will be close to auto-published on save, and the first person to try the code will delete all entries from a live table/collection.
Ah, that's not how it works. I think you're thinking that you edit code in your editor and then there's this super dangerous deploy. That's not it at all.
When you make new code you open a feature flag. The feature flag doesn't run until you're ready to run it. We haven't dealt with the delicate case, but I'm imagining that we'll let you put a clone of the DB in so that you can test it.
And you can have code reviews and tests and so on while the feature flag is open. Think of it like a branch.
I guess this is to be expected. HN is totally not the target audience for this. A closed, proprietary coding system is bound to be scrutinized by a site that has “hacker” in its name.
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.
We (using general "we" here) spent so much time convincing developer that version control is good, reviewable changes are good, automated CI is good, and editing directly on the servers is bad. This was not because of some abstract ideas, but because of practical lessons about how to maintain long-lived applications.
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..."
Agreed. Most of the tone here is definitely way too cynical.
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.
I'm getting serious "Building Dropbox is trivial with with curlftpfs, SVN and CVS"[0] vibes from this thread.
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.
While I agree with a lot of what you said I'd like to point out that Dropbox's initial customer was the common person, a non-tech savvy person who didn't want to carry USB drive around. Dark's customer base are developers in this thread, likely to be early adopters. That's my sense at least.
Radical approach - they flip the whole thing upside down. The biggest challange is not new language or ide per-se imho - but detachment from git, this has implications ie. it seems open-source hostile (you can't use it for open-source code, or am I wrong?); what about libraries?
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.
> The scope they're claiming is gigantic, they must be taking compromises somewhere. There's no way is all unicorns and rainbows.
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?
I am doubtful. My view of the future of software engineering is that developers will be better equipped to handle _more_ complexity, not _less_. And we all know what happens when there's black boxes. Not to mention you're locked in to a particular editor and language.
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?
This would have appealed to me before building a rather large side project with Google Cloud's proprietary Firestore database. There are loads of drawbacks that slowly become apparent the more I build and the deeper I dig myself into that hole. I loved how quickly I was able to get something up and running, and was super excited about it at first. But as I've had to add more and more features and turn it into a real project, being limited to only the tools provided by the vendor has become a real drag. Migration, testing, debugging, is all so much more of a pain. Can't even run my application locally without an internet connection. On top of all of that, there may be pricing hikes, or the service could go away all together.
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.
In high school, I think I worked for a company that has prior art on deployless software. We wrote php and perl directly on the prod server with vi through putty. No deploy necessary!
Well, with compiled languages and multiple servers it does get a bit more complex.
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.
> Well, with compiled languages and multiple servers it does get a bit more complex.
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.
Dark founder here. Many people remember writing directly on the server quite fondly, because it had a great turnaround. But we stopped doing it because it wasn't safe. Dark makes it safe [1], so you can start doing it again.
This reminds me a lot of the Salesforce Apex platform where the language, runtime, datamodel, hosting and all infra is part of one package.
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.
I'm very excited about this idea and have even asked for an early access invite.
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.
I'm not convinced. The authors cite sources of complexity that are mostly domain-specific artifacts of web development, yet make pretty broad claims about a fundamental advancement in language design. Maybe the authors have some insight about these pain points, but it certainly doesn't seem necessary to create a whole new language to solve them, especially as frameworks such as gRPC have already (at least partially) solved one of these supposed fundamental issues without replacing the base programming language.
I am not convinced either. Getting a language off the ground is a 10 year affair, don't think its possible for a funded company to bring up a new language unless they are targeting some niche where full scale programmability is not a requirement.
It might just transpile into something else, doesn’t necessarily need to be completely from scratch. Their documentation is pretty opaque though as others have mentioned so who knows.
I’m admittedly biased (early Parse employee, but not there by shutdown). Which part was a “fiasco”? As far as turndowns go I thought it was pretty damned fair: one year notice, a live data migration pipeline to self-hosted mongo, and an open source server implementation with a free license. Facebook even paid employees to continue working on the OSS components for a while till the community became so abusive that they moved elsewhere. The only thing I think could have been smoother is if Parse appIds were indicated by subdomain rather than header, which would have allowed switching over without client code changes and minimal cost to Facebook.
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 fiasco was not on Parse's end but it was ours for locking ourselves into their platform.
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.
Thanks for the clarification. I’ve seen a shift to BaaSes that have a core of open source and self-hostable architecture that are wrapped in vendor-specific hosting that can improve performance, reliability, simplification/integration, and extra ancillary toys. See Kubernetes vs GKE.
I’ve used Dark for the backend of a mobile app (> 20k installs) during the beta, and it has been an incredible experience. Something like 30 lines of code do it all.
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.
This seems misguided to me. How do you get people into an ecosystem like this that is totally isolated.
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.
It sounds pretty cool until the point where you read something like: "Deployment is risky because you’ve only tested on your own machine, and now you need to run the same code on many different machines, to serve (millions of) users." Which makes it seem like they don't even know about the existence of Docker; making me doubt most of what they'll try to sell us.
Don't get me wrong, I understand where you're coming from and what your goals are; it'll be grand if Dark can deliver on its promises. I just don't understand why that particular statement on deployment had to be included, as it makes it sound like you're solving a problem with an existing solution.
Unfortunately when you do press, you're at the mercy of whatever gets quoted and sometimes things that are kinda irrelevant get picked up. That's definitely not the thing we wanted as the lead. Our blog post on it was different: https://medium.com/darklang/dark-announces-3-5m-in-seed-fina...
That's a fair point. Regardless of my current impression, I'll have to try it out first hand in order to form a proper opinion, so looking forward to the public release. Good luck!
For the last 10 years I've been working mostly on CI and CD automation for a few projects that as part of their offering tried to automate the deployment for their clients.
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...
Agreed. You have to develop such that your product survives whatever is fashionable today in any case. As Joel Spolsky pointed out at some point, your architecture is not the framework you picked.
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?
I've been coding since I was a kid, for about 33 years. I actually think they are right about all of this stuff.
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.
Did you had any experience with "low code" platforms? It is all easy until you hit that one case where it stops beeing easy. The same with image oriented languages. Maybe a lot of projects will profit from such solution, but for such projects that can be done "low code" you don't need developers. There has to be culture shift. If you need developers to operate your "low code", "low infrastructure", as business person you are doing something wrong.
While I also long for more powerful frameworks / libs that lighten the burden of infrastructure code and other boiler plate code having it all dominated by one company, specially a small startup is a grave problem for adoption.
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.
I think that is a consequence of "culture" being an important deciding factor in software engineering decisions. Culture causes a company to value "agile development" over "waterfall" or "strong-typing" over "weak-typing" without having solid definitions or objective arguments backing their reasons. I would like to see the day when culture is no longer a deciding factor in my work, but I don't think it's coming. People don't share foundational beliefs, and even if they did, the gap between reasoning from their foundational beliefs to their base programming beliefs is vast. Even if we all simultaneously underwent a shared spiritual experience that transformed all our foundational beliefs to a shared common set, we'd still need to reason our way upward to beliefs about programming, and that would be fraught with error. So even in a field as black and white (or red and black, if that's your preference) as programming, we will still have arguments, there will always be naysayers, we'll have conservatives who refuse to stop practicing COBOL, progressives wasting time on Frilly-BottomJavascriptContainerLib-2.0, and we'll all still be wasting time trying to get Intellij to build in our dev environment properly.
I think that's the future. Perhaps not exactly Dark itself since we know nothing about it but a toolset that integrates all moving parts from current computation and information engineering and sets them in a well coupled system. Reinvent the wheel at higher levels.
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.
I have a hunch that Dark won't generalise well. It might be good for making simple data-backed web applications. But a business of any nontrivial size has more than just simple data-backed web applications.
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?
Or do you use micro service architectures where some of your services (eg ML training) runs on dedicated/specialized hardware and traditional event/request based business logic can be written more quickly and only moved to Dark incrementally?
I mean I guess. Salesforce did it with Apex and Wolfram did it with Wolframlang or whatever Steve is calling it these days. But I feel like this is a solution in search of a problem. The issue isn’t complexity or even accidental complexity. It’s that businesses usually have many competing and often conflicting needs. I can already hear the angry snort when I go to the head DBA and ask if I can use some new hosted product to replace our on prem data warehouse. It’ll never happen. And it’s not even an “old school” thing. We just have a variety of reasons why it’s a bad solution. So now we talk about setting up small web apps hosted in Dark’s cloud. How is it any better than what we have hosted in Amazon, Google, and Azure where we also have the ability to at any minute tap in to a huge market of developers? I guess then we look at this for new projects that aren’t interfacing with production stuff? In that case I guess it’s an interesting experiment. But the reality is that most corporate things (from my experience anyway) have an if it ain’t broke don’t fix it mentality and with good (often painfully learned) reasons. I’m not debating the values of this (it’s hard to since their entire site is marketing buzzwords) but I’m saying it doesn’t seem on the face of it to be a realistic problem solver. I’m very likely wrong but that’s how it feels to me.
They really need a good bottom-up example showing what Dark is and why it is different from ssh-ing into a production server and fiddle with some php-scripts.
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.
I don't get it. I tried to find out anything about what Dark is, how it works, or what it looks like and found almost nothing. They make claims like "holistic programming language" but don't show me what they mean. The What is Dark[1] blog post makes a lot of claims, but I've seen these claims made many times and they rarely live up to the hype. They don't show me how they plan to meet these claims or what it looks like. Finally, their marketing focus is on deployment, but honestly, deployment really has never been the biggest pain point for me. Sure, it can be a headache, but its nowhere near as much work as actually writing the applications themselves. I'm not convinced.
Okay good. I was feeling so confused because I could have sworn I saw them posting like a year ago about paying a few early startups to dogfood the Dark platform as it was being developed.
Beause everything is integrated, compiled code roughly means deployed code, they need strong, sound type system and many constructs are not allowed because the way it runs. I don't think there is a way to use threads for example because concurrency is handled above you.
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.
I only tried it once, and the technology was pretty flaky at the time. I don't think it really went anywhere.
The focus was on the fact that you could have multiple people editing a single codebase at once, rather than on doing it in production. Indeed, you wouldn't have to do it in production, you could work on a shared development image. That was definitely a very interesting sensation, having a whole team working in a single space; like pairing but much more so. Lots of calling out to other programmers to ask them what they thought, or to suggest something. You could all work on parts of an idea at once, so you could try things out quickly. But there was so much overhead in making sure you didn't tread on each others' toes.
This doesn't seem to be the emphasis in Dark at all. In fact, i don't know what Dark's story about collaboration is. It seems to be much more about the instant deployment, and all sorts of sci-fi tooling to make that safe.
One question/unsolicited advice: the articles frequently mention “feature flags,” but these will cause simultaneous rollout in prod without any real testing or canary.
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.
It’s good your feature flags have the necessary...features. The same word is often used for global bools; I wish there was a better word (eg “experiment” or “experiment flags”) or documentation to brag that you’re doing more than simple flags.
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.
I said this last time I read about it and I'll say it again because all I keep reading are puff-pieces with nothing to back it up, it sounds like a convoluted version of Geocities, funded by a seed round from Russ Hanneman.
Cofounder/CTO here. Sorry this went up when I was sleeping, so I missed the discussion. I'll answer some things through the threads but if you have any questions for me I'm here.
Per another article, the editor doesn’t even allow syntax errors. Seems like they have a tight pipeline built around AST manipulation, which is actually novel. I’m not sure I understand why that took a new language though.
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?
in theory having an online code editor that makes deployments and handles the infrastructure for you sounds good and from this i can see the logical deduction that this platform would save costs and simplify processes. But they are most likely not technical and as such don’t understand that code is written the way it is due to the many variations between projects.
It's simple if you know people with deep pockets -- and there was this mantra of invest in the team for awhile; not sure if that's still really a thing.
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.
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.
> ... 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.