I lost my job for speaking up about women's rights - <AUTHOR> https://medium.com/@MForstater/i-lost-my-job-for-speaking-up-about-womens-rights-2af2186ae84 <comment><USER2> So, I support her right to have personal opinions about what constitutes a person of the female gender.

However, I also support her employers right to choose not to continue to employ someone who creates a toxic environment for other employees, especially when the only crime those other employees might have committed was to be born into a body of the wrong pairing of X and Y chromosomes.

</comment><comment><USER3> This is the first time seeing a TERF in the wild. I am saddened by her opinions. Having many trans friends, I believe that trans women are women too.

<comment><USER4> Do you also believe that people who think otherwise should be fired?

<comment><USER5> It seems she was fired for singling out and harassing a colleague, not for her opinions.

<comment><USER4> I can see no evidence that she singled out and harassed anyone. I've read several articles about this story, and they all mention that she was engaged in conversations on Twitter with various people, but nothing about "singling out and harassing a colleague". Could you share the source you got that information from?

<comment><USER5> From the article

>I've got a Q for my male twitter friends who have pledged not to appear on all male panels - if u were invited on a panel w Pip Bunce - one of FT's top 100 female champions of women in biz & another guy would u say yes or call the organisers & say sorry i don't do #manels?

>This question sparked several threads of discussion and I wrote about 150 tweets over the course of a week [...] The tone of these discussions was one of ordinary discussion and disagreement, but not long after I received an email from HR</comment></comment></comment></comment></comment>


OwnCloud "most secure open source file sync and share" - <AUTHOR> https://statuscode.ch/2015/09/ownCloud-security-development-over-the-years/ <comment><AUTHOR> Lukas also gave a talk about security at the conf: [https://www.youtube.com/watch?v=iUMsPppwIH4](https://www.youtube.com/watch?v=iUMsPppwIH4)</comment>


Python's Tornado has swept me off my feet - <AUTHOR> http://blog.perplexedlabs.com/2010/07/01/pythons-tornado-has-swept-me-off-my-feet/ <comment><USER3> I've been building a web backend for an iPhone app with it in the past two months. It's ideal for serving simple JSON requests that depend on other I/O stuff (like, contacting Facebook) - but it's got plenty of problems:

1\. The callback architecture. I simply freakin' hate the IOLoop. If you have just one asynchronous I/O operation, it's nice and easy. If you have one that depends on another, you have to wrap and curry a callback inside another one. Three? More wrapping and currying. I understand it's pretty much the same in many other platforms like client side AJAX these days. But man, this is Python and we DO have far better alternatives like gevent! You want the epoll() and kqueue() for performance? Fine. But it's Python and you can do it with coroutines without all that asynchronous event handling mess. And minus all those function wrapping and curry, I'm sure it can be much faster, all the while being easier to program with.

2\. The Facebook API in auth.py sucks. Just read its source code - it performs all requests by GET - WTF?! It can't even upload files unless you hack it (I've got a branch at <http://github.com/martinkou/tornado-upload> for that). And look at that _signature function under the FacebookMixin class - <USER2> doesn't even use session secrets? I'm not sure if I'm doing anything wrong, and Facebook API's docs don't mention that.. but in my testing, if I just use the application secret key all the way for the signature, Facebook gives me 104 errors. I had to hack it again to make it use session secrets in signing requests.

I don't really care about databases. But last time I checked, psycopg2 has a page telling you how to do async requests with gevent or libevent style coroutines. Tornado? Good luck integrating that with IOLoop and currying your callbacks. Sure you can still make it work, but it's unnecessarily complicated.

<comment><USER3> btw, it's possible to run Tornado on $NUM_CPU forked processes, have them listen to one port and so you wouldn't need nginx load balancing. Just read httpserver.py and you'll find a fork() there. The downside? Assuming you're still running your Tornado in your console and haven't daemonized it somehow - you press Ctrl-C, it exits (the console part, I mean) - and the $NUM_CPU children are still running. It's still not fixed today, and that doesn't really speak of quality.

</comment></comment><comment><USER4> I like Tornado, too, but here are a couple problems:

\- Hard to test, at least relative to Django. There's no built-in support, and being async makes it a little complicated. I have it working now, but it took some bashing and plenty of the mock library.

\- Lack of libraries for things we might want to do asynchronously. I can buy the argument that that's fine for databases, but for AMQP it's mandatory. The lack of a (working) Tornado AMQP library drove me to use Cyclone, which is a production-ready port of Tornado to the Twisted framework. Libraries ahoy.

</comment><comment><USER5> I had a few issues with Tornado when I tried it (back in February). They pretty much came down to two things:

1\. Database queries are not asynchronous. This is a big deal for most traditional web applications, and pretty much removes any benefit to using Tornado for them. Even for things that rely mostly on HTTP APIs, there's still a decent chance that you'll want to do authentication or something against a database.

2\. It was generally lacking a lot of the maturity and handy declarative syntax you can get with frameworks like Django. There was no ORM, form helpers, etc.

That being said, I really like the idea, performance was great and development seemed to be proceeding at a tremendous pace. The whole project is on GitHub and they seemed very willing to accept both bug-fixes and features.

<comment><USER6> re 1: Bret Taylor addressed db queries in the video on Tornado (the video is on Facebook, but I cannot find the link). If you run more than one instance of Tornado per core and you have a decent load balancer in front of the instances, then short blocking calls to the db work just fine. If your db calls are taking a long time, then it might be better to speed up the queries with caching or query optimization before worrying about async.

I like this approach because I prefer writing app logic in a straight line instead of in callbacks. The code is easier to understand and debug.

<comment><USER7> any recommendations re loadbalancers?

<comment><USER8> haproxy is brilliant.

</comment></comment></comment></comment><comment><USER9> I originally started unscatter.com on Tornado, then got caught up in the whole node.js spin. I started rewriting the application using node.js, then realized I was rewriting large chunks of Tornado in javascript. I went back to Tornado and have since put up something that works, very quickly.

I use supervisord for maintaining multiple instances of the application running. I found it the simplest way to manage it. It also gave me support for watching and restarting any instances that hang. I'm also using nginx to proxy. Currently I'm proxying 2 instance of tornado on a 4 core box. I'm also running mongodb, memcached, and nginx on the same small 256MB ram box right now.

In the future I could see me moving to node.js in the future, but for any application that requires working with multiple APIs, Tornado was a much better headstart, and the framework itself was more mature and ready to use than anything from the node.js camp several months ago.

Unfortunately no one is actively supporting the auth portion of Tornado, and it could use a maintainer. I'd set up, but with a newborn I'm not sure when I'll get to it. I'll be releasing ( and have already done so in the past ) any changes I make back to the Tornado project.

</comment><comment><USER10> I've been building things with tornado and pymongo for going on six months, absolutely love it. Light and fast, easy to customize, a solid auth system builtin, a realtime chat demo (!); keep things simple and it is a joy.</comment>


Sociopathic traits linked to non-compliance with Covid-19 containment measures - <AUTHOR> https://www.psypost.org/2020/08/sociopathic-traits-linked-to-non-compliance-with-mask-guidelines-and-other-covid-19-containment-measures-57773 <comment><USER2> Validity of these findings aside, a brief look at the headlines on the source site (psypost.org) suggests it may be a news outlet that plays to confirmation bias in order to generate shares on social media.

<comment><USER3> That's very well written.

</comment></comment><comment><USER4> Something stinks with this paper.

I don't personally think Black Lives Matter people are sociopaths for protesting during a quarantine, I don't think people trying to live their lives, and keep their business open, and feed their families, are sociopaths.

I would love to find out if this paper underwent peer review and see if it's reproducible before I believe it.

It could be bunk and agenda driven like the hydroxycholoroqunine paper which was retracted. [https://www.thelancet.com/journals/lancet/article/PIIS0140-6...](https://www.thelancet.com/journals/lancet/article/PIIS0140-6736\(20\)31180-6/fulltext#articleInformation)

</comment><comment><AUTHOR> research paper: [https://www.sciencedirect.com/science/article/pii/S019188692...](https://www.sciencedirect.com/science/article/pii/S0191886920305377)

</comment><comment><USER5> Isn't weird, readily-accepted, severe adherence to arbitrary draconian rules like indefinite house confinement, and the social shaming for any infraction, a form of sociopathy?

It's like a cult - people love the moral superiority they get from following rules(whether they're based in reality or not) and the permission it gives them to berate and abuse other people, who even so little as question the rules, and they categorize these people as agents of evil.

Social shaming for not following the pack in their agoraphobia? Isn't that sociopathy?</comment>


Is the Internet Making Us Stupid? - <AUTHOR> http://www.npr.org/templates/story/story.php?storyId=91543814&ft=1&f=1013

<comment><USER2> This is a summary of this longer article from the Atlantic Monthly: <http://www.theatlantic.com/doc/200807/google/>

The author is complaining that the internet is teaching us to skim more, and I'm not sure that's a bad thing. I don't do less involved reading than I did before the internet, but I do spend a lot more time skimming to find things that are worth reading.

He also claims that "Deep reading, as Maryanne Wolf argues, is indistinguishable from deep thinking." I don't find that to be true at all! If I'm reading something thought-provoking, I often have to stop reading to think.

</comment><comment><USER3> Reminds me:

[http://www.newscientist.com/channel/being- human/mg18624973.4...](http://www.newscientist.com/channel/being- human/mg18624973.400-infooverload-harms-concentration-more-than- marijuana.html)</comment>


Emberlight turning all lightbulbs into smart lights - <AUTHOR> https://www.kickstarter.com/projects/1375573028/emberlight-turn-any-light-into-a-smart-light

<comment><AUTHOR> OP here. I'm helping out w/ a lot of the BLE and mobile architecture. I'd love to hear what sorts of things the HN crowd would like out of a home automation platform like this. For example, we're considering developer SDK's, RESTful API's and all that good jazz. We've event tossed around the idea of using these as iBeacons. Let me know what you think and some hacker use cases you'd like to build would be great as well.</comment>


How Dark Deploys Code in 50ms - <AUTHOR> https://medium.com/darklang/how-dark-deploys-code-in-50ms-771c6dd60671 <comment><USER4> It's an interesting concept that flips many things on its head. We're getting some real hard-to-achieve benefits out of the box, while sacrificing a lot of things we used to take for granted.

One thing that I notice is that Dark requires a completely walled in environment to be able to deliver all of its promises. In reality, any real- life project has to interact with external services, legacy systems, or custom peripherals which are unlikely to be based on Dark.

How will Dark be able to handle such cases? Current tooling and processes are able to cope with such things through custom, hand-crafted, and as the article stated, often fragile, systems and processes. The are a pain, but they get the job done. They are very versatile by their nature. While they break more often that we would like to, they can be patched up well enough to band-aid over rough patches and adjust to surprising externalities. Dark seems to have one way of doing things, and I am curious how compatible that way is when it comes to interfacing with external systems.

<comment><USER5> It seems that Dark is designed to allow you to wrap external APIs in easy-to- use interfaces, so it should be at home as part of a larger SOA or ecosystem, of course with the caveat that it's still being developed. See the footnote at [https://medium.com/darklang/dark- residency-7dbc878a5f0a](https://medium.com/darklang/dark- residency-7dbc878a5f0a) .

<comment><USER6> Yes, that's exactly right. Dark speaks HTTP (and at some point, will speak GRPC, Thrift, etc) so you can access 3rd party services over HTTP (and wrap them in SDKs in the Dark package manager, same as on npm).

We expect we'll have some built-in support for common things (resizing images and videos, or generating pdfs for instance; we already support static assets on a CDN).

<comment><USER7> Hey Paul, nice to see you here on HN. Very promising start!

What's the best way to contact you? (I'm $HNusername @ gmail).

<comment><USER6> Thank you! I'm at [https://twitter.com/paulbiggar](https://twitter.com/paulbiggar) or firstname.lastname@example.com.

</comment></comment></comment></comment></comment><comment><USER8> First I've heard of Dark. The blog post is cool, but reading it I felt two main things: (1) no pull reviews would be terrible for a team, and (2) everything being instantly live in prod and automatically versioned etc sounds like a nightmare once you move beyond a simple program.

Reading on Darklang.com I see they kind of address this. The ecosystem they're building is training wheels for developers, a way to make "coding 100x easier."

I can see that working in a sense, and being an entry point that a lot of people use to make neat toys. I could even see it being a gateway that people use to get interested in and learn about programming. But I can't imagine wanting to build a business with more than one programmer, or any kind of scale on a completely black box system like that.

I will also say, there's a problem when it comes to entry-level systems, trying to teach people to code:

The struggle with the complexity is actually important. Dark isn't actually making all the work of building and running a web application go away, it's abstracting it all into a platform such that you can't see it.

Suppose a person gets into coding self-taught and learns to work this way. The knowledge isn't going to be very transferrable - ie when they look at other languages or systems they're likely to struggle with problems like "what does prod versus dev mean, I just want my program to run for the world..."

You usually move knowledge between ecosystems by translating "I did it this way in (toolset A), so what's the parallel in (toolset b)?" The more you have an idea of the underlying principles the easier this is to figure out.

That said, Dark certainly looks neat, and I imagine the implementation is quite cool.

The only other nit I'd pick is the name. To me, its not really a language, but maybe a development environment, or framework. I suppose it had a language in it, which I'd probably call DarkScript or something.

<comment><USER6> Author and Dark CTO here.

> Reading on Darklang.com I see they kind of address this. The ecosystem > they're building is training wheels for developers, a way to make "coding > 100x easier."

No no no no no. This is not what we're doing. We're building something for experienced software engineers. (New developers will be able to use it too and it should be much much easier for them than learning in other ways, but that's a secondary audience).

> Dark isn't actually making all the work of building and running a web > application go away, it's abstracting it all into a platform such that you > can't see it.

Some of it is being abstracted, but a lot of it being properly removed. Servers are abstracted, but almost all of actual deployment is actually being removed.

</comment></comment><comment><USER9> How does Dark handle code review?

Even if I was willing to accept the other tradeoffs that come with Dark, I'd want another human to approve my changes before that 50ms deploy to production kicks off.

<comment><USER6> The model is quite different to how people write code today. Instead of a process that takes code from your machine and sends it to prod (and thus has a lot of risk), you code in a sorta sandbox _in prod_. That is then enabled for users via changing the feature flag setting.

So to do code review, you write the code behind the feature flag, then ask someone for code review. (There's google-docs style collaboration, so they can see your code if you permit it). After code review, you can "merge" by toggling the feature flag, or changing the setting to "let 10% of users see this" or whatever roll-out strategy you want.

just safely. So you're writing code behind a feature flag (but "in prod"), but no users can see it.

<comment><USER10> So what protects you from accidentally doing "DELETE TABLE users" on prod?

In traditional design, there will be pre-commit code reviews and staging env with limited access. But looks like Dark get rids of all of this?

<comment><USER6> Good question. The answer to most questions like this is "it'll probably be the same as now". I know it seems like everything is different, but we're not really trying to invent much new stuff, only what's required to take stuff out. Whenever things from today work, we'll keep them. Core review, testing, ways of preventing deleting everything on prod; they're all valuable.

</comment></comment></comment></comment><comment><USER11> Sounds cool, seems like an interesting set of tradeoffs that nobody else has tried yet.

From what I've read so far it seems like Dark is a good fit for prototyping, experiments, and small products and teams that "move fast and break things". Would you consider it a good fit for large teams and applications, where different people own different components and reliability is the most important metric? A lot of the accidental complexity in the "standard issue" continuous deployment process detailed in the post is there to prevent accidents and enforce permissions.

<comment><USER6> Yeah, all this stuff is actually designed for large teams (though, it'll be a while before Dark is production-ready enough for them). CD matters because it allows you deploy in small chunks which is much less risk than deploying in big chunks.

The feature flag is a thing that you might not need if you're small, but it completely changes how large teams work. Same with DB migrations: if you have a small amount of data you can just do a schema migration and the locking wont affect you too badly.

We'll have a permissions model at some point that will take care of the ownership problem. We designed Dark to allow extremely fine grained ownership, for example allow a contractor access to a single HTTP route or function.

Overall, this is kinda similar to how we went about building CircleCI. We focused on good tooling for companies (eg parallelization and speed) instead of individual projects (eg build matrices).

</comment></comment><comment><USER12> Given how tightly coupled is Dark with its IDE and deployment environment, I'm interested in knowing how much VC money have they taken? What if they get acquired or simply shut down?

It looks like there won't be a migration path, and you'll need to rewrite your app from scratch using a different language. Again, it would be nice some transparency around how much VC money they've taken.

<comment><USER6> The sustainability of Dark is super important to use. We're not fucking around with customers' livelihoods.

For our early customers, we have a handshake agreement that we won't leave them hung out to dry. If Dark was to shut down, we would 100% make sure they had the time and ability to port their app off. There would be a time cost to them of course, so it's not perfect.

As we get closer to opening up to the public, we'll be doing a bunch of work on the sustainability question so we have good answers to the "acquired or shutdown" problem. We imagine a legal framework to protect customers, but haven't got the details worked out.

<comment><USER13> A legal framework doesn't help much in the "bankruptcy" case. Unless that legal framework means all IP becomes open source and people can self-host I guess.

</comment></comment></comment><comment><USER14> > When you write new code in a function or HTTP/event handler, we send a diff > of the Abstract Syntax Tree (the representation of your code that our editor > and servers use under the hood) to our servers, and then we run that code > when requests come in.

You can achieve the same result with PHP and FTP, however once you start adding unit tests and branching, that's when things start to take time.

Long builds aren't necessarily a problem if they give you enough in return.

<comment><USER15> I am not sure people are getting these results with PHP and FTP. Sure, the build time is zero seconds. But each page load takes 100ms because it's doing the same work over and over for every request. Yes, even if you cache opcodes. We have a legacy PHP app and an "echo hello world" request takes 100ms. An extremely complicated request then takes 102ms to process. It is shockingly slow, but it is not something you will notice unless you have a lot of instrumentation, so you might be lead to believe that your performance woes are caused by something else.

<comment><USER16> You must be doing something wrong. There's a lot of overhead for frameworks like Symfony, yes. But it's possible to write reasonably productive and modern website code where you can get sub 20ms responses (doing auth, fetching from db, processing and rendering html). I know because I've done that, on PHP 5.4.

<comment><USER17> Full checkout experience here, 18ms average. PHP 7.3, Symfony.

</comment></comment></comment></comment><comment><USER18> I'm getting _really_ tired of learning new languages / stacks every few months. I want _one_ language to write things in. It has to be a pure-OO language and right now that's ruby. I want to edit that code with _one_ code editor. Syntax awareness is a nice-to-have but not essential. At the moment my editor of choice is Sublime Text 3 but to extend it I need to write python which is unideal. When I start writing websites it'll be hyperstack.

Unless your new language can fix _all_ my issues, be open source, and be my One True Human Interface to All Things Machine, I'm going to keep building on ruby, with occasional bash / crystal / rust excursions for speed.

Is your language pure-OO? Do you have gradual typing? Does it run on a common VM? Am I going to have to rewrite everything I'd ordinarily bring in a library for? I can accept every single one of your claims but still not be interested in learning _a whole new stack_ because I can already deliver stuff quickly enough with the one I've been iterating on for a decade. Especially when it could end up orphaned in 3 years if it doesn't get enough adoption.

I'm not saying your holy grail can't be holy enough. But it has to be pretty darn holy.

</comment><comment><USER19> Syntax errors are the easiest errors to fix and almost never get into production.

Zero downtime deployments are very rare, and ads a lot of complexity, so it's a big trade-off, compared to just uploading the new code and restarting the service. And having the front-end deal with minor hiccups like service restarts, because users will have such issues all the time due to being on mobile networks, trains going through tunnels etc.

You can do as much testing as you want, both manually and automatically, but you still can't detect all issues as efficient as thousands of users in production. So just accept that there will be issues, and instead design your pipeline so that those issues can be fixed within minutes.

<comment><USER20> > Zero downtime deployments are very rare

What do you mean? Rolling deployments are a very basic feature of container orchestrators.

<comment><USER19> If you aim for zero downtime there will be a point where the complexity work against you. for example: load balancer goes down, corrupted state due to two different versions running simultaneous, a bottleneck causing congestion, etc.

My favorite "load balancing" for web-pages is using "DNS round robin" where you add several A records, and the browser automatically try another IP if the request fails.

<comment><USER21> The browser does _not_ try another IP if the request fails; it tries the first one only (the DNS server chooses a random order for the response), unless browsers have changed their behavior recently.

DNS round robin is not failover. If one of your four A records points to a dead box, 25% of your customers are SOL.

<comment><USER22> [https://en.wikipedia.org/wiki/Happy_Eyeballs](https://en.wikipedia.org/wiki/Happy_Eyeballs)

Browsers even try other IPs and alternate between IPv4 and IPv6 before the connection is established.

<comment><USER21> I know all about this, but most websites only support v4, and I don't think this is used in any way for choosing which A record to use.

<comment><USER22> Most websites don't have redundant servers but its still there and used by a lot of big sites.

The whole point of it is to connect to multiple A and AAAA records with a very short delay (250ms in chrome). The browsers use poll to get notified about the first established connection and then use it. So if one A/AAAA records IP is unreachable or slow it will use a another one. There will be no fallout (except maybe for clients that don't use something like happy eyeballs, but any browser does that) if you have multiple A/AAAA records and one of them is down.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> Hrm...we don't deploy code in _to prod_ in 50ms, but we certainly deploy to dev/staging/testing in <1s, and promote to prod once we are 100% sure we want to do so. We use the boring, industry-standard tooling and process everyone else uses (Jenkins, k8s, Ansible, nothing bleeding edge). I'm unsure what advantage their product has that makes it stand out among the battle tested tools already in use. Would someone elaborate?

disclaimer: working for a l2 network provider, and a mistake costs us infinitely more than an _" Oh we're sorry!"_ can fix.

<comment><USER24> The point is all that stuff (jenkins, k8s, ansible) is accidental complexity that, I presume someone at your company has-to/had-to think about. I think Dark's angle is it's stuff you shouldn't need to think about in order to solve the actual problem, and removing as much of that as possible is better.

<comment><USER25> Okay, I mean conceptually cool, but it's not like an existing startup gonna throw away all their code and rewrite it to save on dev-ops time.

I guess the value prop is that if you're starting from scratch, and want to write _your whole app_ in Dark then you can avoid hiring a dev-ops engineer and iterate faster?

Seems like a stiff trade-off. If it's an interpreted language you're coming from, setting up envs can be < 30 secs anyways (and same with prod deploys), so that's faster than you need.

If it's a compiled language you're coming from (e.g. scala/c++) then it's likely Dark may not match your needs.

Plus I guess this assumes every team in your company is using only dark? Like what if it's a SOA and a full environment has a node component?

</comment></comment></comment><comment><USER26> How coupled is Dark with the Dark language? I understand that the purely functional nature of the language makes its integration with the rest of the platform easier, but the blog post doesn't go into much detail about that. What would it take to integrate Dark with: a) another (existing) purely functional language, and b) a general-purpose language, e.g., Go? Could a code intelligence tool like Sourcegraph help?

<comment><USER6> Extremely tightly coupled. That's kinda the point "what can we do if we don't have to couple dark to anything else" (eg editors, other languages). I can't imagine how you'd couple Dark to another language, but I also don't see the point?

<comment><USER26> Thank you. My point was risk mitigation, which I discussed in another reply (which you answered: [https://news.ycombinator.com/item?id=20399267](https://news.ycombinator.com/item?id=20399267) )

<comment><USER6> Yeah, the bigger picture here is that there's a ton of valid reasons why people can't use Dark right now. Of course there is, we're a small team with an early product. Once we show that this is really a better/faster/easier way to make backends, then we can start working on handling the risks and constraints of more teams.

<comment><USER26> That makes sense. It does look like you're very close to that first objective though. Congrats! Your blog post very clearly describes what Dark actually is (which was still unclear before I read it).

</comment></comment></comment></comment></comment><comment><USER27> Twenty years ago, deployment of a new version of a web app means FTP'ing a new php file to the server.

<comment><USER28> Which wasn't a bad thing after all. I've had more incidents with deployment pipelines than with the actual code.

<comment><USER29> Mostly because people forget that pipelines are code and need documentation, tests and software engineering practices just like any code.

</comment></comment></comment><comment><USER30> I've been seeing a lot of talks about darkland and can't find a single example of code. Can someone show me at least how does it look like?

<comment><USER31> from darklang.com:

"Dark is currently in private alpha."

That's probably the primary reason why there's little to no info.

<comment><USER32> They are leaving us in the dark, so to speak.

<comment><USER33> It feels like an ICO launch in that regard. Kind of exciting!

</comment></comment></comment></comment><comment><USER34> Back in the day (early 00s), you could do something similar with ZOPE: develop on a production server, in a private session and you could mock about with your version of the code, and when you were satisfied push it through for everybody else. This was because the database that was holding the users, permissions, ... was also holding the code. It was lightyears ahead of J2EE at the time. (Now I wonder what happened to it)

<comment><USER35> Former professional Zope guy here! (I made a living building things with it in the early-mid 2000s).

What happened to Zope? Well, Chris McDonough (creator of Pyramid, and Zope veteran) blogged about this in 2011 and from my perspective he got it exactly right. I still think this history is fascinating and I wish more people knew it.

[https://web.archive.org/web/20161019153348/http://plope.com/...](https://web.archive.org/web/20161019153348/http://plope.com/Members/chrism/in_defense_of_zope_libraries)

After the history lesson, some of his "lessons learned" bullet points seem very apropos in the context of Dark, particularly the first two:

* "Most developers are very, very risk-averse. They like taking small steps, or no steps at all. You have to allow them to consume familiar technologies and allow them to disuse things that get in their way."

* "The allure of a completely integrated, monolithic system that effectively prevents the use of alternate development techniques and technologies eventually wears off. And when it does, it wears off with a vengeance."

<comment><USER6> Thanks for pointing to that, it's super interesting.

One of the things we designed Dark around was being able to safely and easily continuously deliver language and framework changes. The Zope 3 project was a disaster by the sound of it, and I would hope this will allow us avoid a similar fate. That's the goal.

Also, we're pretty pro-testing (though also type systems, which help too).

</comment></comment></comment><comment><USER36> So... you're 50ms away from a total global outage and/or major feature fault?

Why would I want that? How do I control it for green-blue? For rational isolation? Is there native support for canary releases?

<comment><USER37> > So... you're 50ms away from a total global outage and/or major feature > fault?

And 50ms away from restoring service.

The degree of care that needs to be put into a release is related to the potential damage a bad release can cause and the time to repair.

Reducing time to deploy reduces time to repair for most errors (certainly not for errors than write bad states, if you write bad data to your database, that's most likely a long repair regardless of how fast to deploy it was).

If you're building NES cartridges, you should really get it right the first time, since there's no way to update. If you're making a low cost internet service, for small changes, it's not unreasonable to try things without a lot of testing before hand as long as you commit to detecting and rolling back quickly.

<comment><USER36> > And 50ms away from restoring service.

Sure, but fast rollbacks are _much_ easier than fast rollouts.

> Reducing time to deploy reduces time to repair for most errors (certainly > not for errors than write bad states, if you write bad data to your > database, that's most likely a long repair regardless of how fast to deploy > it was).

A uniform fast rollout is almost always worse, and a separate problem from data recovery or fast rollbacks. But I agree with this paragraph in principle.

> If you're making a low cost internet service, for small changes, it's not > unreasonable to try things without a lot of testing before hand as long as > you commit to detecting and rolling back quickly.

When you're doing more than basic presentation of semi-dynamic content, most CSPs make multi-region deployment very affordable and easy. It's generally a failure of early engineering departments or an accumulation of technical debt that makes it otherwise in 2019. Too many folks assume it is something they should do later rather than get right to start.

Canaries and regional redundancy should be part of every product's basic launch checklist, imo. People love to say any kind of software engineering best practice is bad, because they love to pretend software engineering has no value. But for every flash UX trick or tracking feature someone ships providing value, that's completely overshadowed by being down when a user needs you. Reliability not only saves you time at the developer level by making features more predictable, but it means you need to worry slightly less about funnel optimization because your user attrition is lower.

</comment></comment></comment><comment><USER38> How does it compare with hot swapping in other languages and platforms like Erlang, JVM/.NET hotswap technologies? I'm guessing the built-in safety functionality from the feature flagging is one thing?

<comment><USER6> It's much simpler. Those have complex in-process hot swapping. Dark's "hot swap" is a write to a DB, then new HTTP requests use the new code.

As we grow and start to look at compilation and optimization, I think we'll probably get much fancier, but for now we're very into keeping things super simple.

<comment><USER38> I'm pretty interested in this. Signed up to the mail list. Good luck!

</comment></comment></comment><comment><USER39> Marketing piece with grand plans...not really

I would argue with you that this is not such a priority for a software development organization, there are more important things to do.

You got so excited...so fast, I think this community may be doing more bad for me than good lately.

</comment><comment><USER40> This sounds extremely exciting and it looks like a lot of thought has been put into this. I'm looking forward to try it out.

A lot of comments here are coming from an anxiety that is caused by many years of dealing with fragile deployment processes, but I like the boldness of Dark to just bypass all that and make the fundamentals safe and solid.

</comment><comment><USER41> I added the same feature to my Java app server: [http://github.com/tinspin/rupy](http://github.com/tinspin/rupy) it's a simpler design which compiles, zips and hotdeploys over HTTP to a classloader.

But it's fast enough as long as you keep each project small.

</comment><comment><USER42> The problem is granularity of deployment - the smallest piece you can rollout is, these days, a container with code and dependencies, that has to be build and threaded through your CI/CD stack before it hits prod.

I like to imagine what would need to happen to reduce(increase?) that granularity to single function - you change the code, byte-compile it, send that blob to your backend's hot code swap port and voila - you're done. A lot has to happen behind the scenes though - a change in dependencies would still require a larger deployment or much smarter code swapping procedure, caller/callee tree would need to be considered, functions need to be pragmatically pure (talking to dB is fine, being part of an "object" - <USER2> really), functions need to be extensively specced, etc.

But that would be my backend holy grail.

<comment><USER43> What are you looking for, that isn't provided by platforms with hot code-swap (e.g. Erlang) or FaaS systems (e.g. AWS Lambda, OpenFaaS) ?

<comment><USER42> you're thinking of only surface functions/endpoints, those that are invoked directly from your api route dispatcher. i'm talking about _any_ function in your source code of a large backend with many endpoints.

think of function `+` - i want to be able to deploy a change to that function such that no worker process gets respawned.

also imagine every time you call `+` in your application - it goes throught the whole FaaS shenanigans with serializing, sending rpc over wire, receiving response, deserializing, dealing with throttling, errors, backoffs. all of that is ridiculous for `(+ 1 2)`.

and yes, erlang is a good example of an environment where this could work.

</comment></comment></comment><comment><USER44> Code deployment is almost always trivial and fast. It's the databases that are slow and very tricky, especially in distributed systems.

</comment><comment><USER45> Very curious about the data migration piece. It sounds like it's designed to handle mapping a row of type a to a row of type a prime. What about situations like a specific combo of type a and c to b and two different records of type c, and optionally delete a record of type d? We occasionally have migrations that are only representable as a function of several entire tables, and which may even leave gaps, e.g. for domain events that affected the system but weren't logged until a later revision.

</comment><comment><USER46> EDIT: Ha. My apologies as I just realized my stupidity - I was browsing on mobile and it turns out out I jumped into the 'What is Dark' post [1] and never finished the original! The mailing list links are in that one - <USER3> subscribed. This is a lot more interesting, cheers :)

[1] [https://medium.com/darklang/the-design-of- dark-59f5d38e52d2](https://medium.com/darklang/the-design-of- dark-59f5d38e52d2)

<comment><USER6> The section that describes how it does it in 50ms is called "#deployless". That describes the mechanics of the deployment. How we made deployless possible is addressed for the rest of the post after that.

(The mailing list thing is weird, I only see that link at the bottom. Can you point me at the ones you see in the text?)

</comment></comment><comment><USER47> Very interesting, but I don't like the idea of abandoning VSCode to learn some single-purpose IDE

</comment><comment><USER48> Dark sounds like it would satisfy my preferences well.

\- statically typed, functional language with no null pointers

\- safe deploys and rollbacks

\- structured editing / version control

\- minimal infrastructure management

...etc. A tool that makes writing a correct program, and deploying it without catastrophe or fuss, easy. I look forward to reading more.

</comment><comment><USER6> Author here - happy to answer any questions!

<comment><USER49> Other languages have large ecosystems of packages that allow users to do common tasks quickly. I can imagine not having something similar would be a sticking point to adoption; how does Dark picture the Dark ecosystem working and competing with other already well-entrenched ecosystems? Thanks!

<comment><USER6> There's a couple of ways of handling this. First is that of course we need to create a package manager and ecosystem, and that will take time (we can accelerate it by making a great experience, but haven't gotten there yet).

Dark can talk to other HTTP things, so many of the functions that are done by libraries can be done over HTTP. So you can call other services, even if we don't have an SDK for that yet. And from there it should be easy to package it up so there is an SDK.

Finally, it's a question of what you're doing. There's many tasks where the disadvantage of not having an ecosystem is outweighed by Dark's other advantages. And as we grow the ecosystem, the disadvantages go away, unlike the status quo tooling.

</comment></comment></comment><comment><USER50> Very interesting and flips mostly everything about CI and CD on it's head. I am disappointed the blog post doesn't include any screenshots or actual examples of the Dark code/editor working. It's kind of hard for me to wrap my head around how this works at a technical level just reading about it...would like to see some concrete examples. I went over to the website to look for a demo/examples but there isn't anything.

</comment><comment><USER51> As an aside, that big list of tasks and diagram at the end are perfect to show next time a client exclaims about how long it takes to get a simple change into production!

</comment><comment><USER52> They show very little, I'm anxious to be able to see.

<comment><USER6> We're talking about the design of Dark in these posts. We plan to show what Dark looks like in our launch in September.

</comment></comment><comment><USER33> I think it is fantastic that this kind of innovation is happening. I get sick of waiting for stuff at work, some kind of build or CI thing. npm i, docker build or whatever else. I hope the language experience is good, and it's a reasonable language (static typing!).

It sounds like taking the Go idea of quick builds to the next level.

</comment><comment><USER53> What are the server/OS/cloud prereqs for Dark?

<comment><USER6> There are none! We run the infrastructure in the cloud (we run it on GCP using Postgres and k8s, but will likely go multicloud at some point).

Most of the advantages we discuss in this post come from the fact that you're using the Dark editor, language and infra. I don't believe this would be possible with a self-hosted solution.

<comment><USER54> So anyone using Dark is completely locked-in, to the point that they can't even take their code into an editor other than yours?

It's a proprietary language, that can only be edited in a proprietary cloud- based editor, that only runs on proprietary infrastructure?

<comment><USER6> Yes, that correct. There are lots of downsides to this, but you also get a lot of things that we don't think are possible without it.

<comment><USER54> I understand the concept, but I don't think the downsides can be so easily passed by. Some quick thoughts/questions:

\- What happens if Dark-the-company disappears? It doesn't matter how. You're acquired by Google and shut down, your office is hit by a meteorite, whatever. Everyone that's ever built anything using Dark would completely lose it? Every company that's built anything using Dark would have nothing remaining in its place except--at best--some code that can't run anywhere?

\- How much venture capital have you taken? Do you expect to take more?

\- What if you update the platform and it introduces behavior changes or bugs into some of your users' applications? Can they rollback and stay on the previously-working version of Dark (indefinitely), or will they have to rely on you to resolve the issues?

\- The first mission of the company that you list on your Values page is "Democratizing Coding". How does making literally every aspect of Dark completely dependent on your company support that? Will Dark users vote on company decisions? How can a completely centralized system with a for-profit owner promote democratization?

<comment><USER6> These are the downsides I'm talking about. If you're sensitive to them, don't use Dark! That's totally fine with us. We're creating a technology with a ton of advantages that don't exist elsewhere, and that comes with different tradeoffs.

If you're worried about a meteor hitting SF (and I know that's a metaphor, but let me run with it), then your risk profile indicates you won't be using new technology from a new startup (you probably won't even use less risky stuff, like Rust or Elm).

If every technology had exactly the same constraints, then we'd be stuck with those constraints forever. This isn't the _right_ way to do it, it's just our vision of how to solve the problems with coding.

<comment><USER26> It's a hard sell. Another risk is that, after I've invested a lot in Dark, you increase your prices, and I can't switch because I'm dependent on your product. The switching cost would be rewriting my entire code base (my biggest investment).

I'd like to have the option to reuse my code to mitigate those risks. Two possibilities: a) If the Dark IDE and infrastructure were compatible with a common language, I could use "regular" build and deploy tools if I wanted (I'd weigh the pros and cons vs. your price increase), or b) if the Dark infrastructure had an open source API (not necessarily an open source implementation, but like what SQL is for databases, or the S3 API for object storage), I could implement my own alternative infrastructure or shop for one.

(a) seems difficult technically and (b) means risking commoditization on your end.

<comment><USER6> > Another risk is that, after I've invested a lot in Dark, you increase your > prices, and I can't switch because I'm dependent on your product. The > switching cost would be rewriting my entire code base (my biggest > investment).

This would also kill the company.

We are actually looking at ways to mitigate this risk, as we do agree that being locked in is a real risk. We also have to provide sustainability to the business, as Dark failing as a business isn't helpful for our customers either. We're thinking about this, but nothing concrete yet.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER55> Is Dark intended to be a Lisp? I'm surprised by the fact that the team didn't include language examples (from what I can gather)

<comment><USER6> No, it's an ML. (You're right that we haven't published samples, we think people get distracted by syntax and we want to focus on the goals at the moment)

<comment><USER55> Oh cool! That makes me quite a bit more interested.

</comment></comment></comment><comment><USER56> Can I take Dark out for a spin?

<comment><USER6> Right now, we're in private alpha. If you have a product or service that you want to build, fill out [https://darklang.com/subscribe](https://darklang.com/subscribe) and our CEO Ellen will get back to you to discuss and schedule an onboarding. We're not doing tire kicking yet though :)

<comment><USER56> Entered my email awhile ago... just updated the mailchimp profile (email@example.com) to include my use-case. Let me know! Would love to provide feedback - what you're working on sounds awesome

</comment></comment></comment><comment><USER57> One question: Security

</comment><comment><USER58> That's quite a dark name for such a bright idea.

</comment><comment><USER59> It sounds like a convoluted version of Geocities.</comment>


Foggy Periods, just a confused thought dump - <AUTHOR>

I have days where the steps necessary to create the future I want are so clear.  Today is not one of those days.
For the past two years I've been working weekends on a project collaboration app for the construction industry. Saying marketing has been a problem would be an understatement.  I have, or maybe even had, 3 partners.  Yet the only thing to show for the past two years is what I have built as the sole developer.
I'm currently doing contract work for two companies.  The work and people are nice.
But I'm tired, I'm burnt out.  I'm considering taking a job full time from one of the companies I'm contracting with.  This is the most rational direction to take.
My health has been neglected, my family has been neglected (even though I didn't realize they were being neglected until this past summer).
Everything came crashing down this summer.  My fiancé almost left me, I fought for us and our son and now we are back together.  So that is good.  We took on new partners to handle marketing but all I have received thus far from them are more things to build.  Those things have been completed, so now would be when their marketing should pick up.  Have not heard from them in a month.  I had pleaded with them to start the marketing 3 months ago, but its just easier I think to have the monkey keep building.
I am proud of what I have done in the past two years.  I have stared into the abyss chewing glass, and still managed to cross the finish line.  Marketing was never my thing, I accomplished my part.
So now is the time for change, I think I will spend the next 6 months recovering, getting in shape, fixing personal finances, just refocusing on the basics.  Then I will start a new company.  Solo, by myself.  It will have to be a consumer product, since breaking into the enterprise market has proved to be a task that I don't currently have the soft skills for. <comment><USER2> My harsh advice, based on real and similar experience, is to get a job. Just to tide you over, to let you get back on your feet. Look for something in construction - maybe with a consulting firm that works with potential clients of your future business. Heck, they might even be interested in marketing the system you've developed. Regardless, what you really want in the future is freedom and stability, and to sacrifice the health and relationships you have now for that goal is a huge price to pay. I did it, I know.

Next, screw marketing - you don't need that right now. Maybe you had bad advice or just made it up, but what you need is sales - very different from marketing. You are the best sales person because you're the one who saw the need and believes in your solution. Forget websites and blogs and social media, that's not right for you - just talk to people and get them talking to people, until you can make contact with and sit down with potential customers. Tell them about the solution, land your first big friendly client and make them happy.

Just my 0.02 based on real life experience :)

<comment><AUTHOR> Thanks for the advice, I don't get my feelings hurt, so be as harsh as you like. I agree with you, the focus now should be stabilizing home, steady paycheck, family expectations. The best way to do this is to simply have a full time job.

You are also right when concerning sales. I need sales. I use the term marketing cause from my developer perspective I see them closely intertwined.

What I wanted my marketing team to handle was to start the conversation with people in the industry. This would in turn create a need for creating marketing copy that could be left with individuals. It would also have started the process of determining how best we could communicate the value we are providing to the industry in a language that was easily digested by potential customers.

As best as I could tell they talked to one company. This turned into an opportunity to pitch them on some custom development work that we could have used to fund our startup. It went well, it proved to me that we had a talented team, but it didn't result in a sale. But, much like in sports, kinks in working as a team need to be flushed out over time. And this takes practice. I consider my group to be comparable to some seasons of the NY Yankees, we have a bunch of talent, but if we can't work together consistently we will not be winning the world series.

It was important to me to bring the code to completion for a variety of reasons. #1 I have a character flaw of not finishing what I start. It was paramount that I saw this to the end to prove to myself that I have the determination & resolve to create companies. #2 I wanted to get the code to a place where even if I quit, or just take time off, it could continue to live on without me. This has been accomplished. My more active partner has started using it in his Subcontractor Company. One of my AWAL partners might still use it at his General Contractor company, but I won't know until I hear from him again.

So, this project might not be dead, but after a 2 year push, I can't continue to build on it until I see some tangible effort and sweat from my partners. We'll see what happens.

As a person that hates being idle, I will hope for things to work out here, but make plans to move forward on my own should the company fizzle out.

</comment></comment><comment><USER3> Hi, I'm interested in learning more about your project. If you're interested, please reach out to me via the email address in my profile.

<comment><AUTHOR> I love talking about what I've built, I'd be happy to ping you later this evening.

</comment></comment><comment><USER4> Keep your fiancee and son, keep the feeling of pride for "finish line" accomplishment.

The rest will come by itself.</comment>


Ask HN: How do you manage your projects locally? - <AUTHOR> Dear all,
during the years many projects accumulated on my laptop. If that sounds familiar to you, how do you keep an overview? Ideally I would like to have a tool (perhaps curses based?) that let's me list, sort, tag and search all of my projects, with the goal to know what project has which status, aso.
I only found (and tried) tag based file systems (tmsu, tagfs) or file organizers (tagspaces, tagtiql), but nothing especially for folders containing source code and I am sure I am not the only one with this problem. So, what are you doing? I guess not every project is on GitHub or your private repository hosting platform (thinking of gitolite, Gogs, Gitlab here). <comment><USER2> Wiki (that doubles as a home page), directory layout conventions, and README in project's repository.

README gives an overview and shows goals of your project, to both you and your potential users. A very important part.

Wiki serves as a landing page, repeats some (many) of the information included in README, points to documentation (or even hosts it). A collection of wiki pages can be then organized into categories, so it's kind of a listing of what have you written already.

Unified directory layout has the least spectacular function: you know where to look for which project.

> I guess not every project is on GitHub or your private repository hosting > platform (thinking of gitolite, Gogs, Gitlab here).

Except for GitHub, I don't use any of that. For read access, I simply expose through HTTP what git calls "bare repository", adjusted with `git update- server-info'. For write access, I use ssh:// transport to what otherwise is published for reading/cloning. Plus gitweb, so I can browse repositories with a web browser these rare times I need to.

And then I treat GitHub as a supplementary distribution point and a merge requests source for projects I consider good enough to be published. Not everything lands in my GitHub, but everything gets its own repository on my server.</comment>