I like the premise, but at $3000/month it'd be hard to live in SF (which is a requirement). More importantly though, it appears the goal is to lock-in startups, then as they scale you make more money.
For Dark, this makes total sense and is a good business model, for a new startup - it seems like an unnecessary risk.
Our goal is to get in-person feedback from the first user of our product, so it does have to be in SF. In the future, we'll obviously open Dark up to everyone, but sadly not with the cash incentive :)
Presumably the 3k/month would supplement your already existing funding or make it easier to achieve ramen profitability. You wouldn't want to rely on the 3k alone.
OP here. Exactly, we're helping out, not funding you :) We're hoping there are some folks already in SF where we can help stretch their runway a little bit.
It doesn't sound like they have limitations on where you live. They only ask that you come to their SOMA office every day. You can live in a more affordable place like Oakland and take BART or Redwood City and take Caltrain.
We don't really have policies on this as it's a new idea, but there's no reason we'd have restrictions around this I guess. It's your startup, work whenever you need to!
Can we get some more info on what exactly "Dark Lang" is? A Google search yields absolutely nothing.
Definitely sounds interesting though. I have a lot of ideas, and would jump at the chance to cut my salary in half in exchange for total freedom to pursue them.
We’re creating a new programming language, tightly integrated with an editor, compiler and PaaS, to allow engineers to build distributed applications using high-level primitives. We abstract away individual machines and low-level distributed systems code to:
* Generate and run scalable infrastructure for you.
* Use APIs as easily as if they were functions.
* Remove the deployment step entirely.
* forever bind you to our services and charge you any amount of money because you have no choice but to pay. If you fail we will just take your business.
Eh, even if what they are promising is only economically viable as a proof of concept, it's probabally still better than the "overengineer a system that nobody ever actually uses" situation that's pretty much the norm now.
No I think locking yourself into financial servitude to some entity is just about the dumbest thing you can do. If you fail you wasted time getting experience not applicable elsewhere, if you succeed they will bleed you dry.
If you succeed, you have some blood in you, and can work on V2 architecture on some other cloud or in your own cage at a DC. This seems like a good bargain for a business that is validating whether they can make money at all, especially a VC-backed startup that is fine with burning cash to prove a concept. Seems like something in-between totally-infinitely-scalable-and-portable-bulletproof-infra and "fake it with spreadsheets and manual work".
I looked around the website and couldn't find any mention of what Dark even is. I keep hearing that "Dark is a new tool to help you build a complete scalable app in an afternoon", but how does it actually do this? Why would I want to base my startup on this platform?
For this reason, I wouldn't recommend that anyone try this. I expect that the Darklang employees will present a really early/difficult platform to the startup and require that the developer expand the platform as they go, which will be more friction that actually developing the startup's software.
Most applicants will realize this halfway through the interview, and the one that takes this offer will be the one who is most surprised by this fact.
Unfortunately "we'll fix it for you" isn't nearly enough unless you have 100 dedicated employees waiting at their keyboards for requests for the one "test" user you're hiring. Even environments like Erlang with years of support from hundreds of companies and individual programmers, you will run into blocking problems like "we need a binding to this database" or "my editor needs plugin support" or "we need a debugger and way to inspect memory".
A language environment emerges using baby steps.
- spark interest from hobbyists wanting to try new ideas
- provide enough inertia to the platform for the hobbyists to want to join as users or contributers
- accept the role as a contribution manager (accepting source code if open-source, or finances if proprietary), while still developing core stability by yourself (the language designer)
- then encourage small companies to try it to solve problems that are made easy by a niche of your environment
That is how it has gone for many languages, but it isn't the only way. Examples of languages that have gone differently include Java, Javascript, Erlang and Visual Basic.
More generally, if we look at devtools adoption as a whole (and I suspect Dark's adoption will more closely resemble a B2B devtool than a programming language), I don't believe those steps you outline are sequential at all. As an example, PHP was adopted by small companies extremely quickly, as were Parse and Firebase.
So I understand your point, and I'm not going to claim that you're wrong, but there are definitely other adoption models that potentially apply here.
There is a little more information on the root but it is still fairly opaque. Based on reading their value proposition, I don't think their vision matches the reality of where application development is going. (although I've been known to be wrong)
Presumably because they want to learn how well their platform is working directly from you every day by being there in-person - like a three month in-person usability test.
(It's not intentional voting manipulation, but I do wish Hacker News would clarify their policy on linking to submissions as a discussion forum, which can cause this unintentional voting manipulation)
Cute but how the hell is someone expected to survive in SF for $3000 a month?!? This sounds like a way to get interns cheaper than standard intern wages in SF ($48k).
Excuse me for being "dumb". I definitely don't understand the some businesses operation modes but... shouldn't this be the other way around? That is, I won't pay you directly $10k but I will pay your employer 20 times that money so they can pay you a good salary and still come with a profit?
> Your product is not backend-heavy, such as: ...machine-learning models
Maybe the meanings of these words have morphed over time, but in what sense is a "machine-learning model" not a back-end concern? It sure as heck isn't front-end...
(E.g., the current wiki page for "front and back end" explicitly mentions "converting the symbolic phonetic representation into actual sounds" as an example of a back end concern, and that's certainly the type of task that some people use machine learning for.)
Honest question: does "back-end" now mean "the CRUD and API client portions of a web-based CRUD app?"
This might go toward a larger question that others are asking: what exactly is darklang and what does it do?
> Maybe the meanings of these words have morphed over time, but in what sense is a "machine-learning model" not a back-end concern? It sure as heck isn't front-end...
Huh? They're giving it as an example of something that is backend-heavy that they don't want your product to be like. You've got it backwards.
> (Your product is (not (backend-heavy, such as: ...machine-learning models)))
> They're giving it as an example of something that is backend-heavy that they don't want your product to be like.
I think it's you who have got it backwards.
Here's the entire thing:
"This probably isn’t a good fit if:
Your product is not backend-heavy, such as: an iPhone game, hardware, machine-learning models, blockchain, or embedded systems."
I read that as "if you're a hardware startup, you're not backend-heavy, so you are not a good fit", "if you're an iPhone game startup, you're not backend-heavy, so you are not a good fit", and yes, also "if you're a machine learning startup, you are not backend-heavy, so you are not a good fit".
> They're giving it as an example of something that is backend-heavy that they don't want your product to be like. You've got it backwards
Yes, it's clear enough that they don't want you to be a member of that list. But what characterizes the elements of that list?! In any grammatical or intuitive reading of
"This probably isn't a good fit if your product is not backend-heavy, such as: ..."
the "..." is a list of things that are "not backend-heavy". And the first element is "iPhone game", which is certainly an example of something that is "not backend-heavy"!
> (Your product is (not (backend-heavy, such as: ...machine-learning models)))
Oh no! That's horribly confusing and not how lists are used in English! If that's what they meant, the post needs rewording. The correct way to say something like that is e.g., "Your product is back-end heavy but is not [insert delineating characteristics], such as: [insert original list here]".
To return the substance instead of grammar, IMO the "[insert delineating characteristics]" portion of that sentence is exactly what's missing from this advert!
> And the first element is "iPhone game", which is certainly an example of something that is "not backend-heavy"!
I thought they were referring to a multiplayer game with a server that has to be very low latency, handle a lot of connections, and not easily distributable, so that did seem backend-heavy.
But whatever they mean then, it's obviously not clear enough.
Fair comment, thought something similar when I first read this, but ML falls into its own category IMO because it's not part of the "application" most of the time. It's back-end in that it's not front-end, but it's not what you'd normally consider the back-end of an app.
A model is built offline, experimented upon, tested, and then once ready "connected" to the main app. Like, the TensorFlow code you write doesn't "need" to be on the server; it could be running on your laptop for all you care. It's the output model that eventually makes it into the back-end ¯\_(ツ)_/¯.
> Honest question: does "back-end" now mean "the CRUD and API client portions of a web-based CRUD app?"
Back-end has always meant the CRUD/API portions of a CRUD app.
> It's the output model that eventually makes it into the back-end ¯\_(ツ)_/¯.
Yes, the model itself is part of the backend, not the code used to generate the model. But the website explicitly mentions "machine-learning __models__" as an example of something that's "not backend".
> Back-end has always meant the CRUD/API portions of a CRUD app.
This is not true. Compilers have backends. Speech processing pipelines have backends. The dragon book, which pre-dates the advent of the WWW, distinguished frontend from backend (and in those words).
People have back-ends. Of course I know "back-end" is very broad, I just thought we were in the same page here, talking about a web back-ends, that is all.
Under that broad definition of the term, sure, go ahead and rant.
I get the feeling a lot of people in the comments here didn't actually read the article.
If you're complaining that $3k isn't enough to live in SF, you missed the point. Dark isn't trying to pay you a $3k salary. They're not looking to hire someone to build a random app. They're looking for an employee of some other startup to camp out in their office for 3 months and use Dark to build the backend for that startup, and they will pay $3k/mo to do this. Presumably that money goes to the startup, not to the employee directly. The employee will get whatever compensation from their own startup they would have gotten without working out of the Dark offices.
I feel that you are extrapolating on one data point.
The quote I think you're using to say "this is for startups":
> We pay you (or your company) $3000 a month.
In contrast to the multitude of other more personal references:
> We'll pay you $3000/mo
> Dark is a new tool to help you build a complete scalable app in an afternoon.
How many startups are working on "building an app in an afternoon"?
> You come to the office
> You build the backend
I don't think it's particularly fair to say "a lot of people didn't read the article" and that it is somehow obvious that this is aimed directly at startups, not individuals or otherwise.
Of course, no, it's not a livable wage. It's to me, more a "beta tester stipend" with a few bonuses. Can it realistically work for someone as a sole "job"? No, not without external support or a nest egg.
But I don't think that shows conclusively that they're looking to pay startups to work from their offices.
I mean, you certainly could be a sole operator working for yourself and be interested in this, but the point remains that the $3k isn't meant to replace whatever compensation you would have received if you didn't take this offer.
I guess the important point here is you're not supposed to quit your day job with the expectation that Dark will pay you a livable wage to build your pet project.
> I guess the important point here is you're not supposed to quit your day job with the expectation that Dark will pay you a livable wage to build your pet project.
I absolutely agree, I think phrasing it as a stipend/some other offer than what sounds like a salary would help a huge deal.
I think the offer would be cooler if they were just open to maybe daily meetings via slack, there's no reason that people need to go to an office anymore, and it'd open the whole country to them. I'd totally be interested in something like this, if I lived in SF, but I can't afford the cost of living there, and I like living in Provo, UT.
This sounds like a good fit for a friend of mine, but he'd need some kind of documentation to even consider showing up. Do you have anything about the platform that you're willing to share?
Only tangentially related, but this thread seems like a good way to contact the team: the "engineering" and "operations engineering" job description links are 404s on this page: http://darklang.com/team/
It’s a bold move. I like it, but I’m alarmed at how many people are acting like $3k isn’t worth taking. If I wasn’t solidly anchored on the east coast (Jacksonville, FL) I’d be taking a serious look at this, since it would give me about a 30% better chance at bootstrapping and avoiding taking on funding or other debt to build something cool.
But the whole point is it isn't in Jacksonville. It's in San Francisco, where $3k will pay your rent and that's about it. So you'd really want to reconsider not taking other funding or debt.
If someone is serious about starting a company, betting the success or failure of that company on an entirely new piece of technology (unless it’s critical for the product) in exchange for $3K/month doesn’t sound compelling.
Does anyone not even realize that if Dark really is so easy to use that you can build a scalable app in an afternoon, it will not even take a month for a startup to build their backend, and thus they will pay nothing?
Dark team - this is a great idea that I used myself. I had a startup building an Excel-like product and we had a casual office in SF. We didn't pay anyone but got some consulting teams to come into our offices for a few days so we could watch them work.
The consultants got to tell their client that they were engaging with this cool new startup's tools to analyze the client's data (which we never saw), wear T-shirts to work, and get free food. We got to see where the problem areas in our product were.
Lots of folks asking exactly what Dark is so answering separately.
tl;dr Dark is a programming language and service. Our goal is to allow you to build backends without having to deal with the endless accidental complexity in software today. (Accidental complexity meaning everything from infrastructure and storage, to syntax errors, etc).
What does that mean exactly? Dark is a language, and editor and a PaaS, combined. We're aiming to allow you build an application in an afternoon.
One thing to bear in mind: we are very early on this, so it's buggy and doesn't have all the featured you'd need. This will literally be our first user, so set your expectations from that :)
Adopting a new language with no ecosystem of libraries seems like a hard way to build useful applications. Or does Dark build upon an existing ecosystem like Elixir and Erlang? Dark's feature set reminds me a lot of Erlang.
We're mindful of this. Our goal is making coding much easier, and obviously that will need libraries. Our plan is that in the early days we'll make it very clear what Dark is useful for, and what's outside of its capabilities.
Not to mention it's in SF, which puts it around the poverty line. With that money you'd have to eat rice&beans and noodles for a month to alpha test a product.
Will it be possible to deploy Dark apps outside your platform? I don't mind paying for the language and SDK. We already do that for Visual Studio and C#. But being locked in your PaaS forever is a nonstarter.
While it's hard to say how the business will go, that's not really the goal. We're trying to make coding much much easier, and the tight integration is part of that.
> We’re creating a new programming language, tightly integrated with an editor, compiler and PaaS, to allow engineers to build distributed applications using high-level primitives.
Not sure if this is ambitious enough. Maybe you should make a database, too :)
But seriously, you'd have to convince me of a lot of things before I consider using a service like this, much less basing a business off of it:
1) The bar for your language is going to be high. Not only does it need to be appreciably better than everything out there, it needs to compensate for a lack of community / libraries.
2) You'll need to show me that your language is production ready. For most languages, it takes years to build up that level of confidence.
3) Holy vendor lock-in, Batman! What happens if you go out of business? You mean you're trying to lock me into an ecosystem that you haven't even built yet?
4) If that's not all, a new editor as well? Editors are substantially harder than most programmers think they are. It's hard to make them fast, harder to make them intuitive and there are tons of companies who focused solely on editors who have failed.
5) "High-level primitives"? "Use APIs as easily as if they were functions"? Honestly, sounds like using AWS services with Boto.
3) You're totally right: we're concerned about this and have been thinking about it a lot. Obviously, vendor lock-in is a disadvantage for us because it will hurt adoption, so we'd definitely prefer this wasn't the case.
4) Bear in mind that the editor only targets Dark, including our infrastructure component, APIs, and language. So this is substantially less work than say, building vim or Atom.
5) We're targeting way way easier than that. Literally you should be able to call an API in one line (including all the retry logic, backoffs, rate limiting, auth, etc).
Also, sorry but I'll (probably) never use anything other than emacs. I already invested ~10 years of customization. Most people did the same for other editors, IDEs etc. Its way too ambitious to make your own editor for a programming language. No project uses just one language. I'm not going to use emacs for 3 other languages and your app for one other. If your language is way too good, I'll try port an emacs mode and ignore your editor. Half your business model is already ignored by me.
Emacs is great - I used Paredit for years, and really learned to love the REPL in emacs. Actually, I still use Magit every day!
I know there are many many people who have deeply invested in their environments, whether it's an editor, language, framework, etc. And there are also millions who haven't, and are looking for the tool that speaks to them like Emacs did to you.
Where are you getting your numbers from? $3k * 12 months * 7 would be $252k/yr. Glassdoor reports average software engineer salaries in SF at $125k/yr.
Still, you're right that $3k is on the low side for SF, if you're treating it as your sole income to live off.
Tangential to the post, but the pages on darklang.com are really fast. They load instantly. I clicked the Medium link and it took a couple seconds to load what was essentially a blank page.
The darklang.com homepage took 70 msec for DOMContentLoaded and was only 25.5 KB total page weight.
That's even including two fonts!
Hacker News is usually my gold standard for a lightweight fast page. And while HN is only 13 KB (no fonts), it's >400 msec for DOMContentLoaded.
131 comments
[ 2.9 ms ] story [ 204 ms ] threadFor Dark, this makes total sense and is a good business model, for a new startup - it seems like an unnecessary risk.
Could you briefly explain what Dark is?
Definitely sounds interesting though. I have a lot of ideas, and would jump at the chance to cut my salary in half in exchange for total freedom to pursue them.
We’re creating a new programming language, tightly integrated with an editor, compiler and PaaS, to allow engineers to build distributed applications using high-level primitives. We abstract away individual machines and low-level distributed systems code to:
* Generate and run scalable infrastructure for you. * Use APIs as easily as if they were functions. * Remove the deployment step entirely.
Quite ambitious I must say
A language environment emerges using baby steps.
- spark interest from hobbyists wanting to try new ideas
- provide enough inertia to the platform for the hobbyists to want to join as users or contributers
- accept the role as a contribution manager (accepting source code if open-source, or finances if proprietary), while still developing core stability by yourself (the language designer)
- then encourage small companies to try it to solve problems that are made easy by a niche of your environment
More generally, if we look at devtools adoption as a whole (and I suspect Dark's adoption will more closely resemble a B2B devtool than a programming language), I don't believe those steps you outline are sequential at all. As an example, PHP was adopted by small companies extremely quickly, as were Parse and Firebase.
So I understand your point, and I'm not going to claim that you're wrong, but there are definitely other adoption models that potentially apply here.
http://darklang.com/
They plan to make money on support in the future (I believe), so why this model won't work for other spots on this planet?
(It's not intentional voting manipulation, but I do wish Hacker News would clarify their policy on linking to submissions as a discussion forum, which can cause this unintentional voting manipulation)
Since this submission got to #3 on the front page, there are likely enough authentic upvotes. Again, it's an algorithmic gray area.
Are you breaking california labor laws?
Maybe the meanings of these words have morphed over time, but in what sense is a "machine-learning model" not a back-end concern? It sure as heck isn't front-end...
(E.g., the current wiki page for "front and back end" explicitly mentions "converting the symbolic phonetic representation into actual sounds" as an example of a back end concern, and that's certainly the type of task that some people use machine learning for.)
Honest question: does "back-end" now mean "the CRUD and API client portions of a web-based CRUD app?"
This might go toward a larger question that others are asking: what exactly is darklang and what does it do?
Huh? They're giving it as an example of something that is backend-heavy that they don't want your product to be like. You've got it backwards.
> (Your product is (not (backend-heavy, such as: ...machine-learning models)))
I think it's you who have got it backwards.
Here's the entire thing:
"This probably isn’t a good fit if:
Your product is not backend-heavy, such as: an iPhone game, hardware, machine-learning models, blockchain, or embedded systems."
I read that as "if you're a hardware startup, you're not backend-heavy, so you are not a good fit", "if you're an iPhone game startup, you're not backend-heavy, so you are not a good fit", and yes, also "if you're a machine learning startup, you are not backend-heavy, so you are not a good fit".
Yes, it's clear enough that they don't want you to be a member of that list. But what characterizes the elements of that list?! In any grammatical or intuitive reading of
"This probably isn't a good fit if your product is not backend-heavy, such as: ..."
the "..." is a list of things that are "not backend-heavy". And the first element is "iPhone game", which is certainly an example of something that is "not backend-heavy"!
> (Your product is (not (backend-heavy, such as: ...machine-learning models)))
Oh no! That's horribly confusing and not how lists are used in English! If that's what they meant, the post needs rewording. The correct way to say something like that is e.g., "Your product is back-end heavy but is not [insert delineating characteristics], such as: [insert original list here]".
To return the substance instead of grammar, IMO the "[insert delineating characteristics]" portion of that sentence is exactly what's missing from this advert!
I thought they were referring to a multiplayer game with a server that has to be very low latency, handle a lot of connections, and not easily distributable, so that did seem backend-heavy.
But whatever they mean then, it's obviously not clear enough.
The other examples (iphone games, embedded systems) are not back end heavy.
I think what they mean by "back end heavy" is actually CRUD heavy and they put all these systems together under that non-CRUD heavy banner.
A model is built offline, experimented upon, tested, and then once ready "connected" to the main app. Like, the TensorFlow code you write doesn't "need" to be on the server; it could be running on your laptop for all you care. It's the output model that eventually makes it into the back-end ¯\_(ツ)_/¯.
> Honest question: does "back-end" now mean "the CRUD and API client portions of a web-based CRUD app?"
Back-end has always meant the CRUD/API portions of a CRUD app.
Yes, the model itself is part of the backend, not the code used to generate the model. But the website explicitly mentions "machine-learning __models__" as an example of something that's "not backend".
> Back-end has always meant the CRUD/API portions of a CRUD app.
This is not true. Compilers have backends. Speech processing pipelines have backends. The dragon book, which pre-dates the advent of the WWW, distinguished frontend from backend (and in those words).
Web-based CRUD apps inherited the terminology.
Under that broad definition of the term, sure, go ahead and rant.
If you're complaining that $3k isn't enough to live in SF, you missed the point. Dark isn't trying to pay you a $3k salary. They're not looking to hire someone to build a random app. They're looking for an employee of some other startup to camp out in their office for 3 months and use Dark to build the backend for that startup, and they will pay $3k/mo to do this. Presumably that money goes to the startup, not to the employee directly. The employee will get whatever compensation from their own startup they would have gotten without working out of the Dark offices.
The quote I think you're using to say "this is for startups":
> We pay you (or your company) $3000 a month.
In contrast to the multitude of other more personal references:
> We'll pay you $3000/mo
> Dark is a new tool to help you build a complete scalable app in an afternoon.
How many startups are working on "building an app in an afternoon"?
> You come to the office
> You build the backend
I don't think it's particularly fair to say "a lot of people didn't read the article" and that it is somehow obvious that this is aimed directly at startups, not individuals or otherwise.
Of course, no, it's not a livable wage. It's to me, more a "beta tester stipend" with a few bonuses. Can it realistically work for someone as a sole "job"? No, not without external support or a nest egg.
But I don't think that shows conclusively that they're looking to pay startups to work from their offices.
I guess the important point here is you're not supposed to quit your day job with the expectation that Dark will pay you a livable wage to build your pet project.
I absolutely agree, I think phrasing it as a stipend/some other offer than what sounds like a salary would help a huge deal.
Edit: some more info here: https://news.ycombinator.com/item?id=16803660
That said, since we're so early we really have no idea.
For our first user, it'll be free for quite a while, and then we'll make it work :)
Edit: a little more info here: https://news.ycombinator.com/item?id=16803660
I hope this idea works out for them though. It's about time someone paid the users of the software.
The consultants got to tell their client that they were engaging with this cool new startup's tools to analyze the client's data (which we never saw), wear T-shirts to work, and get free food. We got to see where the problem areas in our product were.
tl;dr Dark is a programming language and service. Our goal is to allow you to build backends without having to deal with the endless accidental complexity in software today. (Accidental complexity meaning everything from infrastructure and storage, to syntax errors, etc).
What does that mean exactly? Dark is a language, and editor and a PaaS, combined. We're aiming to allow you build an application in an afternoon.
One thing to bear in mind: we are very early on this, so it's buggy and doesn't have all the featured you'd need. This will literally be our first user, so set your expectations from that :)
Not sure if this is ambitious enough. Maybe you should make a database, too :)
But seriously, you'd have to convince me of a lot of things before I consider using a service like this, much less basing a business off of it:
1) The bar for your language is going to be high. Not only does it need to be appreciably better than everything out there, it needs to compensate for a lack of community / libraries.
2) You'll need to show me that your language is production ready. For most languages, it takes years to build up that level of confidence.
3) Holy vendor lock-in, Batman! What happens if you go out of business? You mean you're trying to lock me into an ecosystem that you haven't even built yet?
4) If that's not all, a new editor as well? Editors are substantially harder than most programmers think they are. It's hard to make them fast, harder to make them intuitive and there are tons of companies who focused solely on editors who have failed.
5) "High-level primitives"? "Use APIs as easily as if they were functions"? Honestly, sounds like using AWS services with Boto.
No that's what they are doing, you just use the new language.
3) You're totally right: we're concerned about this and have been thinking about it a lot. Obviously, vendor lock-in is a disadvantage for us because it will hurt adoption, so we'd definitely prefer this wasn't the case.
4) Bear in mind that the editor only targets Dark, including our infrastructure component, APIs, and language. So this is substantially less work than say, building vim or Atom.
5) We're targeting way way easier than that. Literally you should be able to call an API in one line (including all the retry logic, backoffs, rate limiting, auth, etc).
I know there are many many people who have deeply invested in their environments, whether it's an editor, language, framework, etc. And there are also millions who haven't, and are looking for the tool that speaks to them like Emacs did to you.
Still, you're right that $3k is on the low side for SF, if you're treating it as your sole income to live off.
The darklang.com homepage took 70 msec for DOMContentLoaded and was only 25.5 KB total page weight.
That's even including two fonts!
Hacker News is usually my gold standard for a lightweight fast page. And while HN is only 13 KB (no fonts), it's >400 msec for DOMContentLoaded.
http://darklang.github.io