Nice. Though i haven't seen many libs really go unsupported in python2. I am still hesitant to move to python3. Doesn't mean i don't share your pain. The py3 choice was a bad one in my opinion.
I'm both in the business world as well as a developer, here's my experience ...
I was riding the new tech wave as well as a young Tech Jedi. Built a polymer-dart project, put it in production, a year later and polymer actually became 1.0, but not compatible with 0.5. Now to keep that project up to date, we have to spend almost as much as we spent on building it, lots of money down the drain. Python, we were riding the latest and greatest Python 2 libraries, built awesome stuff quickly, two years later and Python upgraded to Python 3, plenty of the libraries we used is no longer supported and we have to do a rewrite to get stuff to work in Python 3 - the initial project costs several million to develop, we haven't made estimates how much it will cost to migrate / rewrite to Python 3, but it still seems like a waste. PHP, we built a giant system in PHP, since PHP doesn't have type safety, we had some random errors in the system that none of the developers could solve, somewhere in the code something that was supposed to be an integer morphed into a string and strange things happen. ExtJS, similar issues, after a year or two, it becomes difficult to support the old system.
Java, so far stuff that we have built 5-7 years ago still runs perfectly, if we need to add features, we simply add the features and stuff continues to work, we've never needed to rewrite anything due to libraries not being supported anymore, porting things to the latest versions of libraries usually works without any tinkering, in the cases where it doesn't, the older versions from 10 years ago of that library is still available and we can stay in business.
For the software we've been building in the last 1.5 years, we've been using Spring + Java heavily in the backend and we've made a bet on Dart for the frontend seeing as Google is already using it internally. The result is we have rock-solid backends with which we can easily handle 100+ requests per second, scaling is easy due to the middleware we've chosen (something which was developed 20 years ago), plenty of developers available who can work on it, if we run into a problem, a quick post on StackOverflow usually gets us an answer within 10 minutes, the number of options to deploy on is big, we have docker support and can run it on just about any kind of server. Dart so far has helped us get frontends out very quickly, we're hoping that Dart will give us the same kind of stability with backwards compatibility we're getting with Java which means we can spend resources on marketing and new features, rather than rewriting stuff every 2 years.
I read nice blog post about this topic a few days ago.
What it basicly said was that there are two types of developers in every company: Conservative programmers which care more about WHAT are problems they need to solve and on the other site Inovators which care more about HOW the problem is solved. And you need both types in your team. The author recommends to use new technology if:
- you know it from some other project
- you want to do something that is not possible with your current technology
- you can find people who understand this new technology and you can't find people who understand the old one
- you will be more productive even if you count in the time for learning it
The article can be found here (but is written in czech): knesl.com/articles/view/co-budujete-v-cem-b..
As for my personal opinion newer and trendy does not always mean better. For example I do not like the new Atom editor (written in Coffeescript/JS) from GitHub. I find it really slow and laggy especially when I compare it to Sublime Text 3 (written in C++, plugins in Python), which I use for daily work.
What I saw in my short time as developer is that often people who are sitting in the positions to choose the technologies don't know anything about these things.
Another reason is that companies often already have a working system and it is a question of money, if they change their whole architecture, so that they have a... working system again. An accountant, who gives the money wouldn't see the reason here.
Or, they simply don't have the capacity and the knowledge. How do you want to change the system if nobody knows how?
I'm in the position to talk to CIOs and CTOs of MNCs quite a bit, and my observation is that they are primarily thinking about risk to the organization. They view risk through a number of lenses: - delivery risk (does this speed up development? does it introduce quality concerns?) - security risk (is this a proven technology? who's looking at it for security? how quickly are issues resolved?) - people risk (do I have enough resources to use this technology at the scale that I will need to use it? will people leave if they are forced to use it / if they cannot use it?) - integration risk (how does this fit into the enterprise's architecture? is it interoperable with what the organization currently uses?)
There are probably 5 or 6 more different types of risk, but those are the ones that are top of mind. So that said, I don't think MNCs are "avoiding" new technologies, I think they are adopting those technologies at a different speeds. Companies like Facebook, Google, etc. have different risk profiles than, say, a manufacturing company in the Fortune 500. I believe it was Gartner (a company that issues reports on technologies and trends in the enterprise IT space) that created an adoption curve that talks about "Pioneers", "Fast Followers", "Slow Followers", and "Laggards". Big MNCs are spread across the spectrum, but generally fall into the last three categories - they wait to see what will emerge as standards and, where they can find resources who know the technologies.
Two caveats to this: One - Many MNCs WILL develop on these technologies, just on smaller projects (everything from internal projects to proofs of concepts, etc) where if the application fails or doesn't work, there's no critical impact to the business. Two - other commenters have talked about "corporate inertia" - if it works, why "fix" it? I think the addendum to that is "If it works, and our business requires it to work, should we take the risk of breaking it?"
- When you say 'big' do you mean 'legacy' companies or big in terms of revenue / employees etc? Is BBC big enough? BBC is using nodejs & Go. Ref how bbc uses nodejs & how bbc uses go.
- It takes enormous effort to port legacy applications to anything newer. Unless there is enough justification, nobody wants to touch what is working and bringing in loads of money.
- Nodejs may be newer, it is not yet been proven it is better. Big companies have to think in long term. Will Nodejs survive for another 10 years? Will it scale for 1k concurrent connections? IT departments in these companies have to evaluate on many params. New & shiny is not one of the criteria. Sturdy & stable probably are.
A lot of good answers already that I think cover things in a lot of depth. I'll just add a personal anecdote from some years ago.
Almost a decade ago, I was working on a web project for a large corporation. The plan was for us to do the initial development, and then hand the site off to them where they would take over maintenance. We had proposed using Rails for the project and naturally they were wary. They asked for pros and cons, a list of other major websites that use it, etc, which we provided. They actually ended up farming the question out to a consulting agency.
The answer that came back was this: They thought it was awesome that we suggested Rails and that we were on top of (then) new technologies, but because it was a new technology they also advised that it would be harder to find developers who could maintain it. "Harder" in the business world translates effectively into "more costly." Even though they could have saved some money up front with a faster initial development time, they felt they would have paid more in the long run. That kind of consideration puts a kind of built-in conservative lag time to large companies; most of them will never ride the newest wave, they will always be at least a couple of years behind. This also minimizes risk if it turns out the new technology was poor in some way, ends up abandoned, etc. (Somewhat ironically the project didn't live for very long after we handed it off to them anyway. I don't want to give too many details about the situation, but I will say that it was a company who was trying to surf the relatively new fad of social networks with a questionable fit.)
The other thing I will add is to say that new technologies are awesome. They're fun for developers and there is a reason they were created; they definitely have some advantage over what came before. However, that doesn't inherently mean they're better in a given circumstance. When I hear "age old technologies like Java" it feels like you are deriding Java, when there's really nothing at all wrong with it. There's a reason it's "age old" and yet still in use. I certainly have no problem with new technology, but neither do I have a problem with old technology. "New for the sake of new" shouldn't be the answer for an MNC.
I am not sure if MNCs avoid the latest tech. They may take a little more time than smaller companies, but eventually, they will adopt new tech, but only for newer projects. Few reasons I can think of:
Larger companies usually have products that they created years, even decades back. Re-writing these is not just an expensive proposition, it also jeopardizes millions of customers who are using these products. Unlike smaller companies, they don't have the luxury of starting fresh with very few customers.
It's not as if the older tech is bad. There's tons of stuff out there written in older tech that continues to work just great. There's really no business reason to change it.
BTW, I don't think it's a case of large companies vs. small companies. It's a case of older products vs. newer products.
My previous company was a small one, just 10 developers. We used Struts 1.3, JSP and YUI (remember this dinosaur?). That's because that was indeed the latest tech when we started, way back in 2008. But we continue to use all that even now. That's because it's a herculean task to convert all this to jQuery / Bootstrap / Node or whatever (more than 2 million lines of code each on the server and the front-end). Plus, it's just not worth it, the product works just fine with the old tech.
We are using php, and nodejs for different projects (a new project uses node.js but we did not decide to use it, we bought a company that developed its application in js, that's the main reason).
Apart from this, I agree with Miloš, customers usually do not care about the tech behind their application, but it's sometimes faster to build something with js than, say, java.
Also, there are a lot of companies that are quite big that use node.js (Netflix for example) so no, not all big companies avoid Node.