We can do better than percentile latencies - <AUTHOR> https://medium.com/theburningmonk-com/we-can-do-better-than-percentile-latencies-2257d20c3b39 <comment><USER2> Just plot the latency distribution in a histogram [1] and be done with this boring topic. The problem you're complaining about is that aggregating everything into a single number doesn't give you the information you want to know. It's impossible by design. If you want a different type of information you will also need a different type of diagram or statistic.

[1] [https://rethinkdb.com/assets/images/docs/performance- report/...](https://rethinkdb.com/assets/images/docs/performance-report/w-a- reads-latency.png)

<comment><USER3> I think you may be overlooking the challenges that the author is trying to tackle with their proposal.

First, the author is looking for a characteristic that can be monitored automatically - for example, alarm if P99 latency is over 2 s. Visualizations while useful don't help with that.

Second, the author is looking for a solution that can run in soft real time, so that it can be used for system monitoring.

Third, they're looking for a solution that does not have to aggregate the full raw data set from across the fleet. It is implied that they are working with reasonably large fleets such that full aggregation is impractical; or maybe just too costly or too slow.

If you were able to aggregate the full raw data set in real time and compute the Nth percentile, then that statistic would meet the author's needs. Their point is that actually computing the Nth percentile is expensive and not commonly done in real-time monitoring (hence the statistic is usually an average of host-level Nth percentile).

The challenge they've proposed is to define a statistic that is more useful for alarming while still avoiding the need to aggregate the entire raw data set.

I thought this was a thoughtful article with a clever suggestion. "Percent of requests over threshold" meets these criteria. One criticism of this approach however is that the threshold needs to be known ahead of time, prior to aggregation.

<comment><USER4> > Second, the author is looking for a solution that can run in soft real time, > so that it can be used for system monitoring.

Histograms can absolutely be used for alerting. We have done this at Circonus for ages: [https://www.circonus.com/features/analytics/](https://www.circonus.com/features/analytics/)

I wrote up the case of latency monitoring 6 weeks ago here: [https://www.circonus.com/2018/08/30/latency-slos-done- right/](https://www.circonus.com/2018/08/30/latency-slos-done-right/)

</comment></comment></comment><comment><USER5> Worth watching is How NOT to Measure Latency: [https://www.youtube.com/watch?v=lJ8ydIuPFeU](https://www.youtube.com/watch?v=lJ8ydIuPFeU)

The speaker Gil Tene is also the author of the HdrHistogram which addresses this articles point: [https://hdrhistogram.github.io/HdrHistogram/](https://hdrhistogram.github.io/HdrHistogram/)

<comment><USER6> I don't get hdrhistogram at all. It's really just histogram with a shitload of logarithmic buckets.

<comment><USER7> The compression format is really smart, there's a neat trick to make the logarithm calculation fast, and there's a concurrent thread handoff mechanism so you can swap out a histogram without disturbing the thread you're measuring (though last two probably only in the java version). Those three make it super useful for very low impact performance measurements.

</comment></comment></comment><comment><USER8> Stop trying to re-invent statistics. Use a box and whisker plot of latency. You quickly get to see the mean, the quartiles, and all the outliers and you get it in a format which is familiar and easy to understand. You can even plot box and whisker plots next to each other for quick meaningful comparisons between different things.

<comment><USER9> I've recently grown to like violin plots for latency ([https://en.wikipedia.org/wiki/Violin_plot](https://en.wikipedia.org/wiki/Violin_plot)). I've also added 99%ile tick marks, which with the already present median mark, gives a relatively full picture of latency that is easily digestible.

</comment></comment><comment><USER10> The article states that almost everyone is doing percentile latencies wrong by averaging on agent level (thus creating nonsensical data) and proposes using the percentage of requests that are over the threshold instead, a metric that can be averaged properly. He additionally suggests to always use actionable dashboards catered to its users (dev/ops/manager).

</comment><comment><USER11> I agree with the premise but it seems that there are more solutions out there. As other commenters noted, you can collect histograms or hdrhistograms. Those have the problem of needing to be precofiguring and of not being able to be merged unless they are configured the same way.

Instead you can use the t-digest ([https://github.com/tdunning/t-digest](https://github.com/tdunning/t-digest)), a very cool online quantile estimation data structure from Ted Dunning (which he has recently improved with the Merging approach). There are a number of implementations out there. It is not unreasonable to serialize them and merge them. Unfortunately there's no easy way to set this up in Prometheus but making that easy could be a fun project

</comment><comment><USER12> I'm not sure which tools the author has tried, but the Prometheus monitoring system supports both histograms and quantiles.

There's a good discussion of the respective merits of each at [https://prometheus.io/docs/practices/histograms/#quantiles](https://prometheus.io/docs/practices/histograms/#quantiles)

<comment><USER13> Histograms require you to configure buckets into which your samples are allocated; to allocate the buckets appropriately, you need to know what your expected values are — that is, to measure latency, you need to know your latency. While this can work (I think most of us have a clear idea, or can obtain an idea of what our typical latencies is, and configure buckets around that) it is inelegant. I feel like I would rather have X=percentile, Y=latency, but such a bucketing gives you X=latency, Y=request count. Still useful, but only as informative as you are good at choosing buckets. (There is the histogram_quantile function, but I am unclear that its assumption of linear distribution within buckets really makes much sense, since most things would be long-tail distributions, and thus I would think that once you get past the main "hump" of typical latencies, most samples would cluster towards the lower end of any particular bucket.)

I am not clear on how Summaries actually _work_ ; they appear to report count and _sum_ of the thing they're monitoring; that is, if one were to use them for latencies (and the docs do indeed suggest this), it would report a value like "3" and "2000ms", indicating that 3 requests took a total of 2000ms _together_ ; how is one supposed to derive a latency histogram/profile from that?

Prometheus's fatal flaw here, IMO, is that it requires sampling of metrics. That is, things like CPU, which are essentially a continuous function that you're sampling over time. But its collection method/format doesn't seem to really work that well for when you have an event-based metric, such as request latency, which only happens at discrete points. (If no requests are being served, what is the latency? It makes no sense to ask, _unlike_ CPU usage or RAM usage.)

To me, ideally, you want to collect up all the samples in a central location and then compute percentiles. Anything else seems to run afoul of the very "doing percentiles on the agents, then 'averaging' percentiles at the monitoring system" critique pointed out in the video posted in this sibling comment: [https://news.ycombinator.com/item?id=18194507](https://news.ycombinator.com/item?id=18194507)

<comment><USER14> Your points are largely valid, but prometheus is a monitoring solution, not a scientific or financial tool. Certain tradeoffs are taken since the monitoring aspect comes first and being scientifically correct comes second. Hence poll vs push, for instance.

</comment></comment></comment><comment><USER15> For diagnosing, I like building up a cumulative distribution function (CDF) plot. If you're collecting data either for percentiles or thresholds you likely have the data already. If you're setting thresholds, it's a useful plot to judge how likely a given threshold might trigger an alarm.

</comment><comment><USER16> I really like the idea of displaying what percentage is over a certain threshold. at my work, we kinda sorta simulate this by having separate alarms for many percentiles (with increasing thresholds). The approach suggested by the article seems to be quite obviously better tbh.

</comment><comment><USER17> The approach here sounds a bit like the ApDex metric New Relic has been doing for years? Is there something different I'm missing?

</comment><comment><USER18> Reservoir sampling with outliers?

<comment><USER19> Correct.

</comment></comment><comment><USER20> Mean excess delay?</comment>


Ask HN: $100/month, how to spend it on online subscriptions? - <AUTHOR> If you had $100/month to spend on monthly or yearly subscriptions, what subscriptions will you pay? <comment><USER2> De Tijd ( Belgian) is the only one currently that gives me a lot of interesting economic ( Belgian) information with news I can't find elsewhere

</comment><comment><USER3> I would make sure some portion of it goes to "independents" and small shops via avenues like Patreon.

</comment><comment><USER4> 2x VPN 2x VPS 1x usenet account 1x humblebundle.com</comment>


How many times has a unittest saved your day? - <AUTHOR> How much time is spend on writing unit tests compared to receiving the bug and fixing it. All i hear around me is, the screen must be green so all unit tests have been successfully processed. When a unit test fails and the dot is red, 99% of the time they have to fix the unit test and not the actual code, I understand when you use unit test to workout your problem, but most of the time its the unit test that fails and not the code. <comment><USER2> Several. I've found race conditions with unit tests. I found a call to a pure virtual function in the base class's destructor. I've found "hey, that code I just wrote didn't do what I thought it did" not _frequently_ , but still more times than I care to admit. I've also found "whoops, I didn't think about how my change would affect that code over there" several times.

That's just _my_ code. Then there's finding out what my _co-worker 's_ changes did to my code...

</comment><comment><USER3> I agree most of the time I am just fixing silly issues like this mock is now broken because I added a method or a field or the like - or some beefy test setup code is now broken because of some otherwise innocuous change. I do believe high-level functional/acceptance tests are important however, that is, tests that check whether the various programs that make up the system actually do what they are meant to do. For example a CLI test for a program that interfaces with the user from the CLI. If a program is writing to storage, check to see if it actually writing to the storage properly. All the little mocks and stubs and so forth seem to be to form a false sense of security.

Those who are in favor of unit tests have one big weapon on their side of the argument and that is simply the word "test" "how can a test be bad?, right?"

</comment><comment><USER4> If you are specifically asking about unit tests and not testing in general, they don't save my day as much as give me confidence that my code is working as it is supposed, specially at the edge cases. I'm not a fan of mocking alot of stuff because it takes time to maintain, so in general terms I prefer testing higher in the pyramid (eg integration testing).

As for saving the day, I find that they are very helpful with refactoring, specially in dynamic languages. When the business rules change, first thing I do is rewrite the test, the just make it pass.

</comment><comment><USER5> So you made a change and a test broke, what about all the ones that didn't break? They still represent a lot of scenarios you probably wouldn't have tested manually.

I would also guess that the problems with your tests breaking are because you're not following the single assert principle. A unit test should generally (plenty of exceptions) not break unless the specific behavior (the unit) it is testing for changes. A common anti-pattern is to treat tests as scenarios, setup the scenario, test it and check everything went as expected for that scenario. Instead you want to work out the behavior you're testing, "foobar gets written to the log" is a test and the setup should be just enough to produce that behavior..

</comment><comment><USER6> Our code base is primarily Python. We do use type checking, but we risk having problems that you simply don't have in strongly typed languages.

Unit test save the day every time I need to refactor large parts of the code base or make a change that affects the entire code base. They don't necessarily find problems I didn't think of, but they make these kind of large refactoring a lot easier.

Recently we replaced the ORM. I replaced the code that handles setting things up, and wrote the code to configure the new ORM. Then I just ran the tests. Almost all of them failed because the imports and syntax are slightly different. So, I would just take it test by test and kept fixing things until the tests passed. When all the tests were passing I was reasonably sure everything was still working as expected.

Sure, we also face the problems you're facing. Sometimes the tests just fail for unrelated reasons. Or somebody wrote a test that is a bit flaky and fails from time to time. Usually we just consider this the cost of doing business so to say.

When tests are failing every time the code changes, that usually indicates a problem with how you write tests. Stick to the single assert principle, make sure tests are simple, don't require a lot of set up etc. complex tests are usually a sign of complex code.

In dynamic languages, mocks are very popular, but I've found them to be the source of having to change things. They are often a sign that the code is poorly split and untestable. Instead, write smaller, isolated modules and possibly use dependency injection, making the "mocking" part of the code.

<comment><USER7> Basic idea: to verify your robot in a quick and harmless way, disconnect its actuators, feed fake data to its sensors, observe its stream of decisions, and verify that it behaves according to some rules.

If your robot has different parts with their own rules of behavior, then you should be able to detach them to test them on their own, or in a much simpler test harness.

I think the complaints about unit tests often amount to "we're taking the robot apart into too many parts that actually depend on each other in complex ways, so testing them independently is tedious and gives us little real information."

Another kind of complaint is "our robot has a huge amount of functions that all interact in very complicated ways and we haven't specified any overarching principles so our tests are just a lot of arbitrary scripts that we have to change constantly to accomodate the robot's ever-changing repertoire of fascinating behaviors."

Or "there is no exhaustive list of our robot's sensors and actuators, and many of them are complex third party products which we integrate without any adapters, so it's nearly impossible to take the thing apart and provide a realistic simulated environment."

I think the underlying complaint is something like "we were told that there was an easy method to make our software correct, and it's disappointing that it doesn't work well without considerable investment into domain modeling, architectural work, mathematical analysis, etc."

</comment></comment><comment><USER8> Not necessarily unit tests, but automated tests in general? All the time. Setting aside linting failures (and frankly I'm not sure how those even get pushed), I'd say we have a new test failure on our integration branch in CI an average of once a day.

</comment><comment><USER9> You really learn to appreciate unit tests when writing algorithms based on heuristics. One heuristic can easily break another so unit tests become critical to avoid introducing regressions. However, BAD unit tests can definitely be a drag. But the remedy is not to stop writing unit tests, it is to write better tests! :)

</comment><comment><USER10> More times than I can count.

</comment><comment><USER11> unit tests have saved me a few times.

they really help with legacy code where you may not be the original creator.</comment>


Mnuchin Seeks $850B in Coronavirus Stimulus -Report - <AUTHOR> https://www.thestreet.com/investing/mnuchin-to-seek-850-billion-in-coronavirus-stimulus-report <comment><USER2> The payroll tax holiday is the opposite of good policy. The problem is people furloughed or laid off. If you have no paycheck, you have no payroll tax. It is alarming that this is part of the stimulus package because it indicates people are not taking this seriously.

</comment><comment><AUTHOR> In the video Trump insists that Google is working on a website that the media says Goggle says.. well what is going on really?

<comment><USER3> Apparently Google did not at the time of the press conference, but started afterwards.

[https://www.nytimes.com/2020/03/14/us/politics/trump- google-...](https://www.nytimes.com/2020/03/14/us/politics/trump-google- coronavirus.html)</comment></comment>


Go Is a Shop-Built Jig - <AUTHOR> http://robnapier.net/go-is-a-shop-built-jig <comment><USER2> Lack of generics seems to always be _the_ argument against Go. I have been coding in Go for over a year now nearly every day and it really became an annoyance only once: CRUD operations in a web-service expecting JSON-objects. That's literally the only time where the code-duplication was a problem for me.

Now, not everything else has been all good (mostly minor issues with community libs), but the one thing that never ceases to amaze me with go is that: You hammer out a few hundred lines of code, compile, fix those few syntax errors, compile again and 9 out of 10 times your code just works. The simplicity of the language is the key. It's a tool that feels right and gets the damn job done.

<comment><USER3> The funny thing is that adding generics will also improve error handling as you would be able to make that Result<T> generic from Swift and implement flatMap for it. This would be as good as exceptions, if not better because its very explicit and can be made compatible with the existing mechanism.

This is why I find it unbelieveable when Go users tell me "I never need generics". I look at their code and see

      if err = logit(FrobulatingMessage); err != nil {
          return err
      }

repeated over and over again and can't help it but cringe

<comment><USER2> You get used to that pattern ;-)

Also, the "I never need generics" made me smile. Sure, one can get by without them, but sometimes, as I said above, it would be _really_ nice to have them.

<comment><USER3> Getting used to it is not the point. What I find cringe-worthy is that that's a bewildering amount of noise. It actually makes it harder to figure out what a specific piece of code does.

Admittedly the error pattern is so common that I can imagine people getting very much used to it, but thats not the issue here. The problem is indicative of Go's lack of abstraction power, and its pervasive. There is no difference between `filter`, `map` and a regular foreach - every piece of code that wants to do things like that must re-implement the mechanics of creating new slices and assigning things to members which are accessed using a specific index. So many details - I can't see the forest from the trees!

I see the same kind of noise in legacy messy projects where a piece of code works on multiple abstraction levels and its impossible to think about what a it does without thinking about the mechanics of how it does it.

Given all this I really can't understand how someone can call Go code beautiful and clean. My gut reaction is "this will cause a mess couple of years down the line".

The cost of not having generics in Go is really understated, and it saddens me greatly. With them, Go would be an extremely interesting language. But apparently, the language designers believe that you (the user) are not to be trusted with writing sensible abstractions and therefore are forbidden to do it.

<comment><USER4> _Getting used to it is not the point. What I find cringe-worthy is that that 's a bewildering amount of noise. It actually makes it harder to figure out what a specific piece of code does._

I find that so bizarre. That's on a personal level, I'm not throwing stones.

My two favorite languages before Go came along were Objective-C and Python. Different tools for different problem-sets of course, but Objective-C can quite easily be called insanely noisy.

Go is obtuse, but I find its readability on par with Python in that there's one way to do something, and that way is repeated over and over. I don't have to worry too much about stylistic preferences between programmers, people trying to get fancy while writing code (or trying to show off). Our server code serves thousands of requests per second - I need that code to be rock- solid, not fancy or overtly minimalistic.

You're right, people do get used to the error pattern. I can either handle it, ignore it, or toss it up the stack, and I get to make an explicit decision about that every time.

We've been rewriting critical systems code in Go (from mostly Python) and it's a joy. I am, of course, the (unintended) target audience for Go - a dynamic language dev looking for speed, concurrency, and compile-time safety, along with the simplistic beauty of gofmt, goimports, and so on. But I do find it beautifully simple, if not entirely "beautiful."

Edit: formatting.

<comment><USER5> The difference though is that Python is powerful enough to avoid the repetitive noise even if use of that power isn't the 'Python way'.

</comment></comment></comment></comment></comment></comment><comment><USER6> Seriously, in good faith, I attempted to learn and write a simple web application in go.

I found it hard coming from a world where IDE support was available in other languages that do autocompletion and things like that and development just moves faster. In go, there is some level of support in sublime text, go for vim etc, but it is not nearly as full featured as say, IntelliJ. Want to learn about the javadoc - Command + J. Want to refactor code, much easier than in go. So tooling is a big problem I encountered.

Next in line is lack of reusable data structures. Sure, embedding of structs is supported, but lets see...what will you do with a person struct (name, age, gender) that should be part of a employee struct and also the executive struct. You have 2 options 1) copy paste the person struct fields into each of the other structs or 2) you have interfaces and implementations of those interfaces so you can only deal with it through interfaces using embedded structs. What we really want is a flattened struct (just like inheritance). Most time people use inheritance not because its the right thing to do for that piece of functionality, but because it allows easily flattening out a data structure so you have reuse of a common data structure with common properties across other data structures. This one killed it for me with go. I can't reuse. I am not google to have loads of dollars and when I try to make things work, I need to be able to keep an eye out for bugs that can creep in with go where re-use is artificial or takes excessive work to get.

All in all, maybe go has its niche, but for a small shop that runs on scanty resources and needs to build robust and reliable applications, a heavy weight like Java or .Net is still ruling the roost.

<comment><USER7> That's funny, because I'm also a Go skeptic but your 2 points are literally exactly the opposite of mine. On the top 2 of the things I like about Go they are tooling and removed inheritance.

Being able to fire up a fully formed, non-handicapped environment consisting of only vim and some command line tools is great. I've tried repeatedly on the JVM to accomplish this and always end up back with bloated IntelliJ and the vim plugin as my only option.

I would say that in the last 15 years I've used inheritance correctly a handful of times, embedded structs are nearly always the correct solution to data structure reuse problems. That Go prioritizes composition over inheritance for data structure reuse is one of its fundamental value propositions, that anyone that has used Java extensively thinks otherwise is baffling to me.

If Go had a longer history I'd probably argue the exact opposite conclusion of you. If you are a small shop with scanty resources and need to build practical business solutions Go seems like a great choice. Conversely, if you are able to afford the best developers and have massive enterprise software needs, maybe Java or .Net makes more sense.

<comment><USER6> >> bloated IntelliJ and the vim plugin as my only option

Bloated it may be but helps me get the job done faster...much faster than I can do it in vim. I work on a mac with 16 GB RAM and thats sufficient for lots of processes. Every bit of the way, I have documentation I can lookup right within as I type, I have autocomplete that always works, I have debugger support to catch little things I missed, tons of libraries and plugins that have stabilized over the years...whats not to like? The downsides (and the reason I looked at go) are both Java and .Net are memory hogs. I needed something more lighter that would offer the same level of productivity during development.

<comment><USER7> But that's the beauty of the go tool chain. I have a source browser (godef), a documentation browser (godoc), a code style formatter (go fmt), code vetting (vet), unit testing (go test), a linter (golint) etc. and they are all fast command line programs. This means that it is trivial to setup a vim/command line environment the way I like.

In my vim setup with simple key strokes, I can go to the source of, see the type definition of, see the documentation for the call under the cursor. I have formatting, vetting, and if you want compiling on save of the file (and it's super fast). I have autocomplete that behaves exactly as I want it to.

I wish there was better ctags support for go, and the go oracle tool is more prototype than production software, but on the whole I am much happier with my development chain in go than I've ever been on the JVM or .NET.

</comment></comment></comment></comment><comment><USER8> This piece reminded me of "Zen and the Art of Motorcycle Maintenance", with its talk of the practical qualities of the language through analogy to a shop- built gig.

</comment><comment><USER9> Notice the author would still rather use Swift when he's doing fun stuff. I get this sentiment and more than once I've wished there were more constraints in the language to mitigate the damage some kid with a chip on their shoulder could do but it says something about the psychology of programmers, "I know personally I'm good enough to do magical, wizardly stuff with all the cool stuff that Swift gives me but you, well, you need some training wheels so we're gonna use Go for this project".

I don't know about you but I'd rather work with people that understand the tools they are using and when it's OK to do fun stuff and when it is important to exercise restraint and "dumb it down" for the good of the team. Using the language to solve the problem of uneven programmer ability feels a bit off. It's something out of 1984. You can't say "great" in Go you can only say "good++".

<comment><USER10> So you're saying you want programming to be hard because that means you get to work with smarter people? I think what Go is striving for is simplicity, not elegance. And that change makes the code easier to write and maintain for everybody involved. At 10AM I might feel like writing Swift, but at 3AM I'm sure as hell glad I used Go.

Or, less anecdotally, I maintain about twelve services in Go, including web services, proxies, and an analytics engine, and I have never been woken up in the middle of the night with a failure. That was certainly not true when I was writing Python or Javascript. Erlang or Swift might offer comparable reliability, but it comes at the cost of a lot of complexity.

<comment><USER11> When things get serious, I think you'll discover that Go provides far less reliability, and is far more complex. (What's simpler than "it's already handled for you with OTP and battled tested for 2 decades"? That's a lot more simple than "you can't do it in this language and you'll end up with a poorly implemented half version of OTP in Go."

Of course for toy or small services, go is fine. Erlang certainly could use the "build a binary run it anywhere" distribution model of Go tool.

But reading all these pro-go articles, it strikes me that none of them seem to be written by people who really understand concurrency.

Believe me, I wish Go was written by people who had understood erlang. There's a lot to like about it and it has momentum.

<comment><USER12> I'm not sure YouTube or dl.google.com qualify as "toy or small services", nor the handful of other relatively large businesses building on top of Go (CloudFlare, Iron.io, etc).

</comment></comment></comment></comment><comment><USER13> "Go feels under-engineered because it only solves real problems"

This belies a multitude of real problems Go doesn't solve, like generics or preventing data races

<comment><USER10> As he said in the article, neither seem to be problems which come up in practice. I maintain about twelve Go services running in production, and neither failure has cost me any significant amount of time.

<comment><USER14> What kills me is that generics (or any other programming language abstraction) are not problems, but problem-solving tools. Technically speaking, they are never needed, if your definition of "not needed" is "I can work without them".

You don't need anything beyond assembly language, really.

The thing with most tools and abstractions is that you don't appreciate them until you use them -- when you _truly_ use them, not merely when you learn about them. Then you wonder how you ever lived without them. You don't know if failing to use an abstraction hasn't cost you a significant amount of time until you've embraced their use.

To me, this is a variant of the Blub paradox at work.

</comment></comment></comment><comment><USER15> Props to whoever built this presentation software. With Javascript disabled, it gracefully degrades to a basic HTML page. Most others leave you with a single broken slide.

</comment><comment><USER16> What is with Go supporters ? I don't understand why if I don't use Go then I am not solving real world problems and instead building over engineered monstrosities. Working in the enterprise features like exceptions and generics makes it easier to ensure consistency across the platform and our 20+ developers.

<comment><USER17> > What is with Go supporters ? I don't understand why if I don't use Go then I > am not solving real world problems and instead building over engineered > monstrosities.

What is with you? The article is talking about _languages_ , not the category of problems people are trying to solve using those languages. (In principle, NASA could have written the Mars rover code in brainfuck).

> enterprise features like exceptions and generics

What is an "enterprise feature"? Sounds like a Java-world word though.

I also don't understand how generics and exceptions "ensure consistency across the platform".

<comment><USER16> From the article:

"Go feels under-engineered because it only solves real problems" "and so you build real solutions rather than finding excuses to use your beautiful tools"

The implication from reading the article is that those of us that rely on those so called exotic features aren't doing so for serious business and technical reasons. And it seems to be a common thread amongst many Go users.

And generics allow you to reuse existing components much cleaner and exceptions allow you to handle errors in a consistent way across the system. You can build error handling classes but often handling errors explicitly doesn't scale.

<comment><USER17> > The implication from reading the article is that [...]

The implication _you inferred_ from reading the article is that...

I think there reason is that there a misunderstanding here caused by a cultural gap. The Practice of Programming is a very good read which I feel like recommending to every programmer.

> And generics allow you to reuse existing components much cleaner and > exceptions allow you to handle errors in a consistent way across the system.

Although I don't think "exceptions allow you to handle errors in a consistent way" (based on my long and still on-going experience with C++), I still don't see how exceptions and generics " _ensure_ consistency across the platform".

> You can build error handling classes but often handling errors explicitly > doesn't scale.

You don't build error handling classes in Go.

<comment><USER18> > You don't build error handling classes in Go.

That much is true, you compare strings!

<comment><USER19> Or do type assertions.

<comment><USER18> Ah ok, that is a better approach.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> But you can't deploy your Go to iOS. Or your Swift to Linux.

I'm getting interested in Nimrod (or Nim as I think it's planning to become). Compiles to native binaries via C, C++ or ObjectiveC. Even compiles to JavaScript. So it will run on all consumer and server platforms, on microcontrollers and in browser.

And it has generics, exceptions, macros, inheritance, and (optional, time- boxed) garbage-collection.

It's a tiny community which hasn't even managed to get a Wikipedia page to stay up, but I'm barracking for it.

<comment><USER17> > But you can't deploy your Go to iOS.

And? iOS and Android supports are on their way in case you're not following recent developments. In case you're interested in writing programs for mobile devices, there's already a supporting go.mobile repository with (mainly targeting Android at the moment).

> And it has generics, exceptions, macros, inheritance, and (optional, time- > boxed) garbage-collection.

Sigh... this "where's my feature!" argument almost always comes up.

It is not reasonable to expect that feature X that is very important to you has to carry the same weight for other people.

Some people think that it is unthinkable to write programs without feature X. If you think that way, then Go is probably not a language for you. Note however that there are many people who do not think that absence of feature X is a crippling thing, and do enjoy writing programs in Go.

> It's a tiny community [...]

in total contrast with... Nimrod community?

<comment><USER18> > OS and Android supports are on their way in case you're not following recent > developments.

Yes, but it remains to be seen how Go's view on data structures map Objective-C and Java APIs.

As for Android support, the Android team doesn't seem to care any little bit about it, given their statements on Google IO.

So you have developers of a Google language trying to target a Google platform, where the platform owners just want to support Java (NDK is a kind of stepchild).

<comment><USER19> The rough shape the Go<->Java mapping has already been formed:

[https://godoc.org/code.google.com/p/go.mobile/cmd/gobind](https://godoc.org/code.google.com/p/go.mobile/cmd/gobind)

<comment><USER18> Thanks for pointing this out.

Even though I don't like some of Go's decisions, it would be nice to see it on Android. After all, I created the ticket request on Android Tools.

But the feedback at Google IO from Android's team in this regard was disappointing.

<comment><USER21> Why do you want to see Go on Android? Yesterday, on the C++14 thread, you told me about why you gave up Turbo Pascal for C++ when you started programming for Windows 3.0 because you wanted to use a language officially supported by the OS vendor. If we apply that logic consistently, it seems to me that it would be best to just use Java on Android, unless you want to share code between platforms.

<comment><USER18> I agree, but sharing code between platforms is what I do, as I want to target both Android and Windows Phone on my hobby coding. So the common language winner to both SDKs is C++.

The ticket was created back when I was still into Go and was wishing for first level support on Android.

Still I think it would be nice if it would be supported for those that like the language.

<comment><USER21> Have you looked at RemObjects Elements ([http://www.remobjects.com/elements/](http://www.remobjects.com/elements/))? With that (commercial) toolchain, you can write in either C# or Oxygene (an Object Pascal-derived language), and compile to .NET IL, JVM bytecode (and from there to Dex bytecode for Android), and even native code running atop the ObjC runtime for iOS and Mac.

<comment><USER18> I know then from the time they used to collaborate with Embarcadero. Although I left Turbo Pascal/Delphi when Windows 3.x was still actual, I kept on following Borland.

What I am doing are very basic hobby projects, when private life allows for, which is seldom the case nowadays. You can check some of them with my nick at GitHub.

If I would be doing a commercial app, I would be buying either Qt or Xamarin, mainly because they are better known and using Pascal like languages (except maybe Ada) is no longer relevant on my CV.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> Am I the only one who is very confused by these examples?

A function named "frobulate" \- what is frobulate? I dunno. The function calls: thingsToFrobulate, logit, cleanupOldest, processOld, doNewThing, cleanup and somehow FrobulatingMessage is set on the way.

Honestly; you can do the most clever functional programming in the world but if you naming is like this then your code is just going to be bananas.

And BTW: both Swift and Go are missing exceptions; I think those would be very helpful here.

<comment><USER23> frob is a [https://en.wikipedia.org/wiki/Metasyntactic_variable](https://en.wikipedia.org/wiki/Metasyntactic_variable) , but not a "common one" which may have led to your confusion.

<comment><USER22> Ok. Maybe I am not getting the joke then. So thingsToFrobulate, logit, cleanupOldest, processOld, doNewThing, cleanup and FrobulatingMessage are "metasyntactic variables" too?

<comment><USER23> It just comes down to a habit of giving a name to something as an example of something that isn't meant to map to any problem domain. E.g. when a manufacturer is in the business of making "widgets," we know they're not actually making products that are widgets (whatever those are.)

Once you know that the names being used are not considered to be "important", the other names aren't as important as well, only the syntax. These metasyntactic variables are useful for avoiding situations like "Who's on First?" (e.g. [https://www.youtube.com/watch?v=kTcRRaXV- fg](https://www.youtube.com/watch?v=kTcRRaXV-fg) ) which is humorous to native-English speakers, but probably incoherent to non-native English speakers.

</comment></comment></comment></comment><comment><USER24> I would switch from python to Go but

\- Type system needs to be improved e.g. generic code

\- Verbosity, duplication of code are painful

\- Lack of functional features

\- Tooling

\- Maturity

<comment><USER25> Tooling? I am not sure about that one. Go tooling is pretty nice. The one area lacking a bit is, for want of a better word, "package management". However, I have been using gpm with success, and others are happy with godep.

For me, the biggest pain point is, to be honest, dealing with json. json in Go is not as fast as you would expect, due to the overhead of runtime reflection. Parsing "loose/dirty" json is also _painful_. If you cant be sure ahead of time if a value is `"1"` or `1` (int or string of int), and have to support both, you are going to have a bad time.

<comment><USER26>
        > If you cant be sure ahead of time if a value is `"1"` or
        > `1` (int or string of int)

...then your data provider is _broken_ and you need to take it up with them :)

<comment><USER25> Well, these are B2B customers, who are huge companies. We have actually had customers say they can't even find which servers are running the code, so could we "pretty please with money on top" just make it work anyway....

Sometimes you actually have to deal with what you get, and can't just "fix the other end".</comment></comment></comment></comment>


Is Writing More Important Than Programming? (2006) - <AUTHOR> https://blog.codinghorror.com/is-writing-more-important-than-programming/ <comment><USER2> A note that this is from 2006.

<comment><USER3> This is still valid though.</comment></comment>


NATO Group Catfished Soldiers on Facebook to Discover Troop Movements - <AUTHOR> https://www.wired.com/story/nato-stratcom-catfished-soldiers-social-media/ <comment><USER2> >"We managed to find quite a lot of data on individual people, which would include sensitive information," Biteniece says. "Like a serviceman having a wife and also being on dating apps."

I wonder if you could play it the other way like a double agent.

Have a target do those things that you know the opposition is going to look for. Have them jump on a dating app, have them wear a fit bit and visit some sites of interest, and see how quickly someone contacts them / how / what they eventually ask for / offer?

It seems logical to do that already, and to some extent easier to possibly play the double agent role?

<comment><USER3> Occam's razor: No. That serviceman was looking for an affair. That's it. :)

</comment></comment><comment><USER4> Another fun one is the case where FitBit data revealed military base locations and patrol routes

[https://www.wired.com/story/strava-heat-map-military- bases-f...](https://www.wired.com/story/strava-heat-map-military-bases- fitness-trackers-privacy/)

<comment><USER2> Back in the early days of smartphones (back when it was just blackberries) I worked for a company where we provided service (rarely, but it happened) to a site where no electronics were allowed aside from what you needed to do the job past the front gate... and even the you were told not to bring anything in the car you couldn't afford to loose at the front gate. We were told to expect to leave the site with nothing but you, your clothes, and the keys to your car that they'd give back at the gate.

Any phone wasn't even returned if you parked at the front gate and left it there (they searched all vehicles). It was also very clearly stated that you do not try to hide anything if you accidentally brought your phone and to just accept it was gone, it was considered very bad form to hide anything.

Anything you took in (laptop...) was carried by solders until you needed it, and nothing electronic ever left the site.

It was extreme but to some extent.... the most sure fire security I ever saw. I suspect it is the best policy for sensitive sites. Maybe not civilian friendly, but then again who knows where we end up eventually.

Basically almost anything was considered a security risk... decades later they're still right.

</comment></comment><comment><USER5> Reminds me of those three Chechen girls who catfished ISIS for $3000 on facebook by promising to be brides if they sent travel money, then blocking them after they did.

<comment><USER4> Somebody should give them a medal. I suspect that this sort of thing is an underutilized avenue of attack against terrorists and gangs. The surface area of attack has grown exponentially since e.g. the kind of thing seen in The Wire, and the general public is mostly ignorant of opsec.

<comment><USER5> Could we perhaps automate the process using machine learning to produce seed capital for a new VC fund?

edit - Call it 'Fundamental'.

edit2 - our brand consultants rejected 'The Foundation' as too obvious and thought 'Bottom Capital' wouldn't play well in the market.

<comment><USER6> "Bottom Capital" is brilliant

<comment><USER5> Thanks, is nice to have at least some positive feedback.

I suppose given my comment makes light of venture capital, machine learning, crowdfunding, catfishing victims, ISIS and Al-Qaeda, I should have suspected it might be unpopular with a fairly wide cross section of HN. ;)

</comment></comment></comment></comment></comment><comment><USER7> What is this "open source data?"

<comment><USER8> In military/spy discussions, "open source" means "doesn't require a spy to collect" ( [https://en.wikipedia.org/wiki/Open- source_intelligence](https://en.wikipedia.org/wiki/Open-source_intelligence) ).

</comment></comment><comment><USER9> Russians SIGINT/Cyber folks have been using various techniques to locate and identify Ukrainian forces using their personal devices in order to target them with rocket and tube artillery with devastating effect.

</comment><comment><USER10> Trident Juncture and Tinder comes to mind

<comment><USER11> I remember bellingcat covering the Trident Juncture exercise, they were able to find a lot of deployment info by just looking into public posts.

<comment><USER10> There are good greentexts on it (same story, told in different ways) [https://i.ylilauta.org/41/2ec653ba.jpg](https://i.ylilauta.org/41/2ec653ba.jpg) [https://i.ylilauta.org/c1/87a2bea0.jpg](https://i.ylilauta.org/c1/87a2bea0.jpg)

<comment><USER11> I hadn't heard of that story, thank you for sharing those links.

<comment><USER10> Haha my pleasure, military greentext stories are my weak point.</comment></comment></comment></comment></comment>


How to build a beautiful, sturdy standing desk for $30 - <AUTHOR> http://blog.voicebunny.com/2013/05/31/how-to-build-a-standing-desk-for-30/

<comment><USER2> I've been working at a standing desk for a few weeks and I don't think I could ever go back to sitting all day. My neck and shoulders feel so much better. Getting a nice mat to stand on is definitely the key though, otherwise your ankles and knees will start to feel it.

<comment><USER3> how many hours a day can you stand with a standing desk?</comment></comment>


The Man Who Loved Tanks - <AUTHOR> http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2009/01/13/BAHA157UND.DTL <comment><USER2> I was at his place for a fund raiser a while back. It is a truly awesome place, hundreds of tanks in huge metal buildings around a courtyard. My favorite was a scud missile launcher complete with scud from Yugoslavia (not Iraq). You would expect that a missile would be bright and shiny, like a new car, but no, this thing looked it had been beaten with sledge hammers. I am not sure whether it was the assembly process or whether it had just had a hard life.

</comment><comment><USER3> It was an amazing collection, and he had a team of people who really understood those machines. My favorite was a Russian radar system with giant water-cooled vacuum tubes that emitted radar pulses at some absurdly high power. That or the mobile bridge.

</comment><comment><USER4> I'm always amazed by people who can go to school for ~16 years, work for five years, and then spend the rest of their lives to "managing investments", sitting on various boards, and collecting tanks.

 _sigh_ wish I could do that...

</comment><comment><USER5> I've seen his collection on TV a few times. They used two of his tanks in an episode of Mythbusters, and the restoration of the Panzer tank mentioned in the above article was chronicled on a program called "Tank Overhaul":

[http://military.discovery.com/convergence/tank- overhaul/epis...](http://military.discovery.com/convergence/tank- overhaul/episode/episode.html)

His family has my condolences. Hopefully they'll now find a way to open his collection to the public.

</comment><comment><USER6> that sucks, I saw a special about him on CNBC and he seemed like a nice guy.

\+ he was an actual gear head and knew how to work on his stuff + drove it...instead of being one of those collectors who goes to an auction and buys a completed project that someone else poured thousands of hours into

</comment><comment><USER7> Ok, now that's what you call a hobby!

</comment><comment><USER8> Never got the chance to die in one.

You better believe that's what he was thinking about the whole time. Who wouldn't?

<comment><USER9> Why should he want to die in a tank?

<comment><USER8> It's better than cancer. Lots of people through history have wanted to die in battle.

<comment><USER9> Perhaps. Though the article states that he was not a fan of war.</comment></comment></comment></comment>


Citymapper is what happens when you understand user experience - <AUTHOR> https://medium.com/@zmh/bye-google-maps-ea3ea10f84dc <comment><USER2> Citymapper has this bizarre flaw (in London at least) where it relies on average times to give you journey times.

So, for example, if your train takes 10 minutes to reach your destination, leaves your local station every 30 minutes and you've just missed one, CityMapper will show an estimated journey time as 25 minutes (avg wait 15 minutes + 10 min journey), instead of the actual 39.

On multi-train journeys like many Londoners have, that error compounds quickly, and it can make choosing the fastest route near-impossible. And I don't know why they do it, because they have all the timetable data (including live timetables).

<comment><USER3> This isn't a bizarre flaw. We favor routes with higher frequencies, as typically users don't want to take routes immediately.

(I work on Citymapper's routing.)

<comment><USER4> Thank you for your work on CityMapper. However may I respectfully suggest you stop developing for a bit, and go out and actually use it for real, 'in the field'?

Head out the office, pick a spot to get to (say a meeting in another part of town) and see if you can figure out which route is actually quickest. It's seldom the one suggested. Trying to figure out the real trip length for upcoming departures for a number of travel options is a head-wrecker.

I use CityMapper frequently, and I _love_ it. But this 'feature' is _infuriating!_

<comment><USER5> > see if you can figure out which route is actually quickest

On this question, there's a balance between possible maximum speed, and reliability. If I want to go to point B, the quickest possible route will often be made by stringing together a serious of improbable connections. For instance, the route could rely on taking three infrequent buses, with little leeway for transfer between one and another, on the assumption that they won't be slowed down by traffic (or just slow customers, stopping more than normal, etc). But if an app sends me along this route, and one of the buses is behind schedule, and I miss the connection, that then becomes a big problem. So there definitely is good sense in prioritizing frequent bus routes to some degree.

<comment><USER6> When dealing with (London) tubes and train lines, most of the time it should be possible to indeed work out which route is actually quickest. I agree that buses do complicate things.

<comment><USER5> Yeah, I agree it doesn't make sense for train times, where there is a meaningful, rigid timetable (all jokes about British Rail aside).

</comment></comment></comment></comment></comment></comment><comment><USER7> Slow page. Ah, I see. One of the gif's in that page is 24MB:

[https://d262ilb51hltx0.cloudfront.net/max/800/1*rjIGH2VNUxDe...](https://d262ilb51hltx0.cloudfront.net/max/800/1*rjIGH2VNUxDerHiGBSydIA.gif)

And this one is 32MB:

[https://d262ilb51hltx0.cloudfront.net/max/800/1*a7_PF64-SfAd...](https://d262ilb51hltx0.cloudfront.net/max/800/1*a7_PF64-SfAdCLVtVYYDgQ.gif)

Total size of gifs in this page: 149MB.

Is Gfycat embedable? We should encourage its adoption.

<comment><USER8> Gfycat is just a service that provides h.264 video versions of gifs. Yes, h.264 videos are embeddable. So is WebM, but native support for it is worse than h.264.

That said, embedded videos will limit your browser compatibility unless there is a fallback. On the other hand, older browsers are also likely to have problems with 150MB webpages heavy on javascript.

<comment><USER9> That's what's needed - an iframe embed that detects and loads accordingly.

... but you couldn't embed that on Medium, anyway.

<comment><USER10> You don't need to use an iframe. HTML5 video tags natively support multiple formats. Between WebM and H.264, you support every major browser.

<comment><USER9> But with no inline playing on iPhones.

<comment><USER11> Some of us consider that a feature. If you go inline then either your video is distracting and hard to scroll past or tiny and hard to see. Neither of those is a good experience.

<comment><USER9> No matter how you feel, the end result is everyone using GIFs when targeting iPhone. So you end up downloading much bigger files.

Doesn't seem like a win for anyone.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Google Maps is for car drivers.

CityMapper is for multi-transportation within a few metropolis.

The UX of Google maps for routing when driving is incredible and beats everyone: Apple, TomTom, Garmin... everyone. Down to showing labels on side streets "3 minutes slower" allowing you to evaluate every decision you could make when faced with traffic.

But... for public transport, or mixed transport solutions like crossing a city when so many external factors are at play... CityMapper wins.

It's not an either/or, and it's not that Google Maps don't understand UX. Google Maps just has a different focus... the car.

<comment><USER13> Now if only I could easily set up waypoints on my navigation, so that I can plan a trip. (Leave in the AM, stop at X in 150 miles, stop at Y or Z in 2 hours, stop at Q for lunch, arrive at destination)

<comment><USER14> Oh yes it please. I ride a motorbike and I usually don't want to go on any of the suggested routes. I have to pick a waypoint, go to that, stop, take my gloves off, get the phone out of my jacket, pick another waypoint, put my phone away, put my gloves on, repeat.

The other annoying thing is it uses street names as in "turn right on to Main Street" but often the streets don't have name boards and there could be two close together.

Still, first world problems eh?

<comment><USER15> I don't know about the mobile app, but Google Maps on the desktop has supported multiple waypoints for many years.

Edit: as someone else mentioned, the app does support it.

<comment><USER14> I just double checked, in case of update, no such option.

</comment></comment></comment></comment></comment><comment><USER16> Honestly, the biggest fault of Google Maps is that I can't find something "along the way" to something, just nearby. I'd be much happier if I could specify "TGIF's on the way to Alice's house" or "Gas stations along the way to Las Vegas near the halfway point."

I can't get too mad at it, since I can just zoom out and it'll search from the center of the map - but it's not very effective if the distances are long or if I'm using the text interface.

<comment><USER17> Checkout Waze. It calculates time off your current route.

<comment><USER18> Since Google now own Waze, hopefully these features will be heading to maps soon.

</comment></comment></comment><comment><USER19> It's fantastic that they understand user experience, but they don't seem to understand that 95%+ of the world doesn't live in 8 specific cities. Google Maps might be an obnoxious app (it is!) but at least I can use it.

<comment><USER20> " _Google Maps might be an obnoxious app (it is!)_ but at least I can use it."

You know, you're going to have to actually elaborate on that.

<comment><USER19> Elaborate about which part—Google Maps app being obnoxious? The linked article makes a strong case for that—common actions are a number of slow steps, the information that people are actually looking for is missing or difficult to discern, etc. Or that I can use it? That's because I don't live in one of the 8 cities that Citymapper supports, whereas Google Maps works on, I dunno what % of the world, but I'm guessing it's pretty high.

<comment><USER21> Except it's really not designed for that. It's designed for people who know where they're going and how they're going to get there. I don't know, I get in my car, punch in an address, and GMaps does a pretty darn good job of finding a route. That's what 95% of us want.

</comment></comment></comment></comment><comment> TD-Linux OpenStreetMaps has begun to add routing information, and it's becoming very good lately. It would be nice to see Citymapper work with them, as both sides could benefit - OpenStreetMap quality in citymapper's supported cities would improve (though OSM is already quite good in those cities), and citymapper could gain support for more cities. This is the route MapQuest has gone with MapQuest Open.

Still, I'm glad to see Google Maps competitors alive and kicking. Google Maps is one of the main lock-in apps that keeps people inside the closed Google Play Services ecosystem.

<comment><USER20> " _Google Maps is one of the main lock-in apps that keeps people inside the closed Google Play Services ecosystem._ "

I can't speak for others. But as someone that tried the Apple "ecosystem" after being on google, I have a big appreciation for it. A lot of websites/apps these days use google for single sign-on, pretty much meaning that I don't have to type my damn login every time I install a new app, etc.

But, on the Ipad, I had to type my password in so many times. And my password is 25+ characters long, with mixed upper and lower case. Easy on a keyboard, but on a touch-screen keyboard it is a _PAIN_.

<comment> rational-future Apple has 99 faults, but your lack of touch typing skills ain't one :)

<comment><USER20> I can touch type, just not on a touch screen :)

</comment></comment></comment></comment><comment><USER22> Great, but the fact that Citymapper is only available in eight cities makes it completely useless to those outside of those cities. From this post, however, it does seem like a very well put together experience.

</comment><comment><USER23> Not everyone has the same needs.

When I use Google Maps all I really want is for it to take me from point A to point B in my car.

I type the name of a place and It loads directions, time, traffic, and guides me there using the best route possible. One click. Quite literally the best UX I could imagine.

For most of Google Maps users (the ones who don't live in those 8 cities), Google Maps is almost perfect. It's not that Google Maps doesn't have a good UX, it just wasn't built for you.

</comment><comment><USER24> I love Citimapper! I live in NYC and it's the only app I use for navigation now. Highlights for me:

1\. Get me Home/Get Me To Work quick links. It takes your current location as starting point and tells you your options for going home/work.

2\. You can configure it to monitor your subway line during commute time (7AM to 10AM and 4pm to 6pm) and it will notify you if the subway is delayed for any reason. I use line 6 which breaks down more often than I want and thanks to the App, I can take N/Q/R if Line 6 is down.

3\. The way 'Get Me Somewhere' works. In addition to being able to type an address, you can move the map around to point the destination pin to a particular point in map. It's hard for me to explain but it works amazingly well especially in NYC where people often go by cross streets and don't have the actual street address.

I completely agree with author that Citiymapper has an exceptional UI/UX.

<comment><USER25> 1\. native behaviour in Google Now 2\. native behaviour in Google Now 3\. native behaviour in Google Now

None of these requires additional configuration, it just does it all automagically.

<comment><USER26> Nobody knows what Google Now is. It's hidden away in the Google Search app in iOS (who uses the Google Search app? Nobody I know. You search in a browser.), accessible only if you happen to know to swipe up from the bottom of the screen. Because that's a really obvious place for a mapping app to be.

</comment></comment></comment><comment><USER27> I agree that the UX of Google Maps isn't great, but one thing that might not be quite fair in the critique is the point about having to enter the origin destination. On mobile, I'd venture to guess that most of the time you simply want to get somewhere from where you are right now. So I personally don't see the origin destination as something that I need quickly accessible. I enter address, click when it auto-populates, and click to navigate. It's usually 2-3 steps for me on Android and I'm ready to go in 5 or so seconds.

</comment><comment><USER28> It's nice to see a thoughtful critique/comparison (dev on iOS gmaps here). Interestingly I don't think anyone who works on iOS maps lives in a citymapper-enabled city.

Couple of points that might be helpful if the writer reads this:

\- you can switch off the shake-to-send feedback (it even prompts you to do so if you dismiss it a few times without leaving feedback).

\- I'm not sure how the Citymapper UI in scenario 2 (getting directions from a->b) differs from using the directions search screen in googlemaps (reached via the little button with arrows next to the profile button). It presents the directions search screen immediately and would cut down the time in that scenario drastically. (But I guess if the person writing the article doesn't know about that button that's rather a UI smell. I wonder how many people don't know that our things that don't look like buttons are buttons?)

\- Scenario 5 is also fixed by using the directions non-button, your previous searches show up in the zero type suggestions there.

I am however going to try and convince the powers that be that Citibike integration is a must, so I can have a holiday to new york.

<comment><USER29> I don't think adding the integration would be hard. For example, the Montreal bike system (and other Bixi deployments) has all the information you'd need to add the integration, including the lat/lon of all stations and their current bike count[1]. Citibike has a different endpoint[2] and data format, due to the contractual dispute between Bixi and 8D, so they had a different system deployed than other Bixi rollouts.

A simple implementation would simply walk between the endpoints of the route and the closest bike stations. A better integration would also consider more complicated multimodal routes (walk, bike, metro, bike, walk) and historical usage patterns to predict empty/full stations.

If it helps convince the PTB that public bike system integration is a must, I use it as my sole means of transportation during the summer months, relying exclusively on bike navigation (it's great!), then awkwardly fumbling with another app to find a bike station near my destination.

[1] [https://montreal.bixi.com/data/bikeStations.xml](https://montreal.bixi.com/data/bikeStations.xml) [2] [http://appservices.citibikenyc.com/data2/stations.php](http://appservices.citibikenyc.com/data2/stations.php)

</comment></comment><comment><USER30> I would sure hope that a site that only works in seven cities would be better than a site that works worldwide. Otherwise what's the point?

<comment><USER20> What about a site that only works in one browser? _(Ok, just trying to be catchy there. It works on 2 /3 of the browsers I have installed to test with.)_

</comment></comment><comment><USER31> "OK Google, how do I get to X?"

"It takes 22 minutes to get to X, here are your directions."

I guess that's an unfair comparison. Fair enough about actually using the app though.

<comment><USER32> That's not really a comparable experience in a city where you have multiple modes of transport, many different options for a single journey, and so on.

<comment><USER33> But I'd wager that the vast majority of Americans don't live in cities like that. It sounds like Citymapper is nailing its niche, so for people that fit that profile it's a much better experience.

But I live in Austin, TX. No one is taking a bus or train or bike anywhere. Especially not in a hurry. Virtually everyone drives everywhere; with Google maps on Android I can often do that in a single voice command and zero clicks.

</comment></comment></comment><comment><USER34> Citymappers founder, Azmat Yusuf, gave a talk at the Hacker News London meetup earlier this year and it was categorically one of our most popular talks in a long time. Unfortunately Azmat (very politely) requested that we not record his talk for our vimeo page (vimeo.com/hnlondon) which is a shame because it was incredibly insightful.

If you get the opportunity to attend a talk by Azmat or any of the team, take it. They are an exceptionally clever and humble bunch and I'm thoroughly enjoying being a witness to their growth and success.

</comment><comment><USER35> "Scenario 3: What are the trains near me?" is great feature.

Even better would be "Where do trains/buses go from where I am?"

It would be very useful to see all route lines radiating out from my location, with next times and freq.

This would help understand the multiple ways to get to another location.

One route might get me directly to location, but leave in 15 min.

Another route me get me 2 blocks from location, but leave in 2 min.

</comment><comment><USER36> I use Citymapper to use Citibike, and it has the following big flaws:

\- Reloading the app, it never remembers I was on the biking screen, and always goes to the main screen. Minor detail, but annoying, and so easy for them to fix!

\- Every time I move the map even slightly, it removes all bike stations from the map and queries the API again for a new set of stations, even if the last request was only five seconds ago. If there's any wireless interference, it complete destroys the functionality. I mean, cache the station _locations_ at the very least! And don't hide the old data while waiting for the new data, if it's less than a couple minutes old.

\- The screen real estate devoted to the map is only ~50%! The bottom third is taken up by a totally unnecessary textual list of stations, which can't be hidden

\- And you can't even rotate the map!

Granted, it's a million times better than the default Citibike app. But it's still got a ways to go to achieve "ideal" UX.

</comment><comment><USER37> Bye Google Maps? It uses Google Maps...

<comment><USER38> indeed, I was expecting...

"...Hello OpenStreetMap"

<comment><USER39> They could probably do this for the cities in Europe, but the US cities have still some work to do.

</comment></comment></comment><comment><USER3> I'm a backend engineer at Citymapper. Just to let everyone know that we're hiring... [https://citymapper.com/london/jobs](https://citymapper.com/london/jobs)

<comment><USER40> Needs more Melbourne already :P

(sorry about the pain and suffering if you do decide to build out melbourne and look at PTVs API docs)

</comment></comment><comment><USER41> [https://citymapper.com/](https://citymapper.com/) is down. Google Maps is up. I don't think I can say "Bye, Google Maps" just yet...

</comment><comment><USER42> Citymapper is okay, it sometimes screws up with its notifications feature though. I live in London and have it set to notify me if my "favourited" tube lines are suffering problems.

A signal failure happened earlier this week on my line and I received no notification of it, only finding out when I got to the station.

It's probably an issues to do with Androids background notification system or something, but I dunno

</comment><comment><USER43> I was in London recently and was astounded at how prevalent Citymapper has become there. So I'm now taking bets on who will acquire them:

1\. Google --> unlikely, they have a large maps team already, and have recently gorged on Waze

2\. Apple --> most likely, IMO

3\. Facebook --> who knows why? But probably in the running too.

<comment><USER30> Google did buy Waze, so they are open to maps acquisitions.

<comment><USER44> They bought Waze "mostly" for the userbase, but the fact that they have some of the best traffic data is useful too.

<comment><USER45> . . . and is interesting as it's almost completely orthogonal to this.

Google's existing offerings fail most spectacularly for knowledgeable people in urban environments (I cannot overstate how much GM's handling of subways drives me insane), which is the niche this lot have successfully found. Apple seem to have a lot of customers in that bracket so they are the better fit.

</comment></comment></comment></comment><comment><USER46> Feature Request / Suggestion - So I tried the "Share Destination / Meet me sonewhete" feature the other day and thought this was going to do something completely different.

How it worked: sent a link to the end location to a friend.

Expected / Hoped for usage: Citymapper would separate who clicked the link (allow you to add a name perhaps), then show where everyone else was on the map, and their ETA.

So I can say, let's meet at this place, send the link, and know everyone's ETA. A bit like latitude, but smarter. Once there, or on my way, I can track progress.

Sure, people might shout about privacy, but it would be insanely useful and save constantly being punished for being on time!

Any Citymapper devs out there fancy championing this one?

</comment><comment><USER32> Citymapper's UX is really awesome, and I always use it as my example of the degree to which attention to detail is so absolutely vital in this sort of app. Like, first-class, best-app-I've-ever-used level of UX.

I'm still not totally sold on their routing algorithm in London, but I'm not sure exactly what's wrong with it - all I know is it often suggests routes that no same person would take. It definitely seemed to get a little worse maybe 6 months or so ago; it's possible it's just been tuned in a way that doesn't get on with my usage pattern.

<comment><USER47> I find that it's become a bit worse as I've become more familiar with London. For someone who doesn't know the city at all it's perfect, but once you know the tube map and various local details, some of the options do seem a little odd.

One of the devs posted in this thread that they favour routes with more frequent services, as people often don't want to travel immediately. I'm not entirely sure I agree with this thinking in a mobile app, but it could explain some of the less optimal routes.

<comment><USER48> Yeah, it doesn't really get all the tiny things that you have to know the system to know. For example, on trips where multiple lines travel on the same tracks, the average wait calculation looks to use only one line's frequency (Liv St to Edgware Rd, "5 min avg"). Time to change between lines at interchange stations also feels unrealistic (1 minute Northern-Bank to Victoria at Euston and 2 minutes Victoria to Piccadilly at Green Park?).

</comment></comment></comment><comment><USER49> Btw, Citymapper website doesn't load in Firefox Aurora, v33.0a2 :/ ([https://citymapper.com/apps](https://citymapper.com/apps))

<comment><USER48> I found that occasionally their Javascript won't load, at least in Firefox. Usually works after a reload or two.

</comment></comment><comment><USER50> This looks great. It needs more coverage and I don't think the silly options are a good selling feature for a real map app. It's just more visual clutter.

</comment><comment><USER51> "Turn-by-turn directions"

One of the reasons Im guessing it doesnt have this is because the Google Maps API prohibits building turn-by-turn applications quite directly. If only they trusted OSM, they could have this up and running pretty quickly.

</comment><comment><USER52> I don't understand why they can't use Google Maps or OpenStreetMaps or some other API to grab city data for other cities. It only covers NYC, London, Barcelona and a few other cities. Nearly useless for anyone else in the world!

</comment><comment><USER53> If I hit "snap to location", Google decides it needs to auto-zoom to a default zoom-level. It's annoying to have to re-zoom to whatever zoom level I'm actually interested in.

</comment><comment><USER54> Meh! I find these features just incremental improvements. Most apps these days quickly catchup on UI/UX features. Even OSes are mostly the same these days.

</comment><comment><USER55> I wanted to try it but it doesn't seem to support San Francisco! What kind of app doesn't start with San Francisco, let alone not even include it :)

</comment><comment><USER56> Yes! I've really been wanting something like this, maps apps are only good at doing one thing at a time and not good for comparing.

</comment><comment><USER57> I havent ever tried Citymapper. That said, if Google Maps re-routes me one more time during my transit I will kill an innocent puppy.

</comment><comment><USER58> It would be interesting to compare to Ridescout, which seems like a more direct competitor than Google Maps.

</comment><comment><USER59> Anyone know what screen recording software might have been used to create the gifs/vids in this post?

</comment><comment><USER60> I hate the popup in google maps when I search for a location. It takes up 1/3rd of the screen.

</comment><comment><USER61> And yet Google maps has mapped the world, has my little town mapped, Citymapper is but a fraction of what Google maps has done.

</comment><comment><USER62> How do I buy you a beer?

</comment><comment><USER25> I suppose when you're on an iOS device it doesn't take much improvement in the UX department to get you fired up.

<comment><USER63> The ability to just drop a widget on the home screen that instantly brings up directions home or to work (or any other destination you want) in the preferred mode of transportation would blow this guy's mind. 10 seconds? How about 1 second. That's been around since _2009_.

Now, Google Now automatically shows directions to these places together with expected travel time on preferred mode of transport without any configuration at all. 10 seconds? How about 0 seconds?</comment></comment>