Hey folks, excited to finally unveil Dark and show you what we’ve been working on! We haven’t publicly shown how Dark works before, what code is like, or how deployless works. We hope you like it.
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.
I'm excited to see more people get access to this! My cofounder and I rebuilt our project tracking platform on Dark and will be building the rest of our products with it. It makes building simple and makes testing 10x faster and easier for everyone on our team. I've been waiting for it to launch so that I can recommend it to more people.
Hey folks, excited to finally unveil Dark and show you what we’ve been working on! We haven’t publicly shown how Dark works before, what code is like, or how deployless works. We hope you like it.
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.
The workflow that creates a new request from historical 404 requests is incredibly intuitive. I could see this helping entering the development "flow" zone when jamming on a brand new project.
I’ve been using Dark for the past 12 months and I cannot say enough good things about the product and the team behind it.
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.
We combine version control, deployment and feature flags, with the intention of simplifying the three concepts into one.
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.
Not planned. We plan to expose the APIs around this so you could build something yourself that syncs to github possibly, but that's not the design for sure.
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.
# Ecosystem
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).
> 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.
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.
I've been impressed with Dark -- it has the potential to make it possible to build a scalable cloud application in an afternoon and reduce application complexity. This has a number of impacts long-term, from both making existing teams more productive, to bringing less sophisticated developers to participate in application development. I highly recommend you check it out.
[Disclosure - I'm an investor in the company, but my thoughts are my own.]
Why should I go for a vendor locked, proprietary solution that could disappear at any moment for any critical infrastructure? Especially when it requires a proprietary language no one has ever worked in before while there are at least a half dozen tried and true tech stacks that do this exact same thing, are not proprietary, and engineers already know them?
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?
Look very cool, and I'd love to try it out... HOWEVER....Being closed-source, backed by a single company (startup or not) is not an acceptable level of lock-in imho.. (maybe for small pocs)...
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...
The collaboration is google-docs style. You can see if you're working on the same code as someone else, see the feature flags they're building, etc, to avoid conflicts.
That said, we haven't tested this with teams of more than two people, so we might need to change how this works.
This project represents a stark tradeoff: lose some complexity, and lose almost all control.
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 feels like HN regular are unlikely to be the ideal audience for this. Reaching for a metaphor, it's like a bunch of expert Unix users gathering around an IBM PC or Macintosh in the 1980s.
It's so easy to bemoan the control we lose (a major problem given our existing workflows) and have no use for the functionality it confers (simplicity, batteries included, lack of yaks that need shaving).
A really great new idea should empower millions of people completely unlike us to build software.
We do intend the HN audience to love this too. Our target audience is developers building backends. We don't expect we'll wrestle people from their Emacs, so we're definitely not targeting all possible developers today, but definitely developers.
Most languages are vendor lock-in actually, with forks not passing an experimentation level. OpenJDK may be the only working example from the mainstream languages.
Are you forgetting C and C++? These are probably the least risky languages you can use. Open source implementations, open standards, multiple implementations.
A language with only a single, open-source implementation controlled by a single vendor, like Go or Erlang, has slightly more risk, in that the single vendor could choose to take the language in a direction you don't like. However, even if that were to happen, it's open source, and the community can maintain it as long as there are enough users.
A language primarily controlled by a single entity that is actively hostile towards openness, like Java, is a little more risky yet, but even so, with enough users it becomes safe enough.
A language that's not open at all, like Mathematica or F#, puts you entirely at the mercy of the company that controls it... but if that company is big and has a good track record, it's still at least a reasonable trade-off.
Now, if something is created by a startup that has at best even odds of being around in five years... you still might take that risk if the technology was open, and you could run it yourself when they close up shop, like, say, Meteor or MongoDB. These are decisions that one is rather more likely to regret, but it's not hard to see how people make them.
However, if a new company introduces a new language that is also it's own walled-garden deployment environment, which you can't run on your own systems, which has no demonstrated history of doing anything well, and which is not open source, anyone choosing that language for a project that's expected to be around for a while would have to be either inexperienced or just plain crazy.
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.
> .. buuuuut you don't have to learn how to: 1) deploy your code 2) deploy your datastore 3) manage your datastore 4) shard your datastore 5) deploy your infrastructur3
Or you can just get a cheap host and throw a table into a SQLite database (a file) and use JavaScript.
> I’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.
Many people who are "self-taught coders" don't perceive themselves as "engineers", often because many other forms of engineering have certifications. They expect that "engineer" requires a certain level of knowledge that they do not have; it's an unknown unknown kind of thing.
I know someone who, through using a lot of Goole Sheets, managed to re-invent SQL joins. She'd never identify as an engineer, but she did manage to get some software to accomplish her task.
A lot of people can do some magic stuff when it comes to spreadsheets (and as a self-taught software engineer, I am not one of them), but does that same logic really apply to API endpoints?
Look at how many acronyms are in the intro video alone ... the narrator says "we'll just use REPL ...". Does someone playing around in Google Sheets say "yes, REPL, great choice!" or do their eyes glaze over?
What about when you tell them they have to learn "Darklang"?
I personally find “engineer”'s use in a software context as pretty pretentious, so I understand how they might feel like they're really something different. What they don't know is they're as much a programmer as any other.
A better metaphor would be PC and Mac users gathering round a 90s 'thin client' and expressing the same concern. If you've never heard of the 90s thin clients there's a reason...
I have heard of thin clients, they competed with desktop apps, which were the incumbent technology.
But thin clients did win, we just call them web apps now, which we run in thin client emulators we call “browsers.” And I recall incumbents scoffing at web technology back then, too.
From my perspective all the negatives of the web app approach have largely come to pass and I'm moving away from hosted cloud apps. Once bitten twice shy I guess. I'm not sure it's time to declare a winner.
Yes, your personal perspective invalidates thousands and thousands of webapps out there that are reaching massive numbers of people that they otherwise never would have ;-)
My first code was written in Flash 4 (I think?), so I understand the value of a easy-to-use walled garden, and I understand how companies can make money from those walled gardens.
> A really great new idea should empower millions of people completely unlike us to build software.
I agree, but I don't think this is it — it doesn't feel like the SquareSpace of backends. It requires a bunch of pre-existing knowledge (requests, databases etc.), and its language doesn't have the simplicity of most starter languages.
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).
Does (or will) Dark have a light mode? Given the name and seeing the dark mode screenshots in the article, I wonder.
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!
We will absolutely support light mode, and we plan to deal with many other accessibility concerns (I touch on that very briefly at the end of my video). This sort of inclusivity is massively important to us. I hadn't realized Dark mode was tough for certain audiences - I'll add it to the list. (We also plan to get an a11y consultant in to make sure we get all of them)
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.
I second your request and I'm grateful for your comprehensible and respectful way of pointing out the problem. I usually just get frustrated and angry at software that only supports dark mode.
I'd say that it is a problem when you have optimal lighting in the workplace.
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.
In my 40s as well and same here. Light mode hurts me. But always has. My first computer was monochrome green on black. Then MSX for many years where the first command after startup would be color15,1,1 (white on black) until I was able to make a custom eprom to have it at startup.
I mainly use light modes, but very rarely use white ones. Similarly, I often find that many dark modes, esp. those emulating old-style terminals and computers, liek to put bright green colors on bright (as it were) black, or similar schemes that to me are more garish than, say, Base16.
I got the email, and read through the post, it seems awesome. I remember the original HN post and am excited to see the progress.
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?
1. The "foreign function interface" in Dark is HTTP. So to do machine learning, either use a service that for it, or put your ML stuff in a container with a HTTP wrapper around it.
2. We plan to charge for infrastructure, on a usage basis. If you use only a little, that should fit within the free tier.
Good to know! With the approaching FedRamp High certification across all GCP services, this seems like it could be really useful for resource constrained state/local governments and municipal services.
> 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.
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.
I've read the blog posts in the past, and it seems quite likely that Dark could be a large conflation of concepts (as opposed to composition), which repeatedly traded off desirable properties for faster deployments.
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).
"speed of developer iteration" is a phrase I've heard outside of Dark. Specifically, "developer iteration" is how fast you're able to iterate on ideas with your code. If you can ship stuff faster, you can iterate on your ideas faster.
I applaud the effort for the project because it's really ambitious. The delivery at this point on the other hand makes me a bit skeptical. I've watched the hello world app a few times and my impression is that it relies on lots of convention over configuration (same reason I disliked Rails). The "cards" or files on the canvas look a bit chaotic and their relations are not clear at all what thing triggers which event. The slackToken thing is confusing too.
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 have user tested, and a ton of people have built full apps with it. That said, you are correct that it can be a rough experience at times, which is one of the reasons we're in private beta.
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 :)
I love the "cards", or at least, the step in that direction.
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.
I've been using the private beta for several months now. It took a few hours to get the hang of it, and once the language clicks, the speed of development moves quick.
I'm sure the Dark team will be releasing more in depth videos soon with a look into the language soon!
A little over a year ago I was building an app, and decided I'd have literally no backend at all. I wanted to build something fast and ship it to the appstores as quickly as possible to go through the process. After I launched, it was featured by apple and was getting thousands of downloads per day. Users wanted to be able to save their data across devices - but it wasn't something I really had time to build in the ways I had in the past. I had heard what Dark was up to, and was lucky enough to join the beta. Dark now powers the backend for my app (nzd.life) - and I really can't express just how amazing it is to use. We added the functionality in just a weekend with a handful of LOC. Dark really is a game-changer. For any entrepreneur / dev who wants to move fast and ship things, they should try Darklang ASAP.
This is an awesome case study. Thanks for sharing. I was having trouble coming up with good use cases for this, but this makes a ton of sense. It's basically like a much more advanced, better Firebase/Lambda/Google Cloud Functions/Azure Functions.
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.
Honestly, that's totally cool. There's a certain risk profile that's right for where Dark is now (new startups, low risk projects, under-resourced projects/teams). Folks with a different risk profile should not be using Dark at the moment.
Respectfully: why should you be considered a fair steward of trust for them, either? Those people shouldn't be using a startup-backed, no-accountability platform either.
Why would a new startup want to add another factor of uncertainty into building their product? If you want to prototype fast, you use whatever your technical side is comfortable with, you don't pick a new tool where you don't know how or even whether you can do your thing.
Personally, the only real user segment I see for a proprietary language built by a startup is hobbyists and language enthusiasts.
Honestly, our "prototype" was screenshots from an 800 line demo, and about half the people we spoke to believed that this wasn't actually possible to build.
Can you speak more to the scope of this? I'll be watching the video later - but, I'm curious how this "isn't possible to build"?
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.
Specifically in the context of fundraising, we said "backends are way too hard to build, we can remove all the accidental complexity of infrastructure, deployment, and APIs". Many people felt that that was not possible.
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.
> Can we access the data store/our data outside of dark?
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.
Having worked full stack for so long, sometimes things like this seem way over the top and I don't really get it. Why not have control over your language? Why not have control over deployment, VCS, servers, etc?
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.
I am in the same boat, I've been full stack for many years across a variety of technologies.
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.
One thing that crossed my mind while walking since my last comment is that this could be great when you work on a team with some junior developers. Like you say, they need to learn all the acronyms and concepts between them, but they're working in an ecosystem with guard rails and mentors who (assuming they're experienced with Dark) can easily keep them on track and help them solve common problems. Hopefully there would be less edge cases and rabbit holes to die in.
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.
The way workers and events are exposed looks pretty slick, and I think abstracting away infrastructure and dev environments is the future for teams who care about speed to market. One nagging question is, how do you plan to make money? Will you have a free/freemium self-service offering? Any plans to target enterprise? I think some assurance of financial viability would ease the minds of otherwise reluctant adopters. Full disclosure, I'm a solo developer working in the IaaS space.
We charge for infrastructure (that is, we host your infra, so you pay based on usage) - this is also what we did at CircleCI. Small users will pay us very little or fit within the free tier. Huge users will pay a lot.
We plan to support enterprise users too, but that's a little bit down the line.
How confident are you that your database abstraction is going to fulfill the needs of someone with anything more than a few trivial query workloads?
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.
The model here is that we own the responsibility of making it scale. We haven't solved the problem of significant workload, but there doesn't seem to be any reason why this wouldn't work - certainly our current (low-scale) users have not had any scaling issues with Dark. If there's a fatal flaw we haven't thought of, please let me know.
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.
> We want to add joins back - right now you're doing stuff the NoSQL way
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 :)
> What I meant was that our datastores are simple key-value stores at the moment.
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 deliberately cut relational features for now because they didn't mesh with our language. We want to add joins back
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.
It's very easy to paint yourself into a corner if you haven't figured out at least a plan of attack for these topics up-front, especially if you're starting to ramp up actual use of your product.
Right, the demo video lost me at the datastore point. This is a fancy ORM. Now, I do get that making app dev so much easier is a very good thing, but ORMs are a double-edged sword. You need an option for the dev to have much more control over the schema and queries!
> How confident are you that your database abstraction is going to fulfill the needs of someone with anything more than a few trivial query workloads?
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.
261 comments
[ 5.0 ms ] story [ 276 ms ] threadWe’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.
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.
[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.
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.
- Austen @ Serverless Inc.
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.
# Ecosystem
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.
[Disclosure - I'm an investor in the company, but my thoughts are my own.]
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?
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...
That said, we haven't tested this with teams of more than two people, so we might need to change how this works.
It feels like forcing users to learn a new language is a step too far here - I can't imagine a ton of people are so eager to build slackbots that they're willing to give up all their existing tools.
It's so easy to bemoan the control we lose (a major problem given our existing workflows) and have no use for the functionality it confers (simplicity, batteries included, lack of yaks that need shaving).
A really great new idea should empower millions of people completely unlike us to build software.
A language with only a single, open-source implementation controlled by a single vendor, like Go or Erlang, has slightly more risk, in that the single vendor could choose to take the language in a direction you don't like. However, even if that were to happen, it's open source, and the community can maintain it as long as there are enough users.
A language primarily controlled by a single entity that is actively hostile towards openness, like Java, is a little more risky yet, but even so, with enough users it becomes safe enough.
A language that's not open at all, like Mathematica or F#, puts you entirely at the mercy of the company that controls it... but if that company is big and has a good track record, it's still at least a reasonable trade-off.
Now, if something is created by a startup that has at best even odds of being around in five years... you still might take that risk if the technology was open, and you could run it yourself when they close up shop, like, say, Meteor or MongoDB. These are decisions that one is rather more likely to regret, but it's not hard to see how people make them.
However, if a new company introduces a new language that is also it's own walled-garden deployment environment, which you can't run on your own systems, which has no demonstrated history of doing anything well, and which is not open source, anyone choosing that language for a project that's expected to be around for a while would have to be either inexperienced or just plain crazy.
...oh.
;-)
Why wouldn't developers building back-ends just continue building back-ends in their preferred language and environments?
I type this as I'm tabbed out of Visual Studio creating API back-end in C# .Net Core right now. It's easy.
With this I'd have to 1) Learn a new language 2) Learn a new GUI interface for that language 3) Lock myself in
1) deploy your code 2) deploy your datastore 3) manage your datastore 4) shard your datastore 5) deploy your infrastructur3
Among many other things. The value of Dark Lang lies not just in the programming language and the IDE, but in the holistic experience for backend development it provides, since _all_ of the overhead required to actually move to production and make new releases completely vanishes.
Reducing the entire idea of darklang to "vendor lock in, lol naw" is missing the point, but also kind of nailing it.
By reducing options, you gain the freedom to focus on the problem you set out to solve in the first place.
Of course, it's not a silver bullet right now, but it's an interesting bullet nonetheless.
Or you can just get a cheap host and throw a table into a SQLite database (a file) and use JavaScript.
I'm probably not the target audience.
Well with what I saw on the videos if it's possible to extend Dark inside itself - yeah, I would prefer this over Emacs
> I’ve been lucky enough to be an alpha user of Dark. As a non-engineer, self-taught coder, I was able to build and deploy the back end of a react app, including a Stripe integration, faster on Dark than anything else, including Heroku + Flask. Real game changer.
Can anyone let me know what an engineer is again?
I know someone who, through using a lot of Goole Sheets, managed to re-invent SQL joins. She'd never identify as an engineer, but she did manage to get some software to accomplish her task.
Look at how many acronyms are in the intro video alone ... the narrator says "we'll just use REPL ...". Does someone playing around in Google Sheets say "yes, REPL, great choice!" or do their eyes glaze over?
What about when you tell them they have to learn "Darklang"?
But thin clients did win, we just call them web apps now, which we run in thin client emulators we call “browsers.” And I recall incumbents scoffing at web technology back then, too.
> A really great new idea should empower millions of people completely unlike us to build software.
I agree, but I don't think this is it — it doesn't feel like the SquareSpace of backends. It requires a bunch of pre-existing knowledge (requests, databases etc.), and its language doesn't have the simplicity of most starter languages.
This ain't exactly new, though. The value proposition here is very similar to that of a lot of existing cloud-hostable middleware products, e.g. Dell Boomi, albeit perhaps targeted at a different audience (that is: adapted to actually building backend systems instead of tying a bunch of existing systems together).
Boomi, however, is a flaming pile of trash (and I say this as someone whose dayjob is - among numerous other things - to maintain a bunch of Boomi processes); the version control sucks (and you have to use its version control, because what's Git or Mercurial or Fossil or even CVS, amirite?), it's way overpriced, it's a pain in the ass to do simple things with it (unless there's already a shape defined for the exact thing you're trying to do, or it happens to be something conducive to JS or Groovy scripting; the JS/Groovy escape hatch is the one good thing about Boomi), and you're permanently locked into it unless you want to completely rewrite everything in a different language and for a different platform.
If Dark can address those four problems - namely, by supporting external version control systems (Git at the minimum), having a sane price point (and not gouge users on connector licenses), making it easy to do easy things and reasonable to do hard things, and providing some pathway to escape vendor lock-in (e.g. import/export from/to a self-hosted option, preferably an open-source one) - then I could see myself at least trying it out. As it stands, though, there's no indication that Dark doesn't have the same exact crippling problems Boomi has (made worse by forcing a specific new language instead of relying on existing ones).
Do you mean, like, some sort of "silver bullet"?
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 :)
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.
> 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.
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).
It's as if I wrote "developer deployment".
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!
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.
No thank you. There's zero chance I'm going to learn and build anything in a language owned by a startup.
Sure: hobby projects and experiments.
I would not include "under-resourced teams" or "new startups" in that, without many strong qualifiers attached.
Personally, the only real user segment I see for a proprietary language built by a startup is hobbyists and language enthusiasts.
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.
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.
/s
#HNPropaganda
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.
We plan to support enterprise users too, but that's a little bit down the line.
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?
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.
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.
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.
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.