Earlier quoted context omitted.
Agreed. It only sounds maybe 1 step removed from where aws lambda’s are now. You fiddle with the code in the lambda IDE, and submit for deployment. Is this really that much different?
I 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…
Dark emerges with ‘deployless’ software model
141–150 of 174 posts
Re: Dark emerges with ‘deployless’ software model
#142I'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 th…
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?
Re: Dark emerges with ‘deployless’ software model
#143The tone here is _extremely_ cynical. 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." https://twitter.com/sama/status/571733273996488…
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…
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.
Re: Dark emerges with ‘deployless’ software model
#144I'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.
Re: Dark emerges with ‘deployless’ software model
#145Earlier quoted context omitted.
> 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…
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.
Re: Dark emerges with ‘deployless’ software model
#146Radical 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 loc…
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).
Re: Dark emerges with ‘deployless’ software model
#147In 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! What's old is new again I guess.
[1] https://medium.com/darklang/how-dark-deploys-code-in-50ms-77...
Re: Dark emerges with ‘deployless’ software model
#148It 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.
Re: Dark emerges with ‘deployless’ software model
#149The page for the language is here - https://darklang.com/ but sadly no technical details appear to be publicly available at this time.
Re: Dark emerges with ‘deployless’ software model
#150Looks like one thing the infrastructure doesn't automate is using the right SSL certificate: https://hellobirb.com/ (that company is an early adopter mentioned in https://medium.com/darklang/dark-announces-3-5m-in-seed-fina... )