Have you compared and contrasted Java and C# (especially with regards to let's say larger frameworks)?
Both of those put a strong emphasis on types, but only one of those (it's Java) is the sort of language that really attracts developers that love types like AbstractWidgetBoundaryFactoryWrapperFactory.
I can definitely understand the "Citizen Kane" effect of looking at a modern Java framework and going "yeah looks just like any other language, except with types and IDE support". Java didn't get there from nowhere. It got there after 20 years of being overly verbose and frustrating to work with.
My only real gripe with the language is JRE versioning and updating and that's the only legitimate complaint I've seen from others. It seems that you can sidestep that issue by baking in the JRE to your executable.
Honestly, I think the only reason C# is winning at all right now is because MS controls Windows and can silently keep .NET infrastructure up to date all the time. There must surely be a parallel universe where Oracle created their own OS where they enjoy the same benefits as MS.
Search for the memo where google employees were saying, "we the developers of google are losing to Youtube, as Youtube engineers use Python and we use Java. And iteration in Java is slower than Python." That's before google purchased youtube.
YouTube was based on Python from the very beginning. And since then has migrated more and more pieces to Golang. PHP was never a major component of their stack, if it was ever used at all.
Search for the memo where Twitter migrated to the JVM. That one actually did happen.
The link from your linked page states that Google were using C++, not Java. Which is correct. I was there. Writing web servers in C++ is a good idea if your web server is 1% HTML rendering/UI and 99% complex algorithms over large binary data structures i.e. a search engine. It's not so great if your web server is 95% UI.
Are you reading these links carefully enough? The first link you posted was talking about Google's use of C++, but you presented it as an argument against Java and in favour of PHP (which YouTube weren't using). This second source also doesn't say Java vs Python was the problem. They say:
"We're constrained on UI/Java development resources", "we have 1.5 engineers working on UI things and that is slowing us down" and "I think if we had one more good Java/UI engineer we'd be kicking butt vs YouTube".
So the problem was a lack of people ("resources") assigned to the UI side, i.e. too much of their headcount is being consumed by the C++ infrastructure leaving very little time for UI-centric work like social features. Google Video's problem is stated here to be too little Java development, not too much.
As someone who was there at the time and who read the internal post-mortem written by the Video team, Google Video vs YouTube wasn't primarily about implementation language. It was pretty much as the emails you cite say:
"They're cranking interesting features a lot faster than we are, but don't likely have a backend that will scale or a plan to make money. We, otoh, have these"
The YouTube guys did the now classic VC play of focusing on growth hacking without any idea of how to pay for it all beyond being acquired. At the time Google bought them the site was close to total collapse; the project to stop it running out of bandwidth was literally called BandAid. The Google Video team was also small but focused more on stable and scalable infrastructure, and product-wise they'd been chasing professional content as they couldn't see any obvious path to monetizing hobbyist produced video. In turn that pushed them away from the Flash plugin towards a more HD video oriented custom plugin, which hurt adoption. These were the wrong calls clearly, but, YouTube didn't really have a plan either. In the end both sides needed each other. One of the first things that was done after the acquisition was start moving core YT functions like video and thumbnail serving off Python and onto the Google C++/Java infrastructure. The web server UI on the other hand remained in Python for a long time so their (social) feature throughput wouldn't be disrupted. I think that codebase did eventually stop scaling and got rewritten, but my memory starts to fail there and I can't quite recall what the state was back when I left.
> Before Google acquired Youtube, the majority of the code was initially written in PHP, but there were many restrictions and clutters in PHP at the time, so after acquiring Youtube by Google, they moved to Python as one of the core parts of its backend programming.
Python started after google's acquisition. It's not that youtube was "never written in PHP".
The more common and recent hate I hear is that so much has been layered on top of it that it's difficult to manage or really understand what's happening in the code. Mentioned in other comments, but things like loads of annotations, Spring abstractions, and so on.
Recently coming from a Python/Flask codebase to a Java/Spring codebase, I would say that the amount of "magic" is not all that different.
It's just that with Spring, I can go to an extremely well-written user manual, or to StackOverflow and get my questions answered. With the Python/Flask codebase, I had to splunk my way through all the layers of random libraries the original developers slapped together, in an attempt to reproduce something resembling out-of-the-box Spring.
I suspect that those original developers had fun making all of those custom choices back in the beginning. I don't know for sure though, since of course they've all left the company since then. The company chose to migrate because it wasn't maintainable once that tribal knowledge left.
That sounds more like a microframework vs a kitchen sink opinionated framework issue though than a language issue. eg Flask is a DIY collection of libraries with your own architecture vs say Rails or Django where you have 95% of those decisions made for you and baked in.
I'm sure there are Flask style frameworks in Java land too. And there was a port of Spring for Python a while back too :)
At some point I realized I was doing more programming via XML files and Spring decorators than via actual Java code. Mostly because Java itself isn't a great abstraction for a CRUD server.
If you did it recently, you should not have needed XML. Even a decade ago, XML-based configuration was on its way out. The transition from Spring to Spring Boot enabled us to use regular code to configure our injectors, for example.
I haven't touched XML for nearly a decade as a full-time Java developer.
I've only ever developed Java at places that had their own infrastructure for everything, so this question may sound uninformed, but isn't Maven still the de-facto package manager used for most Java applications and isn't Maven configured with XML?
Yes it's using XML for all the wrong reasons - as a config and even scripting format (hello ant plugin) when XML is for markup/text. Fscking Maven doesn't even allow basic XML/SGML features such as entities/text macros. And yes Maven's pom.xml is used for package metadata on maven-central and elsewhere even if you don't use Maven directly.
BUT I have to say, every project using gradle as alternative so far has receded into bizarre ad-hoc deployment scripting. Maybe that's just because gradle can do stuff that was hidden away in jenkins build files, but still ...
XML is pretty rare in Java code written this side of 2010. Not that it doesn't exist, but the whole spring mess is not something you really have to touch to set something up in Java.
I usually enjoy Spark[1] for bootstrapping a simple REST-like interface. There are other options, but in general, you don't really need glue-languages at all if you stray away from old-fashioned EE-style frameworks.
Yikes! You can't attack someone like this on HN, regardless of how wrong they are or you feel they are. Obviously it's completely against the site guidelines.
I can only tell you my own lived experience, and that was it.
It is possible there's a better way to do these things my team was unaware of (I was aping an existing server and replacing its RPC handlers with our own, not starting from scratch), but yep. XML and I can't be arsed to remember if they call their @-forms "decorators" or "annotations" because I use too many languages that have some variant of them to keep track.
Point is, I wrote more of both than actual Java, and the annotations make debugging much harder than slapping a tracing debugger on.
ETA I think the peer comments and this one underestimate the stickiness of methodologies in old languages. The fact that there are better ways to do it now is irrelevant... Because there was a previous best practice that is no longer a best practice, that best practice lives forever in the code bases and shared knowledge passed by peer review of existing institutions. Hell, I can go to my bookshelf and pull down two Java tutorials that show how to do an RPC server with Spring and XML... Once it's committed to paper, it lives forever. One can make the assertion that a team should be constantly developing their process, but management is a lot more comfortable with standing up a new server that looks exactly like the old one than with trying a new methodology that is unproven at this company. If for no other reason than so we don't have multiple ways to approach debugging servers depending on what team set it up.
Has those people have any understanding of what is their computer? It is layers upon layers of abstractions, plenty in hardware and even more in software. In fact, the only tool we have to actually solve complex problems is (good) abstractions. So those haters should probably find better arguments.
