We do intend the HN audience to love this too. Our target audience is developers building backends. We don't expect we'll wrestle people from their Emacs, so we're definitely not targeting all possible developers today, but definitely developers.
A language with only a single, open-source implementation controlled by a single vendor, like Go or Erlang, has slightly more risk, in that the single vendor could choose to take the language in a direction you don't like. However, even if that were to happen, it's open source, and the community can maintain it as long as there are enough users.
A language primarily controlled by a single entity that is actively hostile towards openness, like Java, is a little more risky yet, but even so, with enough users it becomes safe enough.
A language that's not open at all, like Mathematica or F#, puts you entirely at the mercy of the company that controls it... but if that company is big and has a good track record, it's still at least a reasonable trade-off.
Now, if something is created by a startup that has at best even odds of being around in five years... you still might take that risk if the technology was open, and you could run it yourself when they close up shop, like, say, Meteor or MongoDB. These are decisions that one is rather more likely to regret, but it's not hard to see how people make them.
However, if a new company introduces a new language that is also it's own walled-garden deployment environment, which you can't run on your own systems, which has no demonstrated history of doing anything well, and which is not open source, anyone choosing that language for a project that's expected to be around for a while would have to be either inexperienced or just plain crazy.
Facebook is closing Parse (parse.com)
1202 points by theunquietone on Jan 28, 2016 | hide | past | web | favorite | 500 comments
...oh.
;-)
Why wouldn't developers building back-ends just continue building back-ends in their preferred language and environments?
I type this as I'm tabbed out of Visual Studio creating API back-end in C# .Net Core right now. It's easy.
With this I'd have to 1) Learn a new language 2) Learn a new GUI interface for that language 3) Lock myself in
1) deploy your code 2) deploy your datastore 3) manage your datastore 4) shard your datastore 5) deploy your infrastructur3
Among many other things. The value of Dark Lang lies not just in the programming language and the IDE, but in the holistic experience for backend development it provides, since _all_ of the overhead required to actually move to production and make new releases completely vanishes.
Reducing the entire idea of darklang to "vendor lock in, lol naw" is missing the point, but also kind of nailing it.
By reducing options, you gain the freedom to focus on the problem you set out to solve in the first place.
Of course, it's not a silver bullet right now, but it's an interesting bullet nonetheless.
Or you can just get a cheap host and throw a table into a SQLite database (a file) and use JavaScript.
I'm probably not the target audience.
Well with what I saw on the videos if it's possible to extend Dark inside itself - yeah, I would prefer this over Emacs