We'll pay you $3000/mo to build your startup on Dark
darklang.com
darklang.com
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.
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.
(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.
While it is interesting to be paid to give some feedback to a system and maybe learn something, it would be interesting to know just what it was.
Consider: if you told me darklang was a python based language that was built on top of django/AWS and automated a lot of the work around it.
Consider: you told me darklang was a JSON storage model, with a react-like front end.
Consider: you told me that darklang was based on RUST in the browser.
All these things would appeal to very different startups. It would tell me that the work I did would not be wasted and I could take the basic models (ORMs, etc) if the project failed.
That's why I think it would be useful to say a little more about the stack around darklang. Even if it is "totally new", what is it based on?
There's a lot more types, though in a really good way. We're aiming for all the advantages of static typing, coupled with all the advantages of dynamic typing. For example, you use the same types all the way from DB schemas to API validation.
Sounds like what Microsoft tried to do with the .NET ecosystem, but with cloud integration (which Microsoft should be doing for their own cloud) and API validation.
Someone needs to actually succeed at doing this. Most of the type-checking/inference problems in this domain are decidable -- it's really a tooling/tooling integration problem. Creating a single unified tool instead of having developers clobber together libraries (JSON schema validator, ORM, MVC framework, deployment workflow for all of that, etc.) would be a huge value-add.
Suggestion: code example/screenshot/workflow video on your homepage, and a link to your homepage in the advert. Nearly every programming language/library out there has a concise "hello, world" example on their homepage. Nearly every software development tool has a screenshot of sorts on their homepage. Those examples are worth a million words. Even an appropriately caveated "Wizard of Oz" (https://en.wikipedia.org/wiki/Wizard_of_Oz_experiment) demo would go a long way.
Internally, we build a Real World app (https://github.com/gothinkster/realworld) and some other stuff. It taught us a lot but not nearly as much as a real developer will :)
Can you share what language darklang uses (or what language it is based off of)? I imagine if it is a language the startup already uses, it would lower the risk of trying it.
Dark is probably closest to an ML (like OCaml/ReasonML or Elm), with some interesting twists that we think will greatly increase productivity and decrease complexity, most notably tight integration with its editor and platform.
Edit: some more info here: https://news.ycombinator.com/item?id=16803660
For 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?
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.
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?
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.
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.
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 :)
- Literally no one else in the world uses this framework. You are entirely on your own when something goes wrong.
- Virtually no guarantee that the framework will still be being developed in 1 year.
- No packages made to work with it.
$9,000 is not nearly enough to take this gamble with three months of your engineering time.
All of my naysaying aside, I think it's a really cool idea by the DarkLang folks!
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 :)
This just raises red flags and smells.
There's got to be some catch like they are going to start charging those companies a monthly fee to use their product or license it after they have already committed and it's too late to change.
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.
Edit: a little more info here: https://news.ycombinator.com/item?id=16803660
err. herd of erlang ?
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.
I hope this idea works out for them though. It's about time someone paid the users of the software.
Are you breaking california labor laws?