8 ms·

It feels like HN regular are unlikely to be the ideal audience for this. Reaching for a metaphor, it's like a bunch of expert Unix users gathering around an IBM

It feels like HN regular are unlikely to be the ideal audience for this. Reaching for a metaphor, it's like a bunch of expert Unix users gathering around an IBM PC or Macintosh in the 1980s. 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.

pbiggar 7y ago
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.
- inimino 7y ago
  You're never going to wrestle anyone who experienced more than one tech hype cycle into such a stark vendor lock-in situation.
  - mapcars 7y ago
    Most languages are vendor lock-in actually, with forks not passing an experimentation level. OpenJDK may be the only working example from the mainstream languages.
    - inimino 7y ago
      Are you forgetting C and C++? These are probably the least risky languages you can use. Open source implementations, open standards, multiple implementations. 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.
  - yawaramin 7y ago
    Yes, of course HNers are too wise to be taken by simple vendor lock-in! Facebook is closing Parse (parse.com) 1202 points by theunquietone on Jan 28, 2016 | hide | past | web | favorite | 500 comments https://news.ycombinator.com/item?id=10991729 https://news.ycombinator.com/item?id=10991729 ...oh. ;-)
    - Volt 7y ago
      Is your point that they'll fall for it again?
- eternalny1 7y ago
  > Our target audience is developers building backends. 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
  - cuddlecake 7y ago
    ... buuuuut you don't have to learn how to: 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.
    - eternalny1 7y ago
      > .. buuuuut you don't have to learn how to: 1) deploy your code 2) deploy your datastore 3) manage your datastore 4) shard your datastore 5) deploy your infrastructur3 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.
- mapcars 7y ago
  > We don't expect we'll wrestle people from their Emacs Well with what I saw on the videos if it's possible to extend Dark inside itself - yeah, I would prefer this over Emacs
steveklabnik 7y ago
As a concrete example of this: https://twitter.com/stevehind/status/1173643069347917824 https://twitter.com/stevehind/status/1173643069347917824 > 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.
- eternalny1 7y ago
  So this "non-engineer" learned a new programming language, understands Heroku and Flask, and created a REST API integration for Slack? Can anyone let me know what an engineer is again?
  - steveklabnik 7y ago
    Many people who are "self-taught coders" don't perceive themselves as "engineers", often because many other forms of engineering have certifications. They expect that "engineer" requires a certain level of knowledge that they do not have; it's an unknown unknown kind of thing. 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.
    - eternalny1 7y ago
      A lot of people can do some magic stuff when it comes to spreadsheets (and as a self-taught software engineer, I am not one of them), but does that same logic really apply to API endpoints? 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"?
    - TazeTSchnitzel 7y ago
      I personally find “engineer”'s use in a software context as pretty pretentious, so I understand how they might feel like they're really something different. What they don't know is they're as much a programmer as any other.
mattnewport 7y ago
A better metaphor would be PC and Mac users gathering round a 90s 'thin client' and expressing the same concern. If you've never heard of the 90s thin clients there's a reason...
- braythwayt 7y ago
  I have heard of thin clients, they competed with desktop apps, which were the incumbent technology. 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.
  - mattnewport 7y ago
    From my perspective all the negatives of the web app approach have largely come to pass and I'm moving away from hosted cloud apps. Once bitten twice shy I guess. I'm not sure it's time to declare a winner.
    - yawaramin 7y ago
      Yes, your personal perspective invalidates thousands and thousands of webapps out there that are reaching massive numbers of people that they otherwise never would have ;-)
muglug 7y ago
My first code was written in Flash 4 (I think?), so I understand the value of a easy-to-use walled garden, and I understand how companies can make money from those walled gardens. > 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.
yellowapple 7y ago
> A really great new idea 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).
ubu7737 7y ago
> A really great new idea should empower millions of people completely unlike us to build software. Do you mean, like, some sort of "silver bullet"?
- onemoresoop 7y ago
  Maybe like a "rubber bullet", it can inflict some damage but shooting oneself in the foot bears very little risk.

pbiggar 7y ago

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.

inimino 7y ago
You're never going to wrestle anyone who experienced more than one tech hype cycle into such a stark vendor lock-in situation.
- mapcars 7y ago
  Most languages are vendor lock-in actually, with forks not passing an experimentation level. OpenJDK may be the only working example from the mainstream languages.
  - inimino 7y ago
    Are you forgetting C and C++? These are probably the least risky languages you can use. Open source implementations, open standards, multiple implementations. 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.
- yawaramin 7y ago
  Yes, of course HNers are too wise to be taken by simple vendor lock-in! Facebook is closing Parse (parse.com) 1202 points by theunquietone on Jan 28, 2016 | hide | past | web | favorite | 500 comments https://news.ycombinator.com/item?id=10991729 https://news.ycombinator.com/item?id=10991729 ...oh. ;-)
  - Volt 7y ago
    Is your point that they'll fall for it again?
eternalny1 7y ago
> Our target audience is developers building backends. 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
- cuddlecake 7y ago
  ... buuuuut you don't have to learn how to: 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.
  - eternalny1 7y ago
    > .. buuuuut you don't have to learn how to: 1) deploy your code 2) deploy your datastore 3) manage your datastore 4) shard your datastore 5) deploy your infrastructur3 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.
mapcars 7y ago
> We don't expect we'll wrestle people from their Emacs Well with what I saw on the videos if it's possible to extend Dark inside itself - yeah, I would prefer this over Emacs

steveklabnik 7y ago

As a concrete example of this: https://twitter.com/stevehind/status/1173643069347917824 https://twitter.com/stevehind/status/1173643069347917824 > 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.

eternalny1 7y ago
So this "non-engineer" learned a new programming language, understands Heroku and Flask, and created a REST API integration for Slack? Can anyone let me know what an engineer is again?
- steveklabnik 7y ago
  Many people who are "self-taught coders" don't perceive themselves as "engineers", often because many other forms of engineering have certifications. They expect that "engineer" requires a certain level of knowledge that they do not have; it's an unknown unknown kind of thing. 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.
  - eternalny1 7y ago
    A lot of people can do some magic stuff when it comes to spreadsheets (and as a self-taught software engineer, I am not one of them), but does that same logic really apply to API endpoints? 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"?
  - TazeTSchnitzel 7y ago
    I personally find “engineer”'s use in a software context as pretty pretentious, so I understand how they might feel like they're really something different. What they don't know is they're as much a programmer as any other.

mattnewport 7y ago

A better metaphor would be PC and Mac users gathering round a 90s 'thin client' and expressing the same concern. If you've never heard of the 90s thin clients there's a reason...

braythwayt 7y ago
I have heard of thin clients, they competed with desktop apps, which were the incumbent technology. 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.
- mattnewport 7y ago
  From my perspective all the negatives of the web app approach have largely come to pass and I'm moving away from hosted cloud apps. Once bitten twice shy I guess. I'm not sure it's time to declare a winner.
  - yawaramin 7y ago
    Yes, your personal perspective invalidates thousands and thousands of webapps out there that are reaching massive numbers of people that they otherwise never would have ;-)

muglug 7y ago

My first code was written in Flash 4 (I think?), so I understand the value of a easy-to-use walled garden, and I understand how companies can make money from those walled gardens. > 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.

yellowapple 7y ago

> A really great new idea 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).

ubu7737 7y ago

> A really great new idea should empower millions of people completely unlike us to build software. Do you mean, like, some sort of "silver bullet"?

onemoresoop 7y ago
Maybe like a "rubber bullet", it can inflict some damage but shooting oneself in the foot bears very little risk.