(I believe Etsy had a policy of rewrites needing to support current needs multiplied by five. This acknowledges that there's a reasonable trade off between current needs and future-proofing.)
Less wrong: "made architectural choices based on personal preferance"
Don't be such a politically correct idiot!
The business requirements to the architecture — not functionality! — change over time. At first, you have to be lean as hell and try a lot of different stuff. Then, you need to scale, and performance becomes an issue. Some time afterwards, you want to add more features to increase monetization and retention, and here you start needing good, abstracted out architecture for all this stuff not to interfere with each other. And finally, you find the sweet spot, and start to really care about bug-free experience, maintainability and reliability.
And all these different business priorities are best suited by different languages, different design approaches, different architectures and people with different personality traits.
Though, that being said, I'd actually recommend Elixir, which gives you the same Erlang-ecosystem benefits, but with the key advantage of being 5x easier to convince the average Ruby/Python developer to use.
Only the particular languages and frameworks change, but the patterns remain the same.
If you had tried out Parse right when they got acquired by FB, chances are you would either have a fundable business that can hire engineers to move to your own infrastructure, or you would know that your business idea doesn't work. Either way, you no longer need Parse.
Similarly, the shutdown mostly affects "zombie" businesses - the ones that aren't dead, but aren't growing either - because in a year, you should be able to figure out whether or not your business concept has legs.
While it was not 'idiots' that was the reason, the later developers always had just enough more data on the assumptions to be made for the current revision. But then again, not enough to foresee the need for a fresh rewrite when things changed again in the future. Sometimes, the rewrite was essential, sometimes it was just on a subjective whim to build a silver bullet once and for all!
I've worked in startups that tried to implement the "1-2 languages only" (usually Java and Jython/JRuby/Groovy) policy as a startup, and they didn't go anywhere. That team of prima donnas who is willing to mortgage the startup's future in order to ship an awesome product seems to be a necessary feature of startup success, and only successful startups get to hire the team of professionals who will button down everything, choose "official" languages, and build tier-1 infrastructure. So yes, it's incredibly unfortunate, but this is the industry we live in. Pick which role you wish to occupy accordingly.
I believe those 4 languages were Java, C++, Javascript, and Python. Nowadays they also use Go, Dart, Groovy (in Android Studio), and I guess a lot more. (When I say Groovy, I mean the tiny non-Turing Complete subset of the syntax used as a DSL in typical Gradle build scripts.)
I've thought this myself but never put the words together so clearly
Google as written by Larry Page was done in Java. It was rewritten in Python by Scott Hassan before the company was incorporated. As of 1999, the webserver and crawler were still in Python. It was almost completely rewritten (multiple times) in C++ shortly thereafter for efficiency. Most of the Google Apps (GMail, Docs, Plus, etc.) are written in Java. The webserver for Search shifted over to a combination of Java and two different DSLs in 2010; I worked on the implementation of this. My comment is lightly paraphrased from a remark Larry Page gave when asked why Google doesn't adopt more modern programming frameworks like Rails or Node (it was in 2011, when both of these were still state-of-the-art).
I started my career with the belief that your company has one tech stack, the chief architect chooses it when the company is founded, and that you never ever rewrite it because you're in for a world of pain if you do.
I learned that basically no company that experiences hyper-growth ever does this. Instead, the founder chooses a tech stack based on whatever he knows best and will let him write a v1 quickest - whether it be Java (Google), Perl (EBay), PHP (Facebook), or Common Lisp (Reddit). The first few employees collectively say that the founder is an idiot, choose a different tech stack (usually whatever's hot right now - probably Go or Node.js at this time, Python or Rails in 2005), and rewrite the whole product. They hire an experienced VP who says that the first few employees are idiots, chooses a different tech stack (often the tried and true enterprise favorites of C++ or Java), and dictates that everyone rewrite the product. Eventually, managers with more recent experience in that language get hired, who collectively say that that VP was an idiot, and the real way to do C++/Java is with Guice, Boost, C++11, etc, and rewrite the product that way. Development grinds to a halt, and the company buys a bunch of hot startups who wrote in whatever language they were familiar with, who are technical idiots but managed to build a product that everyone likes.
In this context, Parse and other BaaS providers makes a lot of sense. You can get your v1 product out there really quick, get customer feedback, improve it, take VC, and hire lots of programmers to call you an idiot and rewrite your product into something saner. Then you get bought, everybody at the new company thinks you're an idiot, but you have at least cashed out. Or you don't get bought and hire a VP who'll force you to rewrite your product, but at this stage you have so much of a market lead that it doesn't matter, and the BaaS got you to the point where you have the resources to free yourself of it.
(I wonder if I'll end up tripping some HN flamewar auto-detector with the number of times I've said "idiot" in this post...)