What changed in the architecture? It is rather interesting that by just having a language change you could remove 28 servers from the system.
There is a recent trend of building more and more complex systems, have less coupling and 'good oop'. That's all good and nice but simple code is:
- more maintainable (a complex nest of objects & function calls all loosely coupled isn't)
- a lot more readable
- easier to optimize
- better for your sanity
Exactly. That's the terrible stuff with all this "enterprisey" mindset: people are working on medium-sized codebase made of this special kind of hell that Java/C# + ORM ([N]hibernate) + XML + SQL is and these app often run into the 200K / 300 KLOC lines if not more. Yet what does these applications really do? Actually not very much. Yet these programmers are sure to be working on super-advanced stuff because their codebase is big.
When several companies reported a drop in LOC of 90% by switching to something else than Java then at one point you have to at least consider that maybe most of your Java codebase is hot air.
PS. The fact that you can point to one (or a few) efficient abstractions doesn't mean they all are.
More close to heart, the abstraction that source control gives you. Imagine not having git (or whatever tool) and thinking you will compare this weeks code with what was available last week. Now just do the same based on the changes introduced by a single developer. Trivial with the abstraction of source control. Hella tough without.
So, no, just because there are layers of abstractions does not automatically mean things are going to be slow.
All of that said, I can see and ultimately agree with your point. Excessive abstraction can be bad. Unfortunately, I think the jury is out on where the hell that line is. (Likely they are distracted with other pointless questions while others are out solving problems.)
Abstractions can definitely be an improvident in some cases. They just bring extra complexity at it's cost. In the 'map' case you pointed out, you now need to take into account the performance characteristics of an array, one or more hash functions and linked lists in their specific configuration.
Even though the lookup of a hashmap is supposed to be O(1), you now have to run a hash function for every lookup. That's bound to be slower than the simple integer addition we were doing before on the flat array.
Besides that, if it's a bad hash function (or if the data is bad), performance will easily go down to O(n).
>> So, no, just because there are layers of abstractions does not automatically mean things are going to be slow.
That's not what I'm saying is it? I'm making the point that it'll be slow/er/ because of the overhead of the abstraction. I didn't say "less productive" or "every abstraction is bad", I'm point out that each extra layer comes at a cost and that the extra cost gets buried the more layers you add.
I'm not going to go into the source control argument because I'm talking runtime application performance and mental overhead, not developer performance.
Basically, I object to the idea that abstractions slow you down by their nature. I agree that poor or unnecessary ones do so.
What could be more expensive than rewriting all you code? For many Rails web apps the cost of additional servers is far below the cost to rewrite things in Go.
Obviously, the economics of a rewrite depend very much on the size and complexity of the code base, but it didn't sound like they had a huge code base at the time of the rewrite.