Live data from Hacker News

Dark emerges with ‘deployless’ software model

techcrunch.com

141–150 of 174 posts

Re: Dark emerges with ‘deployless’ software model

#141

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…

Yes, this is pretty close! There are multiple instances in the cloud - when a HTTP request comes in we look up your program from the DB and run it.

Re: Dark emerges with ‘deployless’ software model

#142

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 th…

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?

Re: Dark emerges with ‘deployless’ software model

#143

The 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…

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.

Re: Dark emerges with ‘deployless’ software model

#144
post #42

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.

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.

Re: Dark emerges with ‘deployless’ software model

#145
post #39
post #27

Earlier 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.

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.

Re: Dark emerges with ‘deployless’ software model

#146

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 loc…

> 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).

Re: Dark emerges with ‘deployless’ software model

#147
post #6

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! What's old is new again I guess.

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.

[1] https://medium.com/darklang/how-dark-deploys-code-in-50ms-77...

Re: Dark emerges with ‘deployless’ software model

#148
post #17

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.

Founder of Dark here. Here's a thing I wrote about docker before, that led me to create Dark. https://circleci.com/blog/its-the-future/

Re: Dark emerges with ‘deployless’ software model

#149
post #2

The page for the language is here - https://darklang.com/ but sadly no technical details appear to be publicly available at this time.

We've got some stuff on our blog. See here and the links at the bottom: https://medium.com/darklang/the-design-of-dark-59f5d38e52d2

Re: Dark emerges with ‘deployless’ software model

#150
post #65

Looks 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... )

We're manually doing SSL at the moment, and our customer controlled the DNS. Should be fixed now.
Post reply on HN