Show HN: Darklang

Is there an open source version of the language? ...bc I'm not touching a programming language with a ten foot pole if it hasn't got at least two implementations, and at least one open source :|

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.

They are 'allowing' people into a private beta of a programming language? Coupled with the fact it is not open source and has a bunch of fad ad-tech videos on the front page this is so many red flags.

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!

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.

I think the fact it maintains the "backend/frontend" separation makes it an awkward product solution imo.

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.

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.

I... don't want to be negative, I like new languages, but I can't help but feel underwhelmed. I guess I just don't understand how this meets the goals that were talked about in previous posts (or how it allows development "without accidental complexity"). I don't understand how this makes things easier and I guess when they claimed that deployment is super fast, I didn't realize they meant to infrastructure under their control. Besides the problems other people mentioned (vendor lock-in[1], non-open source programming language, few details on security), being limited to deploying on their platform, while not that unexpected and I certainly understand it, is not what I'm looking for in a programming language. I also don't really like the "HTTP is the FFI" aspect.. even in mainstream languages with fantastic library support, I find myself reaching for FFI (or libraries that themselves use FFI to wrap something else) surprisingly often. I guess this will be a hard pass for me.

[1] "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).

> Dark is a holistic programming language

No thank you. There's zero chance I'm going to learn and build anything in a language owned by a startup.

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 really want to try this, but when I put my email address in the website, it's making me fill out what I want to build with it and when I plan to ship and what's my favorite cloud platform...

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.

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.

First, thanks to Paul Biggar and the Dark team, for fighting complexity.

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.

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?

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.

What about transactions? Can I do joins?

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 had a chance to sit down with Ellen, one of the co-founders, and see an earlier beta. Congratulations to the entire team on this milestone; excited to see what you have in store. For context, I used to run a consulting company where I shipped a lot of greenfield software, especially CRUD MVP apps (which I think is a segment you're targeting). So I love folks trying to make this kind of work easier.

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 this is really cool. I love that they're writing a projectional editor and trying to make that work, because it's such an obviously good idea that should be more widespread. You can make major DX improvements by tightly integrating tools that are presently decoupled, and that seems to be the big idea behind this.

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!

Great stuff! My suggestion is to really leverage the possibilities opened up by the design choices that make Dark different - the structural editing and db/infra/editor integration. E.g.:

- 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.

We have no insight as to what the actual costs of running the infrastructure is.

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.

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 originally posted over at https://news.ycombinator.com/item?id=20985429, happy to answer questions here until the mods merge them]

Who is this for exactly?

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.

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?

Very exciting! This is great.

I'm having trouble understanding what this is. Is it supposed to be a competitor to Django/Rails/etc.? or a competitor to ansible? a competitor to docker? Something else?

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?

Brain dump: Looks very cool. From what I can tell...

pros:

* 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

cons:

* 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.

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.

This reminds me of the way Meteor was hyped up. Except now with vendor lock-in at the language level.

Conceptually, Dark is a game-changer. The question is: can you deliver on the details?

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.

Great to see you unveiled. Best of luck, i really look forward to having a real cloud-native way of developing software.

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.

Not sure I'd want to be writing services I depend on in a language whose priority is ease of prototyping.

In his post, Real problems with functional languages [0], 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.

[0] https://medium.com/darklang/real-problems-with-functional-la...

This may be too ambitious- throwing away control over code, editors, infrastructure, and having a sub-par offline experience seems like a dangerous move.

After watching both videos, Dark just looks like a more managed version of AWS Lambda, with a fancy proprietary editor.

This is really awesome and even if it doesn't "win" is a glimpse of a future where you can build a full scale tech company and nobody needs to know about things like k8s and "service meshes".

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.

This is really cool and very intriguing.

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?

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'm recalling the disaster that was the Parse framework. What makes this any different?

This is interesting. Congratulations on your hard work!

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?

How does version management work with dark?

Do I get access to the "raw text files"?

Ok so I’ve read the linked post (who still uses medium?? ;)) and the HN comments and I can’t think of a reason to consider this product.

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.

I’m not even sure if developers are the target audience here, but rather C levels who will dictate that the developers will use this to lower perceived costs and reduce theoretical development time. What could go wrong?

Paul, first of all kudos on what your team has accomplished so far. And plenty of respect on having the courage to attempt a leap on how backend technology works.

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?

I still remember how involved pbiggar thesis on compiling scripting languages such as php was

https://paulbiggar.com/research/

Well I watched the videos, honestly what he is talking is exactly all the problems I've been facing for the last 7 years working on web backends. I wish you well and hope I can use Dark at work one day.

Maybe it's just the color scheme, but a lot of that UI reminds me of the Kickstarter-era demos for Light Table (in particular, the "lots of windows each with one function inside" pattern)

Dark looks really cool. When I heard about it before my initial reaction was a huge "nope", but after watching the videos I'm curious to try it out.

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 ;)

I guess if you wanted to do something similar but open, you can edit code directly on your server, use erlang/elixir's hot reloading, and call it 50ms deploys.

What scares me is that their whole site doesn't mention the word "security" once.

Also "testing" is in the FAQ as a "we're working on it"-item.

Ugh, why embed tiny videos that can't go full screen.

I don't like the arrogance of such projects. Plus, when I decide to invest into a technology, I do due diligence, and I'm not impressed here.

This would be awesome if node wasn’t around. But I feel like this is a 2D canvas on which you throw node functions.

Node+express is already simple enough...

Why invent an entirely new language instead of using an existing popular one such as JS or Python?

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.

I can deploy a Docker-based node backend with basic functionality from my phone's ssh client in five minutes.

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?

Am I the only one excited for this tool but with an actual programming language like Python instead?

Congrats on the private beta launch! I look forward to doing some tire kicking when it's in open beta ;)

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!

There are a lot of interesting ideas here. They're two years in, I'd guess perhaps one or two years from the larger vision of supporting real applications with lots of users.

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.

How do I work with a team of people on something like this? How does it deal with conflicts?

So what kind of prototype do you have to have to get money to work on this for 2 years?

I watched the videos and read the blog post. My response is equal parts amazement and skepticism. They poked fun at Kubernetes but what they have is something less transparent (more magic) and requires you to learn a new language and way of working. I'd be much more receptive if the option was there to peek under the covers and let me use my own language. I'm also curious how this would work in a CI/CD environment inside enterprises that require it. This all being said, I signed up for the beta and look forward to kicking the tires.

Congrats! I have tremendous empathy for your cause. Best of luck.

- Austen @ Serverless Inc.

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.

I fail to see how this is "a holistic programming language". From what I see, I would call it a SaaS for building APIs. Even if I were able to use outside the platform (which doesn't appear to be possible) it looks more of a framework or DSL at best.

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.

Really cool idea. Even after being a coder for 4 years, I still don't know internet stack and I'm greatly confused as to what backend/frontend to use whenever building a new product. Looking forward to using it as I have tons of small prototype ideas.

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.

How much will Dark cost? A >>We're still determining specifics, but Dark pricing will be based on how much infrastructure you use. We will be charging for traffic, compute, and memory usage, similar to other infrastructure. Dark will be free to start, and will gradually scale up with usage. We expect that our free tier will fully cover small projects.

ummm, no

Proprietary language. Proprietary IDE. Proprietary infrastructure. Each is required to take advantage of the others.

NO FUCKING THANK YOU.

congratz!

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.

not sure to which spectrum this falls into but: how different is this from firebase? or from any other backend-as-a-service? surely not something for engineers, but for business/product people that want to quickly bootstrap/hack their own backend/api

>"I can serve them whatever I want"

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.

Any chance of a link that doesn't require a medium account?

Sounds interesting from the comments.

This reminds me of Circa ~2006-2008 3Tera Applogic ... https://en.wikipedia.org/wiki/3tera

From the landing page:

> 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.

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.

How do you do version control with this? or debug? or test?

Reminds me of how I started with PHP.

Like all projects hoping to reduce the complexity of software development, this will go nowhere.

Use our lang! Then be locked in with us and pay! Yay! Why post marketing BS like this on HN, it's too smart a crowd to fall for that?

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.]