Sure, keep the IDEs and deployless infrastructure and all proprietary, but a core programming language in 2019 can only be open-source. Heck, even Microsoft gets it now.
Proprietary language (Apex, which is Java 6-ish), complete vertical integration, no open source spec or implementation.
Yes, always good to plug something you haven't used.
Are you an investor by any chance?
Schema migrations are easy if there's no complexity to the schema.
EDIT: I got it, I got it. Go has multiple implementations. Bad example.
Rust - pretty fast growing open-source community despite only one implementation... but yeah I'm sort of worried that Rust is a "hard to implement" kind of language with maybe a not high enough bus factor... similar worries for Julia too
But tbh I'm not drawn much to either Go and Rust for other reasons - Go is too verbose for my taste, no way to write denser code that highlights the logic instead of the plumbing, and it has a "dumb" type system, Rust seems a really bad choice for rapid prototyping and iteration which is what I care about now.
EDIT+: glad to know that Go has multiple implementations in fact, pardon my ignorance!
I'm assuming you don't mean the traditional bus factor, but one of alternative implementations? Rust (and from what I can tell after short research Julia at least partially too) has quite a big development team that is supported by many different companies with no benevolent dictator, so I don't see a big bus factor risk.
Which is fair, but they seem like the kind of language where the compiler or run time is the really important part of the language, so it might make sense to have multiple implementations. Rust without the lifetimes implementation, and Julia without the highly dynamic but high performance run time, aren't worth much.
gollvm (aka Gollum): https://go.googlesource.com/gollvm/
On a more serious note, in my personal experience, the GCC and the LLVM
back-ends are generally much better at math- and computation-heavy
workloads and worse at… everything else, basically. But that was a long
time ago, when gccgo still used to spawn a thread for every goroutine,
so my experiences are probably outdated. Also, back in the day the LLVM
back-ends used to be the only way to get link-time optimisation with Go.
The GCC back-end probably can do it by now.
To answer your question directly, I don't know any large projects that
use them, but they exist. Which means that there is an alternative.
Unless Google goes full Oracle, that is.
Yeah, it was kind of clumsily worded. I get why people use the ones that are the only options for their respective target platforms (browsers, microcomputers, etc). I don't understand the advantage to using compilers besides gc, although your comment provides some clarification.
> To answer your question directly, I don't know any large projects that use them, but they exist. Which means that there is an alternative. Unless Google goes full Oracle, that is.
My question wasn't whether or not there is an alternative, it was simply "who uses the alternatives and why?".
Last I checked, it was capable of compiling releases of rustc well past 1.0.
- Trendy font that reminds me of Comic sans
- 1 MB of images and JS
- Mission statement and values read as generic lifestyle brand copy.
- A 1.4 mb PNG header image on their beta sign up page
- Tiny unreadable video (with huge black borders) or full screen only.
I'm a new user so this is very confusing to me.
This is an honest worry for an older developer like me. When you're young, your eyes can focus on just about anything. This changes as you get older. A dark mode causes your pupils to open wider, where a light mode gets them to stop down. And if your lenses are imperfect, stopping down helps make things sharper.
I'm posting this as a reminder and plea to younger developers: no matter how much you love your dark modes, please consider those of us who can't focus on them, and give light modes full support too. Thanks!
While I've got you, let me put in a word for proportional font support if you don't already have it. Proportional fonts are another thing that make it easier for me to read code.
Would be happy to chat with you about any of this stuff - contact info is in my HN profile.
Bright UIs can block out glare and reflections, thus preventing tiredness and headaches in such cases.
It's sad that we have to stare into a bright light all day just to accommodate natural sunlight, or shut the blinds and code in the dark. Can't wait for cheap, fast and unlit high contrast monitor technology resembling the experience of plain paper.
The bright white glare bothers my eyes and I can't work for hours staring into it. I have to go dark on everything these days.
Back to the light-on-dark computers I grew up with :)
Have you tried user testing the platform with random developers, giving them a laptop with the instruction, "Here you go, this is the readme, getting started guide, go build a todo app"?
I'd like to see a more detailed look of the language itself with a slower pace of explanation.
Just by watching the video, Dark feels like I'm interacting with a cloud backend rather than building stuff in a programming language.
We wanted to show people what we were working on, warts and all. We are super aware of what you're bringing up. The "cards" especially are not the metaphor we intend to use, just a shortcut to get this in front of people. I hope you'll bear with us :)
Just like Apple Numbers, it seems to point to a future paradigm of software development IDE experiences. Something a lot more freeform, flowy, than a traditional file/tabs UI. Some files are 2k lines long, some are 10 lines long; some are text, some are data; it's time we stop cramming everything into the same square file editing box. I think there is room for a lot of innovation here in the UX of developer tools.
Was very excited to see that.
I'm sure the Dark team will be releasing more in depth videos soon with a look into the language soon!
Dark being a proprietary language means most "experienced" or "full-time" software engineers probably won't touch it. You can get pretty close to "deployless" with FaaS services now anyways in whatever language you like.
So if this is being targeted toward low-experience/no-experience developers that just want to get something running, how is it addressing the problem much better than all the no-code/low-code solutions?
For that market, I don't think having them even deal with a separate "backend" and "frontend" is a good idea, they should just be dealing with logic only and have that whole concept abstracted away.
You can do that with any language and any serverless stack around, but it still requires work. I'm struggling often to make my teams accept that this little extra setup work will let you iterate faster and often it's not that obvious that it would, since the overhead of the process is non-zero (for some value of zero).
I can't wait to try darklang; I'm really curious. I just need to think of a pet-project that would be suitable for the beta.
Like how is that a 10x improvement on modifying a Lambda function in something like Netlify and clicking "Deploy"? And just "Rollback" if it goes wrong? For most products, which have relatively small user counts, they don't gain much from gradual rollouts.
Right now I'm looking at it for what it is: food for thought.
For me this gradual deploy matters because:
1. it generalizes local development and production and possibly also staging/testing environments in between. I don't have to setup some docker-compose environment that sets up the whole shebang locally. I don't have to setup complex CI systems that spin up an env for integration tests. And I don't have to bend over backwards to ensure that both local and automated test envs are reasonably similar so I can troubleshoot when stuff fails only on CI.
2. even if I don't have that many users, and even if my uptime is not that important; I still don't want to unduly break the application. Somebody will be watching and complaining, if only your boss. What usually happens is that people tend to batch changes and have periodic pushes to production. I've seen products with relatively small user bases have very time consuming release processes. Starting weekly, then biweekly, then monthly. The more the pain, the less frequently you ended up doing them . The less frequently you ended up doing them the more painful they become. Then you end up with somebody dedicated on that because this "release engineering" is becoming clearly a bottleneck. And you do more of it, because now it's somebody's job.
Ah, so "Dark" as in "dark launch"?
When we were thinking about the scope for Dark, we briefly thought about trying to remove all the complexity for frontend too. However, when thinking about how Meteor went, and specifically about how much stuff is going on in the frontend world, we thought it would be simpler to understand if we stopped at the HTTP boundary.
Bear in mind that there are tons of applications that dont have frontends, especially ones that are just APIs.
But how many people are writing APIs and either
1) aren't experienced enough to figure out how to write a Lambda function (using a wrapper FaaS like Netlify), or
2) are experienced and are willing to sacrifice the ecosystem you get from open-source/widely adopted languages/frameworks for a marginal amount of convenience over something like Netlify, where they can use whatever language they already know.
Maybe I don't see it and it's actually a lot of people. But in all my time working on APIs, I've never heard of someone writing an API who wasn't already a decently experienced developer.
Typically the front-end facing solution would come first for them, because why would they build something people like themselves would have trouble figuring out how to use? Which is where most no-code/low-code solutions are targeted for that reason.
Obviously, no one is going to leave something that's good for something that's slightly better with a ton of downsides.
1) Dark is a lot better, like way way way better than what's come before, or
2) it's not, and no-one will use Dark.
We can probably agree that one of these two are true, right?
If we're talking about a front-end dev, they're probably using React, in ES/Typescript. Any backend product targeting these devs would be nuts to not start by offering a JS environment, I would think.
Hence why every FaaS thus far starts with a Node env.
Well, I think this whole idea is wrong, but at least you quit while you were ahead with that one.
I am in the same boat. I often build apps that are pretty much 98%+ clientside, but there are just a few routes I need for the backend that would add a lot of value, but if I were to create those I can no longer sleep soundly at night because suddenly I have to worry about online storage security, pingdom checks, deployment pipelines, etc.
Now I get where this could be really, really useful.
 "We're in this for the long haul" isn't the only reason to be worried about vendor lock-in. The other reasons might be worry that the pricing changes (for the service or for support) or that their priorities change or simply don't line up with yours (eg you require a feature that they don't plan to add).
No thank you. There's zero chance I'm going to learn and build anything in a language owned by a startup.
Personally, the only real user segment I see for a proprietary language built by a startup is hobbyists and language enthusiasts.
Sure: hobby projects and experiments.
I would not include "under-resourced teams" or "new startups" in that, without many strong qualifiers attached.
I think I understand now that this isn't for me, but could have been once. At one point in your career, you know little or none of this stuff. Something like this would have been very empowering for me while I figured it all out I bet. I like to see technologies empowering people to do more, so I'm looking forward to seeing what people build with this. It looks pretty cool so far.
I would be afraid of hitting limitations and being locked in. That would be a major drag.
The intro video doesn't seem like anything is being made any easier, other than hiding a few of the templated bits away from the developer.
But the developer still has to understand what all this stuff MEANS. You need to understand REST, GET, PUT, REPL and any other acronyms that are involved in API development.
If you know all that, why not just use an established language you already know and build the API, with the added bonus you aren't in a closed language with a closed system that can disappear at any time?
PLUS you can do literally anything you might need to, without hoping that things like this might get around to implementing that feature in the future (which again makes their tool more advanced, opposite of what they are trying to achieve).
Programming is for programmers, and programmers understand how to build APIs ... it's quite simple.
At the same time, I value all those scary holes I ventured into as a junior dev, the problem solving skills it helped develop, and the independence it instilled.
It's hard to say, I think this is a cool idea but I'm biased to prefer my own methods I guess. I can't imagine working in such a closed ecosystem these days.
Holy crap, y'all, I just want to try out your language. It looks cool and all, but why can't I just download the IDE and try it? How are you going to get traction if normal people can't just play around with your language at home?
The tail doesn't wag the dog - I'm not going to recommend this for any projects at work without being able to try it first on my own.
I guess I'm just disappointed because my interest was piqued a couple months ago (probably when they hit alpha??), and I expected the next big announcement to be able to download something and try it out, or at least play with an online REPL.
Also IME "Show HN" means I can try something out. In this case it just means "hey we've hit another milestone but you still gotta wait indefinitely if you want to use it".
I'm probably being too negative, but again it's because I'm excited by the concept. A definite hurdle for me on my side/hobby projects is setting up all the infrastructure for some little toy app, so this concept is really exciting to me.
Congrats to the team, seriously--based on the demo this is a pretty mature product and the UX looks really amazing. I hope the next big announcement is that I can try it out :)
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.
> 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"?
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).
> 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.
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.
Facebook is closing Parse (parse.com)
1202 points by theunquietone on Jan 28, 2016 | hide | past | web | favorite | 500 comments
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.
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.
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
Do you mean, like, some sort of "silver bullet"?
Whether or not we agree with Dark's approach doesn't invalidate it in any way. It may mean we don't understand it. There are plenty of companies selling non-FOSS tools and making others successful with them. FOSS does not mean a secure future by any means. The fact that they know they have to prioritize making it a sustainable business is a good sign.
Using any tool, and depending on it commercially, is a risk. You weigh that against who is behind it, the path forward if it goes away, etc. It's easier if you can keep building even when the company goes away. If you rely on their servers, there is always more risk. Is there more risk to a project like Dark than FB's Parse? Nobody can say, without inside information.
What you have to look at, when selecting any tool (ignore the fact that there's a language component here, or that we're devs), is the benefit and the risk. If you have a stack that works for you, and you don't think there's a problem with how you're doing things, don't change. It's really that simple. But there is a revival of RAD, called Low Code, that says there are a lot of businesses out there with needs that aren't being properly met with our "modern" dev processes. If you can get a working product out, and it runs for a couple years, that's a win if you couldn't do it any other way. If you only use Dark to prove a concept, rewrite it after that if you're scared it will go away. Once you have a working product, though, good luck convincing the business it should be rewritten without strong justification.
But we can step back even further and ask: Do you think the state of software development is great? Just OK? Don't see any issues? Do you think that complexity is killing us and things we call solutions really aren't? Or are you somewhere in between?
In watching the videos, there are some things that aren't to my taste. But they note that this is not the final product. If you watch Paul's video, can you deny there is some deep thinking behind it, smart people who have already done a lot while being forced to make real-world compromises.
Yes, it's a business, but they're doing it to make our lives easier too. Shouldn't we cheer them on and wish them the best of luck?
That's what I'm doing.
What "guarantees" that you dont decide to charge far too much (or increase price mid-way)? What "guarantees" you wont kill a feature I need/my development requires?
Its a very nifty thing but without having self-hosting ability and this being some sort of open project (at least partially so users have a 'way out' if the company's direction changes) I cant see using this for any non-personal project...
I don't think there are any languages that allow the same thing that Dark allows - the integration with the infrastructure is the whole point. I certainly haven't seen deployless or live values in any other stacks. Which ones are you thinking of?
I didn't hear much about the database at all other than "it just works." This sounds like a recipe for full table scans falling over once more than ~10K records are in a given table.
What about transactions? Can I do joins?
At this point, why does a tool like this need to exist at all? To a full-stack developer writing API's isn't difficult ... and if it is difficult then you are going to need a lot more than a tool like this.
Should non-programmers be creating JSON REST APIs in the first place? I don't really see where this is going.
We deliberately cut relational features for now because they didn't mesh with our language. We want to add joins back - right now you're doing stuff the NoSQL way (which is not my preferred way, but it's where we are today). We haven't figured out or transactional model, but we want to have a good story around that.
You're going to get caught in that age-old trap.
Try to make something to "make programming easy", then realize it meets the needs of very few due to lack of features, and then start adding features until it's not "easy" any more it's just programming.
And then you realize you're decades behind what people are already using to do programming.
Can you expand on the database capabilities? By NoSQL do you mean no relational data, no constraints, etc?
You can do joins in Mongo, but it's still not an RDBMS. And you can have relational data and constraints in databases that support non-SQL query languages. NoSQL is a bit of an overloaded term these days :)
And if you go down the route of trying to expand that, then you are no longer a tool for easily building APIs, you are now a database tool also ... and before you know it you are trying to replicate features that RDBMs have had for 40 years. I wouldn't envy trying to have to implement ACID transactions.
I realize it seems like this is hyperbole but have you drawn a fine line in the sand at where the features for Dark end? Because if not you will quickly paint yourself into a corner with this.
We’re not fully publicly available yet (we hope you’ll excuse this Show HN when you can’t use it, sorry!), but we’re working hard to open Dark up to more people.
Would love to hear your feedback. I’ll be around all day to answer questions.
Where is this hosted? Asking as an EU based user with GDPR requirements.
Currently hosted in GCP, US west.
I'm curious who you see your audience as. If you look at a spectrum across skill level:
* On the far left you'll have those learning: univ students, boot camper's, technical folks in non-eng jobs (think operations-y people who are zapier+spreadsheet wizards).
* In the middle you'll have junior engineers starting their first or second role.
* On the far right, you'll have senior engineers who are looking at factors beyond functionality like architecture, style, performance, etc.
I think the middle is out. These are folks who've made an investment in their education and are looking to apply it. They're looking to earn their stripes and might trade efficiency for that. There's also secondary effects of using the incumbents like membership into a community (I run the SF Django meetup so I see this up and close).
The far right is out because DL is hiding the complexity they're precisely interested in tailoring (or at the very least, having the optionality to in the future). Additionally, they're very fast at the operations you've optimized for (CRUD) so that's not necessarily a barrier for them. They'll be working with boilerplates that are deployment ready (though not instant like y'all - that's pretty cool!). Yes there's some pain here you're solving. Not enough to justify the switching costs, IMO.
I think that leaves you with the beginner crowd. Zooming in further, I'd exclude students since there is no value for them to invest in something they wouldn't get hired for. There's the casual indiehacker / weekend project person. I think this would work fantastically for them because they just want to spin something up as fast as possible. There's also the operations person who does a lot of ducktaping of airtable+zapier+typeform+etc. I know many people who are doing that and when they hit a ceiling, this could be perfect.
I'm arriving to the following conclusion: though you're not a no-code tool, you share the same target audience. Repl.it is a good comparison here.
> I think that leaves you with the beginner crowd.
The problem with that, is ... well ... $$$.
I have a hard time believing this is going to work, but I've been wrong before and if I lived in the US I'd be tempted to apply for a job. How often do you see programming languages get funded!
- Have multiple projectional views of the system, triggered on keypress, e.g. caller context, database context, handler context. So if I'm editing a function I should be able to see the handlers that are affected, also the call stacks up and down, even show function calls inlined, current live errors overlaid, etc.
- Easy example based testing. Can I just click on a function, type input values at the top, then dark shows my intermediate values and output, and then I mark a 'check' on this trace to stamp it as a test case? Then every related change (or a special button) runs affected tests and I can see what's failing. I didn't see any testing in the demo.
- History of each function, each handler, each table - absolutely need this, with 'blame'.
- Immediately live is nice but really you want to roll out some related changes together, and a 'diff' of a snapshot against another one is great. I should be able to see the db diff, the function diff and handler diff in one integrated view. Should be able to 'label current version', in addition to auto-save.
- Annotations - these should be allowed everywhere. I assume functions, AST nodes, tables, columns etc are already reified, so I should be able to link to them in free form annotation comments that I may put in the code or just floating around by themselves. Documentation needs to be integrated as well. At the very least I should be able to link to a function or table via an external hyperlink.
- A standard CRUD UI for DBs should be available.
> Have multiple projectional views of the system,
Some amount of this works already (you can see callers and callees, you can see the DB schema); we want a callgraph view for sure, and I like the idea of seeing the handler at the bottom of the call stack.
> Easy example based testing
Yes, this is planned to work similar to traces, and it should be trivial to turn a trace into a test
> History of each function,
> 'diff' of a snapshot against another one is great.
Planned, but low on the priority list compared to the other stuff you've mentioned.
Planned. We've implemented some grouping (similar concept but obviously different use cases to tagging). Some of these annotations would be automatic or semi-automatic.
> A standard CRUD UI for DBs
> DB/field annotations for privacy
We plan two aspects to this. There is the "PII indicator" which says this is PII and shouldn't be logged at all. Then there's access-control lists where we decide who (if anyone) can view certain attributes (eg: this dev is a contractor, do not show them live values).
Thanks for all the suggestions!
- DB/field annotations for privacy - given it's 'one integrated system', can we attach a privacy attributes to fields or db and automatically hide them everywhere (even in the dev view?)
Dark can basically ask for any numbers they want and you'd have to pay it if you build something sizable on this platform, because moving away would be even more costly.
I don't think this idea will work since there are too many viable options in the marketplace, and people are smart so they will avoid lock-in when they can.
Maybe right now, if the funds are there. But what about in the future, where revenue is required to keep it alive?
These comparisons to Amazon are unfounded, because Amazon is not going to create a blog post one day alerting their customers that AWS is shutting down. AWS was built because Amazon needs it, and people knew that when they signed up. It's not going anywhere.
What about this: pass through infrastructure cost with a wee markup for maintenance/support and negotiate a modest percentage of gross revenue from your successful client companies.
That way you have a low-risk "farm" of potential big hits, and your users have stable costs.
[I originally posted over at https://news.ycombinator.com/item?id=20985429, happy to answer questions here until the mods merge them]
I don't have time to write anything, so I'm not signing up for your beta, but I kinda wish I had the time.
I don't see how the target can be entirely non-technical people, since this still assumes some knowledge around databases/functions/REST/HTTP/Schemas/etc.
Technical people have very little reason to use this, since this platform is a walled garden of proprietary tooling, and there's only so much you can achieve with abstractions and fancy ORM. You won't be able to break out of the mould when the time comes, so why waste your time in the first place? Do it right the first time and maintain your flexibility and freedom later on.
I believe the only remaining target audience here is technically-inclined people that want to build a cheap prototype quickly, just to test ideas. This is a playground basically.
Moving the bar on "high-level programming" up a few notches to remove even more of the plumbing required to build and launch an app is only a good thing in my mind. It provides more options for more people.
Dark definitely won't be for everyone, but it seems to me like it will empower a lot of people to bring their ideas to reality more easily than before.
> "There is a large - and growing - population of technically-minded people who understand the core concepts you're referring to (REST APIs, databases, HTTP, etc) and have ideas or needs for applications, but don't have the experience required to build non-naive implementations of their ideas."
Sure, but one could argue the Darklang approach is actually not that far from a "naive implementation" of those ideas. There's only so much you can do with prefab code and lock-in tooling. There's definitely a market for "Wix for SaaS software", but does Darklang strike the right balance?
Funny that you bring up Wix, I was thinking of that comparison too earlier..
In the early days, we had Geocities, Angelfire and other hosted web publishing sites where people could tinker with the CSS and images and post their content.
Then came Wix and Squarespace and the like, where you could also edit the HTML and start to add some functionality..
Now we have Darklang where you can write code as well..
Each one targetted the level of sophistication of the current generation of digital natives who wanted to build something for themselves on the web.
And each one is likely a stepping stone along the way for those who want to keep learning and have more power and control as they build more sophisticated things.
That is, after they learn a new programming language, error handling concept, a new IDE, and a proprietary data store.
But yes, after that it's almost drag-and-drop!
But those concepts you listed are certainly more straightforward (and aligned with "building an app") than dev ops, hosting, deployment, scaling, database config, etc..
I have a few random questions.
1. What is the support for interop with other languages (e.g., python for machine learning, rust for low level). Or is that even a reasonable question to ask?
2. What is the pricing structure going to look like?
Very exciting! This is great.
2. We plan to charge for infrastructure, on a usage basis. If you use only a little, that should fit within the free tier.
If I have a Django/Django REST Framework app, can I deploy it with Darklang? How is it better than "git push heroku master" for small apps?
Unlike elm-lang, it's not open-source.
So to answer your question, no, you can't deploy a Django app with their platform.
EDIT: It seems like you're even giving up git for their own particular brand of version control that is tailored for their use-case, e.g. seems to include in its scope database migrations.
* No tooling to set up, don't have to think about project structure or computation (VMs or cloud functions)
* Don't have to think about databases, connection strings, etc
* Fast deployments
* Perfect for rapid prototyping or hackathons
* Vendor lock-in at the language and infrastructure level
* Not open source
* Have to learn a new language
Compared to serverless (for a CRUD application), I wouldn't have to write configuration to set up the API endpoints / dynamodb tables. Also, deployments would be super fast which closes the developer feedback loop. I shouldn't have to worry about emulating my stack locally or deploying my stack every time I want to test my code.
The cons make this very hard for me to buy though. My ideal framework would be open source in a popular language (JS / Go), runs on cloud (AWS / Azure / GCP), fast deployments (no cloudformation), low configuration / convention based (like nextjs), and integrates with popular NoSQL data stores (mongo, redis, etc). Basically it would be completely conventional with an opinioned data access and the ability to override features to add more complicated functionality like optimizing data access after the initial prototyping.
Can apps written in Dark scale to 10k LOC or will the browser UI get jittery? How many concurrent users can Dark apps handle?
Do you integrate logging and metrics?
I hope you are making an iPad app. That would be truly next-level.
> Can apps written in Dark scale to 10k LOC or will the browser UI get jittery?
We've had a number points where there editor became unresponsive and we had to rearchitect parts of it. We feel pretty confident about scaling the UI - not so much that it's perfect but that the problems are tractable.
> How many concurrent users can Dark apps handle?
Many more than our current users need, but not as many as we'd need for general release. One of the reasons we're in private beta is that we need to do a lot of work on scaling to make sure we can support new users without damaging the experience for current users.
> Do you integrate logging and metrics?
We have integrated observability, and we plan to have metrics but don't yet.
Do you guys plan to support smart diffs for code reviews? As you work on AST level, it should be possible to detect some more patterns, e.g. an re-arrangement of some pieces of code, refactorings of many identifiers, etc., categorise them and have a diff summary for the review.
In his post, Real problems with functional languages , Paul Biggar creates a false dichotomy: static types help us to write correct programs while dynamic types let us prototype faster. Dark wants to be able to do both.
I believe Haskell allows us to reject outright incorrect programs sooner and allows us to prototype things faster due to its types and inference engine. I don't really see how Haskell is poor as a prototyping language. From experience it's better than dynamic languages as it has allowed me to focus on logic and domain problems instead of mucking up my code with brittle run-time and equality checks... and then chasing down bugs I've made for myself.
No where is it mentioned what type system Dark is using. Will Dark allow a program to be deployed that it cannot reason about? What about higher-kinded types and polymorphism? Does it enforce termination or is bottom a type in every kind? Does the type system enforce linearity in usage? Quotient types? Row types?
This looks like a cool project but I don't think I'd use it for anything without knowing more about how it works.
After watching both videos, Dark just looks like a more managed version of AWS Lambda, with a fancy proprietary editor.
This is obviously very early but for doing basic backend stuff there's so many smart things here going on already that it's already 10x better for the use cases they're targeting.
The one thing that didn't get covered in the "Dark in action" video that should have is where do the twilio/slack tokens get stored? I'm sure there's some environment/global variable somewhere UI somewhere but the fact that it's alluded to but never shown is an annoying omission.
If they work on a ton of integrations (which is super annoying work unfortunately) I could see this being a big competitor to Zapier or the whole "glue" type infra work that so many companies deal with. If they take a marketplace approach where people can build "blocks" that are easily shared that would be a big deal. And considering they run the whole stack, monetizing the sharing of blocks would be a cool business model too.
> The one thing that didn't get covered in the "Dark in action" video that should have is where do the twilio/slack tokens get stored? I'm sure there's some environment/global variable somewhere UI somewhere but the fact that it's alluded to but never shown is an annoying omission.
We actually just put them in functions. We haven't built a secret UI, and we didn't build global vars because functions do the same thing.
> If they work on a ton of integrations (which is super annoying work unfortunately) I could see this being a big competitor to Zapier or the whole "glue" type infra work that so many companies deal with. If they take a marketplace approach where people can build "blocks" that are easily shared that would be a big deal.
We plan to add a package manager so that packages (which could be wrappers of various APIs) can be shared. So similar to npm, rubygems, cargo, pypi, etc.
Can we access the data store/our data outside of dark?
What is the datastore build on top of? Is that proprietary?
Also, is there the option to use the raw Twilio API if we want or is the dark version the main one supported?
Yes and no. You can easily put an API in front of it so that you can expose it however you like, download it, etc. But there isn't something like a postgres connection string.
> What is the datastore build on top of? Is that proprietary?
The goal with the datastore was that there is no impedance mismatch between values in the runtime and values in the datastore. The actual implementation is a thin layer over postgres.
> Also, is there the option to use the raw Twilio API if we want or is the dark version the main one supported?
Yes. That Twilio::sendText call is just a wrapped HTTP call, and under the hood it's pretty similar to how we called the Slack API in the video.
What does error handling look like? Do individual cards basically become individual classes with functions and handlers? I would love to see more examples of apps build with dark.
Does anyone know if there are tools in reverse of dark - build API and based on that create front end?
Do I get access to the "raw text files"?
The idea is that you use feature flags to manage versions (my video on the blog post goes through that workflow). We haven't yet got features to support moving back to old versions (apart from undo), but we will.
A few more questions
# Maintenance costs & agility
You're not just building a programming language, you're also building an IDE, and now a version management system (through feature flags).
Each of these tasks are hard problems individually, what gives you the confidence that a small startup can build all of them? All of this while trying to make your company profitable.
If your language is not hosted, how do you plan on building an eco-system around it. (I know you come from a Clojure background so you've probably seen the wonders of being able to re-use Java's ecosystem).
For sure it's hard. FYI we're hiring: https://darklang.com/careers. The intuition is that this stuff is way easier when you don't have to support everything under the sun. The editor just needs to support the Dark language, the infra is tied to it. It reduces scope massively.
> If your language is not hosted, how do you plan on building an eco-system around it.
We plan to have a package manager that is easy to contribute to. I think we should be able to grow the ecosystem quite quickly.
Thinking about usage from two perspectives:
As a developer, junior/senior/whatever, I don’t know why I would use this. There are so many tools that accelerate and mitigate the difficulties associated with building services that I would choose in a heartbeat over something like this proprietary, closed source product.
As a manager/leader, I would never support using a tool like this. Again, closed source, lock-in, learning curve are a few concerns.
I hope my tone was not dismissive; I would really like to hear people from the dark team sell me on this.
IMHO this as the first time we have improvement in the huge complexity required nowadays to have a backend, particularly for a small company which can not afford a whole Devops or Infrastructure team.
Just a one question:
- Given your use of OCaml and Reason ML why did you choose to go with your own language instead of using one of them. Wouldn't it be easier for developers to adopt say Reason ML, and then just use a library you provide?
Given that, whatever language we'd pick we'd have to hack them to get what we needed, and then we wouldn't have JS (realistically, if we were to pick some existing language it would have to be JS), we'd have some shitty version of JS.
Which is what App Engine did with their early versions: I worked on an app engine project that had a hacked version of Django where nothing worked.
It's amazing just how little friction there is for you to get an API endpoint backed by a datastore up and running. That being said, there are a bunch of unknowns. Having my entire application, even down the language it's implemented in, being proprietary is a little scary.
Will definitely be looking forward to playing around with this. Just as soon as I get my signup email ;)
It's not remotely as unique as you seem to think, as even that framework is just one of many.
Also "testing" is in the FAQ as a "we're working on it"-item.
Still a bit scared for your initial beta users running their business on this as mentioned elsewhere.
Node+express is already simple enough...
It's hard for me to see the benefits being worth the difficulties.
Edit: after seeing the building block like nature of the editor it makes more sense to me. It's ambitious and a really cool concept. Would be great to see wider applications of that editor/language.
Give me a bit more time, a keyboard and I could build you any API endpoint, http server, glue code between DB or even low level proxy server functionalities.
No offense but isn't the 'problem' backend solved years ago?
There has been momentum around this kind of idea (personally I've used WolframLanguage, Anvil) - pros and cons to each approach. I'm excited to see where this goes!
I'm interested to see where this goes, and if they're not able to turn the closed-source version of this into a business, perhaps they'll inspire some community of OSS people to do something like it.
I'll say after having worked on migrations out of proprietary platforms like App Engine, I wouldn't use anything I couldn't run myself all the way down to the bare metal should their company up and disappear. They will have a lot of problems convincing people to bet their business on this platform if it's completely closed.
That said, we haven't tested this with teams of more than two people, so we might need to change how this works.
Also curious about the reasoning behind a new language (Dark), instead of supporting other languages out of the box. Could've started simple with supporting node / python and worked towards go, rust, etc.
The "Dark's philosophy" video addresses the language a little - everything that's cool in Dark is enabled by the super tight integration between the language, editor, and infra.
- Austen @ Serverless Inc.
We plan to support enterprise users too, but that's a little bit down the line.
The linked post, the videos, and the landing page are good in terms of marketing for non-programmers. But it is not satisfying to me as a developer, especially when trying to convince me to buy in the whole platform + custom editor stuff.
Why didn't you use an already common language like python, with rest of features? Is it difficult technically? I'm just trying to understand your choice.
NO FUCKING THANK YOU.
maybe for the generation which grows up with scratch, new concepts and ideas are needed.
not sure if darklang will make it, but exploration in the space will surely help.
writing this from while using emacs as a window manager(exwm), made me realize how impossible it is for me to evaluate change.
best of luck.
Well, this is the problem with designing backend, knowing what to do. Not actually writing the implementation. The way I see it, no problems are circumvented.
Cool development-environment nevertheless, it'll be really good for beginners.
Sounds interesting from the comments.
Sorry about this, I think medium wasn't the best choice for the blog.
> Speed of developer iteration is the single most important factor in how quickly a technology company can move.
What? "Speed of developer iteration" barely makes any sense, it's poor wording.
In any case that proposition seems dubious. Companies exist to please customers, not its own developers. Too often we (developers) conflate our happiness/productivity with that of the actual stakeholders.
With that said, at scale one tends not to need a faster feedback loop, but greater guarantees around correctness (in logic, deployments, etc). Encouraging us to work in a mindless, iterative manner goes in the opposite direction.
It's as if I wrote "developer deployment".
We think a lot about how large teams build at scale, and while we don't support everything we'd need for large teams just yet, Dark is designed for this use case.
The opposite is not impossible though, I'm certainly open to see the actual offering and tradeoffs. I'm mostly expressing that Dark's marketing likely won't appeal to people who tend to question things a lot; extensive rationale is needed for us.
Btw, it seems quite possible to hack a vanilla Clojure setup (Reloaded workflow, tools.deps, some CI magic) to offer deployments under 30s. I just don't see it as worth the effort, and also I actively pursue some healthy constraints (slightly slower deployments = more thought put into things).
Here’s what I like about Dark:
- Build API endpoints in a matter of seconds. As soon as the logic is written in Dark, the endpoint is publicly available on the internet
- Live data: Dark has a feature called traces that shows data as it hits your endpoints. This allows you to quickly manipulate code between your front + backend
- Easy interaction between third-party APIs (for me it handles logic with Stripe, Twilio, and several others)
TLDR: Dark has enabled me to build a backend faster than ever before. If you’re building something new, I suggest you give it a go.