[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

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

[tnolet]

I guess this is to be expected. HN is totally not the target audience for this. A closed, proprietary coding system is bound to be scrutinized by a site that has “hacker” in its name.

No idea what that tweet is meant to say though. People who are critical about startups are never successful? Really? You can easily argue for the opposite.

[maximilianroos]

The tweet is supposed to say:

If 95% of things fail, you'll be correct 95% of the time by calling each thing a failure.

But you'll never be in the 5% yourself. (sure, an exaggeration to say you'll never be successful, but such is 140 characters)

(Agree with your points re audience. I'd hope people can differentiate between things they don't use and things that are useless)

[theamk]

We (using general "we" here) spent so much time convincing developer that version control is good, reviewable changes are good, automated CI is good, and editing directly on the servers is bad. This was not because of some abstract ideas, but because of practical lessons about how to maintain long-lived applications.

And now there is a startup which says "let's edit directly on the servers, automated CI is not needed -- the code will always be correct, and we will add version control in the future.. maybe..."

How do you think people will react to this?

[shay_ker]

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.

[Nullabillity]

Philip Morris is successful, that doesn't mean that their product is a positive on the world.