Docker 1.12: Now with Built-In Orchestration - <AUTHOR> https://blog.docker.com/2016/06/docker-1-12-built-in-orchestration/ <comment><USER2> I chose Docker for my project with hope that it would help me create an easily reproducible development environment... And I'm not really sure if it was a good idea. There's so many moving parts and I can't name one that actually works well. Configuring storage is a hell (running out of disk space can lead to errors that are really difficult to debug), the dance with bridges makes configuring firewall a terrible experience. I definitely wouldn't recommend it as a stable container solution.

<comment><USER3> Why is storage an issue? With databases, for example, you store data upstream (on the host) and keep the dockerised app/thing mostly stateless, or at least capped with regards to storage. More details about your environment would be appreciated.

<comment><USER4> Keeping data on the host is exactly the reason that it's an issue. Swarm offers not guarantees that containers will be rescheduled on the same host that it was initially scheduled on and assumes that it can reschedule containers as failures arise... this doesn't work when your database gets rescheduled and emptied along the way.

<comment><USER5> In docker 1.12 you can 'tag' a node and tell a 'service' to only run on the tagged nodes.

Not saying that's a good idea, but it is getting closer.

You could, for example, have a node that's only for DBs that has volumes on it. You could then use DRBD on the host to clone that data to a secondary node. then in the event that node 1 dies swarm would bring the DB up on node2.

With the mesh network stuff they've added the endpoint would remain the same, so all your apps would need to do would be re-connect.

<comment><USER4> > Not saying that's a good idea, but it is getting closer.

No, that isn't getting closer it's getting farther away. The whole point of containers is that they make the host machine completely fungible. If I can only schedule my DB containers on a specific machine then I might as well just run my DB on that machine and be done with it.

<comment><USER6> My personal opinion is, Docker's good when you need to be sure you deploy exactly the same stuff on multiple hosts. This includes ensuring that the code you try on local machine would be the same on the production hosts. Docker is completely worthless for deploying singleton services that you already have packaging and deployment recipes for - it just doesn't add any value for such use cases.

That is, Docker is just a packaging system + a tool to spawn the deployed stuff in an isolated environment. Now, 3 years after, they've improved dependencies (previously done by docker-compose + hacks for using it in production).

That is, I use Docker only because its images are somewhat easier to build and deploy, compared to .deb packages or plain tarballs (and it's more OS- agnostic, since Docker Machine's available on Windows and OS X, so I can just build an image with dev. environment and don't care what OS is used). Doubt it's something more than this.

<comment><USER7> > My personal opinion is, Docker's good when you need to be sure you deploy > exactly the same stuff on multiple hosts.

There is a technology for that already: it's called OS packaging. Docker does not maintain enough metadata to allow for in-place upgrades of individual components in an image (software and configuration lifecycle management). The best you can do with Docker is install lumps, you can forget upgrades. Docker is not a replacement for configuration management, and specifically, Docker is not a replacement for the operating system's software management subsystem.

<comment><USER8> > Docker does not maintain enough metadata to allow for in-place upgrades of > individual components in an image

Your missing the point of a container, you don't upgrade them in place

<comment><USER7> Containers are actually resource constraints, and were first introduced in Solaris 10, along with zones, which is what you appear to understand under containers. Even on GNU/Linux, containers are implemented via cgroups, which are resource controls and not a virtualization solution.

On SmartOS, when you provision a zone, you get a fully virtualized UNIX server, and you can apply a container to it by defining resource constraints, but that is both pointless and unnecessary there. Once you have a fully virtualized server provisioned from an image with the imgadm(1M) and vmadm(1M), it is only logical that you will want to service individual components via pkg_rm and pkg_add, rather than baking an entire image all over again, and redeploying it, all over again. It's the rule of modularity: "write simple parts connected by clean interfaces" [Kernighan-Plaguer], and it applies particularly well to lightweight virtualization.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Just based on the details mentioned in the keynote, the services API and swarm features look very similar to what's offered by Kubernetes... service discovery, rolling updates, load balancing, health checks, auto-healing, advanced scheduling.

I guess this was to be expected, but it's also kind of sad. I think it would have been a more strategic move to embrace Kubernetes instead of trying to compete with it.

<comment><USER10> Have you ever tried running Kubernetes yourself ? Kubernetes is cool yes, but only on GCE, and managed by Google people. Apart from that, its nowhere near usable.

Docker 1.12 does just what Docker does best: Making complex stuff simple to use and give control back to people.

<comment><USER11> Kubernetes can totally run outside of GCE. For example here is the official k8s-on-EC2 doc: [http://kubernetes.io/docs/getting-started- guides/aws/](http://kubernetes.io/docs/getting-started-guides/aws/). You can run it on your own VMs or physical machines if you want.

The only GCE specific thing is Google's _managed_ kubernetes offering, Google Container Engine (confusingly called GKE).

</comment></comment></comment><comment><USER12> I wish they would address stability issues first, like this bug[1] that has been around 2 years and is still happening on the latest versions.

[https://github.com/docker/docker/issues/5618](https://github.com/docker/docker/issues/5618)

<comment><USER13> Or this nasty one[1] that has been around just over a year now. It didn't take me more work than using docker as a build server to run into this. There are some udev hacks that make it better, but the underlying issue is ultimately docker here.

Doesn't seem that docker inc upstream takes stability seriously from my standpoint.

[1] [https://github.com/docker/docker/issues/13885](https://github.com/docker/docker/issues/13885)

<comment><USER14> Hard problems are hard. We are looking at all kinds of issues related to this, and in reality reports from that issue are likely caused by different things (some things are fixed, others obviously not).

There are several people looking how we can resolve issues like this.

</comment></comment></comment><comment><USER15> This seems like a really exciting, albeit natural, evolution of the Docker "platform". It's really true that no one cares about containers, everyone just wants their apps to work.

That being said the one giant omission from Docker is still seems to be management of volumes/data. Great, we can run 100 nodes on AWS in a matter of minutes, but if your system has data storage requirements (ex: Almost every database ever) ... You're kinda left up to your own still. How does Docker Orchestration migrate the data volumes?

They really tried to sell this as "You don't need to do anything but the AWS beta, the DAB and a few commands" which would be wonderful. However with the need for reliable data storage... you're still stuck doing everything "the old fashion way".

(Edit: No, I don't mean store data IN the container, I presume no one is that silly. I meant the attached volumes. No volume mgmt = less greatly less helpful).

<comment><USER16> It seems to me they are more focused on NOsql databases with multiple nodes and shared data like cassandra. So that you don't have to worry too much about volume/data mgmt because you will have multiple copies of the data on other containers when you lose a docker host or a container.

You also should conside that docker might not be the best option as opposed to just some vms on openstack for your much needed databases.

I'm stuck trying convince my co-workers that docker is not the answer to everything.

<comment><USER15> In no way did I mean to convey "store data IN the container" as I had simply assumed no one was that silly.

What I actually meant was as "there is no way to deal with volumes". So spinning up 100 instances and hot failover doesn't help if it doesn't deal with the attached volumes. Without that functionality, the orchestration is less magic and more "eh".

</comment></comment></comment><comment><USER17> I'm not surprised the Kubernetes primitives got copied into this. I had stated before that Kubernetes was what Docker wants to be when it grows up -- and maybe that time is here. Having used Kubernetes in production, I don't know robust the Docker orchestration primitives are in comparison. But I'll probably find out soon.

The big advantage having a built-in Docker orchestration is that Kubernetes is painful to install from scratch. (Yes, there are scripts to help mitigate this; yes, GKE is effectively hosted Kubernetes). I'm involved in another Dockerization projection, but we don't know if we want to invest the time into setting up Kubernetes (though GKE is an option). This would be a good time to check things out.

Just to show how quickly things change. In 2015, I tried the docker compose, AWS ECS, and Kubernetes for production deployment, and of all of them, Kubernetes addressed the pain points in a practical way. The Kubernetes project ended in late 2015, and now six months later, things changed again ...

<comment><USER18> Having set up Kubernetes to test, I'd say it's a bit less complicated than many people claim, though still obviously complex. I had a two-node cluster up and running in an hour using Flannel and Kismatic's prepackaged binaries for Debian/Ubuntu [1].

The biggest hurdle, ironically, is the official documentation, which seems to have been written by someone with no understanding of explaining things from first principles, or any talent for organizing ifnroamtion. You'd think the "setup from scratch" guide [2] would be the most detailed and useful for someone who wants to see how each piece fits into the next one, but it's actually terrible. It skips a lot of implicit information and makes some odd assumptions/suggestions. Almost every part of Kubernetes is multiple choice, which affects later steps. For example, if you use Flannel and you're not on GCloud, much of what Google's docs say about networking is moot.

Everything is also made harder by the fact that Kubernetes is changing awfully fast in non-backwards-compatible ways, and chances are that if you google some config problem, the answer is long out of date — the necessary kubectl option no longer exists or whatever. A lot of config recipes are useless now.

[1] [https://github.com/kismatic/repo_server/find/master](https://github.com/kismatic/repo_server/find/master)

[2] [http://kubernetes.io/docs/getting-started- guides/scratch/](http://kubernetes.io/docs/getting-started-guides/scratch/)

<comment><USER17> I set up Kubernetes on AWS, a staging and a production cluster. Staging had 1 master, 3 worker nodes, Production has 3 masters, 5 worker nodes, with two compute classes (fixed and burst, so pods could be scheduled to what was needed). All of this was on CoreOS, and included independent etcd clusters. So all total, we're talking 18 AWS EC2 instances. I put live users on it, with real traffic and tinkered with it as I learned things from a production workflow.

This was back in mid-2015, which meant figuring out things like how to get overlay networking with AWS's routing, fiddling with AWS's IAM settings, VPC settings, figuring out how to split the nodes across availability zones. This included integrating with AWS AutoScalingGroups to bring up new CoreOS/K8S nodes whenever something goes down. I never got EBS working as a Kubernetes volume type (at the time, you have to add hackish tools into CoreOS to detect unformatted EBS blocks and format them when they get mounted; forget it), but fortunately, used AWS RDS for persistent stores. Persistent storage is something I look forward to trying on GKE.

I _could_ have tried creating CloudFormation scripts but I was making my way through documentation, blog posts, and Github issues to pull it all together. It was worth it when I was done.

I didn't say it was complicated. I said it was a pain in the ass, and it's something that Kubernetes developers have acknowledged and are working on it.

</comment></comment></comment><comment><USER19> At first I was worried that this is yet another Raft implementation, but it seems they're building on etcd's version [1] which should be a win for everyone trying to prove correctness for the various implementations.

1\. [https://github.com/docker/swarmkit/blob/a78a157ef66adf0978f0...](https://github.com/docker/swarmkit/blob/a78a157ef66adf0978f031e7bbc9bff2c16df9a0/manager/state/raft/raft.go#L19)

<comment><USER20> I like it that etcd is self-contained and easy to troubleshoot, as opposed to a blackbox with tons of magic.

The demo for `docker swarm` was great but as an infrastructure engineer, it worries me. First because of the blackbox effect I mentioned above and secondly because I'm not sure how much flexibility is compromised to achiveve that.

Sure, it's awesome to quickly have a cluster up for your app and the user experience is phenomenal... but what about storage, network, firewalls, integrating with my linux distro, etc. Things are never this simple when they reach a certain scale and/or number of requirements deviate from those of a simple app.

From a quick look at the docs and watching the demo, Kubernetes still feels like a safer option, today. That being said, it's nice to see competition in this space. I guess this will put pressure on Kubernetes and others to improve the user experience further.

</comment></comment><comment><USER21> I also noticed that now 'Docker for mac' is available without beta invite. I just downloaded and installed though its version is 1.12.0-rc2.

Maybe they will make formal announcement when 1.12 for mac is released.

<comment><USER22> They have announced a Public Beta:

[https://blog.docker.com/2016/06/docker-mac-windows-public- be...](https://blog.docker.com/2016/06/docker-mac-windows-public-beta/)

<comment><USER21> Ohk, great. I did not notice that blog post.

</comment></comment></comment><comment><USER23> I wish docker released lite version of docker. Only containerisation, no networking configurations, weird cache mechanisms - just something small and easy to use locally.

No one sane will run docker on prod anyway.

<comment><USER24> Just use libvirt (virsh utility command) if that's all you want.

<comment><USER25> Oh gosh, no. Whatever faults Docker may have, they're outweighed by its very approachable UI compared to the discombobulation that is libvirt's interface.

[https://libvirt.org/drvlxc.html](https://libvirt.org/drvlxc.html)

</comment></comment></comment><comment><USER26> The new orchestration looks based on Swarm and possibly Compose; have they resolved the issue where the lack of lifecycle semantics means that your services don't work if they have any sort of cluster semantics, like Riak, Cassandra or Zookeeper? These previously always required outside hacks to work, and work flawlessly with Kubernetes. It looks like there's some service discovery support; which may or may not fit the bill.

<comment><USER27> Yes, all of that works seamlessly now. Each container gets an IP and is discoverable via DNS.

<comment><USER28> Due to caching implementations which change between OSes, programming languages, and routers, DNS is actually a really terrible discovery mechanism at scale.

For example, I'd never want to implement service discovery via DNS in Java, which ignores expiration times and caches queries according to its own settings. I've also seen some server configurations which result in every gethostbyname call to a fully recursive query against DNS.

<comment><USER27> > _Due to caching implementations which change between OSes, programming > languages, and routers, DNS is actually a really terrible discovery > mechanism at scale._

Only if you rely on the client's resolver caching implementation, which we don't. Docker networking guarantees that a given hostname lookup by a given container in a given service discovery scope will always return the same IP. In that configuration, using DNS is a robust fit for production.

Believe it or not, Docker is built by people who have actual operational experience :)

<comment><USER29> > a given hostname lookup by a given container in a given service discovery > scope will always return the same IP

Did you mean this to cover the situation where N containers have registered the same name? I thought Docker DNS returned all such results in random order.

Given that, if one of those containers goes offline and Java has cached its address, you have the problem the parent was alluding to.

<comment><USER27> That's incorrect. You are describing DNS-based load-balancing, which would indeed rely on the container's resolver implementation. But Docker doesn't do that. Instead it always resolves the service name to the same IP, which is load-balanced by IPVS. That way even the world's crappiest dns caching implementation will still be handled properly.

So when I said that Docker doesn't rely on the container's DNS resolver, I really meant it. We have seen in past lives the consequences of "DNS abuse" and have been careful to avoid it.

<comment><USER29> I was going by [https://blog.docker.com/2016/04/docker- engine-1-11-runc/](https://blog.docker.com/2016/04/docker-engine-1-11-runc/) which advertised "DNS round robin load balancing".

EDIT: calmer tone

<comment><USER30> Docker 1.12 built-in load-balancing supports both VIP based LB using IPVS and also DNS-RR and it is configurable per-service. VIP based LB is the default though. All of these will be fully documented shortly.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> I find it super amusing that GCE isn't mentioned, that ostensibly Kubernetes is the source of lock-in (despite being open-source and likely having more cycles on EC2 than on GCE/GKE), and that this proudly uses gRPC for http/2 and protobuf goodness. So which is it, is Google an evil vendor trying to lock you in, or are we actually doing work in the open and just hoping you'll choose us when you want infrastructure?

Disclaimer: I work on Compute Engine, and think of the Kubernetes folks as friends.

<comment><USER27> Disclaimer: I work at Docker.

You are reading way too much into this. We're introducing orchestration in Docker because it solves a problem for our users. We haven't called your employer or anyone else "evil", and frankly this announcement is not about Google or any other company. It's about improving Docker for its users.

Speaking personally, I think GCE is a great product, Docker wouldn't exist without Go, and although grpc is not my personal favorite, it gets the job done and it's quite popular with Docker engineers. The libcontainer project (now runc/containerd) started with a very fruitful collaboration between Docker and Google engineers. The current Docker networking model is also heavily based on early feedback from the Kubernetes team (one IP per container, remove nat between containers, etc.)

Yes, some features of Docker overlap with other products. One of those products is Kubernetes but there are dozens of others. That kind of healthy competition is normal and good for users!

</comment></comment><comment><USER32> If someone else also want to see the keynote, they have a recording: [http://www.ustream.tv/recorded/88610090](http://www.ustream.tv/recorded/88610090)

<comment><USER33> Thanks, I was looking all over for this! Much appreciated.

</comment></comment><comment><USER34> I have two code bases that are microservices. I thought using Docker would be easy to setup and share a redis instance between these services. After spending a day trying various thing I just gave up and did 'brew install redis' and got back to real app dev. Docker isn't streamlined enough, does have great examples and is still changing lots. Sometimes doing it the old fashioned way is what lets you ship features faster.

</comment><comment><USER35> Omg their navigation bar covers half my screen! Seriously, why do companies inside upon reducing my screen real estate for stupid shit?

<comment><USER36> I actually think this is a valid point, even if somewhat colloquially expressed. I had a lot of trouble getting past that menu bar on Opera Mini and even on an iPad, it's entirely too much.

<comment><USER37> Agreed. To be honest, I think the colloquial nature of the post is fine in this case.

</comment></comment></comment><comment><USER38> Great, now make it a first class citizen in compose and mix in docker- machine's provisioning capabilities!

</comment><comment><USER7> The article is lots of blah blah plus "lock-in" for good measure, with exactly zero code or configuration examples, and it reads like a snake oil salesman brochure. I'm still skeptical about the purported advantage of Docker / Linux over zones / SmartOS.

</comment><comment><USER39> I was using osx beta but uninstalled it for now because docker was eating all my space without recovering it after deleting containers. Anybody using rkt for dev wants to share their experiences, I am thinking about trying it but would not invest time if it is not ready yet.

<comment><USER32> There may be images or volumes you should remove when no longer required.

<comment><USER39> Nope, it was known bug and still not fixed by the time I removed it.

<comment><USER40> Sorry about that -- this was a bug in one of the betas where log rotation was broken. It's been fixed about 3 or 4 betas ago via a mid-week hotfix, so the latest open beta should be just fine. Hope you get a chance to try the latest series again soon!

</comment></comment></comment></comment><comment><USER41> Have they sorted out storing secrets yet? That's one thing I noticed that Kubernetes manages that docker is still scratching it's head over.

But this looks like it could be great progress. Orchestration was always the main pain that stopped me from using docker.

</comment><comment><USER36> This is great. I can't wait for an ARM build, though.

<comment><USER42> Try resin.io!

<comment><USER36> I did. I want the mainstream stuff.

</comment></comment></comment><comment><USER43> Docker is great (wonderful in fact) for building development/CI environment. I never use docker for production.

</comment><comment><USER44> Maybe i'm not uptodate or misunderstanding, but doesn't Mesos/Mesosphere do something similar?

<comment><USER45> There are a dozen tools that do something similar.

</comment></comment><comment><USER46> is docker as good as rkt nowadays?</comment>


Extinction is Natural, So is Global Warming - <AUTHOR> https://paradite.com/2018/11/06/extinction-is-natural-so-is-global-warming/ <comment><USER2> If we stretch the meaning of natural to include global warming then everything becomes natural and the distinction of man-made vs natural becomes meaningless. There's a very important distinction and it's between things we nominally have control over and things we have little/no control over like industrial pollution vs solar output cycles. It's also a question of intentionality we choose to continue using (even trying to encourage in the case of some groups) the use of heavily polluting power sources like coal.

Also in response to the dinosaur example I think if they had done something like that we would speak about them very differently. I think there's a level where when a species starts making large scale changes to their own environment that things go from being the product purely of nature to being the fault and responsibility of whatever species does it. That line is partially drawn by scale and partially by intentionality/sapience where the species can decide about what they're doing and choose other paths.

<comment><USER3> Re: the dinosaur example, I agree. A non-hypothetical example is the Great Oxygenation Event, where the microbes which produced free O2 did not "decide" that they would destroy their anaerobic environment. Hence we talk about it in a different way that we do for humans.

</comment></comment><comment><USER4> What rot. Its not about the existence of change; its the rate and ecological upset that will accompany this catastrophically rapid change.

</comment><comment><USER5> That's like saying a skyscraper is natural or einsteinium is natural.

<comment><AUTHOR> I think there's an argument for einsteinium to be excluded from the nature, as it is something fundamental and yet absent in naturally occurring world.

But skyscrapers, to me, are nothing more than beehives or limestone caves. The former has impeccable geometric precision and latter has marvelous outlook and properties.

</comment></comment><comment><USER3> It seems like needless pedantry to argue that humans are natural and therefore human-induced global warming is natural and human-caused species extinction is also natural.

Quoting from [https://en.wikipedia.org/wiki/Nature](https://en.wikipedia.org/wiki/Nature) : "[Nature] is often taken to mean the "natural environment" or wilderness–wild animals, rocks, forest, and in general those things that have not been substantially altered by human intervention, or which persist despite human intervention. For example, manufactured objects and human interaction generally are not considered part of nature, unless qualified as, for example, "human nature" or "the whole of nature". This more traditional concept of natural things which can still be found today implies a distinction between the natural and the artificial, with the artificial being understood as that which has been brought into being by a human consciousness or a human mind."

That Wikipedia entry even touches on observation "Bottom-line is, we as a species are governed by the same laws of physics, chemistry and biology as other species, there is nothing separating us from the rest of nature." saying "Depending on the particular context, the term "natural" might also be distinguished from the unnatural or the supernatural."

"Natural" in the context of global warming does not mean supernatural, as Arrhenius well knew when he worked out in 1896 the connection between human- caused CO2 emissions and the greenhouse effect.

If you don't want to maintain the artificially constructed delineation of "natural" vs. "human caused", then use "anthropogenic", as in "anthropogenic extinction" and "anthropogenic global warming." That will get your point across without running into problems with the widely-used interpretation of what "natural" means.

Eg, "The Scientific Case for Modern Anthropogenic Global Warming" \- [https://monthlyreview.org/2008/07/01/the-scientific-case- for...](https://monthlyreview.org/2008/07/01/the-scientific-case-for-modern- anthropogenic-global-warming/) and "Anthropogenic extinction threats and future loss of evolutionary history in reef corals" \- [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3678474/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3678474/) .

Even if you managed to convince everyone to use your definition of "natural", it doesn't change a thing, because what's the point? Polio is natural. Lead in the water system is natural. We don't want either of them.

<comment><AUTHOR> Thanks for the long reply. I guess you didn't really get my point, which is kind of implied in the article:

Whatever we do to "save the earth or the environment", they are not really "saving" the earth or the environment, because the earth and the environment don't really care about humans. The nature does not differentiates hot vs cold, high CO2 concentration or low CO2 concentration, earth covered by lava or forest. What we call destructions or damages, are just natural processes by a highly intelligent species. All we are doing is making the earth more suitable for humans to live, that's it.

<comment><USER3> Then you don't really get my point which is that emphasis on the precise meaning of "natural" or what is "saving" is pedantry that no one cares about.

The meaning of "save" in this concept is well understood to mean the connection between human needs/wants and the earth or environment.

The whole point of my lengthy reply was to object to the validity making an argument like "just natural processes".

Polio is "just [a] natural process". One which killed many children. It was a natural process that humans worked hard to eradicate. So, great - let's say anthropogenic global warming is a natural process ... and work hard to eradicate it too.

CFCs in the air are a natural process. We worked hard to eradicate them.

Human killing of whales is a natural process. We decided that we should instead "save the whales".

"All we are doing is making the earth more suitable for humans to live, that's it."

That's too simplistic. We also work to change the human understanding of what "suitable" means.</comment></comment></comment>


The Next 700 Programming Languages (1965) [pdf] - <AUTHOR> http://www.thecorememory.com/Next_700.pdf

<comment><USER2> The HOPL books & papers are great, too. Most (if not all) should be available on citeseer / google scholar. I have the HOPL II book and trivially found all the papers from HOPL III online.

I particularly like the history papers for Lisp, Lua, Erlang, and Forth, but, personal biases.

Another good one: Sammet's _Programming Languages: History and Fundamentals_. (The superior design of Lisp and APL gets asymptotically more embarrassing in retrospect.)

</comment><comment><USER3> I get the impression Peter Landin was ahead of his time. I love this paper. It's worth a read by anyone interested in compilers or functional programming.</comment>


The Myth of Efficiency - <AUTHOR> http://baselinescenario.com/2010/02/11/the-myth-of-efficiency/

<comment><USER2> A quote from my favorite book:

      "Good morning," said the little prince.
      "Good morning," said the merchant.

      This was a merchant who sold pills that had been invented
      to quench thirst. You need only swallow one pill a week,
      and you would feel no need of anything to drink.

      "Why are you selling those?" asked the little prince.

      "Because they save a tremendous amount of time," said the
      merchant. "Computations have been made by experts. With
      these pills, you save fifty-three minutes in every week."

      "And what do I do with those fifty-three minutes?"

      "Anything you like..."

      "As for me," said the little prince to himself, "if I had
      fifty-three minutes to spend as I liked, I should walk at
      my leisure toward a spring of fresh water."

"The Little Prince" by Antoine de Saint-Exupéry, Chapter XIII

<comment><USER3> Possibly related:

> Homer's Uncle Ulysses and Aunt Agnes have a very up and coming lunch room > over in Centerburg, just across from the court house on the town square. > Uncle Ulysses is a man with advanced ideas and a weakness for labor saving > devices. He equipped the lunch room with automatic toasters, automatic > coffee maker,' automatic dish washer, and an automatic doughnut maker. All > just the latest thing in labor saving devices. Aunt Agnes would throw up her > hands and sigh every time Uncle Ulysses bought a new labor saving device. > Sometimes she became unkindly disposed toward him for days and days. She was > of the opinion that Uncle Ulysses just frittered away his spare time over at > the barber shop with the sheriff and thee boys, so, what was the good of a > labor saving device that gave you more time to fritter?

Robert McClosky, _The Donuts of Homer Price_

<comment><USER4> _This is a little longer than I'd normally post, but it's relevant and I use it to make the point often._

An American tourist was at the pier of a small coastal Mexican village when a small boat with just one fisherman docked.

Inside the small boat were several large yellowfin tuna. The tourist complimented the Mexican on the quality of his fish and asked how long it took to catch them.

The Mexican replied, "Only a little while."

The tourist then asked, "Why didn't you stay out longer and catch more fish?"

The Mexican said, "With this I have more than enough to support my family's needs."

The tourist then asked, "But what do you do with the rest of your time?"

The Mexican fisherman said, "I sleep late, fish a little, play with my children, take siesta with my wife, Maria, stroll into the village each evening where I sip wine and play guitar with my amigos, I have a full and busy life."

The tourist scoffed, " I can help you. You should spend more time fishing; and with the proceeds, buy a bigger boat: With the proceeds from the bigger boat you could buy several boats. Eventually you would have a fleet of fishing boats. Instead of selling your catch to a middleman you would sell directly to the processor; eventually opening your own cannery. You would control the product, processing and distribution. You could leave this small coastal fishing village and move to Mexico City, then Los Angeles and eventually New York where you could run your ever-expanding enterprise."

The Mexican fisherman asked, "But, how long will this all take?"

The tourist replied, "15 to 20 years."

"But what then?" asked the Mexican.

The tourist laughed and said, "That's the best part. When the time is right you would sell your company stock to the public and become very rich, you would make millions."

"Millions?...Then what?"

The American said, "Then you would retire. Move to a small coastal fishing village where you would sleep late, fish a little, play with your kids, take siesta with your wife, stroll to the village in the evenings where you could sip wine and play your guitar with your amigos."

</comment></comment></comment><comment><USER3> I find that for me, the biggest efficiency gains are not necessarily changes that _save time_ but rather changes that _reduce cognitive overhead_.

<comment><USER5> Operational efficiency analysis originally came from optimizing military operations in WWII, and it cut its teeth in industrial production in the following decades. The history shows. As a discipline, it's still focused on lowering the amount of time, labor, and money to achieve well-defined objectives (and to be fair, it's very good at it).

The field is still somewhat lost in optimizing creative work, like coding. I definitely agree that cognitive load is the operative bottleneck in a large swathe of non-industrial work. I think that operational efficiency research probably could be used to good effect there if it were applied correctly, but the problems are still poorly understood by the experts, so it's a while off.

<comment><USER6> Well, the time and motion stuff he's talking about actually go back further, to Frederick W. Taylor in the late 19th Century. Robert Kanigel's biography of Taylor _The One Best Way_ gives a very good history and a much more in-depth analysis than can be compressed into a blog post.

</comment></comment></comment><comment><USER7> I used to work in a place where exact same reason was given for not upgrading developer PCs - "devs will goof around anyway, they might as well do it while build is in progress". No joke.

</comment><comment><USER8> I love the example of moving the printers. For me, every time I get up from my desk for a couple of minutes, I get a little refreshed, and I come back more productive than before. Having to walk a little ways to get a print out is a great recharge to my mental batteries. A shorter walk would translate into less of a recharge.

Of course, I could also easily see how if you were focused on something, walking a long ways to the printer might be just enough of a distraction to make you lose your focus. I imagine short "breaks" like walking to the printer would effect everyone a little differently.

<comment><USER9> Sure, but should you be recharging your mental batteries (reducing cognitive overload) based on what documents your printing?

Short breaks and walks are wonderful and productive, but not necessarily at the times your printing.

</comment></comment><comment><USER10> I completely agree that increasing time at a desk doesn't mean much in terms of productivity, specially when the activity in question involves a lot of mental effort. I like how this article talks about time spent working: <http://www.joelonsoftware.com/articles/fog0000000339.html>

</comment><comment><USER11> Echoing the mentions of cognitive load, I get the impression that only about an hour or two of "forceful mental effort" - the period when you're hovering outside of a flow state and have to reassemble the problem you're working on - actually takes place during work hours.

This would account for why it becomes incredibly difficult to polish up creative work after a certain point(fit+finish of software, detailing artwork, tone and timbre in music); once you've solved all the big problems. You're spending all your time on figurative hands-and-knees, straining to find the little things - even though you may know how to attack a problem once you're aware of it, collecting the necessary data to turn the process into a fast feedback loop is hard. Hence why polish work is absolutely exhausting, because you're constantly knocked out of flow.

</comment><comment><USER12> The article seems more to illustrate the pitfalls of incorrectly identifying the bottleneck in a process, thereby fixing the something that isn't broken. He points out, rightly, that time isn't always the bottleneck. But any efficiency analysis that blindly made that assumption without any checking should be thrown out.

</comment><comment><USER13> An important jump in general happiness in my life occurred when I stopped worrying about efficiency when standing in line in the supermarket, when stuck in the slow lane or when doing some maintenance around the house.</comment>


Show HN: Growth Hack and UX Ideas - <AUTHOR> http://growth.userium.com/

<comment><USER2> you could add tagging and/or categories</comment>


Why does GitHub anonymize DMCA takedown requests? - <AUTHOR> https://github.com/github/dmca/commit/5476ab2ffe18a286a1476293276c3149c0c2d50d#commitcomment-442132

<comment><USER2> Why would they publish the sender's contact information?

More disturbing is that Sony requested all available contact information for the offending users .... it would be much more interesting to ask if GitHub honor that.

<comment><AUTHOR> Why would they _not_?

On one hand, the person sending the takedown request is afforded the courtesy of anonymity.

This, while he (or she) is accusing someone who is most certainly _not_ anonymous of breaking the law, & demanding the identities of other users.

That is unfair, & unjust.

<comment><USER2> These are two unrelated things in my opinion:

1) GitHub is anonymizing the sender on DMCA notices they publish.

They anonymize it because they're not The Pirate Bay exploiting someone else's work and keeping teh internets riled up so the ad impressions keep coming. You should not expect them to instigate or facilitate or even just _enable_ retaliation, they gain nothing and risk plenty by taking a more antagonistic approach to publishing DMCA notices.

2) Sony hopes a DMCA can be used in lieu of a subpoena.

This is not the same as removing senders.

<comment><AUTHOR> I'd express it slightly differently:

A Sony employee is publicly accusing a non-anonymous GitHub user of breaking the law, and at the same time demanding the identities of GitHub users in the hopes that GitHub will comply out of courtesy (i.e. without a subpoena). At the same time, GitHub is providing him or her with anonymity.

<comment><USER2> Right, but it's just a _coincidence_ that it's Sony and that they're _also_ hoping to get that stuff - GitHub's policy is to _always_ anonymize the sender regardless.

<comment><AUTHOR> Yes, that's true. My question was _why_ that's their default policy. What is the point of anonymizing requests? I certainly had no expectation of anonymity when I employed the DMCA to take down unauthorised copies of my software from download sites.

<comment><USER2> So as not to cause problems for themselves or others.

Imagine you're a legal guy at bigcorp and you issue a DMCA because some clown uploaded [something shiny] to GitHub ... and then 10s or 100s of thousands of people got pissed off it was removed, and shown your phone number, email, etc.

It's really a good policy for them to have - they don't need the fallout from people harassing some guy or some company, and the internet's always looking for an excuse to be outraged.</comment></comment></comment></comment></comment></comment></comment>


The World's Most Boring Build System - <AUTHOR> http://jezenthomas.com/the-worlds-most-boring-build-system/ <comment><USER2> But wait, your build system is not stupidly tied to a library manager and installer! How are we supposed to live with that? Like, you want us to actually consider what's a necessary dependency for our projects to work? Outrageous!

</comment><comment><USER3> I've never seen a good way of dealing with nested directories in make. E.g., say you have the following directory layout:

        /foo/a.js
        /foo/b/c.js
        /foo/d/e.js

And you want minified files to be written to:

        /bar/a.js
        /bar/b/c.js
        /bar/d/e.js

I'm not a huge fan of Grunt/Gulp, but doing this is very easy using those tools.

<comment><USER4> I can see what are you talking about. You need to use order only dependencies for this: [https://www.gnu.org/software/make/manual/html_node/Prerequis...](https://www.gnu.org/software/make/manual/html_node/Prerequisite- Types.html)

<comment><USER3> How do those help exactly? I believe you, but it's far from obvious, and it arguably makes more sense to use Gulp than to fiddle around with obscure features of GNU Make.

<comment><USER4> Order-only prerequisites are needed whenever your rules depend on existence of some directories. So directories become make goals too in a sense. Obviously it's way too tedious to write all that by hand.

You can have some sort of high-level js.mk scattered in each directory of your project, then there's a top level Makefile which will include all those js.mk files and expand them from high level definitions to make rules.

Make is good only if you create a sort of framework around for your domain. However the learning curve is way too steep. I would only attempt to use make if Gulp does its job horribly bad.</comment></comment></comment></comment>


Intel launches all-new PC architecture with Core i5/i7 CPUs - <AUTHOR> http://arstechnica.com/hardware/news/2009/09/intel-launches-all-new-pc-architecture-with-core-i5i7-cpus.ars

<comment><USER2> Anandtech's has some more in-depth coverage:

<http://anandtech.com/cpuchipsets/showdoc.aspx?i=3634>

<http://anandtech.com/printarticle.aspx?i=3634> (printable)</comment>


The Decade of Swift - <AUTHOR> https://www.swiftbysundell.com/articles/the-decade-of-swift/ <comment><USER2> I hate to say this, but Swift is to Objective-c, what Scala is to Java....

It was very exiting and promising at first, but it became bogged down due to its sheer run-away complexity and over-academic approach to programming....

To an outsider, or iOS new comer, Swift looks much better than Objective-c, (due to Objective-c weird syntax), but to many insiders, Swift seems like a huge missed opportunity...

The use of Swift, outside Apple's ecosystem is going to be limited.

<comment><USER3> For a language whose nearly exclusive use case is writing Cocoa applications, it's odd how Swift ignored most of what had made Obj-C so good for GUI apps. Instead they just doubled down on everything that C++ was and Obj-C actively had tried to avoid.

<comment><USER4> Would you mind expanding on these feature sets a bit more?

Because I just started playing with SwiftUI/Combine without ever using ObjC/UIKit, I don't know what parts of ObjC shined.

<comment><USER5> Objective-C was a good fit for dynamic, object-oriented GUI frameworks like Cocoa because that's how it itself was structured. SwiftUI and Combine are simply a different way of structuring UI code that fits a lot better with Swift's strengths.

<comment><USER6> Could you expand on that? How do the structures differ?

</comment></comment></comment></comment></comment><comment><USER7> > That's why Swift's expressive and very lightweight syntax

And a few paragraphs later:

      extension Array {
        func sorted<T: Comparable>(
            by keyPath: KeyPath<Element, T>
        ) -> Self {
            sorted { $0[keyPath: keyPath] < $1[keyPath: keyPath] }
        }
      }

I can't say this is lightweight any longer.

My greatest gripe with Swift comes not from Swift itself but from its standard library. When most new languages start with their own standard libraries that are usually interfaces towards C APIs or POSIX, Swift's Foundation is half of MacOS and then some.

I recently needed to read some data from a file in Swift, and it took me quite some time to realise there was no fopen equivalent. Read/write files is a function on String? And getting a file handle is an excercise in figuring out proper dir names and user enums? [1]

There are a few other weird things in the language itself like guards which IMO are an entirely unnecessary construct that can be as easily solved with regular ifs. Or Optionals that have no way of working with them except unwrapping them (either with ! or via guards).

SwiftUI, however, is a very interesting approach, and I hope there are more frameworks (especially UI frameworks) like this.

[1] [https://twitter.com/dmitriid/status/1201441652507844608](https://twitter.com/dmitriid/status/1201441652507844608)

<comment><USER8> The directory thing is more due to sandboxing than anything else. They don't want someone to be able to write an app that can read anything anywhere on your phone, so it has specific directories that have different levels of access and temporality (i.e. one is a temp folder that gets flushed each time you quit the app, if I remember correctly).

It's not that complicated once you look it up, and like most of this stuff, you can mostly write wrapper classes one time to hide the gnarly bits and call your wrapper class to do what you need to do the way you like to do it.

It's been several years since I've had it read from a file, and I actually thought I would click that twitter link and see something super complicated, but it's actually pretty straight-forward. Not a one-liner like some languages, no, but as soon as you want to open something with options (like the encoding in this one), most other languages start looking more complicated like this as well.

Like python's open looks more like this with options: "open(filename, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True, opener=None)". I've opened many a file in Python scripts, but I'd have to look up buffering, encoding, errors, closefd, and opener right now if I wanted to use them (I haven't really in the past)

And Python has 11 different access modes that I often have to look up to remember what all my options are again: r+,w,wb,w+,wb+,a,ab,a+, and ab+

<comment><USER7> > They don't want someone to be able to write an app that can read anything > anywhere on your phone,

And that's the main problem with Foundation which hurts Swift as a language: it was made for iPhone apps, and hardly anything else. I was trying to make a CLI app on the desktop. I gave up and used something else.

> It's not that complicated once you look it up, and like most of this stuff

Yeah, I tried to look it up. It's extremely complicated, and it doesn't help that the documentation tends to spread all the knowledge across dozens of pages with very terse documentation and next to zero examples.

> I've opened many a file in Python scripts, but I'd have to look up > buffering, encoding, errors, closefd, and opener right now if I wanted to > use them

My example doesn't have any buffering, or encoding, or anything. It's just reading a file. There's no chance in hell you can deduce those lines from the documnentation, or find out where to put the files to read from, or find out that it's not the file's job to read/write data, but String type's (wat?) etc.

It doesn't help that the only real example of reading and writing files isn't in the docs, but in a StackOverflow answer (most other examples are either outdated, or use calls to Obj-C libs etc.)

<comment><USER8> It sounds to me like you're just asking for a quick and dirty default that's nice and pithy and short. That's fine, but file i/o tends to get messy and easy to exploit without some safeguards, and doing it "right" tends to be a bit more complicated.

Like part of your complaint above is pathing, and even something as short and pithy as Python (at least in my opinion, that's why I keep going to it to write proof of concepts), in order to do file i/o "right", requires knowing about all sorts of other things.

One thing I forgot to mention in my previous post is paths in Python, which has this whole fun page on it in the Python documentation: [https://docs.python.org/3/library/os.path.html](https://docs.python.org/3/library/os.path.html). Part of the reason for this in the first place is because pathing is handled differently between Unix and Windows systems, so you're supposed to use this library to navigate (or something completely different, glob, which is another thing to look up and understand) instead of just using a open("c:/blah/blah.txt") so that it can be compatible for either OS.

That's not too much different than having to specify a type of directory for Swift, and has the same types of reasons for why it exists, for safety, but it just doesn't let you do something potentially dumb like open('blah.txt') for something quick and dirty, like Python does, which I admit I do abuse if I'm trying to write something quick and dirty myself.

EDIT: This link here shows how you can write a helper function to basically turn the file i/o into a 2-liner, and I'm sure there's ways to make this even simpler: [https://www.hackingwithswift.com/example-code/strings/how- to...](https://www.hackingwithswift.com/example-code/strings/how-to-save-a- string-to-a-file-on-disk-with-writeto)

<comment><USER9> > One thing I forgot to mention in my previous post is paths in Python, which > has this whole fun page on it in the Python documentation: > [https://docs.python.org/3/library/os.path.html](https://docs.python.org/3/library/os.path.html). > Part of the reason for this in the first place is because pathing is handled > differently between Unix and Windows systems, so you're supposed to use this > library to navigate (or something completely different, glob, which is > another thing to look up and understand) instead of just using a > open("c:/blah/blah.txt") so that it can be compatible for either OS.

There is pathlib nowadays that allows you to navigate in very complex situations using a quite nice OOP API.

<comment><USER8> Good to know, thanks :) I've only ever used Python for my own tinkering purposes so I haven't been too aware of any new developments.

But I assume the old ways are still valid code, so if you're working with Python code you may encounter any of now 3 different systems of just navigating paths for file i/o, what the parent claims should be dirt simple.

<comment><USER7> Yes. It is dirt simple, for dirt simple things. It's quite easy _and_ discoverable from documentation for more complex things.

The method in my link (which changed rather drastically between versions):

\- is very much iOS and MacOS specific

\- requires knowledge of quite a few iOS/MacOS-related things (FileManager.SearchPathDirectory is probably 80% Apple-specific)

\- even though it's a "FileManager", it doesn't even let you access/open a file. You have to perform additional operations on the resulting Directory type (.appendingPathComponent)

\- even that doesn't give you a means of opening a file, because in order to read a file, you have to invoke a String constructor. In order to write to a file, you need to invoke a method on a String type. Talk about coupling entirely unrelated things

That is an example of objectively bad API design.

And it's clear from API evolution that it's not even Swift APIs. These are very thin wrappers for _OS 's_ existing Obj-C APIs. I think it's the first among languages: to provide OS APIs and call them a standard library for a language. I don't think even MS did that when they were creating .NET.

<comment><USER10> Microsoft does it all the time with .NET, after all the future of Windows was going to be all .NET.

It just did not worked out that way, as WinDev tanked Longhorn efforts and now we have UWP (aka COM) instead of .NET for OS APIs.

Which are anyway easily accessible from .NET given its COM support.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Swift doesn't seem to be a bad language, but during my brief adventures with it I encountered a major drawback: differences between versions are so great, that searching the web for examples is problematic and you end up with many fruitless attempts and compiler errors. Apple's documentation isn't nearly as useful and readable as that of the Go team.

<comment><USER8> This was definitely true in the past, and might still be true now, I'm not sure, but XCode does a good job of catching Swift errors now and can fix several of them for you, and for those that don't, there mostly seems to be useful StackOverflow answers for the error messages online now.

I took a long break from working with Swift and just started diving into it again, and even though there was two major versions since I last messed with it, it was pretty easy to settle into it, and I've only had to look up how to do things on a case by case basis periodically. Maybe that's just my experience, though, and others have a harder time with it.

</comment></comment><comment><USER12> I can't really imagine Swift ever breaking out of Apple's walled garden. It's a pretty big garden, but the language concedes so much to Objective-C compatibility, it is hard to see any role for it where Objective-C never got a foothold.

Where am I wrong?

<comment><USER13> To install swift on a raspberry pi:

curl -s <[https://packagecloud.io/install/repositories/swift- arm/relea...](https://packagecloud.io/install/repositories/swift- arm/release/script.deb.sh>) | sudo bash

sudo apt-get install swift5=5.0.2-v0.4

[0] [https://lickability.com/blog/swift-on-raspberry- pi/](https://lickability.com/blog/swift-on-raspberry-pi/)

<comment><USER14> HN truncates long URLs, you'll need to indent with spaces for a code block to show the whole thing

<comment><USER13> Probably best just to follow the cite link and learn more about what you might be installing. Its a random blog post I found on the internet.

</comment></comment></comment></comment><comment><USER15> Can someone sell me on Swift over dart or kotlin? They seem to be direct competitors.

Since we're talking about the future of programming, can someone sell me on Swift instead of ocaml, SML, or F#?

I don't see a good reason to pick it outside of targeting Apple devices.

<comment><USER16> > dart or kotlin? ... ocaml, SML, or F#

\+ scala, go, rust, elixir/erlang

Yeah its so much time to learn all this stuff. Its a good reason they probably will all fade, better stick to js/python/java/C#/C++ like everyone else and wait.

<comment><USER17> > better stick to js/python/java/C#/C++ like everyone else

I would change Java to Kotlin here, since Kotlin has a 1:1 interop with Java while having goodies like null safety, type inference and functional programming without the academicism of Scala (and its slow compilation time).

If you also account for the smooth learning, Kotlin is probably the safest bet from these 9 mentioned.

A lot of businesses with Java codebases are already messing with it (and not only for Android).

<comment><USER10> How does that 1:1 interop work for calling Kotlin co-routines from Java, or stuff without @JVM... annotations for that matter?

</comment></comment></comment></comment><comment><USER8> Swift has come a long way. I remember first trying it and XCode acting like it couldn't figure anything out in Swift, and you could almost never bring up an autocomplete or search for references or jump to definitions or any nice feature in an IDE that worked just fine with Objective-C. I decided to give it another shot years later, and I'm working on a simple game in Swift right now, and it's been a much, much smoother experience.

Although admittedly there's still some bizarre behavior. Like this morning while iterating over a simple for loop, XCode decided it was just going to stay on the final item in the collection and keep looping until my memory ran out, over and over again, and I couldn't find anyone talking about this online, but eventually decided to do a "Clean Build Folder" and then Build, and that fixed it (but why did it happen in the first place? So odd!).

And it still doesn't always think a class I wrote or renamed is valid when referencing it in another class, but a rebuild or quitting and restarting tends to fix that.

Still, I'm liking it a lot, and having a lot of fun with Swift now. SpriteKit is great for making games, except for the lack of cross-platform capability, but if the game somehow manages to take off, I can write some wrapper classes to have the same behavior as most of the SpriteKit classes I use and port it easily enough.

<comment><USER18> Most of these all sound like improvements to XCode, not Swift?

<comment><USER8> I guess I should say "My experience in working with Swift has come a long way", because XCode being so crap with it made it a pain in the ass to code in Swift back then, for me, especially considering how rock solid Visual Studio is in comparison.

To be more specific about Swift, though, there used to be a ton of things you had to bridge to Objective-C in order to do back then, and now it seems like there's almost nothing you have to bridge to Objective-C to do unless you want to work with your legacy code (all of their libraries now have Swift support, at least those that I use), and there's now a cool new SwiftUI framework that is very easy to use and very powerful.

</comment></comment></comment><comment><USER19> I like a lot about Swift: strong typing, good support for closures, reasonable abstractions. But there's a lot that I dislike too. A lot. In general, I find the language to be far too trendy and fussy. I get the impression the design was guided by the goal of streamlining snippets of code meant to highlight cool features, gaining undesirable complexity as a result. One example: Do we really need $n function parameters? In just about every other language, a function has parameters, period. Those names are used inside the function. Depending on the language they may be used outside the function too. Swift separates those inside and outside views, permitting different names for both. And then allows for no names at all! I don't care. $n parameters seem to come from primitive languages like sh, and should have stayed there.

get/set/didSet introduces ridiculous complications just so we can pretend that a large number of function invocations look like assignment statements. This was a cool idea in C++, briefly, and then we discovered that having arbitrary code hide behind what looks like an ordinary assignment statement was a bad idea.

Extensions also remind me of C++ excesses. It is difficult to look at a piece of code involving a variable some type and be sure that I understand how that type works. The problem is that the code implementing the type is not in one place. There is the type definition, but then there are extensions. Possibly many of them. Defined all over the place.

I really dislike the irregularity surrounding let. In one context in unwraps an Optional. In another context it does not. Why?

I got off the Swift train at the release in which associated types were introduced. I'm sure it solves some actual problem, but it sure wasn't clear at the time. (The project ended -- it's not that I decided to go back to Objective C.)

Reference counting is far too intrusive, and it is easy to get it wrong in subtle ways. I find Java's (!) memory model relatively simple, and that's saying something. I understand why reference counting was chosen over GC. I don't have a good answer, but reference counting is just ugly. I actually think I prefer the C/C++ model of explicitly freeing memory.

<comment><USER20> I certainly don't disagree that there's too much C++ in Swift (the Swift architects write C++ for a living, not ObjC, so it's hardly surprising) but it's not due to trendiness. Most of the features you mention derive from direct experience with Objective-C. Function arguments, property accessors (get/set/didSet), extensions (categories), etc. Every one of these things solves a real problem in the field.

I don't understand your comment about reference counting being intrusive. Apple's implementation, ARC, used in Swift and modern ObjC, is essentially invisible to you if you're using native objects.

<comment><USER21> _> I don't understand your comment about reference counting being intrusive._

It's intrusive because you can never really stop thinking about it if you want to write correct code. Here's an example from a very interesting article by Mark Sands [1]:

How quickly can you tell whether or not this piece of code has a reference cycle?

        class ServiceLayer {
            // ...
            private var task: URLSessionDataTask?

            func foo(url: URL) {
                task = URLSession.shared.dataTask(with: url) { data, response, error in
                    let result = // process data
                    DispatchQueue.main.async { [weak self] in
                        self?.handleResult(result)
                    }
                }
                task?.resume()
            }

            deinit {
                task?.cancel()
            }
        }

In my view, reference counting does not combine very well with heavy use of closures.

[1] This is an interesting read: [http://marksands.github.io/2018/05/15/an- exhaustive-look-at-...](http://marksands.github.io/2018/05/15/an-exhaustive- look-at-memory-management-in-swift.html)

<comment><USER22> > How quickly can you tell whether or not this piece of code has a reference > cycle?

I'm curious. Does it? I would have guessed the "weak self" would have prevented it.

> In my view, reference counting does not combine very well with heavy use of > closures.

It's one of the area where one has to be careful for sure! C++ with smart pointers and callbacks exhibits the same problem. And GC based languages make the pattern easier for sure. However I think this is not even the most critical error source in callback based designs. I think threading issues due to callbacks being executed on different threads cause the most trouble.

Therefore I think languages like Javascript and Dart - which only offer a single thread AND GC - are the the easiest to use for callback based designs.

<comment><USER21> Yes, there's still a reference cycle because the outer closure implicitly captures self as well. The article explains it in greater detail.

I agree that threading is another big gotcha, arguably a bigger one. Rust has some mitigations against that sort of thing.

</comment></comment></comment></comment></comment><comment><USER23> I've recentried tried google trends to see if swift was gaining popularity overall :

[https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...](https://trends.google.com/trends/explore?date=all&q=%2Fm%2F010sd4y3,%2Fm%2F0_lcrx4,%2Fm%2F09gbxjr,%2Fm%2F0h52xr1,%2Fm%2F0n50hxv)

Imho There's definitely an issue in the strategy for this language ( or for ios native development since the two are tied).

My guess is cross platform development is eating mobile, and swift has nothing in that area.

</comment><comment><USER24> With Chris Lattner's move to Google and the state of Java it would interesting to see Google embrace Swift and add official support for it to Android.

<comment><USER25> This seems very unlikely to me.

They would need it to interoperate with their existing stack. They chose Kotlin where they reasonably could have chosen Swift and then worked to extend it to work with their existing stack.

Judging by what I would argue has been a lukewarm reception to Swift for Tensorflow, I think it would a very hard sell to convince people within Google to support Swift as a first-class language in the rest of their ecosystem.

They could for example start by adopting Swift for server-side programming for Google cloud and they seem to be putting no effort into that, at least public- facing effort.

<comment><USER24> I'm pretty sure they went with Kotlin before Swift was open sourced, but I agree with you that the likelihood of them doing it is very low.

Swift for Tensorflow hasn't gotten much traction because the overlap between programmers who know swift and machine learning engineers is super tiny. Making the core language differentiable sounds very promising though .

<comment><USER25> Swift was open-sourced 18 months before Google announced support for Kotlin.

There was probably several months or more of debate and work within Google by the time of the announcement, but it seems reasonable that during those 18 months they would have also considered and rejected Swift.

<comment><USER26> It's an interesting value proposition to consider. From one side, Google could have stood to gain by potentially luring the legion of iOS devs onto their platform. At the same time, it's hard to imagine them surrendering any part of their product to a language which is ultimately controlled by Apple at the end of the day (although I suppose they could fork it).

In any case, open source Swift was not ready for prime time at time of release.

</comment></comment></comment></comment></comment><comment><USER27> > due to Objective-c weird syntax

Objective-C is simply regular C with Smalltalk objects added. If you know Smalltalk and you know C then you're golden.

</comment><comment><USER28> I love swift. but i think it is getting lack of traction.</comment>


Why there is an age field in the YC application? - <AUTHOR>

Was not it sufficient to have a I am X years or older checkbox? <comment><USER2> (I don't know anything about YC applications but) Because it's a useful context in evaluating the people. For example, how low quality certain aspects of the application could be perceived might depend on the person's age -- one being that a 22-year-old isn't going to have much of a resume. Also, if somebody makes certain kinds of mistakes, it's less of a red flag if they're in their early 20's, than if they're 40 and should know better.

<comment><USER3> The logic you just proposed is actually illegal in the states when it comes to job applicants, because it disproportionally discriminates against some candidates based on their age.

<comment><USER4> This is true for employers when considering applicants for a job (as you stated); but, as far as I am aware, YC does not employ any of their applicants directly. Since YC is a private funding group, the equal opportunity protections do not apply to their seed fund applicants. So this is more of an ethical issue than a legal one.

</comment></comment></comment><comment><USER5> Because they discriminate based on age. If you are older, you are expected to have done more. This is legal in investments.

</comment><comment><USER6> Is there an age field in the YC application?</comment>


Requestdiff – Send two HTTP requests and visualize any differences - <AUTHOR> http://requestdiff.com/ <comment><USER2> For command-line junkies:

diff <(curl -sS -L [https://httpbin.org/get](https://httpbin.org/get)) <(curl -sS -L [https://httpbin.org/get?show_env=1](https://httpbin.org/get?show_env=1))

<comment><USER2> Actually this is closer still to the output. Requires colordiff:

diff -u <(curl -sS -D - -L [https://httpbin.org/get](https://httpbin.org/get)) <(curl -sS -D - -L [https://httpbin.org/get?show_env=1](https://httpbin.org/get?show_env=1)) | colordiff

<comment><USER3> You can replace colordiff with vim's less tool (/usr/share/vim/vim74/macros/less.sh ) or vimpager ([https://github.com/rkitover/vimpager](https://github.com/rkitover/vimpager)).

icdiff is also nice to have a side-by-side colored diff ([https://github.com/jeffkaufman/icdiff](https://github.com/jeffkaufman/icdiff)). And of course, you could use meld, vimdiff, kompare etc. with the same bash anonymous pipes indirection.

</comment></comment></comment><comment><USER4> Good work but frankly this would be useful if it was:

(1) Terminal based

(2) Supported other types of HTTP requests

(3) Supported request body

(4) Allowed editing request headers

(5) Wasn't so easily exploitable to be used as a proxy or a DDoS relay (server-side bummer):

[http://requestdiff.com/proxy?url1=https://www.amazon.com&url...](http://requestdiff.com/proxy?url1=https://www.amazon.com&url2=https://httpbin.org/get?show_env=1)

<comment><USER5> You might want to take a look at Gavel [https://github.com/apiaryio/gavel](https://github.com/apiaryio/gavel) (and its JS implementation Gavel.js [https://github.com/apiaryio/gavel.js](https://github.com/apiaryio/gavel.js))

(disclosure: I work for Apiary.io)

</comment></comment><comment><USER6> This is very cool! Looking forward to it being open source (also, things from Barcelona rocks ;) )

For people wanting to have a CLI tool instead, John Graham-Cumming's httpdiff might be worth looking at. [https://github.com/jgrahamc/httpdiff](https://github.com/jgrahamc/httpdiff)

<comment><AUTHOR> Thanks a lot :)

Httpdiff is a really good tool and way more powerful than mine.

I've used it multiple times and wanted to try making something that focused more on the request body (which in Httpdiff are saved to temporary files) and that was also a bit more visual than a CLI.

Btw, here is the code! [https://github.com/vdel26/requestdiff](https://github.com/vdel26/requestdiff)

</comment></comment><comment><USER7> Use Vim, it's the best diff tool by a long shot. Syntax highlighting, side-by- side diffs, and code folding (when large contiguous sections are equal)

vimdiff <(curl -s "[https://httpbin.org/get"](https://httpbin.org/get")) <(curl -s "[https://httpbin.org/get?show_env=1"](https://httpbin.org/get?show_env=1"))

It takes some getting used to but once you go vimdiff you'll never go back.

</comment><comment><USER8> Seems like a useful tool; thanks for sharing it!

Two questions:

1) What's the diff logic? At first glance, it looks like JSON is reformatted (maybe canonicalized in some way) and then a line-by-line diff is applied. Is there more to it? Since the tool seems JSON-aware, I was surprised to see an added trailing comma up as a difference.

2) Do you have plans to expand the kind of HTTP requests users can make? It would be nice to use different verbs, headers, and request bodies. Runscope has a similar tool[0] built in that I believe (haven't tried it yet) allows a bit more flexibility, but it would be nice to have a standalone tool available.

[0] [http://blog.runscope.com/posts/comparing-http-requests- using...](http://blog.runscope.com/posts/comparing-http-requests-using- runscope)

<comment><AUTHOR> Great questions:

1) the diff is really simple, line by line and text based. I'm just using this really awesome library to do it: [https://github.com/kpdecker/jsdiff](https://github.com/kpdecker/jsdiff) The JSON is just being pretty printed to be able to do a text diff in a meaningful way.

2) Yes, I do, and thanks for the suggestions! But I just wanted to go with the minimal version first and see if people found it useful.

I didn't know about Runscope's diffing feature. Btw, I'm using a HTTPBin for the sample requests, which is a Runscope project as far as I know :)

</comment></comment><comment><USER9> Comparing URLs comes up from time to time here on Hacker News and at one point inspired me to write a tool that batch compares pages visually:

[http://www.productchart.com/blog/2015-07-19-urldiff](http://www.productchart.com/blog/2015-07-19-urldiff)

It renders a set of pages in a headless browser, compares them visually and alerts you if something changed.

Just a few lines of bash as you can see. But it turned out to be pretty useful. UrlDiff is a regular part of our regression testing at Product Chart now.

</comment><comment><USER10> Reminds me of Diffy, a tool Twitter is using to algorithmically diff test their HTTP-based services.

[https://blog.twitter.com/2015/diffy-testing-services- without...](https://blog.twitter.com/2015/diffy-testing-services-without- writing-tests)

</comment><comment><USER11> Personally I use these from the command line:

[http://www.pixelbeat.org/scripts/urldiff](http://www.pixelbeat.org/scripts/urldiff) [http://www.pixelbeat.org/scripts/idiff](http://www.pixelbeat.org/scripts/idiff)

See also mergely which supports diffing URLs: [http://pixelbeat/programming/diffs/#mergely](http://pixelbeat/programming/diffs/#mergely)

</comment><comment><USER12> Wonderful.

Just the other day I needed something similar and was disappointed that I could find it.

I wanted to discuss something with a remote colleague and to illustrate it I wanted a visual diff of two files. I was hoping there was a nice little web app offering this but I was forced to screenshare (I could have terminal- shared but it was more hassle).

I was hoping for something like Etherpad but with a live visual diff.

</comment><comment><USER13> Not working on Safari Version 8.0.6 (10600.6.3) Mac OS X 10.10.3

From JS Console:

[Error] TypeError: undefined is not a function (evaluating 'Array.from(e)') _toConsumableArray2 (app.min.js.pagespeed.ce.ozGaCBt6Kj.js, line 1) s (app.min.js.pagespeed.ce.ozGaCBt6Kj.js, line 1) f (app.min.js.pagespeed.ce.ozGaCBt6Kj.js, line 1) onload (app.min.js.pagespeed.ce.ozGaCBt6Kj.js, line 1)

</comment><comment><USER14> It's pretty easy to write a recursive diff function that compares JSON strings, in order to avoid the JSON -> diff by line hack that you're doing. But it's a clever hack that easily translates to the command-line.

</comment><comment><USER15> If you're looking for something similar, but with more features that natively understand HTTP, check out www.runscope.com. Full disclosure, I'm an employee and proud of what we've built!

</comment><comment><USER16> Another solution: [https://github.com/xthexder/httptee](https://github.com/xthexder/httptee)

A daemon that sends to two backends, and diffs the results.

</comment><comment><USER17> This would be useful behind a firewall. Is the source available?

<comment><AUTHOR> Not yet, but I'm planning to open source it later today. I will reply here with the Github link. Glad that you found it useful!

<comment><USER18> Awesome, waiting for the Github repo!

<comment><AUTHOR> Here it is! [https://github.com/vdel26/requestdiff](https://github.com/vdel26/requestdiff)

</comment></comment></comment></comment><comment><USER19> I'd like to have a bookmarklet that lets me compare the states of the DOM trees of a website taken at two different times.

</comment><comment><USER20> Requests are made server side, which make this unusable for local/dev environnement purpose. Too bad !

<comment><AUTHOR> Right. I was aiming to do it client-side only but I found out that web browsers restrict the headers you have access to through cross-origin XHR requests [1][2].

So it was a trade-off and I preferred showing all the headers at the expense of having to proxy the calls through a server.

[1] [http://www.w3.org/TR/XMLHttpRequest/#the- getallresponseheade...](http://www.w3.org/TR/XMLHttpRequest/#the- getallresponseheaders\(\)-method)

[2] [http://www.w3.org/TR/cors/#cross-origin- request](http://www.w3.org/TR/cors/#cross-origin-request)

I will make it available on Github later, so that you at least have the option of running it yourself.

</comment></comment><comment><USER21> Doesn't seem to work at all in IE11 / RTM Win10.

</comment><comment><USER22> Use cases?</comment>


Vaccinating the World's Top Predators May Be the Only Way to Save Them - <AUTHOR> http://motherboard.vice.com/read/vaccinating-the-worlds-top-predators-may-be-the-only-way-to-save-them

<comment><USER2> They should do it.

Almost every extinction I've read about was caused at the end by an infection of some kind (fungus, parasite, virus, etc). Sure there might have been other factors that weakened the animal or plant, but the nail in the coffin seemed to always be an infection.

Hunting and other animal predators can massively reduce the numbers, but extinct to zero almost always seemed to me to be an infection at end. Without that they seem to hold on at low numbers, but not gone.

<comment><USER3> That may have been true before human beings conquered the Earth. Here are sixty more recent extinctions: [http://en.wikipedia.org/wiki/Category:Species_made_extinct_b...](http://en.wikipedia.org/wiki/Category:Species_made_extinct_by_human_activities)

<comment><USER4> Brace yourself for the HN downvotes!

</comment></comment></comment><comment><USER5> The video can have another hidden meaning (apart that the constatation that humans are inherently stupid). This ill tiger is acting like a poisoned predator. The fact is that top predators are being systematically erradicated in a lot of places and to blame a virus as main cause is as convenient as naive.

[https://www.youtube.com/watch?v=SYN0z52x4pw](https://www.youtube.com/watch?v=SYN0z52x4pw)

[https://www.youtube.com/watch?v=PLaLUyH4-vo](https://www.youtube.com/watch?v=PLaLUyH4-vo)

9 of each 10 wild lions living in Africa 60 years ago were exterminated in just one human generation. Our generation. We will not save them only with vaccines.

</comment><comment><USER6> Maybe NOT vaccinating any of us real top predators may be the best way to save the rest of the predators.

</comment><comment><USER7> Could vaccinating these animals effect evolution in some way? Species have to die out for new species to come to the forefront; is it right for us to try and change that? My impulse is to say, "Yes, vaccinate them and hopefully eradicate this virus," but there is always that second thought.

<comment><USER8> What do you think is the downside? Affecting evolution is kind of the point (we don't want them to go extinct).

<comment><USER7> What would be the downside of having dinosaurs around? What would be the downside of me being a Homo habilis and carving this message into the side of a large rock?

Whenever humans meddle with the environment there are drastic unintended consequences. I get it, they're charismatic animals and that's probably why I'm being downvoted, but I don't think this is a particularly unreasonable dissenting opinion.

<comment><USER9> _What would be the downside of having dinosaurs around?_

Dinosaurs couldn't possibly still be around. They existed in an era with a much more dense atmosphere and a much higher concentration of oxygen (30% vs 16%, iirc). The type of lung they had and the size of body they had -- they would suffocate here in our current atmosphere. It would be like a really bad case of altitude sickness.

I think that's a very different scenario from what this article talks about, where humans have basically created this virus by domesticating dogs and having a fairly homogenous population of domesticated animals globally and now there are several billion humans...etc....and it is killing wild animals that shouldn't be all getting exposed to the same illness.

I really think this is a very different thing from natural extinction of dinosaurs.

</comment></comment></comment></comment><comment><USER10> Wait, but what if the lions get autism?

<comment><USER11> A tiger with down syndrome made the news a while back.

[http://www.pbh2.com/wtf/meet-kenny-an-inbred-white- tiger/](http://www.pbh2.com/wtf/meet-kenny-an-inbred-white-tiger/)

<comment><USER12> Except that Down syndrome isn't the result of inbreeding. Down syndrome is a very specific genetic disorder.

That's a dumbed-down explanation from a third-rate viral site, which exists solely to generate clicks from Facebook, and not an actual medical or scientific description of the tiger's condition.

</comment></comment></comment><comment><USER9> I am kind of moderately anti-vax, but reading the article makes me feel this is worth a shot because of this:

 _Previous attempts to control the spread of CDV into wild populations focused on stopping the virus at the presumed source—domestic dogs. Unfortunately, research now shows that top predators are probably contracting CDV from smaller wild animals that act as intermediaries. The simplest solution, then—ensuring that humans vaccinate their pets—may no longer be an effective option._

Edit: So admitting to being moderately anit-vax is adequate reason for being downvoted to hell, even though it was given as a qualifier to strengthen my statement that this plan to vaccinate big cats sounds like it has merit.

Wow.

<comment><USER13> I'm curious what is the basis for being anti-vax? Is there science behind that notion? To me it appears irrational, but I'm up for an alternative take out of curiosity.

Sometimes I wonder why people with this conviction dont just move to locations of low vaccination. I hear places in SE Asia, some parts of Africa have low vaccination rates, more out of poverty than conviction, but low rates non the less

<comment><USER9> I have a deadly, incurable medical condition for which an annual flu vax is routinely prescribed. I was diagnosed late in life, just before I turned 36. Doctors told me bluntly "People like you don't get well. Symptom management is the name of the game." But it is genetic, so I was born with it, so I felt strongly that now that we knew why I was always sickly, we should be able to do a better job of dealing with my health than the years before that when I knew something wasn't right but did not know what and doctors acted like I was a hypochondriac.

In part due to happenstance, in part because doctors were not really doing much for me, I sort of fell into a lot of alternative med stuff. I began getting gradually healthier, even though I had spent a year at death's door. All of the people who were actually helping me get stronger while doctors wrote me off for dead were very strongly anti-vax.

The first two or three years following my diagnosis, when I was prescribed the flu shot, my doctor said 'Sign here and roll up your sleeve." and gave it to me right then and there. Then one year my check-up was a few weeks before the vaccine was available, so he wrote me a prescription. By then, I was already seeing a lot of gains from the "crazy" alternative med stuff I was doing. It was easy enough to just not get that prescription filled. I haven't had another vaccine since then.

Fourteen years ago, I nearly died and spent 3.5 years in bed. Now, I walk four or more hours a day and I am gradually getting my life back.

I am not on some campaign to convince people that vaccines are bad. I don't have strong feelings one way or the other. For complex reasons, I happen to be in a position where I can reasonably comfortably fence-sit on this issue and not develop a strong opinion. But, as things stand now, I don't plan to get any more flu shots. I think I am better off using other tactics to protect my health.

<comment><USER14> Flu vaccines aren't about protecting your health, they're about protecting everyone's health. By not vaccinating, you're contributing to the elimination of herd immunity[1], ensuring that people who _cannot_ vaccinate for whatever reasons (too young, compromised immune system, egg allergy, etc) are at a significantly higher risk of contracting the disease and putting their lives at risk.

Unfortunately, this isn't one of those situations where you can fence-sit, because fence-sitting means you don't get vaccinated, which undermines public health and allows for the accelerated spread of diseases that can cripple or kill other people.

[1] [http://en.wikipedia.org/wiki/Herd_immunity](http://en.wikipedia.org/wiki/Herd_immunity)

<comment><USER15> Partly disagree in this case.

So few people take the flu vaccine that there's no possibility of establishing general herd immunity, even if the experts guess right every flu season (this year they didn't for the Northern Hemisphere, or at least the US). On the smaller scale it's wise, e.g. now that I'm living with my 81 year old father, partly to help take care of him, that's an additional reason I take the vaccine.

<comment><USER16> Targeted herd immunity works even at low levels. (Ex: staff at nursing homes.) The benifit it simply exponential (Assuming the vaccine is not 100% effective but transmission chances are low.)

</comment></comment></comment></comment></comment></comment><comment><USER4> Very sad, and yet, sadder still is that we don't see ourselves for the locusts we've come to be.

<comment><USER17> So, have you got a solution?

<comment><USER4> I don't, really; the obvious one of using unregulated power, bring in far too much chaos, and hence useless.

I'm actually surprised that this view is so unpopular here...

<comment><USER17> I dunno, your statement is kind of anti-growth. Calling humans locusts, at least to me, brings the image of some greeny who would advocate genocide for the sake of the planet.

<comment><USER4> Sorry, I guess I should fully weigh the connotations of the words I use.

I certainly am not Anti-Growth; but I do believe that per-capita Growth can be accomodated with a decrease in the nominal economy. I think, as yet, the only known, surefire way of doing this is by improving education (esp. that of Women) and the economy.</comment></comment></comment></comment></comment>


Worldwide observations confirm nearby 'lensing' exoplanet - <AUTHOR> https://phys.org/news/2019-11-worldwide-nearby-lensing-exoplanet.html <comment><USER2> 1600 lya is only 'nearby' compared to 2600, still a lucky find!

<comment><USER3> It is actually quite nearby on astronomical scales. For reference, the milky way is 105,700 light years in diameter.

</comment></comment><comment><USER4> Could someone share info about how astronomers know about microlensing effects?

I (educate) guess that we start by setting eyes to a specific star and then compared its image before and after X amount of days. Then, if there is a huge delta, then people would zoom into that star again to understand why there was a difference.</comment>


Anonymous Takes Revenge On Security Firm - <AUTHOR> http://blogs.forbes.com/parmyolson/2011/02/06/anonymous-takes-revenge-on-security-firm-for-trying-to-sell-supporters-details-to-fbi/ <comment><AUTHOR> The torrent: <http://thepiratebay.org/torrent/6156166/HBGary_leaked_emails></comment>


Ant Design - <AUTHOR> https://ant.design/ <comment><USER2> It's got some downsides (or maybe not I could be wrong on these parts) from what I've seen:

1\. if you want the antd style for a particular component I do not believe you can import a css file specific to just that component. you are importing the full Antd css. it's sort of big. If anyone knows how I can import just the css for a component please show me how.

2\. the Antd css has a lot of rules that address generic html elements, i.e. not antd classnames only. This makes component reuse more difficult.

<comment><USER3> You're absolutely right about both of these points. I don't think they provide any solution to #1, but they do include a workaround for #2, even if it's pretty dirty: [https://ant.design/docs/react/customize-theme#How-to- avoid-m...](https://ant.design/docs/react/customize-theme#How-to-avoid- modifying-global-styles-)?

</comment></comment><comment><USER3> It's a fantastic UI library, and I'd highly recommend it to anyone using React.

<comment><USER4> How does it compare to the more popular Material UI?

</comment></comment><comment><USER5> Small, 2018: [https://news.ycombinator.com/item?id=16719999](https://news.ycombinator.com/item?id=16719999)

Medium, 2018: [https://news.ycombinator.com/item?id=16684513](https://news.ycombinator.com/item?id=16684513)

Large, 2016: [https://news.ycombinator.com/item?id=13053137](https://news.ycombinator.com/item?id=13053137)

Related from 2019: [https://news.ycombinator.com/item?id=18758697](https://news.ycombinator.com/item?id=18758697)

</comment><comment><USER6> I think I've seen enough: [https://imgur.com/gallery/oZJ9qO7](https://imgur.com/gallery/oZJ9qO7)

<comment><USER7> So your issue is with the term design language?

<comment><USER8> Not OP, but I believe its because it crops the button indicating it is not good for responsive layouts.</comment></comment></comment>