static_typed

Luckily for Uber, the protesters only protest a maximum of thirty five hours per week, Fuck off entirely for the month of August, and won't travel more than two miles from one of the dirty bistros to protest in the first place.

If I was Uber, I would pay cash to all the homeless people to take slow long rides in the normal cabs to block them up.

Or if you are actually going to perform an upgrade, consider a move to one of the more mature, stable, secure frameworks under Python, Perl or PHP.

Less Rails - less fails. Simple!

Citations or evidence required for your claims that Twatter is absolutely one of the best around.

We owe Twatter a big thanks for showing Rails on Fails doesn't scale (via so many fail whales), and so guided many a new startup to explore Scala, Erlang, Python, C++11 - basically things with a good chance to help not hinder your startup.

Thanks Twatter!

I can see the conversations now: "..and they trust you with their wife data?"

"Dumbfucks".

The fact is COBOL is still used, and useful today, all these decades later. I wonder what the sentiment about Ruby on Fails will be in thirty years time, and I don't think we will still be using it.

RESTful services still work in those situations where they are correctly applied. Maybe what has happened is some of the less mature and more shrill developers have stepped back from their war on any Web service that doesn't fit their dogmatic rest-tard view of the world. There are plenty of valid XML-RPC based services that continue to run well despite the whining that someone somewhere did not yet have a ruby gem to connect their ruby on fails site to it and that it was simply unacceptable - and so complain on twatter they must!

So in short - no, REST works, use it in the right places, and remember kids - not every Web service or endpoint has to expose a REST based interface.

Boss has a problem, so he hires an MBA, now he has 300 problems, and he got fired as well.

Database administration - is not a fire and forget task. It dismays me greatly that so many developers do not see beyond the code in their IDE, and think they can just bring a DBA for a few days, and all will be well. It may also surprise some developers just how much return on investment a good DBA can bring - they can and do learn about the business, the data, the processes and can then help get the best from the database as a result of that knowledge. But they can also serve as an SME on the database engine technology, perhaps pointing out where it is not being used in the right or optimal way. The biggest gains in performance generally come when they help a team of developers who were treating the database as a dumb data store and not making any use of the features offered.

The DBA is not dead! They just look and smell that way!

But in all seriousness, if your app uses a database, you are incompetent not to employ an expert to help with the database, whether advising on the query plan of those non-performant queries, or what is the best setup for the current stage of the business and app, they are very useful.

My old Nokia phones had a flashlight mode built in, very quick to activate and use, not as a separate app. Even if it does need to be an app on Android, at least include it in the base or core, as it is such a popular and useful thing to have.

The key takeaway in the benchmarks seem is that Go is significantly slower than the rest, much much slower.

Apart from the regular 30-sec interval postings on HN extolling the virtues of Go, it seems to me, people should rekindle an interest, or discover a new interest in D, C or Erlang where performance is a consideration, and maybe Go where a need to feel like part of the post-Ruby crowd.

Sure - when restaurants take on a new cook or chef, they may well ask him to produce a dish or two, but none of those dishes will be sold to paying customers outside. The staff/management will check them, try them, review them, but will not be selling them to the customers outside.