Show HN: Darklang - <AUTHOR> https://medium.com/@darklang/unveiling-dark-e0be6f1e0b06 <comment><USER5> 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.

<comment><USER6> So, no Rust or Go for you?

EDIT: I got it, I got it. Go has multiple implementations. Bad example.

<comment><USER5> Go - OK, it has one implementation (open-source), but it's backed by one big player (Google) and used by many others... also the simplicity at core design decisions sound like the kind of choices that would make an alternative compiler easier to implement than for other languages

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!

<comment><USER7> > with maybe a not high enough bus factor

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.

<comment><USER8> I generally read bus factor as having few who fully understand a codebase written in said language so if they were to be hit by a bus you'd lose ability not easy to hire.

<comment><USER8> [0] [https://en.wikipedia.org/wiki/Bus_factor](https://en.wikipedia.org/wiki/Bus_factor)

</comment></comment></comment></comment></comment></comment><comment><USER9> 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.

<comment><USER10> I agree, but how did it get so many upvotes? there's a huge disconnect between most top level commenters not liking it and the aprox. 350 karma.

I'm a new user so this is very confusing to me.

<comment><USER8> HN has a much broader population than individual comment threads might indicate.

</comment></comment></comment><comment><USER11> 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!

<comment><USER12> I am the complete opposite ... I'm in my 40s and dark modes are the only thing I can use.

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

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

</comment></comment></comment><comment><USER14> 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.

<comment><AUTHOR> 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 :)

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

Was very excited to see that.

</comment></comment></comment><comment><USER16> 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.

<comment><USER17> It seems that darklang goes one step further than your average faas: every new code you write is deployed as you write it without any explicit deploy action, but the design of the Lang/IDE ensures new code is always behind a feature flag that makes that new behavior visible only to you until you decide to expand the audience until eventually reaching 100% of the users.

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.

<comment><USER16> That progressive deployment is neat and all, but I'm not convinced that's a problem that actually existed. More importantly, I'm definitely not convinced it's a big enough feature to drive a significant amount of developers to sacrifice the ecosystem benefit from using a popular/open-source language to use a proprietary language that only works on one proprietary cloud host.

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.

<comment><USER17> I do share that feeling of unease that comes from non only from the lock-in but also from the departure from the text-only environment I'm so used and probably many other things that might be practical showstoppers for dark adoption.

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.

<comment><USER18> Does dark provide graphql api?

</comment></comment></comment></comment></comment><comment><USER19> 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.

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

</comment></comment><comment><USER20> 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).

</comment><comment><USER21> > 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.

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

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

</comment></comment></comment><comment><USER23> 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.

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

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

</comment></comment></comment><comment><USER24> 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.

</comment><comment><USER25> 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.

<comment><USER26> I'd be easy on them. They're still in their early days and want to exercise control over who receives the product. They probably have a good idea about who it's a fit for and who it isn't. Additionally, they probably want to be high touch right now since it is a whole new language + IDE + paradigm.

<comment><USER25> That may be fair, but I'm looking at the publicity for this and how they're "finally ready to show you Dark in action" which I guess just means... they have a couple demo videos and a private beta?

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

</comment></comment></comment><comment><USER27> 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 - <USER2> can't imagine a ton of people are so eager to build slackbots that they're willing to give up all their existing tools.

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

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

<comment><USER29> You're never going to wrestle anyone who experienced more than one tech hype cycle into such a stark vendor lock-in situation.

<comment><USER30> Yes, of course HNers are too wise to be taken by simple vendor lock-in!

        Facebook is closing Parse (parse.com)
        1202 points by theunquietone on Jan 28, 2016 | hide | past | web | favorite | 500 comments

[https://news.ycombinator.com/item?id=10991729](https://news.ycombinator.com/item?id=10991729)

...oh.

;-)

<comment><USER31> Is your point that they'll fall for it again?

</comment></comment></comment></comment></comment></comment><comment><USER32> 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?

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

</comment></comment><comment><USER34> 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?

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

<comment><USER35> > 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 :)

<comment><AUTHOR> Yes, that was a bit vague, sorry. What I meant was that our datastores are simple key-value stores at the moment.

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

</comment></comment></comment></comment></comment><comment><AUTHOR> 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.

<comment><USER36> I'm not sure if it is possible to give you any feedback on a closed source, invite only beta release but I do have a question:

Where is this hosted? Asking as an EU based user with GDPR requirements.

<comment><AUTHOR> We're not suitable for GDPR compliant applications yet. Now that we've got Dark actually working and shown to the world, we can start addressing it.

Currently hosted in GCP, US west.

<comment><USER36> Thank you.

</comment></comment></comment></comment><comment><USER26> 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.

<comment><USER12> This is an excellent analysis. I'm in that "far right" crowd so I am just not seeing this at all.

> I think that leaves you with the beginner crowd.

The problem with that, is ... well ... $$$.

<comment><USER26> I segmented the beginner crowd into two cohorts: side project folk and operations people ducktaping zapier+airtable, etc. The former does not have budget, the latter does (small businesses, early stage startups).

</comment></comment></comment><comment><USER37> 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!

</comment><comment><USER38> 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.

<comment><AUTHOR> Great suggestions, you'll be happy to know many of these are on the roadmap, and some have already been done!

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

Yup, planned

> 'diff' of a snapshot against another one is great.

Planned, but low on the priority list compared to the other stuff you've mentioned.

> Annotations

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

Planned :)

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

</comment></comment><comment><USER39> 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.

<comment><AUTHOR> We absolutely want everyone using Dark, so jacking the price like this would be extremely counter productive. If we did that, no-one would start using Dark after that.

<comment><USER40> Paul, the incentives you've put into place with this business will destroy your company. The proposition you've set up for developers is to build their buildings on land you still own. Established developers already understand the risks associated with this practice and will avoid you. At some point if anyone manages to build a business with darklang you will have them over a barrel and they will accept any cost increase below what it would take to switch away from using your platform. If you don't want to raise prices, your successors will.

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.

<comment><USER41> How is this different than running on certain cloud providers? For instance, a team can become deeply integrated with AWS services and then have trouble moving off if AWS starts raising prices.

<comment><USER40> AWS has competition, there is only one darklang. While it certainly would be difficult for most to move away from their cloud providers, it can be done. Almost all cloud providers are just packaging together open technologies with their established internal conventions. There is a world of difference between "this is a pain in the butt and we should have planned better" and "you have to start over completely from scratch".

<comment><USER42> And you can actually do a gradual migration from AWS to another service! With the fully closed system of Dark that seems like it would be difficult.

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

<comment><USER43> Congrats! I'm very interested to see how Dark progresses, and wish you all luck.

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.

<comment><AUTHOR> Thanks Steve!

</comment></comment></comment><comment><USER44> 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.

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

<comment><USER45> Who backs your infrastructure? GCP, AWS, Azure?

<comment><AUTHOR> GCP.

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

</comment></comment></comment></comment></comment><comment><USER46> 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?

<comment><USER47> It seems like an elm-lang for the backend -- by that, I am strictly referring to its all inclusive nature. You must use their language, build tools, infrastructure, et cetera. It even seems like you must use their in-browser IDE; though it has advantages they demonstrate in the first video in the post, you're sacrificing a _lot_.

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.

</comment></comment><comment><USER48> 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.

</comment><comment><USER49> 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.

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

</comment><comment><USER51> 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.

<comment><AUTHOR> We hope we can deliver!

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

</comment></comment><comment><USER52> 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.

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

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.

<comment><USER52> > "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."

I agree.

> "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?

<comment><USER53> To your last point, I think we'll have to wait and see?

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.

</comment></comment></comment></comment><comment><USER54> 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.

<comment><AUTHOR> We haven't started work on the built-in code review, but that seems like a cool idea, thanks!

</comment></comment><comment><USER55> 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...](https://medium.com/darklang/real-problems-with-functional-languages- efe668c5264a)

</comment><comment><USER56> 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.

</comment><comment><USER57> 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.

<comment><AUTHOR> Thank you for the kind words!

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

</comment></comment><comment><USER58> 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?

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

</comment></comment><comment><USER59> 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.

</comment><comment><USER60> I'm recalling the disaster that was the Parse framework. What makes this any different?

<comment><USER42> It hasn't had its _incredible journey_ yet!

</comment></comment><comment><USER61> 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?

<comment><AUTHOR> Error handling is done with Results and Options. We have a concept called an ErrorRail to simplify this: [https://medium.com/darklang/real-problems-with- functional-la...](https://medium.com/darklang/real-problems-with-functional- languages-efe668c5264a)

</comment></comment><comment><USER62> How does version management work with dark?

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

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

<comment><USER62> Thanks for the quick reply :)

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

<comment><AUTHOR> > 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](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.

</comment></comment></comment></comment><comment><USER63> 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.

</comment><comment><USER64> 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?

</comment><comment><USER65> 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?

<comment><AUTHOR> There aren't any languages that support what we need to do to solve the complexity we want to solve, including OCaml/ReasonML.

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.

<comment><USER65> I wish it was possible... as of now Darklang is mostly a language that only runs inside of Dark; that will be a problem in the future, but I understand that it's early days, and this was the sound decision to do now. Godspeed!

</comment></comment></comment><comment><USER66> I still remember how involved pbiggar thesis on compiling scripting languages such as php was

[https://paulbiggar.com/research/](https://paulbiggar.com/research/)

</comment><comment><USER67> 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.

</comment><comment><USER68> 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)

</comment><comment><USER69> 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 ;)

<comment><USER70> You might want to check out the serverless framework.

It's not remotely as unique as you seem to think, as even that framework is just one of many.

[https://serverless.com/](https://serverless.com/)

</comment></comment><comment><USER71> 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.

<comment><AUTHOR> When we were designing Dark, we wanted to be sure that it would actually be a thing that was safe to do, so it isn't just the same as hot reloads. Have a look at my video in the blog post: feature flags and versioning are a super important part of making this safe!

</comment></comment><comment><USER72> 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.

<comment><AUTHOR> The FAQ mentions security. We've been working with a security consultant for over a year. One of the reasons we're in private beta is that we need to get security right before we're generally available.

<comment><USER72> No, it does not. The word is not used anywhere on the page. There is a mention about privacy, PII, GDPR, Audit logs etc. and how that's not implemented yet. If that's what you meant, fair enough.

Still a bit scared for your initial beta users running their business on this as mentioned elsewhere.

<comment><AUTHOR> Oh, so it doesn't! Sorry, I meant to check before pressing send but got ahead of myself. We do quite a lot of security work - it's probably the one area we don't cut scope on. Someone reported a security bug today and we fixed it immediately.

<comment><USER72> Ok cool. Would maybe make sense to create a dedicated page for this outlining how you are keeping my data safe and unwanted people out.

</comment></comment></comment></comment></comment><comment><USER73> Ugh, why embed tiny videos that can't go full screen.

<comment><AUTHOR> Apologies, we don't know why this is happening - something with medium and vimeo. The videos on our home page go fullscreen: [https://darklang.com](https://darklang.com).

<comment><USER27> Looks like fullscreen from iframe embeds has been disabled by Medium.

</comment></comment></comment><comment><USER74> 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.

</comment><comment> d--b 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...

<comment><AUTHOR> Agreed about the 2D canvas; we've been cutting scope aggressively to launch this. We have a different metaphor in mind but it will take us some time to implement.

</comment></comment><comment><USER75> 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.

</comment><comment><USER76> 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?

</comment><comment><USER77> Am I the only one excited for this tool but with an actual programming language like Python instead?

<comment><USER78> Node-RED is kind of similar, but for node.js

</comment></comment><comment><USER79> 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!

</comment><comment><USER80> 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.

</comment><comment><USER81> How do I work with a team of people on something like this? How does it deal with conflicts?

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

</comment></comment><comment><USER82> So what kind of prototype do you have to have to get money to work on this for 2 years?

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

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

<comment><AUTHOR> 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 - <USER4> that's cool in Dark is enabled by the super tight integration between the language, editor, and infra.

</comment></comment></comment></comment><comment><USER84> 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.

</comment><comment><USER85> Congrats! I have tremendous empathy for your cause. Best of luck.

\- Austen @ Serverless Inc.

<comment><AUTHOR> Thanks Austen, that's so kind!

</comment></comment><comment><USER86> 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.

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

</comment></comment><comment><USER87> 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.

</comment><comment><USER88> [https://en.wikipedia.org/wiki/PowerBuilder](https://en.wikipedia.org/wiki/PowerBuilder)

</comment><comment><USER89> 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.

</comment><comment><USER90> 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

</comment><comment><USER91> Proprietary language. Proprietary IDE. Proprietary infrastructure. Each is required to take advantage of the others.

NO FUCKING THANK YOU.

</comment><comment><USER92> 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.

<comment><AUTHOR> Thank you, Jack!

</comment></comment><comment><USER93> 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

</comment><comment><USER94> >"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.

</comment><comment><USER95> Any chance of a link that doesn't require a medium account?

Sounds interesting from the comments.

<comment><AUTHOR> Hmmm, I wonder if it's a growth hack that Medium is doing. In incognito mode, i don't get the registration requirement. I'm told clicking "next" just gets you through it?

Sorry about this, I think medium wasn't the best choice for the blog.

</comment></comment><comment><USER96> This reminds me of Circa ~2006-2008 3Tera Applogic ... [https://en.wikipedia.org/wiki/3tera](https://en.wikipedia.org/wiki/3tera)

</comment><comment><USER97> 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.

<comment><USER43> "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.

<comment><USER97> It's development and not developers the thing being iterated, right?

It's as if I wrote "developer deployment".

<comment><USER43> Sure, both ways make sense. Do you measure the thing being iterated upon, or the folks doing the iteration? Since they're linked, both make sense.

</comment></comment></comment></comment><comment><USER98> 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.

</comment><comment><USER99> How do you do version control with this? or debug? or test?

</comment><comment><USER100> Reminds me of how I started with PHP.

</comment><comment><USER101> Like all projects hoping to reduce the complexity of software development, this will go nowhere.

</comment><comment><USER102> 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?

</comment><comment><USER103> 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.]

<comment><USER104> Good on you for the disclosure - but anything good you say is going to be ignored because of it :-)</comment></comment>


FDA grants emergency authorization for first saliva-based coronavirus test - <AUTHOR> https://www.rutgers.edu/news/new-rutgers-saliva-test-coronavirus-gets-fda-approval <comment><USER2> One of the bigger issues with COVID testing is false negatives. I wonder how an even smaller sample of viral load will fare with that.

<comment><USER3> High false negatives due to low viral load in samples would be problematic for diagnosis and treatment (except there is no specific treatment) but for public health purpose it is just as important to test for infectiousness. Imagine if we have a quick and easy way to self test saliva with high false negative rate due to viral load in the saliva, we can feel more confident about not infecting others through talking even if we can't be sure we are disease free.

<comment><USER4> Roughly 1/3 covid tests are falsely negative[1]. I'm not sure any have been cleared/approved by the FDA yet, but some are authorized for emergency use due to the circumstances.

 _" Testing was performed using the cobas(R) SARS-CoV-2 test. This test was developed and its performance characteristics determined by LabCorp Laboratories. This test has not been FDA cleared or approved. This test has been authorized by FDA under an Emergency Use Authorization (EUA). This test is only authorized for the duration of time the declaration that circumstances exist justifying the authorization of the emergency use of in vitro diagnostic tests for detection of SARS-CoV-2 virus and/or diagnosis of COVID-19 infection under section 564(b)(1) of the Act, 21 U.S.C. 360bbb-3(b)(1), unless the authorization is terminated or revoked sooner."_

[1] - [https://www.wsj.com/articles/questions-about-accuracy-of- cor...](https://www.wsj.com/articles/questions-about-accuracy-of-coronavirus- tests-sow-worry-11585836001?mod=e2tw)

</comment></comment></comment><comment><USER5> Ok, but:

1) how accurate is it?

2) how fast is it?

3) what equipment is needed to run it?

4) how robust is it to mis-handling?

<comment><USER6> 1) Presumably quite accurate considering that they received the FRA approval

2) Not clear for this one, but FDA authorized another lab to do saliva-based tests 10 days ago [1], and that test takes 24 hours.

3) It appears this test will be performed in the labs of a partnering health network, RWJBarnabas, and not for a wider distribution (from the article). Their goal is to get to tens of thousands of tests per day. They cover the New Jersey area. My guess is that you take the saliva sample, send it to one of their labs, and you get the answer in 24 hours.

4) Again, sufficiently robust so the FDA grants them the approval.

[1] [https://hitconsultant.net/2020/04/03/fda-24-hour-saliva- test...](https://hitconsultant.net/2020/04/03/fda-24-hour-saliva-test- covid-19/#.XpTGupp7mEI)

<comment><USER7> This test has not been FDA approved and only has an Emergency Use Authorization which does not test the efficacy as an FDA approval would. Even the linked article says "this test has not been FDA cleared or approved."

</comment></comment></comment><comment><USER8> As I understand it, the material supply chains for testing are limited in two key ways: The sample collection material (swabs), and the reagents that the tests need to function.

It sounds like this helps address the sample collection material supply chain, but how do we scale the reagent supply chain? The entire world desperately needs test capacity to increase by a factor of 10 or more, but is that actually possible?

Every single expert says mass testing is the only way to get ahead of this before a vaccine arrives, but I'm very worried that mass testing on the scale needed is simply impossible, which leaves us with only two choices - stay in lockdown for over a year waiting for the vaccine, or accept that herd immunity is the only way out, and do what we can to minimize the damage as the virus spreads, e.g. mandating masks in public, keeping the elderly population isolated while the rest of the population is gradually exposed,etc.

<comment><USER9> I am fairly confident your option A is absolutely not an option.

<comment><USER8> Yup. Year+ lockdown is not possible without reverting to a truly authoritarian government model.

So ..., if widespread testing is not available, we don't have a choice, and have to manage the flow of bodies as we reopen society in stages.

<comment><USER9> As I understand it, the goal of "flattening the curve" was never to reduce the overall number of people that contract the virus. Which, to me, means that neither herd immunity nor hiding were ever really the plan for covid. Giving manufacturers the time to shift into overproducing PPE and researchers the time to develop/test short term treatments so the hospitals could shift into treating it as a part of routine coverage. I don't think you need herd immunity to be prepared.

I can't tell if that's what you meant by "manage the flow of bodies." As I understand it, lots of the deaths have been a result of timing and lack of preparedness, not necessarily overall lethality of the virus itself.

<comment><USER10> The virus has a reported 12-20% hospitalization rate. Once they overfill in any given region, the death rate and the hospitalization rate become the same.

We can argue about small percents for CFR, which only apply given healthcare resources, but if we do not stay under the hospital thresholds by some means, we get a catastrophic death rate that is comparable to the 1918 Spanish Flu, which had something in the neighborhood of a 10-20% fatality rate.

Unless we somehow find an astonishing number of people are true asymptomatic, this will hold. The Iceland survey does not yet count, as they surveyed and tested and found a goodly number of people positive, but we haven't seen the followup of how many develop symptoms where it can take 11.5 days in 97.5% of all cases to develop.

So, we are in a Class 5 pandemic, one of similar severity to the 1918 Spanish Flu. We just have oxygen and ventilators now for pneumonia. Once we run out of those resources, we get to "manage the flow of bodies". If we get the infection rate of the 2009 swine flu at 60.8 million cases, we stand to lose up to 7 million lives in the United States alone.

<comment><USER9> I would challenge most of your numbers but I understand your sentiment.

</comment></comment></comment></comment></comment></comment><comment><USER11> Perhaps silly to ask, but: why does the FDA regulate this?

It's not a food, it's not a drug, if it's purely a saliva swab it is non- invasive — so where does the FDA come in?

In a university context, there is often a blanket IRB exemption for certain kinds of research where the risks are self-evidently minimal, such as taste tests.

If the FDA's role here is to provide a stamp of approval indicating "this test 'works' according to an accepted standard," then I would think something closer to how food supplements are monitored would be a better fit, for example, the test could come with text saying "this language has NOT been approved by the FDA" or equivalent for approval.

I am failing to see risks here besides the risks of misdiagnosis, but I just didn't think it was the FDA's mandate to approve or not approve based on efficacy.

<comment><USER12> The FDA maintains it is within the administration's purview to regulate tests --including laboratory-developed tests, or LDTs--although the current state is that the FDA often elects to exercise its discretion to permit LDTs sans regulation-as-medical-device provided the lab adheres to CLIA and has any required accreditation in order.

Dietary supplements are more or less unregulated, as long as they don't claim to diagnose or treat a disease. This is not exactly a great situation for consumers. Also, the current administration has taken sort of a "safety over efficacy" tack, but I don't know, therapeutic failure seems pretty bad, so maybe there isn't that much meaningful difference between the two.

Back to the testing concept, if not for the FDA to come down on operations like Theranos, then who?

<comment><USER13> > if not for the FDA to come down on operations like Theranos, then who?

Theranos was committing fraud - selling investors a product that didn't exist. You don't need the FDA for fraud to be illegal, ordinary civil and financial law covers this.

If Theranos _weren 't_ defrauding investors and actually had a product that worked, it'd be up to the market to determine if that product were worth paying for. Since different customers have different risk profiles there's no one-size-fits-all best balance between safety, efficacy and cost - let people buy different products that choose different tradeoffs.

<comment><USER14> Theranos was in fact testing people, who received both false negative and false negative results.

From the article I link below:

> At its height, Theranos operated 40 "Wellness Centers" in Walgreens stores > in Arizona and a single location in California, which were the source of > much of its revenue. USA Today reported the metro Phoenix-area centers alone > sold more than 1.5 million blood tests, which yielded 7.8 million tests > results for nearly 176,000 consumers.

[https://www.darkdaily.com/previously-high-flying-theranos- pr...](https://www.darkdaily.com/previously-high-flying-theranos-provides- clinical-laboratories-and-pathology-groups-with-valuable-lesson-on-how- quickly-consumer-trust-can-be-lost/)

</comment></comment></comment></comment><comment><USER15> Anyone know what mechanism this test uses? I didn't see it in a skim of the article.

Saying this because viral load seems to be peaking in the upper respiratory on _day one_ of symptoms, and quickly decreasing from there as it moves to the lungs.

But maybe if this is an antibody test, that won't matter?

<comment><USER16> The decisive absence of this information in the article leads me to assume that it has all the same properties (and reagent demands) as existing PCR tests, just aimed at a simpler sample acquisition process. If there were further advantages they surely would have written about them. Perhaps the RNA signatures the test is looking for are shorter or something like that, to tune the test sensitivity, but I could just as well imagine that it's purely a paperwork difference. Wasting test capacity on samples acquired in a non- approved way would be reckless when done at grassroots level, but if the manufacturer can clear a relaxed sampling process it can be a valuable improvement.

Paperwork-heavy engineering disciplines are full of examples where the exact same hardware got re-rated to higher performance levels once the necessary experience was accumulated. It's not necessarily a bad thing.

</comment></comment><comment><USER17> Does this mean the fda actually tested it or is it just the official stamp of not being banned (yet)?

</comment><comment><USER18> Sensitivity and specificity rate of this test?

</comment><comment><USER19> Will this be an antibody test?

</comment><comment><USER20> Oof, Rutgers miswrote the entire article. Flagged for being extremely misleading on Rutgers' part (OP only quoted them).

This isn't an approval, it's an Emergency Use Authorization. They're completely different. [https://www.fda.gov/emergency-preparedness-and- response/mcm-...](https://www.fda.gov/emergency-preparedness-and-response/mcm- legal-regulatory-and-policy-framework/emergency-use-authorization)

An EUA is specifically to permit unapproved uses _in exigent circumstances only._ Approval still requires the full workup: [https://www.fda.gov/news- events/approvals-fda-regulated-prod...](https://www.fda.gov/news- events/approvals-fda-regulated-products/about-fda-product-approval)

\---

@dang, is there value in changing the title from its current state ("FDA Grants Approval for First Saliva Based Coronavirus Test") to "FDA grants Emergency Use Authorization for Saliva Based Coronavirus Test"?

\---

Edit 2:33pm EDT: calling Rutgers to clarify.

Edit 2:36pm EDT: the appropriate contact for the article has received my message and (as best as I know) is clarifying the release.

Edit 3:01pm EDT: thanks for changing the title, dang!

<comment><USER21> Is it misleading, or are they just using lay terminology in a press release aimed at lay people?

They were approved to begin emergency use without the usual steps to "FDA approval", correct?

<comment><USER16> Easy english could be a reasonable excuse if the precise terminology would be indecipherable to laypersons, but I don't see that here. "FDA grants emergency use authorization [...]" would give the exactly same diffuse "they allowed something on some level" information to people like me who are unaware of the specifics, but without ruining it for those in the know.

<comment><USER21> I mean, the subheadline is, in large bold text:

> Emergency use authorization granted for new biomaterial collection approach

They're not hiding anything here, as far as I can tell.

</comment></comment></comment></comment><comment><USER22> Any of these companies involved have tickers ?</comment>


Ask HN: New landing page of our product. Do you understand what we do? - <AUTHOR>

Hello HN,
Today we completely changed our landing page. Do you understand what we do?
Here is the link: https://staply.co
Thanks! <comment><USER2> My thoughts...

This seems to be basically just a chat server (with message attachments). The notebook style UI is cute but doesn't seem to mean anything. Is there anything here I couldn't do on Skype?

What platforms does this support? There's a picture of a laptop, a tablet, and a phone. They all look vaguely like Apple products, so maybe this is Mac/iOS only, or maybe that's just the icons you happened to have on hand. If it is Apple only, that kind of platform limitation will be a big (almost certainly fatal) handicap to collaboration software. If it isn't, you need to make that clearer.

A hamburger menu (traditionally used to mean "everything else") on the left, and an ellipsis menu (also traditionally used to mean "everything else") on the right? Oh dear.

</comment><comment><USER3> I think calling it a "notebook" is a misnomer and takes away from the collaborative and organizational aspects. Notebooks are physical, personal, and the word doesn't symbolize organization or value in my mind (as a once student who has many notebooks scattered about that I never use.)

Something like "agendas" would be more enticing, but I personally would use the headline as an informative statement to what your service does best like "Collect our thoughts" or "Collect and Collaborate."

<comment><AUTHOR> Hi, Thank you very much for the feedback. We really wanted to differentiate from messengers. Should definitely think more about that.

</comment></comment><comment><USER4> My raw reaction (emphasis on raw):

looks like Quiver

is it for code?

"collaborative notebooks" ok so it's for writing

"get started today" and do what?

ok it works great on mobile and some other devices

 _eyes to image_

you can talk, cool and you can link stuff and add files

so it's not a notebook but a chat?

 _eyes to "block-lower"_

I can create notebooks... what the hell are notebooks?

store stuff

stay up to date... okay? it tells me the current time? it's a clock

 _eyes to footer_ nice, it's made with love... I think...

 _click on heart_... uh, ok, I guess it's love. Perhaps.

<comment><AUTHOR> Wow, nice layout. Raw feedback is always good, thanks.

</comment></comment><comment><USER5> Clickable link: [https://staply.co](https://staply.co)

</comment><comment><USER6> Like etherpad, but social?

<comment><AUTHOR> I never used etherpad before. From what I just learned Staply is more focused on sharing content and less on the text editing.</comment></comment>


Billable Hour as SAFE (Simple Agreement for Future Equity) - <AUTHOR> I am about to do some contract development work for a seed stage startup I would love to get on their cap table eventually. Should I simply ask for a SAFE that is based on my usual billable hour to other client? <comment><USER2> I don't know what is going around again, but this has been coming up a lot. Let me give my opinion having been here in the past.

Only take equity if both of the following are true:

1\. You have enough money to live on and not getting income from this company will not affect your personal or professional life in one bit.

2\. The company has proven some value that you see as a reasonable risk, and accept that you will likely not see the upside for years, if ever.

The first issue can sometimes be offset some by taking equity as a difference for a lower billable rate. e.g. you still bill and get paid for $40/hr, but your normal rate is $100/hr so the difference is granted in equity.

The second issue can be mitigated over time as well, but always assume the most likely scenario. They either will die and you have nothing, or it will take considerable time for things to mature to where the equity is convertible into anything of value.

Taking equity this way means you need to be very intelligent about dilution, liquidation preferences etc or your "time" can become worthless even if they are successful. Safest way is to make the equity convertible for you at the next round, unless you opt out, but even that is no guarantee you'll get cash -- also the upside is limited since your risk is also somewhat more limited as is fair.

Last point, this is a valid way to work and there is absolutely nothing improper with the concept. In fact equity gives you skin in the game so you can win on the upside part of the play. But just understand with that also means you need to accept a lot of risk and realities. I have done this (almost always fails), I have also done a similar method at profitable companies when I have promised my work (or my team in the past) in exchange for a percentage of the upside of what I/we can produce (this is a super hard sell a lot of times and you can get burned as I did a couple of times). I did win on a couple of upside plays for profitable companies, but the startup equity has never paid off in any material way.

</comment><comment><AUTHOR> Thank davismwfl for the quick response! Can you point me to the right keyword I should look for past discussion like this ?

I love your idea about doing 40/60 split to ensure some kind of income. So assuming 40 is the hard cost that you must pay yourself while 60 is the opportunity cost by spending time with another billable client.</comment>


An MVP in Less Than a Month: The Landing Page MVP - <AUTHOR> http://www.ombulabs.com/blog/lean-startup/mvp/the-landing-page-mvp.html <comment><USER2> A little light on detail, but it did talk about something called 'Lean Canvas' which I was unaware of. After a bit of research, Lean Canvas is definitely something I'm going to be adopting in my work-flow. Thanks!</comment>


Pakistan airline admits taking extra passengers in aisle - <AUTHOR> http://www.bbc.com/news/world-asia-39081476 <comment><USER2> Years ago I had a conversation with a Pan Am flight attendant who worked a Teheran evacuation flight after the Pahlavi "dynasty" was deposed and the US nationals had to clear out of Iran quickly. She told me they filled their Boeing 747's aisles with people sitting on the floor.

She told me it's a calculated risk to put passengers in the aisles.

But, the captain of the flight knew exactly what was going on and made the decision to proceed. It sounds like this PIA flight crew concealed their overloading from the captain. THAT is a very serious infraction indeed.

<comment><USER3> In 1991, Israel evacuated 14325 Ethiopian Jews in 36 hours using 35 aircraft, with up to 1122 passengers on a plane [1]. It's such an impressive feat, those must have been some of the best pilots, to be able to fly such an overcrowded plane (even though they stripped the seats from the planes it was probably still overloaded)

[1] [https://en.wikipedia.org/wiki/Operation_Solomon](https://en.wikipedia.org/wiki/Operation_Solomon)

<comment><USER4> Not to knock the accomplishment but to be fair, the passengers were really light (confirmed according to article).

This comment sent me on a journey to find obesity data on Ethiopia and I found this ranked list that tied back to the CIA factbook as source and places them next to last (currently): [http://www.indexmundi.com/g/r.aspx?c=et&v=2228](http://www.indexmundi.com/g/r.aspx?c=et&v=2228)

<comment><USER5> Yeah, people are about the density of water but even an isle full of people isn't enough to be too meaningful to an airliner. The only times it may be a problem would be a short runway with a full fuel load at altitude. Airliner are typically flown well within it's performance limits. No airline would allow a flight plan that's close to the maximum performance of the aircraft since it would be a recipe for disaster in addition to hard on equipment.

Keeping the cargo secure and the wrench that extra passengers throws into emergency procedures is the real issue here.

</comment></comment></comment></comment><comment><USER6> I'm curious, on a scale of 1-10 how big of a transgression do people consider this to be?

When I was in India it was common to have people sitting in the aisles on long distance buses, trains, and theatre halls where fire evacuation plans were clearly not being followed. Agreed, planes are not theatre halls, but how severe of a breach in public safety is this? I think planes are a special case because they are such fragile systems, but it does seem like in the West we worship health and safety a little too much.

<comment><USER7> I would give this incident 1/10\. It's mind boggling to me why people think this is a big deal.

Speaking of theatres and other venues, overcrowding them is way worse. For once, they actually do catch on fire much more often then planes fall from the sky. I consider overcrowding a theatre criminal negligence, while I couldn't care less about (minimally!!) overcrowding a plane.

<comment><USER8> As it says in the article:

        Such an over-crowded flight would have caused
        problems in an emergency evacuation, aviation
        experts said, and passengers would not have
        had access to oxygen if it was suddenly required.

Additionally, you don't wear a seatbelt on a plane to save you from a crash, you wear it to stop yourself being injured during turbulence, or from injuring someone else by being thrown onto them. Obviously these people did not have seatbelts.

<comment> jon-wood I don't know if this is actually true, but I read recently that in the case of a crash the seatbelt isn't there to stop you dying, its to keep your body attached to your assigned seat so that you can be identified afterwards.

<comment><USER9> A myth. Sure, there are accidents where everyone perishes with or without seatbelt (and those make the headlines), but there are surprisingly many accidents where some or many people survive.

> "between 1983 and 2000, more than 95 percent of people involved in U.S. > plane crashes survived."

[http://abcnews.go.com/Nightline/story?id=2619382&page=1](http://abcnews.go.com/Nightline/story?id=2619382&page=1)

<comment><USER7> I agree that it is a myth, but that statistic is misleading, the definition used for "plane crash" is not one most people would agree with.

<comment><USER9> Fair enough, but bottom line is that lots can happen on a flight that might injure you, without necessarily being a prototypical plane crash. So better wear your seat belts.

Similarly, I take off my shoes during long flights, but make sure to have them on for take-off and landing, in case of evacuation.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Even if the safety issues surrounding people in the aisle were negligible, there's the Van Halen-M and M factor. If the airline is ignoring this rule, what other rules are they ignoring?

<comment><USER11> Don't give them ideas - now they're going to throw out all the green passengers!

</comment></comment><comment><USER12> I took a flight from Yekaterinburg to Moscow in the 90s, and there was a delay while they added some of the chairs back to the plane because they had been moving some furniture in the cabin. I mean, like dressers and dining room tables and such.

heh...Aeroflot

<comment><USER13> Aeroflot in the 90s: you sir or madam are a hero for patronizing this airline

</comment></comment><comment><USER14> something that's being ignored, there are three possibilities, and its' never PIA that it will prefer it let alone advertise aisle... It's about 2.30 hr flight from Karachi to Medina.

1\. They are labors. and they can't miss the working day, they beg to fly in aisle

2\. 99.9% is above, other than some religious pilgrims, who have tight schedule ...

3\. PIA is dirt cheap for Karachi to Medina compared to _ahem_ Emirates

And it wasn't as uncommon than one could think, until recent times, few decades ago, it was pretty regular thing for Karachi to Lahore (local flight ... 1 hr approx) ... as people have to meet certain time to perform a job .... and back then there were no local carrier compared to dozen of them now, and about 20+ KHI to LHE daily flights.

It's terrible, but chalking it up entirely to PIA is bit unfair...

<comment><USER15> Thanks for making the connection. If these were Pakistani laborers, everyone's Westernized weight estimate of 100kg/person is about 50% too high.

</comment></comment><comment><USER16> It perplexes me that there are HN'ers who do not understand the risks involved. I can understand that the passengers involved do not have an alternative that ensures their short term livelihood and may not be aware of the risks. But seeing some of the HN'ers, who one would assume have a high school understanding of physics, have the same careless attitude is surprising.

<comment><USER17> They're just hacking rigid and outdated laws about transportation. Pakistan International is the Uber of the skies!

<comment><USER9> nice one :-)

</comment></comment></comment><comment><USER18> Record is 1,122 passengers on a 747 to Israel [https://en.wikipedia.org/wiki/Operation_Solomon](https://en.wikipedia.org/wiki/Operation_Solomon) however that was extraordinary circumstances.

</comment><comment><USER19> I had that years ago (~1983) on a flight in China on CAAC. They put a couple of regular plastic chairs in the isle. CAAC didn't have the best safety record at the time.

</comment><comment><USER20> The flight in question went from Karachi to Medina carrying a total of 416 passengers, on a Boeing 777 with a total seating capacity of 409, including staff seats. !!

<comment><USER20> Were the passengers standing while taking off ?

<comment><USER21> All passengers were seated, airline non-revs were on portable jump-seats. Per Captain's discretion.

Maximum certificated escape capacity for a 777-300ER is 550.

<comment><USER22> What flight are you referring to? The article says extra passengers were allowed to stand in the aisles. It also says the captain was unaware until after takeoff.

</comment></comment></comment></comment><comment><USER20> [https://web.archive.org/web/20140802021208/http://www.boeing...](https://web.archive.org/web/20140802021208/http://www.boeing.com/assets/pdf/commercial/startup/pdf/777_perf.pdf)

<comment><USER23> ↑ Performance summaries of (some?) 777 models.

Not sure how's that relevant to this article, though...

<comment><USER20> Specifies passenger and cargo limits

</comment></comment></comment><comment><USER9> I had relatives in the airline industry, and the backronym going around for PIA (Pakistan International Airlines), which was quite crash-prone back in the days (30 hull losses, according to Wikipedia) was "Please inform Allah"...

</comment><comment><USER24> I've been on several overseas flights, including on US based airlines, where people were stuffed in the aisle. It seems to me to be a dangerous practice, but flight safety standards tend to be more lackadaisical outside the US.

<comment><USER25> Which US airline? There's a fat old FAA investigation and fine waiting for it when you report them (as you should!).

<comment><USER24> One of them was United. I did in fact report the incident to the FAA. Because the flight started and ended outside the US they had no jurisdiction and rejected my report.

</comment></comment></comment><comment><USER26> Isn't the captain responsible for checking the count of people onboard the aircraft before takeoff?

</comment><comment><USER27> Pretty much all transport vehicles in Pakistan do this; taking on more passengers than there are seats.

</comment><comment><USER28> What's the problem? I'm sure those passengers would rather stand in the aisle and get there on time than sit at the airport waiting for the next plane...

<comment><USER29> All passengers are required to have a chair for safety reasons. The chairs absorb a lot of impact in the case of a crash, and obviously they also have seatbelts which are important for safety.</comment></comment>