Hacker News Reader

Comment by emrekzd | Hacker News Reader

I don't think I've learned anything from this article. It's interesting how quickly the keywords pick up on HN (Uber and Go).

More than 3 years ago we've implemented a reverse geocoder web-service that indexed complete Census TIGER dataset. The service handled over 15K reqs/sec on a 2011 macbook, doing exact in polygon search(no approximations). We implemented an optimized (for in polygon search) R-tree data structure for the lookups.

Assuming Uber's geofence lookups would rely on a much smaller dataset than TIGER, I think you could have come up with a much more efficient implementation requiring a fraction of the resources.

And again, use of Go; irrelevant.

View on HN

2 interesting things: 1) Go performs better than Node.js 2) They couldn't get goroutines perform fast enough.

This is a scientific paper.

In all fairness there are many languages (generally statically typed) which perform better than Javascript. That go is on the list shouldn't be a surprise to anyone.

They were worried about goroutines performance but I'm not sure they actually tried them.

What project was that built for? Was the reverse geocoding web service the end goal?

No. One engineer built it in two days.

> We implemented an optimized (for in polygon search) R-tree data structure for the lookups.

I wouldn't be surprised that due to the lack of generics in golang, this approach was less feasible.

Where would they even use generics? All their algorithm requires is arrays of polygons, and a function to check if a polygon contains a point.

To store the RTree entries. Say you want to switch between 32 bit and 64 bit floating point types in your implementation, without re-writing the entire thing.

sed -i s/float/double/ *.go

What do you actually need generics for that you can't do with interfaces? Not to mention that compile-time generics (read: generating code for each type) make testing with mock types much, much harder.

Type safety and performance.

Also, how does it make testing harder?

Not everything could be type safe with generics.

You can't typecheck the generic itself. Especially conversions could be really hard with them.

(I love generics, still this somewhat aweful). Currently Converting Generics between Scala and Java is totally Ugly.

Could you provide an example? I'd be interested to know more.

Not another dismissive comment about the lack of generics in Go again.

I don't know that it's dismissive so much a factual statement.

OMG, seriously? Because people couldn't implement smart data structures before generics were invented?

(disclaimer: i think that lack of generics in Go is a mistake)

We could, but we got clever adopted the ideas of CLU, Ada, Eiffel and ML and stop doing that in the early 2000's.

Go generate, for example, brings me back memories of a time C++ compilers used pre-processor magic for generic programming, around 1994 or so.

Something like

    #define Type1 my nice type1 definition
    #include <generic-list.h>

    #undef  Type1
    #define Type1 my nice type2 definition
    #include <generic-list.h>

    ListType1 ...
    ListType2 ...

This one uses a "Spatial" interface and has worked well enough with a little bit of tuning.

https://github.com/dhconnelly/rtreego

Using an interface is not good for performance.

Reply on news.ycombinator.com