Ask HN: How would you handle items' IDs beyond 2^64 (18.4 quintillion)? - <AUTHOR>

Every item (submission/comment) on Hacker News is assigned to a unique ID number.<p>Assuming that 2^64 is now the maximum number a computer can handle at once, what's the best way you can handle the ID numbering system when there are more than 2^64 items? <comment><USER2> there won't be more than 2^64 items.

[https://www.wolframalpha.com/input/?i=2%5E64+divided+by+%28p...](https://www.wolframalpha.com/input/?i=2%5E64+divided+by+%28population+of+the+world+in+2050%29)

<comment><AUTHOR> The number 2^64 is not the limit itself here. What I meant with it is the number of unique digits combinations we can have at 64 slots. Your calculation would rather be [https://www.wolframalpha.com/input/?i=99999999999999999999%2...](https://www.wolframalpha.com/input/?i=99999999999999999999%2F%28population+of+the+world+in+2050%29). But this is not what I meant.

What can you do best when you run out of unique combinations and the CPU can't handle more than 64 slots at a time? Upgrade to 128-bit architecture is not the answer I'm seeking.

</comment></comment><comment><USER3> The software that HN runs on can handle arbitrarily large numbers. Check it out on [http://tryarc.org/](http://tryarc.org/):

        arc> (expt 2 64)
        18446744073709551616
        arc> (expt 2 65)
        36893488147419103232
        arc> (expt 2 165)
        46768052394588893382517914646921056628989841375232

Note that this isn't converting the number to a floating-point; it's exact precision:

        arc> (+ (expt 2 165) 1)
        46768052394588893382517914646921056628989841375233

<comment><AUTHOR> Perhaps my point wasn't very clear. I didn't mean that a computer won't be able to compute the value of 2^64 or 2^128 or 2^x.

In a 64-bit architecture, the data bus or datapath width will be 64-bit long. That is, we only have 2^64 unique numbers to pass in the CPU at a time. What's the best to do when we need more unique figures? Use unsigned integers, for instance?

2^64 is the number of combinations not the the maximum number itself.

<comment><USER4> > In a 64-bit architecture, the data bus or datapath width will be 64-bit > long. That is, we only have 2^64 unique numbers to pass in the CPU at a > time. What's the best to do when we need more unique figures?

Use data structures that are too big to fit in the CPU all at once. The same way that we did on 8-bit CPUs when we needed more than 256 unique ID values. The problem is vastly more rare with 64-bit machines, but the solution remains the same.

Obviously, comparing such value takes more clock cycles than comparing values that fit in the CPU all at once, but that's the price you have to pay.

> Use unsigned integers, for instance?

Signed vs. unsigned, with the same width, provides the same number of unique values. Just different values. So that wouldn't help.

<comment><USER5> _" Signed vs. unsigned, with the same width, provides the same number of unique values. Just different values. So that wouldn't help."_

Unless you had been reserving negative values to mark errors when returning ids, in which case making use of that top bit as id space lets you double the number of ids. Of course, you could still treat it as signed or unsigned... it's just a possibly related issue.

</comment></comment></comment></comment><comment><USER6> Your assumption is just incorrect. Computers can already handle numbers millions of bits long. The size of the numbers are only bounded by ram and processing power not at an arbitrary limit.

<comment><AUTHOR> You're right, they do handle numbers of millions bits long and rather billions. But a 64-bit architecture allows the CPU's MDR datapath to read numbers only 64-bit long at once.

My question is: what about the case when the number is longer by one bit, let's say? What's the best/most efficient way to handle it?

<comment><USER7> I don't understand this question. Isn't the answer you're looking for just "use a bignum library"?

<comment><AUTHOR> Kind of. I'm looking for a manual and efficient implementation to handle that <=> The speed of arithmetic IS a limiting factor here.

<comment><USER7> So you're just looking for comparative review of different bignum libraries? That shouldn't be too hard to find. Bignum performance is important for several applications, most notably public key cryptography.

Here's a good sort of survey piece to read:

[https://www.imperialviolet.org/2010/12/04/ecc.html](https://www.imperialviolet.org/2010/12/04/ecc.html)

You'll be particularly interested in the limb scheduling optimization, which is tailored to the processor.

<comment><AUTHOR> I'm into figuring out a fast, self-developed mechanism more than using libraries. But you absolutely got it: a solution when the number doesn't fit in a single CPU register.

Great read by the way. Thank you.

</comment></comment></comment></comment></comment></comment><comment><USER8> Put a separate number in front of the id and use that to shard. The historic ids would be a.k.a. 0,<id> and the next lolillion would be 1,<id>

<comment><AUTHOR> You just added two entries to the maximum number of digits a processor can handle at once. I didn't get your suggested solution in full: how would you hande the extra identifier?

<comment><USER8> They only become digits if and when they're parsed out of the textual query string as such. The structure of HTTP query strings is not something the processor cares or even knows about. To it, "=1,333" isn't an equals sign followed by two comma-separated numbers, it's simply 6 bytes of data. The meaning of that data is an application level concept.

<comment><AUTHOR> What I meant with digits is zeros and ones, of course not strings/characters. There's no disagreement about the data context in the lower level.

To be more clear, let's suppose that the maximum a CPU can read at once is one character (8 bits). If we went by your suggestion to add one or two extra characters [on the high level], or 16 bits [on the lower level], the processor won't be able to handle the 24 (8 + 16) at one time, simply because the max is 8 at a time.

<comment><USER9> Are you asking "how can a computer compare strings that are longer than their native word size"

<comment><AUTHOR> Well, not exactly, but rather the most efficient way to deal with elements (big numbers, in specific) that aren't going to fit in a single CPU register. Current libraries I've had a look at has some limitation on the speed of calculations.

</comment></comment></comment></comment></comment></comment><comment><USER10> The solution to this problem is as old as Lucretius.

Go to the edge, then add a bit.

Or, whatever, get two computers. Or twenty, they're cheap.

<comment><AUTHOR> Any extra bit added to the edge won't be handled by the processor. Do you think having a cluster would solve such kind of problem efficiently? Especially that HN used to run on one core in the backend.

</comment></comment><comment><USER11> Hash them to 64 bits, deal with occasional collisions, which will be unlikely in any real world scenario.

</comment><comment><USER12> Bear in mind, it would take 1 Billion users posting 18 Billion times each, to reach 2^64. I'm not holding my breath. (and computers can actually handle 128-bit numbers just fine)

<comment><AUTHOR> The whole concept is how to solve problem at its edges, whether 64 or 128, let's say in 10 years time. Plus, would you use IBM System/37 or DEC VAX to run HN? 18 billion posts by 1 billion users will cumulatively make sense in the context of time.

</comment></comment><comment><USER13> How refreshing, a classic style of troll! Upvoted and flagged.</comment>


The March Towards Go - <AUTHOR> http://zef.me/6191/the-march-towards-go <comment><USER2> Zef writes this as if it's completely amazing that people are leaving Node for Go. Node is based on JavaScript. There are arguably more things wrong with JavaScript than with any other popular programming language, as evidenced by book titles like "JavaScript, the good parts". This is common knowledge; we're all trying to do good work _despite_ JavaScript, seldom because of it. So Node: it's fast, we can share code with the browser, but it's a bitch to use. We knew that when we signed up.

Conversely, Python is a great language but it's not as easy to make it go fast. It's slow, but it's great to use. We also knew _that_ when we signed up.

It's great that Go is getting more mainstream adoption! Deservedly so. But it's probably still easier to be super-productive developing a CRUD app in Ruby or Python. And it's still easier to share code between backends and web frontends with Node. If you don't need either of that, and you do need performance, then, yes, maybe you shouldn't pick Python or Node.

I agree that Go is a great option to consider, but Zef is framing it a little as a silver bullet, and well, of course it isn't.

<comment><USER3> There are minor details wrong with JavaScript. Normally you don't encounter them in daily use.

Apart from that JavaScript is brilliant. Few other languages can match it's simplicity.

Python falls through because it doesn't have real lambda.

<comment><USER4> > There are minor details wrong with JavaScript. Normally you don't encounter > them in daily use.

If you really believe that, I can only assume that you either don't have very much experience with Javascript and haven't yet been burned (or haven't yet discovered that you've already been burned), _or_ that you don't have any experience outside of Javascript and therefore are not aware that languages exist that have all the niceness of Javascript but almost none of the bad stuff. I say this as someone who is primarily a Javascript developer professionally.

Yes, there are languages that are worse than Javascript to work in (I'm looking at you Java and PHP), but there are many that are much better. It's worth noting that everything that is good about Javascript already existed in other languages before Javascript got invented. In fact Brendan Eich has stated that his intention was to create Scheme for the browser. If only he had just used Scheme as it existed, things would have been so much better!

<comment><USER5> I've been working with JS professionally for the last 3 years...priorto that, spent many years with C++/SQL/etc...the statements that people get "burned" by JS (pesumably because of the weird coercion or floating-point comparisons?) I've never understood...maybe I just write my code in a weird way that insulates me from those things...I've never experienced more than a "minor surprise" in dev - certainly never been "burned".

<comment><USER4> > maybe I just write my code in a weird way that insulates me from those > things

Maybe you do. I certainly strive to. But don't you sometimes have to work with other people's code too? I recently inherited a 10 years old codebase written by people who had not heard of implied global and didn't use the var keyword.

In my previous job I had to educate several frontend developers about the dangers of using parseInt without a radix parameter. The ones that already knew did so because… you've guessed it: They had previously gotten burned.

I worked on a project in which the backend had a rest API that served json data. Among the data were some rather long integer IDs. But since javascript doesn't have integers but only floats (of all things), the IDs got rounded off in weird ways. Not very useful as IDs after that! If all everyone ever used was javascript, this would perhaps not have surprised anyone, and it would be known by all that you shouldn't use a Number as an ID, but always only Strings. The problem is that most back-end developers are not Javascript experts and in their world it is only natural that you should be able to use a number as an ID (as it should be IMO).

As time goes by and you get experienced, you begin to learn all of these little 'quirks' of the language, and maybe you start to adopt a defensive style of programming that insulates you from the worst of them. And if you've never experienced anything else, it's easy to tell yourself that this is just the way things are, and that it's probably the same for everyone. But I'm here to tell you, that this is not the case! Sure, other (better) languages have surprising behaviours too, but they are mostly good surprises that empower instead of restrict.

<comment><USER5> > But don't you sometimes have to work with other people's code too?

Yes, I suppose I have gotten "burned" by other people's JS quite a bit...but not any more than I've been burned by other people's bad SQL or C++ or C#, to be honest.

> Sure, other (better) languages have surprising behaviours too, but they are > mostly good surprises that empower instead of restrict.

I am assuming that by "better" languages you are meaning type-safe ones... I know this is not a popular opinion, but I honestly just prefer dynamic typing. When I code, there is only room for one whiny child in the equation: me. Not the language I code in. I would rather not have my language throw a temper- tantrum and break down because I gave it something a millimeter different than what it was expecting. If the object is supposed to have "thing" and it has "thing" then shut your mouth and use it, language. Where JS gets weird is that it tends to put "thing" there in some cases where you didn't expect it, but honsetly after learning the few cases where it does that, I've never had a huge problem with it - I think, like everyone, I bumped into some mild surprises (ya the radix thing with parseInt and [] == false and soforth), but they were never more than just mild surprises in development. I know it drives people insane - and some people will swear that there is no way to build large systems with it. I suspect those people are the same ones who asked the teacher for extra homework for the whole class when they were kids. That was just never me, and I would just respectfully disagree. To me JS is just a ton of fun and there are too many people making too many awesome things with it to ignore. Apparently TJ got tired of it - maybe I will one day, too.

Until then, I just wish people would recognize that the reason JS "won" the language wars of the mid-late aughts was specifically _because_ of the "get- out-of-the-way-and-let-coders-code" dynamic built into it - IMHO the modern web could not have been built with anything else. If you have any recos for "better" languages that share that dynamic, I would be very interested in hearing them.

</comment></comment></comment></comment></comment></comment><comment><USER6> This sums up the problem:

 _> Not looking at Go yet? It may be a good time to do so now — everybody else is._

That's going to be a large albatross around Go's neck, as it has been around node.js', and Rails before that. Large amounts of developers flocking to a new thing because "this is the thing to use now and if you don't you're dead meat".

Personally, I thought Node.js was a _terrible_ platform for serving dynamic web sites. It is, however, a great platform if you need to make a reasonably performant general server with minimal effort (such as a message broker for example).

Likewise, people will now order their projects in Go whether it makes sense given the requirements or not. 20 years of Go experience will be needed on CVs. And when Go inevitably fails at certain things, "everybody" will move to the next thing - probably Rust, thereby completing the migration away from dynamic scripting.

This is not reasonable, is it?

<comment><USER7> > That's going to be a large albatross around Go's neck, as it has been around > node.js', and Rails before that. Large amounts of developers flocking to a > new thing because "this is the thing to use now and if you don't you're dead > meat".

TJ's blog post is basically like if DHH ditched Ruby/Rails for Go.

> Personally, I thought Node.js was a terrible platform for serving dynamic > web sites. It is, however, a great platform if you need to make a reasonably > performant general server with minimal effort (such as a message broker for > example).

Totally agree with you,nodejs is not a silver bullet.

<comment><USER8> It's more like Zed Shaw leaving Ruby for Python.

That happened. So did lots of other stuff. Same as it always was.

</comment></comment></comment><comment><USER9> "In the past week I've rewritten a relatively large distributed system in Go"

Maybe I don't have any programming talent at all, but I cannot even imagine to rewrite a 'large distributed system' in a week. The not-too-large distributed systems I worked with had years of thinking behind them, I could not even type in the characters of the code in a week.

<comment><USER10> You obviously don't know TJ...

[https://github.com/visionmedia](https://github.com/visionmedia) [http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ- Holowaychuk-...](http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk- so-insanely-productive)

<comment><USER11> What am I supposed to take away from these links, other than the technical culture's self-defeating tendency to lionize individuals to fit a hero narrative?

<comment><USER12> If you read the second link, it's presented that that guy is actually a group of people working under a phony name, to give the cult a "hero". Drum up hype, etc.

It's been done before too! [http://en.wikipedia.org/wiki/Nicolas_Bourbaki](http://en.wikipedia.org/wiki/Nicolas_Bourbaki)

\---

Nicolas Bourbaki is the collective pseudonym under which a group of (mainly French) 20th-century mathematicians wrote a series of books presenting an exposition of modern advanced mathematics, beginning in 1935. With the goal of founding all of mathematics on set theory, the group strove for rigour and generality. Their work led to the discovery of several concepts and terminologies still discussed.

</comment></comment></comment></comment><comment><USER13> I've often heard that Go founder were surprised that Go seemed to replace python more than C++ or C which were the initial targets. By judging from the given examples it seems that it isn't the case : people seem to come to Go when they start looking for performance. Instead of writing C modules and using them from python, they just switch everything to Go.

I'd be curious to know how many start ups prototype their first software version with Go.

Note : as a coder that writes a lot of python, seing dropbox switch to Go in parallel to python so often having toxic discussions about python 3 vs 2 is _really_ painful.

<comment><USER14> Because thanks to our experience with strong typed languages with native compilers and type inference, we know better.

Many of us have had the fortune to work with C, C++, Ada, .NET, Java, Delphi, Modula and Oberon derived languages, ML language family.

So we already know what modern strong typed languages, with native compiler toolchains, are capable of in terms of language features. And going Go feels a bit backwards.

Regarding Python, I never saw it more than a scripting language for system administration. ML based languages provided a better experience in terms of both performance and productivity.

<comment><USER15> .NET isn't a language.

The languages you list really suck compared to Go. They are ridiculously verbose. Goroutines in particular are really quite nice.

<comment><USER14> > .NET isn't a language.

It is easier to name the eco-system than all the languages with available compilers targeting .NET.

> The languages you list really suck compared to Go. They are ridiculously > verbose.

Except they embrace the last 30 years of language research.

> Goroutines in particular are really quite nice.

Goroutines are nothing new. Modula-2 already had them.

<comment><USER15> Gosh this reply is ridiculous.

We're talking about languages and .net isn't a language. The differences between visual basic and f# are vast.

Are you saying the last 30 years of language research dictate that languages should be more verbose?

Comparing go-routines to modula-2 is disingenuous at best. Multiprogramming is nothing like multithreading.

</comment></comment></comment></comment></comment><comment><USER16> TL;DR It is very likely that TJH is a hive mind.

FYI some question TJ Holowaychuk's 'person.' A glance at his github commits would lead you to believe he is some open source prodigy, but there is a curious case being built (share=1 trick, no Quora login needed): [http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ- Holowaychuk-...](http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk- so-insanely-productive?share=1)

<comment><USER17> Lol, he works at segment.io and he is very much one person.

<comment><USER16> Have you met him?

</comment></comment></comment><comment><USER18> I don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful. I guess compared to javascript I can see the advantages though

<comment><USER19> Go could be improved in many ways. It lacks facilities that what we consider modern programming languages have, e.g. object-oriented programming, generics. The existing Goland solution to the generics problem is to have an almost duck typing approach of doing everything via interface{}. These are the cons.

The pros are of such value that they more than compensate for the cons: first class facilities for building concurrent programs and distributed systems. These are language features such as go-routines and channels and standard library includes for networking and RPC.

These are so great at what they do that they make programmers like me, who like Go, overlook the suck that comes from the existing typing system.

My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels. Directly as language features. AFAIK, the existing GIL in the reference Python and Ruby interpreters makes adding true goroutines impossible.

<comment><USER20> > The existing Goland solution to the generics problem is to have an almost > duck typing approach of doing everything via interface{}.

I see this repeated again and again. It's wrong.

The "solution" to the generics problem is to not try to do anything that is generic, but do it specific: re-write that sort every time you need it for a new type.

People who have some experience in Go seem to tell that when you go this path you actually realize that you won't write them hundreds of time as was feared; it's completely manageable. Plus, you have your "sort" re-implementation right next to the struct definition, so you know it is sortable.

<comment><USER19> I knew about this solution. It's just that my inner Ruby dev screams "DRY!". Obviously it's so repetitive that it would be a bad sign in other languages.

I like more the solution used by the sort package. You can write generic code that delegates specific type code to a few well-defined functions, like ones that sort.Interface defines.

More here: [https://code.google.com/p/go- wiki/wiki/GoVsGenerics](https://code.google.com/p/go-wiki/wiki/GoVsGenerics)

</comment></comment></comment></comment><comment><USER21> Go may well be better for many apps than js or C++, but there are other languages out there. If you're looking for a new language it's worth considering more possibilities, e.g. see [http://roscidus.com/blog/blog/2013/06/09/choosing-a- python-r...](http://roscidus.com/blog/blog/2013/06/09/choosing-a-python- replacement-for-0install/)

<comment><USER22> Incidentally, your link includes a great example of Go's error handling - which is inevitably what _actually_ happens in languages without exceptions: errors are silenced and the program marches on, each step making less sense than the previous. It's a good talking point that you can always check error values - but it never really happens, in part because library designers try to avoid putting the burden on themselves and their users:

"Getenv returns the empty string and continues. Then Go somehow manages to parse the empty string as an empty JSON list and still continues. Then it tries to interpret the first of the user arguments to the program as the path of the program to run and execs that instead! Utter failure."

I happened to write about it just before Go came out here: [http://yosefk.com/blog/what-makes-cover-up-preferable-to- err...](http://yosefk.com/blog/what-makes-cover-up-preferable-to-error- handling.html)

It seems that having exceptions in the language is a great predictor for libraries/built-ins barfing upon bad input vs silently producing garbage (as in JS's "undefined" string produced from undefined values and propagated, or Go's behavior above, etc.) For instance Lisp's NTH produces garbage and it predates Lisp's exception handling features whereas AREF was added later and indeed complains loudly, etc.

<comment><USER23> _> It seems that having exceptions in the language is a great predictor for libraries/built-ins barfing upon bad input vs silently producing garbage_

Maybe so, but having exceptions in a language is also a good predictor for the misuse of exceptions for purposes other than error handling. For instance, Python has the StopIteration exception to signal the end of an iteration.

Exceptions force API designers to decide whether or not a situation is exceptional enough to force a stack unwind on the caller's end. That's not something that's necessarily decidable from the point of view of the library.

For instance, say you have a function http.get(url). Should a 404 response automatically raise an exception? What about a 301? A network issue? Surely, for a crawler, a 404 is not exceptional enough to merit a hidden goto that unwinds the stack frame (by default). The designer of the http library cannot decide which status code is exceptional in every application.

It's similar with the results of SQL statements, file system access and all sorts of other IO related stuff.

It seems to me that the more complex a system is, the more it needs a very specific error handling strategy anyway and doesn't benefit from library designers' opinions about what is and isn't worth a stack unwind.

That said, I do hate seeing

      if err != nil {
        return nil, err
      }

on every other line of code.

<comment><USER24> > Maybe so, but having exceptions in a language is also a good predictor for > the misuse of exceptions for purposes other than error handling.

Is that really a problem? I once hated such uses, but could never point why.

<comment><USER23> I think it's a problem for two reasons:

First of all, sudden stack unwind comes with a greater mental burden than regular structured code. Something implicit is happening that violates the expectations we have based on what we can see.

Secondly, consistency is always important because inconsistency forces us to think about things that we shouldn't have to think about, which lowers our productivity.

</comment></comment></comment></comment></comment><comment><USER25> > Statically linked binaries make for easy deployment

They certainly do, but have we solved the problem of statically linked bugs yet? What happens when the next heartbleed happens?

<comment><USER26> How many people updated their libssl packages without restarting the server processes, thinking they're safe when they really aren't?

With a bug in such a central place you'll have to touch everything - could as well rebuild everything, when your processes are prepared for it.

</comment></comment><comment><USER27> When node first appeared, the thought of server side JS gave me shivers, maybe I should trust my instincts more often.

<comment><USER28> It's good when you are writing it but someone else will be maintaining it :).

</comment></comment><comment><USER29> I was kind of expecting this. Although I like Go (and prefer it to NodeJS), I hope forthcoming feedback on TJ's "life choices" does not degrade into a "Let's move from Node to Go" echo chamber.

More importantly, I hope the Node community's self-centred "holier than thou" doesn't bleed over, given that Go has (at least so far) kept a fairly high standard of discourse.

That said, I, for one, welcome more contributors to the Go ecosystem. It is a good systems programming language, but it needs a few more "horizontal" libraries to make humdrum tasks (like parsing, accessing databases, etc.) more palatable.

(edit: removed incorrect double negative)

</comment><comment><USER30> It's not surprising that the same crowd that started switching to Node.js en masse a couple of years ago is redoing it for Go :)

</comment><comment><USER31> There are a couple of things which have stopped me getting into go which I am ignorant about.

\- Lack of decent IDE with intellisense/good refactoring support.

\- Libraries seem to be globally shared between projects like rvm rather than in the project like nvm.

Am I wrong, misguided or out of date on these things?

<comment><USER32>
        > Lack of decent IDE with intellisense/good refactoring
        > support.

Sublime Text + GoSublime; vim + go-vim.

        > Libraries seem to be globally shared between projects
        > like rvm rather than in the project like nvm.

There's no fixed rule. If you need dependable reproducible builds, current best-practice is to vendor your libraries in your repo.

<comment><USER31> Thanks, sublime tex and vim with plugins are still a long way off what you get from a good ide. Just glancing there is no real refactoring support, its more around auto complete.

<comment><USER32> Refactoring in Go is accomplished with `go fix`.

</comment></comment></comment></comment><comment><USER33> It's a shame that the debugging story in Go is still "use GDB". It's really lacking good visual debugger support afaik.

</comment><comment><USER5> So what comes after Go? I only ask because I figure if I start learning that now, by the time they switch again I will have a fair chance of being competent at it by then...

<comment><USER24> I'm taking the oposite route. Once all those people live Go for something else, I'll evaluate it and see if it's any good.

</comment></comment><comment><USER34> So I understand there isn't a go package manager like pip/npm/cpan. Is that correct?

<comment><USER35> See the "Managing Dependencies" section, and comments:

[https://www.digitalocean.com/company/blog/get-your- developme...](https://www.digitalocean.com/company/blog/get-your-development- team-started-with-go/#managing-dependencies)

Also:

[http://peter.bourgon.org/go-in-production/#dependency- manage...](http://peter.bourgon.org/go-in-production/#dependency-management)

More discussion:

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

</comment></comment><comment><USER36> I wonder why they didn't choose Go in the first place. Both languages were introduced in 2009, I remember evaluating both, and choosing Go because it was clearly superiour when the goal was serverside, speed, stability, maintenance and simplicity.

</comment><comment><USER37> I want Go but with a really strong static type system. What do I use?

Haskell's Hackage seems to be full of broken packages.

OCaml seems to be stuck in 1999.

F#/Mono is pretty great, but tough to find quality libraries that work with the tools I use (postgres etc)

Anything I'm missing?

<comment><USER38> As far as I know, Go already has a really strong static type system (int32 cannot be assigned to int for example). Which parts are weak?

<comment><USER39> No generics (parametric polymorphism), no algebraic data types. You should learn some Haskell or Ocaml even if you don't plan on using it in production. Go's type system is weak.

Edit: I don't think there's anything like type classes either but I'm not 100%.

<comment><USER40> > Go's type system is weak.

It is strong enough for me.

I see the lack of algebraic data types and type classes as a feature, honestly. It means I can learn the things I need and start working in 2 days instead of in 2 weeks or a month.

I sometimes need generics, but not frequently enough to miss them.

You think Go's type system is weak. I think Haskell's type system is overcomplicated. So, there.

<comment><USER41> Go's type system being weak is a factual statement. Haskell's type system being overcomplicated is an opinion.

One might prefer a weak type system over a strong type system, but that's a different discussion. The parent clearly expressed that he wants a static strong type system.

<comment><USER42> _Go 's type system being weak is a factual statement. Haskell's type system being overcomplicated is an opinion._

Calling one weak and the other overcomplicated are both completely subjective, biased statements.

And no, some random blog doesn't count as a citation: There are zero legitimate, agreed to sources that will back up your definition. Instead it's people painting broad strokes to bias the world towards their own beliefs.

Just as unreasonably I could say that Go has a Clarified Type System, versus the Conundrum Type System found in Haskell.

<comment><USER41> Are you aware that the notions 'weak' and 'strong' are actual terms used to describe type systems [1] ? Did you bother to look that up before going overboard and immediately accuse me of bias? I don't program in either Go or Haskell.

Now whether Go's type system actually has the property of 'weak'ness is very debatable. But whether it is true or false, it remains a factual statement.

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

<comment><USER42> You should read the first sentence in the page you linked. To make matters even worse, _none of the "weak" notions even apply to Go_, and I thought you were talking about something entirely different altogether given that Go is by zero definitions, colloquial or not, "weakly typed".

The post that set this off called Go's type system "weak". They were not saying that it was weakly typed.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER43> > Not looking at Go yet? It may be a good time to do so now — everybody else > is.

I'll be gladly left behind.

</comment><comment><USER44> > Text processing increased 64 percent just by moving from Node to Go.

And rewriting everything from scratch, plus it's a given that node isn't the best tool for data processing..

</comment><comment><USER45> I agree. JavaScript is weird. I think ECMAScript will make a lot things better, but it will still be a couple of months and it still won't fix it all - still a huge step of making it a really usable language for many things.

Node.js is becoming mature, less trendy. I really find it weird how people compare it age wise with Go. JavaScript is way old than Go or other languages. V8 is also older than Node of course. ECMAScript didn't have breaking changes in a really long time. There are many, many implementations. SpiderMonkey has been used on the server side for over a decade now.

Go looks great. There are some rough edges though and whether really good solutions will build up for these things is a really interesting thing to look at.

It is really nice to see Node.js, Go and Rust emerging in amazing ways, all of them fixing problems in amazing ways. I love how great concepts, like node.js streams and pipes are copied to Go and Rust in ways that match their styles, not just blindly.

All these things even influence languages like Java and C++. Who would have known only a couple of years ago that things would emerge in such ways and that it needs some projects with the idea of yet another programming language. What is even more interesting is that a lot of concepts actually stem from Perl... well, not necessarily the language itself, but libraries, modules or Perl6, which arguably was/is a really ambitious research project. It's a bit how many concepts took ages to be ported from Plan 9 to other operating systems.

Anyway. It is great to see how people nowadays look at other projects and don't judge by first impression anymore.

At least it seems like it. Node.js looked extremely awful to me in the beginning and turned out to actually not be (despite its shortcomings and JavaScript, which also turned out to be nicer). On the other hand projects, like Meteor that looked at least okay in the beginning turned out to be way more awful than they looked when I first heard that they don't even support proper REST.

I know, my opinion on this might not be really popular, but it's amazing to see how so many new concepts emerge, even when they seem crazy, sometimes turn out to be crazy, sometimes turn out to be amazing. It's hard to know where we will stand in a couple of years. However, I don't think only one of Rust, Go or Node.js will make the race and I think none of them will look like they do today in one or two years, especially when it comes to their ecosystems. Just because all of them are too young to be judged upon and all of them are changing too rapidly (or new standards are upcoming, as with ECMAScript), so that nobody really has or can develop a deep understanding of the language/framework yet, not even its developers.

What I really hope though is that there will soon be more big projects than just Docker and a bigger ecosystem.</comment>


System Programming Book in GitHub Wiki - <AUTHOR> https://github.com/angrave/SystemProgramming/wiki <comment><USER2> This is great. Are there such books written in Scheme? I am new to programming and still very ignorant, but in my experience so far Scheme seems to be unbelievably simple and easy. How come people prefer these clunky, unwieldy, unruly and, frankly speaking, scary languages like Java?

<comment><USER3> You can try The Little Schemer

<comment><USER2> Is it about Systems Programming?

<comment><USER3> It's about Scheme and functional programming in general

</comment></comment></comment></comment><comment><USER4> GitHub Wiki? Why not WikiBooks, which is designed for this purpose?

<comment><USER5> It's more a FAQ than a book.

</comment></comment><comment><USER6> People now use GitHub not only to host codes, but also host legal documents, write blogs, write wiki books, as a discussion forum (issues). I also use GitHub to host SVG images.

It seems a bit hackish though, as though GitHub is not designed for these unorthodox usages.

<comment><USER7> GitLab CEO here, I think git tools will get better for non-programming use. GitHub is adding a lot of file formats (3D files, etc.) and people are creating book and law making tools with GitLab (see the section 'Build with GitLab' on [https://about.gitlab.com/applications/](https://about.gitlab.com/applications/) for examples). I do believe the interface needs to be simpler, but sites like PenFlip are already experimenting with an easy to understand interface.</comment></comment>


ToTok Seemed Like a Popular Chat App. It's Secretly a Spy Tool - <AUTHOR> https://www.nytimes.com/2019/12/22/us/politics/totok-app-uae.html <comment><USER2> > Pax employees are made up of European, Asian and Emirati data scientists, > and the company is run by Andrew Jackson, an Irish data scientist who > previously worked at Palantir, a Silicon Valley firm that works with the > Pentagon and American spy agencies.

Surprise, surprise.

<comment><USER3> About the fact that he worked at Palantir? Not sure why that's such an enlightening point - I wouldn't automatically expect someone to jump from Palantir to working for the UAE. My general impression is that Thiel and other top Palantir folks are generally very pro USA and protecting America's interests so it's somewhat surprising to me that a Palantir person would work on something like this unless there's a US connection (although money is a powerful motivator to do lots of things).</comment></comment>


Argentina won't repay IMF debt till recession over, VP Fernandez says - <AUTHOR> https://www.reuters.com/article/us-cuba-argentina/argentina-wont-repay-imf-debt-till-recession-over-vp-fernandez-says-idUSKBN20302R <comment><USER2> Argentina just can't get its finances in order. It seems that every time they borrow money they have an excuse to not pay it or to miss payments.

It's too bad since it just makes it harder for the country to move forward.

I read a book that detailed how in the early 1900s Argentina was considered the Jewel of South America. European Immigrants often debated whether they should emigrate to Argentina or the U.S. since they were considered on par as far as economic prosperity and opportunities for immigrants. It's a shame how things have changed over time.</comment>


A non-profit that figured out how to massively cut suicide rates in Sri Lanka - <AUTHOR> https://80000hours.org/2018/03/leah-utyasheva-pesticide-suicide-prevention/ <comment><USER2> Ok I unfortunately don't have the time to listen to the whole episode, but whatever hard data is included in the text of the article doesn't look to fit the title.

 _> the suicide rate in Sri Lanka has dropped significantly. So, from 57 deaths per 100,000 population in '95, it has dropped now to 17. This is a 70% reduction. So, it's a very significant success, in fact the greatest decrease in suicide rate ever seen._

So the first thing we see is that 70% reduction amounts to the suicide rate dropping from 0.057% to 0.017%. That would still put Sri Lanka at or near the top (=most suicidal) according to Wikipedia [1], so I guess it's pretty significant; it's just that I always view relative percentages with suspicion ("we reduced the death rate by INFINITY percent!" "oh yeah you saved one life").

Second, if the rate of suicide decreased by 70% in 20 years, that doesn't mean that it can be 100% percent attributed to lack of pesticides (in fact, I cannot think of _any_ scenario where that could be true). 20 years is a lot of time, especially in Asia, so I don't know, maybe it was just the improvement of the quality of life, or (mental) health-care? _Edit:_ I hope the recording sheds more light on _why_ they attribute _any_ part of the drop to lack of pesticides...

Anyways, it's discouraging, and therefore I judge the title as "click-bait-y".

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

<comment><USER3> This study seems to take that into account[1]:

> Restrictions on the import and sales of WHO Class I toxicity pesticides in > 1995 and endosulfan in 1998, coincided with reductions in suicide in both > men and women of all ages. 19,800 fewer suicides occurred in 1996-2005 > compared to 1986 – 1995. Secular trends in unemployment, alcohol misuse, > divorce, pesticide use and the years associated with Sri Lanka's Civil war > did not appear to be associated with these declines.

Here's another study[2]:

> Overall suicide mortality dropped by 21% between 2011 and 2015, from 18.3 to > 14.3 per 100,000. The decline in pesticide suicides during this same period > was larger than for overall suicides: from 8.5 to 4.2 per 100,000, a 50% > reduction. This was accompanied by a smaller concurrent rise in non- > pesticide suicide mortality with a 2% increase (9.9 to 10.1 per 100,000).

[1] [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3154644/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3154644/) [2] [http://journals.plos.org/plosone/article?id=10.1371/journal....](http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0172893)

<comment><USER4> Their "taking into account" seems like mere handwaving away. How would the ending of a civil war not be associated with an increase in mental health?

>The decline in pesticide suicides during this same period was larger than for overall suicides: from 8.5 to 4.2 per 100,000, a 50% reduction

The way they picked these statistics just seems self serving to their thesis. Another way of looking at the same numbers is that the drop in pesticide suicides accounted for only 10.75% of the total drop in suicides.

The fact that this study focuses only on the immediate tool used to kill oneself rather than the plethora of long term contributing social factors that lead up to a suicide shows a willful ignorance of the root problems.

<comment><USER5> The standards sociological finding is that suicide is more likely to decline than rise during a war:

"Suicide rates are thought to fall during wartime. Durkheim [1] suggested this was due to increased social cohesion, while others have suggested that competing outcomes may be important, with individuals who might otherwise have died by suicide being more likely to die of other causes [2]. Neeleman [3] cites this as an example of contextual effect modification, with suicide risk modified by the likelihood of dying of other causes.

Examples of reductions in suicide rates in times of war have been described for several time periods and cultures [4-9]. Marshall [10] argued that the reduction in suicide rates reflected a reduction in unemployment, a recognised risk factor for suicide [11], rather than a direct effect of war, an argument offered some support by Lester and Yang [12]. Stack [13] suggested that the suicide rate decreased as the proportion of the population employed in military roles increased."

[https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1526726/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1526726/)

<comment><USER4> Did you read the final conclusion of your study?

>Conclusion: In contrast to the established view, our findings suggest that compared to both the pre-War and post-War periods there was an increased likelihood of suicide during the Second World War if the overall declining trend is taken into account.

Moreover, the argument of "increased social cohesion" against a foreign enemy is not applicable to a _civil_ war, where social cohesion has completely broken down.

<comment><USER5> That paper disagrees with the established view, but helpfully lays out what the established view is. Scanning papers on the topic it seems like there's mixed results war to war, and it depends what other things you try to control for - I think you could get to saying it's neutral but not that there should be a strong presumption that a war will suicide.

"the argument of "increased social cohesion" against a foreign enemy is not applicable to a civil war"

You'd get increased social cohesion among each of the ethnic groups which is in conflict with the other.

In any case this focus on the Sri Lankan civil war specifically isn't that interesting - I posted a review article above which includes controls and studies a wide range of cases across different countries, and concludes pesticide control has large effects.

</comment></comment></comment></comment></comment></comment><comment><USER6> Summarizing, this is about decreasing the effectiveness of suicide attempts, not their rate.

About a fifth of the world's suicides are done by drinking pesticides. When removing that alternative, people turn to less effective methods. Those that fail are unlikely to try again.

Very eye-opening.

<comment><USER7> > When removing that alternative, people turn to less effective methods.

Is there data on this? The article mentions that most people contemplate the decision for less than 30 minutes, so if pesticides aren't accessible they literally might not try anything else. (Or by "less effective methods", you might just mean they are less likely to complete suicide, which is true.)

<comment><USER6> By "less effective methods", I did mean that they'll still try, but probably fail.

<comment><USER8> Or if the method is less immediately available, they may not try at all, as the longer consideration time is enough to realise they don't actually want to die.

As they say:

> Leah Utyasheva: Exactly. The research shows that it is in majority of cases > with pesticide self poisoning, it is an impulsive event, and people think > for less than 30 minutes before actually poisoning themselves, less than 30 > minutes. And this of course, is a life altering event. And the other thing > is that apart from low planning, it is also low repetition event. Less than > 10% of people who tried killing themselves will go on to try to do it again.

</comment></comment></comment></comment><comment><USER9> There is a an issue in all statistics: "the seen and the unseen". It basically means "measuring benefits but not measuring costs".

Even if the statistics is accurate.

Even if denying people the right to self-determination is a positive in your ethical system.

Even if X, Y, Z are true... I still have to ask: what about the COST? Pesticides exist because they do something useful - kill off pests. They increase food production and decrease labor.

What if we've saved some lives...but also made 200,000 farmers each spend an extra five hours a week bent over in their fields, picking bugs off leaves? Or made them plant more land in order to harvest the same amount of food?

<comment><USER8> > Even if denying people the right to self-determination is a positive in your > ethical system

You are not denying people right to self-determination, in any way. If someone really wants to have a suicide method handy so that they can commit suicide immediately when they feel the impulse, you can buy it ahead of the time.

> What if we've saved some lives...but also made 200,000 farmers each spend an > extra five hours a week bent over in their fields, picking bugs off leaves? > Or made them plant more land in order to harvest the same amount of food?

Do you have _any_ reason to think any of that is true? If you have to go to a specialist shop to buy pesticide instead of the grocery store where it's right next to your food; or if you have to use pesticide that's slightly more expensive but not toxic to humans, suddenly it's like you need to pick bugs off leaves?

Measuring costs is a fine idea; and 80000 hours definitely do that. Making up costs just to seem contrary is something completely different.

<comment><USER10> GP's point is not that XYZ are the specific costs of reducing pesticide use, but that costs should be discussed when making policy judgments.

</comment></comment></comment><comment><USER11> Well they also had a civil war that lasted for 25 years so I'm sure that ending helped a bit too.

</comment><comment><USER12> This is a classic example for "correlation does not imply causality".

I believe the rate has decreased mainly due to improved education, and other suicide prevention services by NGOs, not because of the lack of availability of pesticides.

<comment><USER8> Um, there's a very clear causative model: not having toxic pesticide on hand makes poisoning yourself with pesticide much harder! Did you even read the article before assuming the two must be unrelated?

</comment></comment><comment><USER13> > _So, this harm minimization, harm reduction strategy was developed by > William Haddon, who was a U.S traffic administrator, the head of the U.S > traffic administration authority, who realized in the 60s that the traffic > accidents in the United States have gone up, and the fatality of this > traffic accidents have gone up significantly as well._

> _So, what he suggested is that radically new approach to the problem. He > says instead of telling people to stop having accidents, and become better > drivers, he suggested that, "Let's accept that traffic accidents, road > accidents will happen, but let's minimize the harm from them."_

Tangent: it's interesting how this suggests that getting people to drive _less_ was not an option in this discussion (which is the most appropriate analogy to banning really toxic pesticides, I would say). Yet that was one of the major factors behind why the Netherlands switched to a policy of encouraging other means of transportation, and why we ended up with our bike infrastructure (ignoring that the Netherlands also has the geographical advantage here, being small, flat and typically with compact cities).

</comment><comment><USER14> Also Star Wars Battle front was released during that time so that might have also been the cause.

<comment><USER15> you can't commit suicide by pesticide, but you can purchase an in-game add-on where your character can

<comment><USER14> Exactly. It's cathartic!

</comment></comment></comment><comment><USER16> thankfully, absolutely nothing else changed for this population in 20 years, so we know this is a legit controlled study

<comment> shaki-dora Yes! And where would we be without internet commentators mentioning that "correlation does not prove causation", and devising intricate interventions to study in the clueless scientists' stead?

<comment><USER4> Maybe I'm missing the humor here, but is doubt due to the lack of a control group not a crucial element of the scientific method?

</comment></comment></comment><comment><USER17> Reading that title I thought they decreased agricultural pesticide usage...

</comment><comment><USER18> I'm not sure if the clickbait title was intentional or not, but I flagged it for now.

<comment><AUTHOR> Annoyingly, it was edited from something much more timid and factual.

</comment></comment><comment><USER19> Let's do a little digging, shall we?

Who is 80,000 Hours?

[https://en.wikipedia.org/wiki/80,000_Hours](https://en.wikipedia.org/wiki/80,000_Hours)

"[80,000 hours is]...one of the nonprofits funded by startup accelerator Y Combinator in 2015...William MacAskill is the Founder and President of 80,000 Hours..."

Who is William MacAskill? [https://en.wikipedia.org/wiki/William_MacAskill](https://en.wikipedia.org/wiki/William_MacAskill)

He is a proponent of Effective Altruism [https://en.wikipedia.org/wiki/Effective_altruism](https://en.wikipedia.org/wiki/Effective_altruism)

For an article that says it will cover " What types of events are causing people to have the crises that lead to attempted suicide?"

All the commentary we have is this:

> "Robert Wiblin: Do you know what kinds of events are causing people to have > these crises and attempt suicide?

> Leah Utyasheva: Well, as I said, quite often it is a cry for help. It is the > acceptability of using suicide as means of solving certain life problems. > For example, if a child is having, a student is having problems at school, > or an old person feeling sick, or a couple argues. So, all this could lead > to an attempted suicide. And quite often, as I said, people just need a > little bit more time to think about it, and then maybe they decide that this > is not a good solution to their problems.

Then they move on. That doesn't sound like a very robust discussion around the real problem.

More importantly, for such a lengthy discussion about pesticide use, nobody speaks about who benefits from switching pesticides.

Leah informs us that: "I must point out that the United Nations and the WHO agencies are highly behind this, and they are supportive of the ban of the most hazardous substances. There are a lot of guidelines and tools developed to find out what alternatives to highly hazardous pesticides are available, and what other substances or agricultural production methods could be used instead of highly hazardous pesticides."

We have an enormous amount of posturing without a single mention of what the replacement pesticide should be. It sounds more like the UN and WHO woud like some kind of "moral" ground to push their own agenda.

I find it all very disingenuous.</comment>


UK Department of Work and Pensions is using 126.96.36.199/8 internally - <AUTHOR> http://www.whatdotheyknow.com/request/93643/response/232567/attach/html/3/b.FOI%203482%202%20Marten%20James%20Reply.pdf.html

<comment><USER2> The DWP aren't alone in this pointless waste of IPs - it's just the scale of their squandering that's worse than usual. I know of many companies doing the same with (multiple) class B ranges. Far too much of the IPv4 space is dark for this reason - an early land grab followed by ignorant deployment. Perhaps only now we're getting to the right level of scarcity and open market value for something to be done about it.

</comment><comment><USER3> The entire country of Angola has 1 IP Address.</comment>


Ask HN: What is "expert" level Javascript? - <AUTHOR>

I figure the answer to this question is when you are so experienced (and confident) that it simply becomes irrelevant. But I'm curious about everyone else's perception. <comment><USER2> Here are a few things:

* understanding prototypal inheritance, e.g. knowing what __proto__ means

* knowing how to model asynchronous code in several ways, e.g. using callbacks, events or even using promises

* understanding how an event loop works

* knowing perf related stuff (though one should always benchmark stuff)

<comment><USER3> __proto__ isn't even part of the standard at all. It's available in chrome as a convenience but it's not in every browser and it definitely shouldn't ever be used in a JavaScript program.

I see no reason an expert node engineer, for example, should be expected to know about it.

<comment><USER4> So not an expert then

</comment></comment></comment><comment><USER5> An idea. If you can create a library or tool set that solves many of the most commonly used (important) aspects of JS and more than one person (besides you) can use effectively, then I think you might be expert.

</comment><comment><USER6> I would say that knowing how operators are affecting your code is something that a lot of JS devs probably don't fully grok. For example, why this works: ~function(){}(); or why this... x = (y = 1, 3) ... sets x equal to 3 and y equal to 1. It's not too useful in day-to-day coding, but it shows a deeper understanding of what's going on in there.

</comment><comment><USER7> Read JavaScript The Good Parts. Some chapters are pretty difficult. I'd say if you can fully understand and apply everything in that book, you're an expert.

Also Addy Osmani free books on large scale javascript applications and design Patterns patterns are very good.

</comment><comment> jarek-foksa I would expect an expert to know the correct answers to most questions in kangax's quiz: <http://perfectionkills.com/javascript-quiz/>

</comment><comment><USER8> A friend of mine once told me that someone who knows Javascript inside out knows how to do things in jQuery with bare javascript.

</comment><comment><USER9> good question...i wonder the same thing

</comment><comment><USER10> An expert would know the ecma spec inside and out, know what javascript does differently from similar procedural languages, know how to approach performance and memory management issues, know common practical development patterns, know the DOM and the new HTML5 APIs, know the differences in the implemented capabilities of commonly used browsers, and have studied (or helped write) one of the open-source implementations.</comment>


This isn't an outtake from Blade Runner – it's the real Beijing - <AUTHOR> https://twitter.com/BrentToderian/status/617498633819172864 <comment><USER3> Beijinger since a year here. That's the famous "Dragon Tower" [1] where IBM China is having its offices, located north of Beijing nearby the 4th ring and Olympic Park. Franckly, it is very rarely that bad, maybe 10-15 days a year with PM2.5 levels over 400 µg/m3.

That picture might even have been taken during the impressive sand storm over Beijing in April this year [2], that's the most foggy day I've seen in the last 12 months here. Looking at the sand storm coming and swallowing the buildings from our offices on 10th floor was quite impressive. :-)

Also, if you live in a big city on any continent, you might want to check your own pollution levels using the AQI site [3], you might be surprised by the results. ;-)

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

[2] [http://www.huffingtonpost.com/2015/04/16/beijing- sandstorm_n...](http://www.huffingtonpost.com/2015/04/16/beijing- sandstorm_n_7081716.html)

[3] [http://aqicn.org/city/beijing/](http://aqicn.org/city/beijing/)

<comment><USER4> Interesting link... some world cities compared (current Air Quality Index at time of writing before link):

 _VERY UNHEALTHY_

298: [http://aqicn.org/city/chicago/](http://aqicn.org/city/chicago/)

 _UNHEALTHY_

170: [http://aqicn.org/city/usa/washington/seattle/beacon- hill/](http://aqicn.org/city/usa/washington/seattle/beacon-hill/)

 _UNHEALTHY FOR SENSITIVE GROUPS_

122: [http://aqicn.org/city/beijing/](http://aqicn.org/city/beijing/)

 _MODERATE_

96: [http://aqicn.org/city/usa/oregon/portland/](http://aqicn.org/city/usa/oregon/portland/)

70: [http://aqicn.org/city/tokyo/](http://aqicn.org/city/tokyo/)

66: [http://aqicn.org/city/berlin/](http://aqicn.org/city/berlin/)

65: [http://aqicn.org/city/london/](http://aqicn.org/city/london/)

61: [http://aqicn.org/city/hongkong/](http://aqicn.org/city/hongkong/)

54: [http://aqicn.org/city/newyork/](http://aqicn.org/city/newyork/)

 _GOOD_

33: [http://aqicn.org/city/zurich/](http://aqicn.org/city/zurich/)

31: [http://aqicn.org/city/stockholm/](http://aqicn.org/city/stockholm/)

24: [http://aqicn.org/city/paris/](http://aqicn.org/city/paris/)

13: [http://aqicn.org/city/california/san-francisco/san- francisco...](http://aqicn.org/city/california/san-francisco/san-francisco- arkansas-street/)

<comment><USER5> The number for Chicago doesn't strike me as accurate. I'm in the area right now and it's a clear day. Plus, the levels for nearby areas in Chicago are far lower (80 or so) and the historical levels are much lower. Looks like a blip. That said, I'm sure Chicago is not the clearest city in general.

<comment><USER4> A quick Google and Wikipedia visit says that pm2.5 fine particulates of the kind reported as being extremely high in some parts of Chicago, are not visible except as a light haze over the city.

It appears to be true that you can have a bright mostly clear day and very high levels of fine particulate pollution.

This haze is part of what contributes to smog when combined with other more visible (course particulates) pollution. But these fine particulates don't appear to be the product of fireworks as suggested below, and are more likely to be the product of the coal power stations.

The measure for Chicago is probably skewed by one of the measuring stations being nearer to, or down-wind from, a coal power station.

<comment><USER6> Why do you assume that the sampling methodology and calibration is ridiculous?

</comment></comment></comment></comment></comment><comment><USER7> as answer tweet indicates [https://twitter.com/lolamachine/status/617518791375912962](https://twitter.com/lolamachine/status/617518791375912962)

Credit where it's due, Twitter. That Beijing photo is by @nntd and first appeared here [http://blogs.wsj.com/photojournal/2013/01/14/photos-of- the-d...](http://blogs.wsj.com/photojournal/2013/01/14/photos-of-the-day- jan-14-2/)

<comment><USER8> Why would you blame Twitter for a user misappropriating a picture?

<comment><USER7> Sorry, I forgot the "..." to indicate I was quoting the tweet. So I don't know! If I can speculate, I would say that, per the history of [https://twitter.com/lolamachine/](https://twitter.com/lolamachine/) , it seems it is not the first time the photo is mis-appropriated, so 'twitter' could be a short hand (because 140) for people of twitter, both posters and retwitters.

</comment></comment></comment><comment><USER9> I still remember 2001 when I first arrived at Hongkong to work. My first day at the office, I got teary eyed. I told my boss why is it so..he told me it's because of the pollution and I should drink lots of water.

It is probably way lot worse now. I saw this documentary recently, [https://www.youtube.com/watch?v=T6X2uwlQGQM](https://www.youtube.com/watch?v=T6X2uwlQGQM) it is a good watch. FYI China is also destroying marine life in the West Philippine Sea [http://globalnation.inquirer.net/120699/ph-slams-china- for-d...](http://globalnation.inquirer.net/120699/ph-slams-china-for- destroying-marine-life-with-reclamation-works) [http://www.philstar.com/headlines/2014/05/12/1322282/photos-...](http://www.philstar.com/headlines/2014/05/12/1322282/photos- dead-turtles-chinese-ship-anger-filipinos)

<comment><USER10> I am not sure it is so bad there. I lived in HK from 2013-2014 and the pollution was bearable. About 60-120 on the AQI scale (PM2.5)[1]. By US standards that's orange/red (bad) but you get used to it.

In comparison, Beijing is routinely 500+. Manhattan is about 40. And some parts of the west coast push 100+, most likely because of Chinese air floating all the way over the Pacific.

[http://aqicn.org/city/hongkong/](http://aqicn.org/city/hongkong/)

<comment><USER11> > Manhattan is about 40

That's insane. Copenhagen is at 80.

</comment></comment></comment><comment><USER12> A genuine question for the people on HN who think government should be as small as possible, and that there shouldn't be agencies like the EPA: what would be your non-government fix for this?

<comment><USER13> Even arch-libertarians believe in collecting fees to correct externalities.

<comment><USER12> And in what way does that differ from what the EPA does?

<comment><USER14> The EPA issues regulations which is different from collecting fees.

<comment><USER12> My understanding is that the worst of the pollution in Beijing is the many thousands of people heating their houses and cooking with coal.

So in this scenario, there would be a team from the government who would drive around and catch people burning coal (as that is clearly an externality) and ask them to pay them money? Similar to how the BBC drives around and demands fees if a person is caught watching TV without a licence?

<comment><USER14> The trouble with billing people for damage is it's usually too complicated to do. The BBC fee is a fixed amount to pay to see its shows. London used to have smog caused by people burning coal at home but they banned it after the 1952 smog killed 4000 people. Sadly I think the Chinese pollution has killed far more than that.

</comment></comment></comment></comment></comment></comment><comment><USER15> Go see Hong Kong sometime, same thing, massive screens taking up entire sides of enormous tower blocks. Shenzhen too.

<comment><USER16> Pollution in HK is nowhere near as bad as beijing, though. SZ's better but does have its moments.

It's not everyday, but when the 'Jing has a bad day, it's really something else. I don't know how people live there, it's terrible and you can just feel it damaging your lungs. It encourages this positive feedback loop too - <USER2> pollution is so bad you want to take a car everywhere, which of course contributes to the pollution!

I wouldn't be surprised if a fair portion of uber's success in CN is due to people not wanting to walk in the toxic smog. Would be interesting to see a graph of pollution index vs. ride numbers.

[edit: positive not negative]

<comment><USER17> You manage. Right now it's spring so the air is quite good. Summer will be a bit hazy, fall will be very nice, then by late December it will be bad again. Pollution season is only 3 months/year, though the air is often not super great outside of that.

Also, uber isn't that successful in the jing, taxis are cheap enough (and ya, there is an uber-like app for them), and if you want to go upscale there is didi zhuanche (same app). You either take a car or a taxi, if you can afford $5-$10, or a bus/subway/bike if you can't, pollution doesn't really affect that.

<comment><USER16> Hm, I've had people tell me that they prefer uber (or the other app you mentioned - i couldn't remember its name) because the cars tend to be better, and with better air filtering. Maybe that gave me the impression it's more popular than it actually is.

Certainly I'd spend a couple bucks more to sit for an hour (or more!) in an audi or VW over a hyundai..

<comment><USER17> Uber is completely off the radar right now, I think they only service some parts of chaoyang even, I do most of my travel from haidian to chaoyang. Didi zhuanche offers better cars, but not Audi (maybe you are thinking of Shanghai?)...at best a VW or Buick.

Taxi is quite ok when the air is really bad. You can only filter so much air in a car, and it's not like they are putting in giant HEPA filters. The main problem I have is sleeping with the window closed when the air is bad...even with the air filter going, it is very hard to sleep soundly.

<comment><USER16> Hey, thanks for sharing your local experience. I've only visited! I thought uber black runs audis in BJ but I only heard that from a friend. Maybe I or he was confused.

Out of interest, why do you have issues sleeping with the window closed? Frankly, it would be extremely rare for me to sleep with the windows open no matter where I am.

<comment><USER17> Probably because as a Seattleite, it's what I'm used to (no ac or heat needed). Chinese people think I'm nuts, especially when we have to share rooms on trips. Couple that with preferred western sleeping temperatures being much lower than Asian ones...it leads to conflict.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> You really can feel it in your lungs. People hocking up lougies everywhere in public (sometimes on your shoes if they don't see you walking by). It's a desperate state of affairs IMO.

</comment><comment><USER19> Meh.. Cool story and all, but Beijing isn't really that bad. Nobody wants to see a picture of a clear sky and yeah, the picture is real. but you will see something like this very rarely.

As a kid growing up in Europe, I remember pollution and acid rain and whatnot being a hot topic on the news every night. Its okay today, but it took time and it will take time in China also, but the government there is doing something about it for sure.

</comment><comment><USER20> Source [http://blogs.wsj.com/photojournal/2013/01/14/photos-of- the-d...](http://blogs.wsj.com/photojournal/2013/01/14/photos-of-the-day- jan-14-2/) has a higher-rez version.

</comment><comment><USER21> Here's another good one: [http://www.dailymail.co.uk/news/article-2540955/Beijing- clou...](http://www.dailymail.co.uk/news/article-2540955/Beijing-clouded-smog- way-sunrise-watch-giant-commercial-screens-Tiananmen-Square.html)

</comment><comment><USER22> if you also suddenly want to listen to the appropriate background music: [https://www.youtube.com/watch?v=FwhZ11lcOJQ](https://www.youtube.com/watch?v=FwhZ11lcOJQ)

</comment><comment><USER23> The background image, on the other hand, looks an lot like the False Creek neighborhood of Vancouver, Canada.

<comment><USER24> Ironically Vancouver is deeply sepia toned this morning, not too unlike the Bejing photo, due to a nearby forest fire. I've never seen anything like it.

[http://www.vancouversun.com/news/Smoke+creates+eerie+morning...](http://www.vancouversun.com/news/Smoke+creates+eerie+morning+coast/11189684/story.html)

<comment><USER23> I took the opportunity to safely stare at the haze-dimmed Sun through a pair of binoculars.

</comment></comment></comment><comment><USER25> Going back home from China always feels like you just changed draw distance in a game.

</comment><comment><USER26> anyone know what time of day this is?</comment>


I Don't Like Google Mobile - <AUTHOR> http://designdare.com/i-dont-like-google-mobile <comment><USER2> The comparison is of some interest, but the title of the article does not do justice to the content.

</comment><comment><USER3> Thanks for highlighting. I will be switching to Bing on my iPhone.</comment>


Impractical Solutions to Intractable Problems - <AUTHOR> http://dilbert.com/blog/entry/impractical_solutions_to_intractable_problems/ <comment><USER2> 1\. "Watchful Husband" problem.

2\. Single point of failure.

Noooo thankyou.</comment>


Misused mobile UX patterns - <AUTHOR> https://medium.com/@kollinz/misused-mobile-ux-patterns-84d2b6930570 <comment><USER2> Some people learn the rules, but the best also learn the exceptions.

1\. It only appears like everyone opposes Hamburger menus, but it's really just an obstacle for publishers (blogs, magazines, deals) who are entirely dependent on discovery to drive engagement. Apps with naturally motivated engagement (music players, deep social, stores) do better with the menu.

2\. I agree icons should be clear. The best way to design an icon is to search Google images and look for a common icon, pattern, or symbol. This greatly reduces the need to label the icon.

3\. Only use gestures that are standardized. Follow the example of major apps by Apple, Google, & Facebook to determine which gestures are most commonly used per platform (iOS, Android). Don't deviate from those patterns unless your app's entire position is to be a gesture-based app.

4\. Onboarding should be optional (skip button), informative, and rediscoverable somewhere in the app. Coach marks are only essential for complex screens. Don't show more that one or two highlights else people will ignore everything. Include an obvious "OK" or "Got it!" button.

5\. Agree - don't show users an empty screen! That being said, apps have unique needs. Google's collections app expects lots of engagement so it shows the user how to use the app. Lootsy needs users to start selling ASAP so it's motivation is reduce steps towards populating listings.

</comment><comment><USER3> Haha, I love the bit about pictograms. I have to use Xcode occasionally at work, and it's always a case of hovering over a few dozen buttons trying to guess which one might do what I want.

[http://codewithchris.wpengine.netdna- cdn.com/img/xcode_5_wor...](http://codewithchris.wpengine.netdna- cdn.com/img/xcode_5_workspace_diagram.jpg)

<comment><USER4> ...what does the tuxedo button do?

<comment><USER5> It is the "assistant view" which opens a second tab with an editor where it automatically tries to open related files.

Although it is now looking like this: [http://i.imgur.com/gA8AwmG.png](http://i.imgur.com/gA8AwmG.png)

</comment></comment></comment><comment><USER6> Great article. I find disturbing how some apps are so hard to use not only by the poor choice of icons, but by not providing immediate and clear ways to perform the most basic actions.

</comment><comment><USER7> The Youtube app "before" picture is very gory. A hamburger menu _and_ the three-dots actionbar icon? That gives me a bit of a cold sweat.

Common UI interactions on mobile devices are beginning to make me feel old.

<comment><USER8> As best i recall, they come out of a misuse of Fragments elements.

The original idea of Google's Fragments framework was to produce something closer to desktop interfaces on tablets. But interfaces that could also "collapse" to fit the "card stack" thinking of earlier Android.

Meaning that what we now know as the hamburger menu was meant to show up as a sidebar in tablet layout, and as a first layer in phone layout.

Similarly, Fragments gave us the actionbar where earlier there was a dedicated menu button. The icon was for when the number of bar entries didn't fit the available screen space.

Again the thinking seemed to be that the bar would revert back to being the menu on phones.</comment></comment>