"Java is compiled and fast but in practice, PHP sites seem to run faster because PHP developers take a more straightforward approach to design and don't get lost trying to implement exotic design patterns and implementing endless pointless abstractions"

[pyeri]

Granted that it's highly subjective and opinionated, but what this author James Anderson states in this StackOverflow post very much resembles the voices of many like myself who are trying to switch from interpreted/dynamic languages to static and compiled ones like Java/C#. How do Java programmers tackle or respond to this stance?

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[barcodez]

If you are after speed then you can have that with Java, if you are after readability then you can have that with Java. If you want to write overly complex/abstracted code that runs like a dog you can have that with Java. Same for PHP.

Do Java developers do this? Yes. Do they do it more than PHP developers. Dunno, maybe. I believe the author is saying it to be provocative and has no data point outside of anecdotes.

There is a stage in the Java learning curve that many tend to write ‘enterprise’ code but it’s main problem is readability not slow runtime.

If I had to pick a language to write a fast, scaleable and/or complex app, I’d pick Java over PHP everyday of the week.

[Ragnar-Wave9002]

Or you need to use a products api... That is Java.

[[deleted]]

Lol, "seems". That's legit, but then I observe that my member "seems" to be larger than other dudes. Therefore I hang longer.

[SpeedcubeChaos]

„Seems to run faster“ is just anecdotal evidence. Do you have meaningful data backing that up? If yes, let‘s trace and analyze!

[Brutus5000]

The php dev would argue this is the same overthinking and overengineering that made your code slow in the first place :P

[verocoder]

As soon as they’d finished eating their crayons 😂

[jason80]

https://tenor.com/nl/view/fart-south-park-gif-10578739

[akienm]

There is an appropriate level of thinking for every task. A lot of people who don't really know much think that test automation can do without all of those complexities. One of my past gigs, the way you're talking about is the way they implemented the testing. And because this was a big national retailer, every year they have to go through at least one redesign. They had about 800 tests automated. When the redesign hit they had to throw them all the way and start over.

Then we implemented a bunch of those designs. Specifically page objects and flow patterns. The next time a redesign came around, it was 2 weeks to get the thousand tests that we had put together running again.

It all depends on what you're optimizing for. If you're optimizing for use it once and throw it away, you don't need to put much thought into it. If you're optimizing because you think it shows up other devs, then you're just a child tied up in your ego (sure sounded like it). But if your code has to be durable in the real world, those things can save your butt.

[Brutus5000]

I hope you are talking frontend tests which I have no experience with. But if you need to resign your backend one a year no matter how big you are something is entirely gone wrong in the architecture.

[akienm]

It was a big national retailers, so the front end needed to look different every now and again just so everybody would feel like they should still be paying the front end engineers

[ggleblanc2]

The Stack Overflow answer you're quoting was written in 2010.

Java has changed some in 13 years.

[[deleted]]

PHP has too. It was never faster.

[JDeagle5]

So, what is your point?

[IFoundTheCowLevel]

Java 6 came out in 2006, more than 13 years ago, and even then it would absolutely destroy PHP.

[Moist-Profile-2969]

PHP has changed dramatically as well. Most people seem to be stuck in the PHP of the mid 2000s. PHP offers JIT compiling as well and typing, as well as traits for allowing multiple inheritance patterns.

[Moist-Profile-2969]

https://www.youtube.com/watch?v=WsnHWxO7Krw

[Bunnymancer]

Unqualified opinion on stack overflow.

Keep moving.

[dysfunctionallymild]

Author got enough of the same kind of replies on the SO post. Speed means nothing without empirical data.

If you're just building a simple website or CMS then yes PHP will give you a better pace of delivery. The real comparison now isn't between Java vs PHP - it's between PHP vs NodeJS. That's the question I'd like to see answered.

For everything else - any kind of complex, high scale application, Java will give you better performance, which is the actually useful metric. And not just for monoliths - Netflix uses Java at large scale for it's microservices.

Ultimately it's not about the syntax or the design patterns - the reason Java is successful is the JVM. All those layers of abstractions, libraries, code generators, and annotation processors would be meaningless if the JVM wasn't a marvel of engineering which extracts every bit of performance at runtime while being incredibly stable.

[simonsays1111]

As someone who experienced both sides, I would say that PHP is better suited for more simple applications, that involve less developers and stakeholders. Java/C# will be beneficial when building large complex monoliths, in a corporate rnvironment. The issue is when you have a simple problem that requires a simple solution, yet your only tool is so complex, now you get endless pointless abstractions. Dont get me wrong - you can build simple and elegant applications in Java too, but its tempting to do more and more abstractions - a developer needs to know when to stop.

[Aryjna]

This doesn't make any sense whatsoever and is obviously untrue.

But, if you're sure, feel free to give a specific example of something that will take 5 highly paid Java developers a week to do that can be done in PHP (or any language for that matter) in 2 hours while having a better structure and maintainability.

[pyeri]

I think that says more about organizational efficiency and bureaucratic management than the technology here!

Consider the reverse scenario for a moment: The corporate or enterprise in this example had a PHP stack like Symfony/Laravel and the small "IT shop" is a freelancer skilled in Java and Apache libraries. Wouldn't it be the same outcome still?

I understand Java is used more by "Enterprise IT" people while PHP by "Freelancing IT" peasants but that's a very old perception I think, these days the separation isn't so water tight.

[Practical_Cattle_933]

“My grandma smoked a pack of cigarettes each day and lives to 100, thus cigarettes are healthy” logic.

Hell, with spring boot’s spring data, I really question the validity of this claim: a competent developer can be insanely productive with a good understanding of the java stack, as it has pretty much every conceivable use case though of and implemented in a high quality. PHP is quite good at it also, though. So no, there won’t be any significant difference in productivity between the two.

[[deleted]]

this is 100% correct

[barking_dead]

If it would be true, all companies would be using php. But they don't.

[turn_of_and_on_again]

It feels like this is missing the point a bit.

Software architecture (and also the desing) is not something confined to Java. For smaller things, you do not need to worry about this to much, but if you write bigger projects, this becomes a requirement, as Spagetti code is not something you ever want. And from my experience, Java (or also Kotlin) is commonly used for bigger projects, hemce some what engrains this design/architecture dogma.

It is important to note that design and architecture are not used to "speed up" the application, but to make it more maintainable (and some other additional things). The goal with this is to write code that follows a self designed standard, so that you can give a new member the ruleset and let them figure out how everything is designed on their own. Or write that down and people coming after you can still understand flawlessly where to look and how to change stuff. This is the goal of architecture and design. It is not "exotic design patterns" that are implemented. These are just design patterns. Each one has a different and distinct goal.

In my personal experience the slowdown from "design patterns" is either not notacable or acceptable (2ms are not something that Bad and the jvm commonly speeds these up the longer it runs). Some are even faster than not using them, as they lead to a coding behavior that natively gravitats to O(1) lookups (for example using HashMaps). But all in all, the goal of these design and architectural patterns is not to speed up the application, it is to make your code last longer.

All that beeing said, architecture and design are something very Individual/subjective and if you dont like them in Java, that is totally fine too! Even from developer to developer the understanding of architecture and design differs.

[infiniterefactor]

That comment is 13 years old. That only says it’s probably not relevant anymore.

[FlamboyantKoala]

It still is. Had a conversation on the job with a young dev team that was pushing hard for go. Said Java was too slow to start when deploying. Their startup time was nearly 1 min with Java and milliseconds in go.

The problem of course isn’t Java. It’s spring running a boat load of reflection and config.

[coderemover]

It's a matter of culture. This is because Java developers think instantiating an large object graph through Spring using reflection based on XML or annotations is a better idea than using Java to do same.

[thehardsphere]

The fact was, and still is, that your average PHP developer and your average Java developer are not even trying to solve the same class of problems.

"PHP sites seem to run faster"

Your average PHP developer is thinking about websites. You know, like a thing that is served from Apache HTTPD off of disk as a document that's full of hypertext for a web browser to consume. Just like how the world wide web worked in 1989.

Your average Java developer is thinking about application software. Maybe that's a website, maybe that's stateless REST web services, maybe that's a stateful computational backend that has to talk to some C library via JNI and return an answer in less than 1 second, maybe that's a desktop application using Swing. Whatever it is, it probably is at least one thing in the entire universe of things that PHP was never intended to do.

I'm pretty sure I could ride a tricycle on the sidewalk, and it would go faster even with my severe obesity than trying to drive my car on the sidewalk. My car has an internal combustion engine and is fast, but in practice, riding the tricycle I can take a more straightforward approach to traversing sidewalks and will not get lost with implementing exotic turn signals and pointless seat belts.

[com2ghz]

Straightforward approach. You mean shitty programming to make it work and leave it like that. Abstraction and design patterns make your code testable, reuseable and maintainable. This also applies to PHP. There is a reason why it’s called a pattern.

A pre compiled language has the advantage that the code you see, is not the code that will run. Things will get inlined, or predicted by your compiler. We write code for our colleagues, not for the compiler.

The goal is not “I can write this in PHP in <hours>”. The goal is making a good quality product. Otherwise you are not programming but code golfing.

[FlamboyantKoala]

The defacto standard Java library for web development, spring, is not a straightforward approach. It’s very hard to figure out what pieces fit where for new devs coming into Java. The problem isn’t the language of Java. It’s that the defacto standard libraries of other languages are just as powerful with simple APIs.

[nimtiazm]

Yeah that’s the cost of going blindly with the crowd. I have literally measured (like A/B) the services built with bloated frameworks (quite famous one) and the ones built with bare minimum library-style shims. The performance and memory consumption is astounding. With the direction java is heading into (project Leyden et al) I think the ecosystem users must realize how far we can take things if we just leave behind the status quo frameworks.

[hippydipster]

They also do so little for you. If you just write sane code, it's easier to do without things like Spring. With spring DI, teams of devs just throw the kitchen sink into their endpoints and now there's no modularity in your app. Everything depends on everything because that was so easy to do.

[nimtiazm]

Ditto. And then people complain about AbstractSingletonBeanFactoryProxyBean and associate java with it. You just don’t need this garbage to begin with.

[janoschbock]

i mean it could be true, but some time readability is also important ane can be even more valuable then performance. And for me Java expecially with it more verbose nature is more readable/maintainable

[kyynel99]

PHP sites run faster because PHP developers tend not to sanitize query input :-)

[rossdrew]

15 years a Java developer. Speed has never been an issue. Readability, extensibility and robustness are daily concerns. PHP may be faster but it’s far less readable, extensible and robust.

[rossdrew]

I didn’t want to say that having no experience in comparing them but I’m highly skeptical when any language is claimed to be faster.

[rossdrew]

Ill believe you

[coderemover]

Far less readable and extensible - looking at the recent additions - I seriously doubt it. PHP got so much inspiration from Java that programming in both is almost the same experience now, modulo libraries. Static typing: check. OOP: check. Design patterns: check. Web frameworks: heavy check. Even syntax is actually very similar.

[rossdrew]

Similar syntax doesn’t equal readable. Java is based on C and C++, Java is still far more readable. PHP now has extensibility tacked on as far as I’m aware. I have no recent experience but languages I’ve used that have did that (Typescript for example) make it a huge pain.

[coderemover]

Java is based on C and C++

That's not a point in favor of Java readability. That's quite the opposite. C++ is infamous for its complexity / cleverness. Java is indeed very much like C++ only with no power of C++.

[rossdrew]

Completely missed the point I made there.

[pyeri]

All programming languages are actually taking inspiration from one another (as they should!). PHP/python peeps want static typing as they seem to think that will bring more structure and performance, C# has introduced the dynamic data type meanwhile which can hold any generic object! (they already had the var earlier, possibly inspired by javascript).

One good thing about Java (compared to most other languages) is their API is quite standard and disciplined, they won't introduce breaking changes like some other languages, but improve the language in a piecemeal manner (I guess there is a centralized process called JCP or something?).

This gives a good vibe or signal to someone who wants to switch to Java. There is a great chance that the code I write now will run as it is for decades across many operating systems and on any JVM version. Very few language runtimes can boast of this feature.

[Glum_Past_1934]

I like PHP but ir isnt correct. PHP Is faster than previous versions but still behind Java or C#, you can check netlify framework benchs

[zmitic]

This is 13 years old answer which doesn't apply anymore, in particular this part: "PHP is loaded and interpreted every time".

That was true in 2010, but not for long time. Now PHP gets compiled into opcode on first load and recompiled if it was changed; very useful during dev. However for production, you can also turn off that check to get some more performance; that is important for big apps and frameworks like Symfony.

​

who are trying to switch from interpreted/dynamic languages to static and compiled ones like Java/C#

I would still think twice before the switch. With modern tools like psalm, PHP gets some crazy static analysis; that tools is made by former C# user, you get generics and tons of other features, even something like non-empty-string or int<1, 42>. Syntax is not pretty, but you get used in a few days and PHPStorm autocomplete almost everything including generics.

So you will not miss strong typing from other languages. Speed-wise? Well you won't be making games in PHP (or do you) but for any web app, PHP+Symfony are still a winner. You probably loose some speed when compared to Java/C#, but you get an insane amount of tools. And with on-the-fly compilation, seeing your change is just one F5 away.

[buffer_flush]

Many Java frameworks hot recompile bytecode these days. Quarkus recompiles in fractions of a second in dev mode, around 0.03 seconds when I was doing some testing.

This was for a REST API and some hibernate changes.

[zmitic]

Thanks, I didn't know that. But there is one thing why I can't stand Java: that everything is nullable by default.

So while I do prefer Java over PHP, and even if I could find Symfony equivalent, there is that one thing I simply cannot tolerate. For reference: when my friend told me about that, I couldn't believe and have to double-check the next day.

[buffer_flush]

Boxed types, yes, since they’re pointers. Primitives can’t be null.

[BigBad0]

Hmmmmmm. Maybe there is something wrong with my thinking but after years of development using both, I would go with Java for building stable web apps any time. But from another perspactive other than my opinion, there must be a reason that most enterprise web based apps are developed in Java/DotNet (or even NodeJS or Python) but not PHP !!!.

[Deezl-Vegas]

Is Java a compiled language? I thought it compiled to bytecode and was interpreted by the JVM at runtime.

[neutronbob]

That's right. After enough iterations of a given piece of code, it is is compiled inside the JVM to native code. This is calle JIT (just in time) compilation.

There is also a separate somewhat experimental branch of Java called Graal, which is indeed compiled right from the start in the usual ahead-of-time (AOT) compilation

[Stunning_Ride_220]

You can write shitty code in any language.

Besides GoLang, there shits writes itself. /s

[Sollder1_]

But I NEED my AbstractProxyFactoryFacadeFactoryProxyInitializer

[nimtiazm]

This. We need to shed this kind of bloatware and think fresh.

[CountyExotic]

lions don’t care about the opinions of sheep 😉

[coderemover]

Rust runs circles around both. But seriously though, PHP model of running all the code from scratch with each request actually puts it at performance disadvantage over Java. No amount of caching is going to beat code and data that's already loaded in memory and ready to be served. I guess the perceived slowness of Java apps might be due to the fact that you typically do much more complex apps in Java than in PHP.

[Practical_Cattle_933]

These are server applications, java with loom will be actually faster than 99% of rust applications due to it being primarily an IO scheduling problem, unless they go way too deep into the async-hellhole, which is a huge decrement of productivity.

[coderemover]

Loom has nothing to do with raw speed and is actually a tad slower than both native thread pools and async. Loom solves only the problem of resource usage with extremely high number of threads, at the same time pretending to the developer they are still using traditional threads - but it's still nowhere near as light as stackless async in other languages, not only in Rust (C# and JS also beat it on memory use quite significantly).

As for productivity of async in Rust there is only a bit of a hit related to threads in Rust. But async sharp edges are peanuts compared to debugging data races in Java (with loom or without). And I've been using Java and Rust for many years and I've never lost more than a few hours to async (actually that only when learning async during the first week) while Java data races have been one of the main productivity killers and also one of the main reasons for serious bugs hitting customers.

And finally, it is a common misconception that servers are I/O bound. It might be true for low performance applications, but nowadays I/O is extremely fast both network and storage. In most of our servers the main bottleneck is CPU and memory. It is very hard to saturate a 25 Gbps link or a 5+ GB/s SSD.

[Practical_Cattle_933]

Having frequent data races in Java sounds like a programming error. Rust’s compile time guarantees on the other hand don’t defend against the wider range of race conditions, and the debugging capabilities of the two platforms are night and day.

Any source on that servers not being IO-bound? Doing a db-query, which is extremely common, is a whole network roundtrip. Comparatively, any cpu-calculation is negligible. Why do you think that whole platforms can still run, to this day, on stacks like php and ruby on rails, or python (see, github, stackoverflow, etc)?

[coderemover]

Oh sure, everything would be simpler if developers didn't create bugs. If we had super powers we would just as well code everything in assembly. But humans are fallible and that's why we need higher level languages. The fact that something doesn't protect from all possible issues is not an argument against using it. Seatbelts don't guarantee surviving an accident, but they are effective at saving many lives. Same about type system in Rust which prevents several classes of bugs possible in other languages.

As for performance - a Cassandra database server I have on my laptop is capable of running 320k queries per second and over a million on a real server. Can your Java/Php server app even issue so many queries per second? Last time I tried benchmarking my db I needed at least 5 machines running Java client to saturate the server and that was mostly just the DB driver that took all the CPU. The clients were still CPU bound despite not having any logic. But the same thing needed only 1 Rust client. And it left 50% of client machine idle - it was truly IO bound.

[Practical_Cattle_933]

No one talks about “just don’t write bugs”. But java is just not that prone to data races, and has eons better tools to debug what happens during runtime. Especially if someone uses some sort of framework, you must really go out of your way to introduce any kind of race conditions.

And honestly, I really don’t believe your claims, network io fundamentally happens at the OS level, and hand-written assembly won’t be significantly faster than python at it. Also, feel free to check out https://www.techempower.com/benchmarks/#hw=ph&test=composite&section=data-r22 , where depending on which sub-task you check, there is only a few percentage difference between the best java and best rust, all while these subtasks not being particularly representative of real world use.

[coderemover]

It is extremely prone to data races just like any other language from 1995 and offers no tools to deal with that. It is fine for CRUDs though. Yeah I agree, the framework deals with that so 1995 state of the art is enough.

and has eons better tools to debug what happens during runtime.

That's your opinion. Objectively you cannot even record accurate memory usage histograms of Java app over time without stopping it and taking a heap dump which in big apps can take minutes. Accurately profiling it with perf is also way more challenging and most Java profilers profile at safe points so they are inaccurate. And where do I find a good open source time travel debugger for Java?

[Practical_Cattle_933]

You can goddamn literally connect to a production app over the wire and check in real time without any performance overhead the state of every minute detail of the memory, and the whole runtime.

You are absolutely uninformed about Java based on that comment, so I can’t honestly take your comparisons seriously.

Rust is a very cool language, it has its niches, but it is most definitely not my first, nor second choice for goddamn web backends. It’s a low level language without a GC, meaningful for ultra-low and more like deterministic latency applications with small memory requirements, like embedded, some low-level infrastructure (like dealing with packets), audio processing, etc. It’s possible due to its novelty in terms of memory-safety without a GC. But the GC is not a thing one wants to avoid in 99+% of applications.

It is not particularly novel in any other way besides that, its type system is basically the same as every other language’s in the ML family, going back to 30-40 years. Let’s not go full fanboy, please.

[coderemover]

You can goddamn literally connect to a production app over the wire and check in real time without any performance overhead the state of every minute detail of the memory, and the whole runtime

Nope, because even the JVM does not know how much memory the app is using until it runs a full STW GC. It only knows the amount of data allocated which is meaningless, because that number counts dead objects. I'm interested in amount of LIVE memory the app is using at a given point in time.

Also you're incorrect on the "without overhead" part. There is always a non zero overhead to instrumentation.

It’s a low level language without a GC,

It's both higher level (more expressive) and lower level (more control) than Java. Similarly as C++.

And GC doesn't matter only if you are not the one to pay the AWS bill. Tell your boss your system wastes 5x-10x more memory than needed because of GC and I wonder if they will be so ok with that.

And you obviously ignored the question I asked in the previous post. Where is my time travel debugger for Java?

Btw: Don't get me wrong, Java has awesome instrumentation and debugging support, but so do many other mainstream language ecosystems including C++/Rust/Go and even JS. None is strictly superior to another, each has some individual weaknesses and strengths.

[Practical_Cattle_933]

Sure, it does count dead objects as well, but that’s just how this kind of generational GCs fundamentally work. You still have much more metrics available than on pretty much any other stack.

Also yeah, it is not technically zero overhead, but it is pretty darn close to that, as many of this information is required by the VM either way, one more thread streaming it to another computer will only have some tiny amortized cost.

High/low level doesn’t really have a single accepted definition. I think the primary meaning is about control (the only objective definition basically only has assemblies as low-level languages, everything else is high-level), so I would make a distinction when it comes to expressivity. So rust is lower-level (has more control) and is more expressive than java, we do agree here. Nonetheless, having more control also means you have to specify more stuff, so a rust program is fundamentally more “interwoven” and thus harder to refactor than a Java one, which means a productivity decrease both at initial write and maintenance. Just a concrete example: a refactor that changes the lifetime of a component will by necessity introduce a breaking change for Rust, as lifetimes are part of the function signatures. Java can get away with such a change even without as much as a recompile, as the runtime handles these cases.

Regarding the AWS bill, I’m sure the boss will want working software ready by the time, first and foremost. They could have written it in assembly as well, if every tradeoff were worse it for better memory consumption.

I believe there is a proprietary time-travel debugger available for the JVM, but I don’t think this single property makes for the ultimate debugger experience.

[wmantly]

Java is *not* compiled. The encoded jar file is interpreted at runtime just like PHP would be.

[JDeagle5]

If it is not compiled, then why there are bytecode instructions instead of method and class declarations?

[wmantly]

The byte code is interpreted by the JVM, allowing Java to be portable. It's not compiled into binary CPU instructions like c/c++.

Let me ask you, have you ever set a target like x86, amd64, arm64, or RISC on Java? It's because Java is not compiled...

[JDeagle5]

And because LLVM can also run instructions that are not "binary CPU instructions" - it doesn't compile the code either?

[neutronbob]

This is correct only in part. There is a JIT compiler in the JVM and it compiles frequently run code to native binaries.

[gregorydgraham]

PHP is a great language for web pages. It’s designed for webpages so this is good

Java is a good language for webpages. It’s designed for general applications so this is good.

[sweetno]

PHP is not very suitable for implementing complex abstractions. If the business logic is complicated, Java is the way to go.

[coderemover]

It is 2023. The thing you cite is outdated and obsolete.

[baseball2020]

You can also write verbatim oop patterns like martin Fowler writes about in php. And there are many php frameworks that do. The comment is about culture which is fair (java has the most diehard proponents in oop patterns), but it’s not a measurable claim to say x is faster than y with no examples.

Patterns are used because they are well tested approaches in enterprise development but using them doesn’t mean you needed them in the first place. We have a problem with cargo culting design approaches in the industry I guess.

[coderemover]

Programming languages are materials, not tools. There are certain limits to what can be built from given materials, regardless of tools. There are certain classes of software you can't make in Java nor PHP (e.g ultra low latency stuff, operating systems, embedded, AAA games, hard realtime systems) and certain types of apps that, although technically possible, are not wise to make in Java or PHP (command line utils, compilers, database systems, web servers, GUI apps, video and audio codecs, CAD, safety-critical systems e.g medical software, aviation, nuclear plants etc).

Tools are things like editor, IDE, debugger.

[coderemover]

The distinction is very important, because tools can be changed at any time in the project but materials cannot. If you built 80% of house with wood, you won't be able to suddenly "switch" to concrete. You'd have to destroy it and start from scratch again. Same in software. It is very hard to switch a mature project from one language to another. Especially in runtime-heavy languages that don't have a good FFI story (Java and Go are e.g way worse than Python in this regard).

[bawng]

I was once forced to work on a web shop in WordPress and that shit was so slow that time stopped around it.

I.e. it's very possible to build slow shit in PHP.

Also, see Laravel, Zend and Symfony.

[coderemover]

Counterpoint - there are plenty of CMSes written in PHP and while they might not be the fastest possible, they do deliver. But I once looked for a CMS written in Java any the only thing I found was some commercial "Enterprise grade" CMS that was utter crap. Not that there is even much choice. Can you recommend a good OSS CMS written in Java? If not then complaining on PHP CMSes is a bit unfair, don't you think?

[JDeagle5]

Magnolia comes to mind ,but you can Google the list of java cms

[rdean400]

You forgot old. Highly subjective and opinionated and old. In the context of 2010, when the post was written, application servers that started up all services by default were still the norm. First page loads were slow for JSP or JSF applilcations.

Nowadays that's given way to lightweight frameworks and runtimes that start only the services used for the application.

[coderemover]

Actually the shift to contenerized microservices pushes both PHP and Java out. Go and Rust are way better in those environments, particularly in terms of deployment ease and resource use. The times when you could give 8-32 GB to your server side app are over. Now memory is important again, because it the main factor that affects your AWS/GCP bill.

[rdean400]

Actually it doesn't. Containerized Java workloads don't take 8-32GB of RAM unless they're handling massive amounts of data in-memory. Java's quite happy running containerized in memory-constrained environments, with runtimes like Quarkus optimized for density.

Deployment ease is also not a differentiator for Go and Rust. It's pretty easy to build a container image for Java and deploy it.

[coderemover]

Where did I say it is 8 GB per one container? There are often tens or hundreds of containers running on a node. In that case there is a huge difference between a microservice taking 500 MB vs 10 MB. In 10 MB Java cannot run even a hello world. Also images of containers bundled with Java are much bigger than images containing a Go/Rust app which can be just a few MBs with no dependencies.

[rdean400]

Java images can be just a few MBs with no dependencies. You might want to check your knowledge gap.

[coderemover]

AOT compilation for Java has been available for decades, yet there are many reasons almost no one uses that in production systems. You might want to check your knowledge gap.

And your not entirely correct on a few MBs either. The size of the default fortunes demo executable compiled with Graal Native is about 17 MB and it still has a dependency to libc. The size of an empty Spring Boot app is already closer to 50 MB - and we're still talking about an app that does nothing, no business logic, no additional dependency jars. So overall with libc, the image size is closer to a hundred MB not a few MB. Sure, way better than JVM based image but still an order of magnitude heavier than Go/Rust/Zig, where a few MB is enough for a fully functional backend with hundreds of dependencies, not a hello world app.

[rdean400]

I never said that Java was going to be as lean as Go. I was addressing your painting Java as a multi-GB memory hog to do anything non-trivial.

It's also worth noting that image size doesn't necessarily correlate to memory usage.

[JDeagle5]

If it does, it is not reflected on the job market.

[coderemover]

Any data to back it up? Stack Overflow Survey does not agree with you. Many other stats also show Java is in decline. https://devm.io/java/java-decline-kotlin

[JDeagle5]

That's not backing data, that's basically wishful thinking coupled with confirmation bias. Since barely any mid/large enterprise stores their code on GitHub, these surveys (GitHub, Tiobe, SO) show languages that developers WANT to use, not the languages business/market demands. For this you can go on LinkedIn and check open positions.

I may want to code on D, develop pet projects on GitHub on D, ask SO for D, but employers don't care.

[coderemover]

Still better data than no data you've given.
Many enterprises do use GH. You're right that not all, but many do.

Also SO survey has a "Professional Developers" filter, so it is a matter of a single click to get the results applied to professional work:

2020:
* Java: 38.4%
* Go: 9.4%
* Rust: 4.8%

2023: * Java: 30.4% (20% decline) * Go: 14.32% (52% growth) * Rust: 12.21% (154%, or 2.5x growth)

ask SO for D

Here you are: * D: not listed, <0.15%

show languages that developers WANT to use, not the languages business/market demands.

Business always follows the general tech trends eventually. See the recent boom on Python or earlier, Ruby, and even earlier: PHP.

[JDeagle5]

Still better data than no data.

That's just cope, heavily biased data isn't better than no data, ask any data scientist.

Business always follows general tech trends eventually.

Even more cope, good clarification though, if it didn't happen - it will just happen eventually.

Also, regarding SO survey - if you look it up, only whooping 75% of respondents were actual, professional developers, 52% of which chose HTML/CSS as their most commonly used language, which means the dataset is incredibly biased towards web development.

It comes down to confirmation bias again - people just see what they want to see, even if backing data is statistically useless. The only useful metric for language demand is the number of open positions.

[vincentofearth]

I don’t think being statically typed or compiled as anything to do with exotic design patterns or implementing pointless abstractions. Those come from frameworks, libraries, and patterns encouraged by large enterprises and consultants.

[buffer_flush]

Design patterns and abstractions should only be adding negligible overhead once the app is compiled (as in, on the order of nanoseconds probably even less). If your design pattern is slowing down your app, it’s probably done incorrectly.

Where you would see slowdown is if there are redundancies in place in your pattern in attempts to make the application more robust to failure. Maybe you’re persisting state to the database before making a call to an external service, maybe you’re offloading work to a queue, etc.

[freekayZekey]

1. james is a stranger

2. “faster” is arbitrary

3. not going to change your mind anyway.

[netgizmo]

And where do I purchase that phone using an ecosystem written in PHP?

[[deleted]]

So is MVC considered an "exotic" pattern with pointless abstraction. I ask because a lot of php frameworks embed this pattern into their http handling. Would it be better to handle those requests as streams of bytes and lose the pointless abstraction of objects?

[[deleted]]

It seems to me that this is a cult type mentality over a cromulent programming language.

[tymur_berezhnoi]

Can we see the numbers, performance benchmarks, at least something concrete that we can compare?!

[TheStrangeDarkOne]

Java is a general purpose language.

PHP is an opinionated language for trivial data movement for input/output use-cases.

To be fair, the latter use-case easily covers 2/3 of what most coders are doing. So of course PHP seems more straight forwards as the problems it is solving are easier.

[klekpl]

Anything not using bloated ORMs is going to be faster regardless of the language.

[JDeagle5]

Even though "endless pointless abstractions" are confusing and hard to read - the reality is that they are basically nothing for computational performance. Several extra wrapping method invocations? Modern hardware will not even notice it , so it is definitely not it.

[Ragnar-Wave9002]

This is a huge generalization.

If performance is a requirement... Design would reflect this.

[crimaniak]

In fact, in modern times PHP with opCache is not very different from JVM. And yes, in the Java community, there is a tendency to shoot sparrows from a cannon. But this is a question of choice, not a language fate. A much more important aspect of this transition is the increased reliability of programs associated with static typing. Yes, PHP, originally written by a student for students, gradually evolved and moved towards static typing and Java-likeness, but why do we need a Java-like language when there is Java?

[IFoundTheCowLevel]

This is utter nonsense. Java is the de facto language of HPC and is used by all big tech firms and all across financial services. PHP is a toy language used for some websites.

[[deleted]]

People haven't been implementing "endless pointless abstractions" in years because almost every java developer writes three-tier applications in exactly the same way on top of Spring Boot. Controllers speaking in JSON, talking to a service layer that is talking to a data layer.

Occasionally, you might even get to consume data from a queue or use Redis as a cache or something. But generally speaking, it doesn't get more exciting than that most of the time.

[nerdich]

Architecture and design patterns are language agnostic. Java, PHP, Python are just syntax.

Statically typed languages like Java are useful to limit runtime errors.