It feels like forcing users to learn a new language is a step too far here - I can't imagine a ton of people are so eager to build slackbots that they're willing to give up all their existing tools.
It's so easy to bemoan the control we lose (a major problem given our existing workflows) and have no use for the functionality it confers (simplicity, batteries included, lack of yaks that need shaving).
A really great new idea should empower millions of people completely unlike us to build software.
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
> I’ve been lucky enough to be an alpha user of Dark. As a non-engineer, self-taught coder, I was able to build and deploy the back end of a react app, including a Stripe integration, faster on Dark than anything else, including Heroku + Flask. Real game changer.
Can anyone let me know what an engineer is again?
I know someone who, through using a lot of Goole Sheets, managed to re-invent SQL joins. She'd never identify as an engineer, but she did manage to get some software to accomplish her task.
Look at how many acronyms are in the intro video alone ... the narrator says "we'll just use REPL ...". Does someone playing around in Google Sheets say "yes, REPL, great choice!" or do their eyes glaze over?
What about when you tell them they have to learn "Darklang"?
But thin clients did win, we just call them web apps now, which we run in thin client emulators we call “browsers.” And I recall incumbents scoffing at web technology back then, too.
> A really great new idea should empower millions of people completely unlike us to build software.
I agree, but I don't think this is it — it doesn't feel like the SquareSpace of backends. It requires a bunch of pre-existing knowledge (requests, databases etc.), and its language doesn't have the simplicity of most starter languages.
This ain't exactly new, though. The value proposition here is very similar to that of a lot of existing cloud-hostable middleware products, e.g. Dell Boomi, albeit perhaps targeted at a different audience (that is: adapted to actually building backend systems instead of tying a bunch of existing systems together).
Boomi, however, is a flaming pile of trash (and I say this as someone whose dayjob is - among numerous other things - to maintain a bunch of Boomi processes); the version control sucks (and you have to use its version control, because what's Git or Mercurial or Fossil or even CVS, amirite?), it's way overpriced, it's a pain in the ass to do simple things with it (unless there's already a shape defined for the exact thing you're trying to do, or it happens to be something conducive to JS or Groovy scripting; the JS/Groovy escape hatch is the one good thing about Boomi), and you're permanently locked into it unless you want to completely rewrite everything in a different language and for a different platform.
If Dark can address those four problems - namely, by supporting external version control systems (Git at the minimum), having a sane price point (and not gouge users on connector licenses), making it easy to do easy things and reasonable to do hard things, and providing some pathway to escape vendor lock-in (e.g. import/export from/to a self-hosted option, preferably an open-source one) - then I could see myself at least trying it out. As it stands, though, there's no indication that Dark doesn't have the same exact crippling problems Boomi has (made worse by forcing a specific new language instead of relying on existing ones).
Do you mean, like, some sort of "silver bullet"?