Popularity stats/maths is easy to explain:

it's like a differential equation, dsuccess/dt ~ success

Just the same as new stories on HN, where a single upvote makes it much more likely to take off.

The reason is that (almost) no one wants to take the risk of being "first": whether at an empty restaurant, liking, kickstarter, comments, etc. But then as more people pile on, it increases faster.

So Thomas, it's not a tautology... it's human behavior. :-)

Parking structures might become high-security, automated bldgs that people don't enter. Further, local parking spaces may be unnecessary as your car (or the car you rent) will pick you up.

The interesting problems are:

- tracking thousands of objects' trajectories to avoid as many threat-weighted collisions as possible. (think NYC times square)

- not going too fast when visibility is blocked

FYI: When I was at Trimble Nav, there were self-driving farm equipment demonstrated c. 2000.

As a creator and a consumer, I think one has to not resent giving away something. Don't expect compensation, but ask for it if it's necessary to accomplish something as a stretch goal up from free. Also, there is value derived from street cred and it's better than a résumé.

https://github.com/steakknife

The Oracle JVM is pretty versatile and has been beaten on in production on an extremely large scale, as much as M$ CLR.

Java as a language though was a primary response to over-correct and over-optimize for secure, correct, safe code based on the history of C's shortcomings. There's are many other lessons that have been learned since.

Java is really hard to beat apart from specialized formal methods verifiers (coq, CVC4), strongly-typed functional languages Haskell and similar derivatives for embedded industrial systems. If you're involved in safety critical systems, you should be using the simplest and easiest to understand formal methods tools as possible. If something's too esoteric, fewer people will be able to double-check the work.

For wider participation, it's a tradeoff to use one of the more popular languages that lack correctness aspects because of the absence of a learning curve.

JVM != Java so not sure why that point belongs in here.

Yes, it's best to use the smallest tool (orthogonal language and libraries) for the job because it's less to test and maintain, and more likely to be correct.

Elixir is neat, but it takes dynamic languages much farther away from static type checking.

Static compilation and compilation speed make Go very attractive for large projects.

Erlang has dialyzer type checker. Depending on how well users refine their types that can produce very good results. Combine that with property checker (PropEr or QuickCheck) + Erlang's default process isolation and fault tolerance, and I think it can make for a more reliable system. I think I'll take that into production over just having a statically typed program. (Just going off my gut feeling and experience).

http://learnyousomeerlang.com/dialyzer

( not sure if Elixir supports it though, but it seems so:

http://elixir-lang.org/docs/stable/Kernel.Typespec.html )

Yeap thanks, have used both.

It's just optional, and therefore doesn't get used much on open source projects. So the average quality of code suffers.

Whereas something like Go where extra import are hard errors, making best-practices mandatory keeps code to certain standard and it's zero work to setup.

Yap, makes sense, I see your point.

Haven't heard of mandatory dialyzer type coverage yet. It would be kind of commit hook of sort, still external to the compiler though...

Ugh. What's most needed is a erlang-platform like haskell-platform.... bring together vital tools (proper/dialyer/etc), have a great package index (like hackage/pypi/rubygems) + package manager and have a skeleton project generator (rails-ish) that sets up what was asked for.

Convention > configuration

The easier it is to get going and contribute, the more people will use it. (Haskell pushed hard on this later on and has really benefited. Node did it early.)

It's essentially duck-typing iOS Objective-C protocols, but closer to how RubyMotion basically makes them optional.

Seems like a bump in the road, but it's something Bezos has to stay on top of to not be too long term to lose investor interest.

FedEx/UPS + Amazon merger would still be a good move and lock up last-mile distribution that only WalMart would be able to touch, but then WM would have to pay a premium for whichever chair would be left.

Nah. They're building their own distribution network. FedEx is great at being FedEx, but Amazon wants to be able to do same-day delivery with multiple time-slots per day. They also want local warehouses, which minimizes wasteful shipping.

Amazon is missing the entire last-mile delivery pipeline apart from some shared boxes and jokes about quadcopter delivery.

Also, Google Express is way ahead given the number of trucks and cars going about from Costco and other local merchants, which is coming at Amazon from the other side.

Building it would effectively be starting from scratch and competing with FedEx, UPS, DHL and everyone else. And if it doesn't work, they'll be stuck with capital tied up in it.

Further, it's going to take a long time and a LOT of capital, and it still might not work AND still not be any better/cheaper, whereas FedEx is a known quantity that works. FedEx has a lot more experience than just delivery: it does lot of logistics and emergency logistics outsourcing for a lot of companies... and it would still be viable revenue if Amazon controlled them.

I take it your city doesn't have Amazon Fresh vans all over the place yet?

Mountain View (for obvious reasons I guess): Google Express.

But really, what difference is there over just extracting the functionality of local courier into a stand-alone global service with an web presence, API, support, backoffice fleet management/dispatching and so forth? All FedEx and UPS have to do to compete with this is send drivers into stores.

I worked at a dept with ~2.5% acceptance rate.

There were two, subtle factors in play: soft ageism and PI's hiring their clones (in thought, gender and race).

So the dept gravitated to predominantly two minorities, at least in terms of staff, faculty, visiting researchers and grad students.