> 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.<p>> ... 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.<p>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.<p>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.
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...<p>> I think the biggest downside of Dark is definitely that you’re learning a new language...<p>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.<p>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.<p>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.
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.
The tone here is _extremely_ cynical.<p>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.<p>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."<p><a href="https://twitter.com/sama/status/571733273996488704" rel="nofollow">https://twitter.com/sama/status/571733273996488704</a>
I'm getting serious "Building Dropbox is trivial with with curlftpfs, SVN and CVS"[0] vibes from this thread.<p>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...<p>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.<p>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.<p>Having a garden with walls this high might actually bring a lot of surprises.<p>0: <a href="https://news.ycombinator.com/item?id=8863" rel="nofollow">https://news.ycombinator.com/item?id=8863</a>
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?<p>Technically very interesting.<p>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?<p>The scope they're claiming is gigantic, they must be taking compromises somewhere. There's no way is all unicorns and rainbows.<p>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.<p>Wolfram does something similar. Salesforce as well. Dark seems similar but for webdev, it's like serverless/lambda v10.
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.<p>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?<p>> Infrastructure is time consuming and difficult, especially as services start to scale.<p>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.<p>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!<p>What's old is new again I guess.
This reminds me a lot of the Salesforce Apex platform where the language, runtime, datamodel, hosting and all infra is part of one package.<p>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.<p>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.<p>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.<p>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.
The page for the language is here - <a href="https://darklang.com/" rel="nofollow">https://darklang.com/</a> but sadly no technical details appear to be publicly available at this time.
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.<p>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.<p>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?<p>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.
Should probably replace with the first-party article: <a href="https://medium.com/darklang/dark-announces-3-5m-in-seed-financing-d64af8a58c1d" rel="nofollow">https://medium.com/darklang/dark-announces-3-5m-in-seed-fina...</a>
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.
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.<p>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.<p>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...
I've been coding since I was a kid, for about 33 years. I actually think they are right about all of this stuff.<p>Including the part about combining everything together into a holistic solution.<p>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.<p>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.<p>But maybe even though its a structured editor that makes things easier, it will still look like code and "count" psychologically as programming.<p>Anyway maybe it will actually become popular. Who knows. Good luck.
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.
Previous discussions with answers from the founder: <a href="https://news.ycombinator.com/item?id=19274083" rel="nofollow">https://news.ycombinator.com/item?id=19274083</a>
<a href="https://news.ycombinator.com/item?id=20394166" rel="nofollow">https://news.ycombinator.com/item?id=20394166</a><p>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.<p>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?<p>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?<p>Or do you bet that Dark will pull more rabbits out of their hat, and you won't need to migrate?
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.<p>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.<p>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.<p>[1] <a href="https://medium.com/darklang/the-design-of-dark-59f5d38e52d2" rel="nofollow">https://medium.com/darklang/the-design-of-dark-59f5d38e52d2</a>
This is hardly "emerging from stealth". This was a blog post from February! <a href="https://medium.com/darklang/the-design-of-dark-59f5d38e52d2" rel="nofollow">https://medium.com/darklang/the-design-of-dark-59f5d38e52d2</a>
Looks like one thing the infrastructure doesn't automate is using the right SSL certificate:<p><a href="https://hellobirb.com/" rel="nofollow">https://hellobirb.com/</a><p>(that company is an early adopter mentioned in <a href="https://medium.com/darklang/dark-announces-3-5m-in-seed-financing-d64af8a58c1d" rel="nofollow">https://medium.com/darklang/dark-announces-3-5m-in-seed-fina...</a> )
One question/unsolicited advice: the articles frequently mention “feature flags,” but these will cause simultaneous rollout in prod without any real testing or canary.<p>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 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.