Hacker News new | ask | show | jobs
by mirekrusin 2518 days ago
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.

2 comments

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

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.