How do they make money?
You have to host with them to use it.
Dark emerges with ‘deployless’ software model
111–120 of 174 posts
Re: Dark emerges with ‘deployless’ software model
#112Personally I’d be surprised if this startup is around in five years
you can say that about every startup.
Re: Dark emerges with ‘deployless’ software model
#113Radical 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…
detachment from git? really? 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?
> why is a SCM all that important?
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.
Re: Dark emerges with ‘deployless’ software model
#114Re: Dark emerges with ‘deployless’ software model
#115The 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…
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.
Re: Dark emerges with ‘deployless’ software model
#116Earlier quoted context omitted.
I'm working on DETA – it abstracts away Lambda/S3/CF/CW/TF. Would you be interested in a quick chat?
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... Sorry for the rant.
Sorry that you didn't like our name. It's not actually an acronym. It's inspired by Commander "Data" from Star Trek TNG.
Re: Dark emerges with ‘deployless’ software model
#117Earlier quoted context omitted.
I'm working on DETA – it abstracts away Lambda/S3/CF/CW/TF. Would you be interested in a quick chat?
What is a DETA?
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.
Happy to elaborate more if you're interested.
Re: Dark emerges with ‘deployless’ software model
#118Earlier quoted context omitted.
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…
I'm working on DETA – it abstracts away Lambda/S3/CF/CW/TF. Would you be interested in a quick chat?
> .. it abstracts away ...
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.
Re: Dark emerges with ‘deployless’ software model
#119Earlier 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?
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.
The Serverless framework provides offline functionality (https://github.com/dherault/serverless-offline) to do this - I've found it works pretty well.
Re: Dark emerges with ‘deployless’ software model
#120I'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.