
Dark emerges with ‘deployless’ software model - yagurastation
https://techcrunch.com/2019/07/29/dark-emerges-from-stealth-with-unique-deployless-software-model/
======
mroche
> 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.

~~~
d2mw
> 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

~~~
mroche
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.

~~~
rohanagarwal94
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.

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

~~~
pbiggar
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?

~~~
HereBeBeasties
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".

I wish you luck.

~~~
pbiggar
Thanks!

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.

~~~
HereBeBeasties
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!

~~~
pbiggar
> 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.

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

~~~
jmngomes
> 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.

~~~
tmikaeld
"Starting at US$6,250/month (Billed Annually)"

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.

------
maximilianroos
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/571733273996488704](https://twitter.com/sama/status/571733273996488704)

~~~
viraptor
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.

~~~
pbiggar
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.

~~~
viraptor
Thank you for answering the questions!

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?

~~~
pbiggar
> 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.

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

0:
[https://news.ycombinator.com/item?id=8863](https://news.ycombinator.com/item?id=8863)

~~~
abalaji
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.

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

~~~
verinus
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?

~~~
perlgeek
> 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.

------
ralphstodomingo
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?

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

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

~~~
kreetx
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.

~~~
flukus
> 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](https://github.com/RhysU/c99sh)), I bet you
could go a long way with that on a network drive or with an rsync daemon.

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

~~~
arethuza
Isn't the platform part of Salesforce also pitched as a general purpose
application development platform? (force.com or something).

Microsoft used to pitch their CRM in the same way as an "XRM".

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

~~~
mikkom
> 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.

Is there some information about the language somewhere? I don't seem to find
any information from the site.

~~~
jasim
[https://medium.com/darklang/real-problems-with-functional-
la...](https://medium.com/darklang/real-problems-with-functional-languages-
efe668c5264a)

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

~~~
ericpauley
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.

~~~
dman
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.

------
vbsteven
After the Parse.com fiasco I am not touching a high-vendor lock-in BaaS ever
again.

~~~
inlined
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.

~~~
vbsteven
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.

~~~
ruperp
However, there's always a new generation of developers who will inevitably
make the same mistake that you (and I) did.

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

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

------
trevyn
Should probably replace with the first-party article:
[https://medium.com/darklang/dark-announces-3-5m-in-seed-
fina...](https://medium.com/darklang/dark-announces-3-5m-in-seed-
financing-d64af8a58c1d)

~~~
kybernetikos
That site also has the benefit that I don't have to sign my personal info over
to oath and their thousands of partners to read it.

~~~
jmngomes
I use outline.com to avoid that:
[https://outline.com/q7MMgC](https://outline.com/q7MMgC)

------
tnolet
The marketing reminds me of the famo.us launch.

“Everything completely different and proprietary and we don’t have any actual
real life examples”

~~~
tiborsaas
For some reason I get the same vibe. Let's hope they learned from the famo.us
case (badumtsss).

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

~~~
pbiggar
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/](https://circleci.com/blog/its-the-future/)

~~~
StyloW
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.

~~~
pbiggar
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...](https://medium.com/darklang/dark-announces-3-5m-in-seed-
financing-d64af8a58c1d)

~~~
StyloW
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!

~~~
pbiggar
Thanks!

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

~~~
jillesvangurp
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?

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

~~~
ozim
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.

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

------
tigershark
Previous discussions with answers from the founder:
[https://news.ycombinator.com/item?id=19274083](https://news.ycombinator.com/item?id=19274083)
[https://news.ycombinator.com/item?id=20394166](https://news.ycombinator.com/item?id=20394166)

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.

------
twic
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?

~~~
inlined
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?

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

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

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

[1] [https://medium.com/darklang/the-design-of-
dark-59f5d38e52d2](https://medium.com/darklang/the-design-of-
dark-59f5d38e52d2)

------
maximilianroos
This is hardly "emerging from stealth". This was a blog post from February!
[https://medium.com/darklang/the-design-of-
dark-59f5d38e52d2](https://medium.com/darklang/the-design-of-
dark-59f5d38e52d2)

~~~
ummonk
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.

------
al2o3cr
"Emerges" my foot, this is a marketing rollout. Code or GTFO

------
twic
Looks like one thing the infrastructure doesn't automate is using the right
SSL certificate:

[https://hellobirb.com/](https://hellobirb.com/)

(that company is an early adopter mentioned in
[https://medium.com/darklang/dark-announces-3-5m-in-seed-
fina...](https://medium.com/darklang/dark-announces-3-5m-in-seed-
financing-d64af8a58c1d) )

~~~
omnimus
SSL certificate automation is the hardest part of any stack.

~~~
jmngomes
Depending on how you approach it, it can be completely automated:
[https://github.com/Neilpang/acme.sh](https://github.com/Neilpang/acme.sh)

------
adrianN
I now almost nothing about Dark, but I don't understand why it is necessary to
do this with a new language and a new editor.

~~~
twic
I remember doing this in Smalltalk in about 2010. Multiple editing one image,
which was running live!

~~~
nudpiedo
besides second player gaming emotions, how did it turn out? was it value there
aside of pair programming?

~~~
twic
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.

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

~~~
pbiggar
I think that what you're calling an experiment framework is what we call
feature flags.

~~~
inlined
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.

------
etxm
I’ve only seen self pleasure articles about this company.

Has anyone seen what the language or editor looks like?

------
pkulak
Is there a code sample I can read? Seems like this will all hinge on this new
language.

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

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

------
rowanG077
similar things have been possible for years with C# in visual studio where you
can deploy to azure with the click of a single button if you want to.

------
freeone3000
How do they make money?

~~~
pbiggar
Dark provides the infra, so you pay us for how much compute, storage and
traffic you have (pricing is planned to be cheap, think close to AWS prices)

------
siffland
So is it a 'deployless' software model, in a 'serverless' environment¿

sorry i could not resist.

------
choiway
So it's a lame version of dot net / Azure?

~~~
inlined
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?

------
shinryuu
Personally I’d be surprised if this startup is around in five years

~~~
twic
Right. It sounds like a fun thing to build. But i'd love to read an honest
explanation from an investor of why they funded it.

Dark raised 3.5 million USD from eight funds, which is under half a million
each; maybe that amount is so small that a VC will invest it just for fun?

~~~
mattbillenstein
The founders are well-enough connected to get this sorta funding...

~~~
twic
Right, and Paul Biggar founded CircleCI before this, which has been pretty
successful!

