A competent Java programmer is not slower than a competent Python programmer. Time to market won't suffer.
There is definitely a higher barrier to entry with Java, and starting new projects involves a bit more setup, but that is never the bottleneck. You start a project once. You work on it every day after that. The time it takes to set up the build system is a drop in the bucket compared to the rest of the work. Maybe it will take your company a few more hours to get to market because of that? Big deal.
> There is definitely a higher barrier to entry with Java
This is what is missing from the conversation. Most of us Java fans have been doing Java for a while. I started in '96. We know the JVM. We grew up with Java and were exposed to various aspects of this platform for over 2+ decades. Java the language is not that hard to pick up, but the platform in its total glory is formidable to those new to the language.
I myself never realized this until a few years ago when in course of quizzing a very vocal anti-Java front-end dev in a startup, he blurted "it intimidates me".
It does seem to me that Java's default tooling is clunky and hard to get running, which is indeed be a big barrier for new devs. The fact that after writing java for ~10 years I'd still need to google how to setup a manifest file for a basic no-frills Java CLI program is silly. I've been tuned out of the last few Java releases, so maybe they fixed that recently though?
It's always sad to see people in the tech industry who are opposed to learning things. Quite a lot of the anti-Java, anti-abstraction, anti-complexity crowd seem to actually just be people who are one step above a sysadmin in their mental model of programming, don't see how large-scale programming is different from imperative scripting, don't understand that complex problems sometimes require complex/systematic solutions, and resist leaving their comfort zone.
There are certainly valid arguments against everything I just said, but quite often they are not the true motivation.
>>Quite a lot of the anti-Java, anti-abstraction, anti-complexity crowd seem to actually just be people who are one step above a sysadmin in their mental model of programming, don't see how large-scale programming is different from imperative scripting, don't understand that complex problems sometimes require complex/systematic solutions, and resist leaving their comfort zone.
May be you are the one refusing to leave the comfort zone. Fairly large chunks of programming ecosystem has moved to Golang, Rust and even other JVM languages like Kotlin for a reason. Most Python programmers today are Java refugees too.
Its just that the overall culture of Java is loaded with programmers who like to use senseless abuse of design patterns as some 'smartness signalling' mechanism. Endless layers and indirections to achieve even simplest of the tasks.
Using something like Golang and Python feels instantly less stressful and liberating when you go from Java to these languages.
How can a programming language stressful or liberating at all? There is no real difference between imperative languages regarding what you can do, and minuscule one regarding how you can do them. I’ve seen hardly maintainable and understandable code in all mentioned programming languages, regardless of used framework.
I have come to form a strong opinion regarding software development people: In general we are more comfortable with operational complexity than conceptual complexity. (A somewhat wider sense of conceptual, to include architecture, structure, etc.)
Some of us, like me and possibly you, are more comfortable with conceptual complexity but abhor operational complexity. This [division] mirrors the society at large, imo, but was masked during the early days a couple+ of decades ago when software geeks were truly geeks. That subset of demographics never was upset by complexity per se, only un-necessary complexity was a cause for getting upset. The general demographics is bothered by complexity, period.
Companion theory partly based on this opinion is that as the community grew by orders of magnitude from say late '80s to '10, it began to more closely resemble the general population. So the degeneration of keep it simple, stupid (KISS) to mean keep it stupid and simple is an economic and social phenomena.
We are workers in a field with an arts and craft mentality on the production side and global industrial demand on the consumer side. The factory worker plugin iPhones together is not asked to think conceptually. The factory worker making software widgets in some IT department however has to come up with an ad-hoc 'assembly-line' with his or her teammates. Of course they are going to poo poo conceptual complexity. What does it bring to the table for them or the production line?
In contrast, learning (or copy/pasting) n chants for m different infra-beasts to get your widget online seems far more reasonable and far more bangs for mental bucks.
I don't want to start a flame war, but I don't think there are "pro-complexity" and "anti-complexity" sides in programming debates, but really different views on where that complexity should be placed. Is a complex language unnecessary and design patterns are enough, or are design patterns symptoms of a language that's not powerful enough? I hope nobody is adding complexity for its own sake, at least.
IntelliJ comes with a step by step GUI to set up Spring Boot for you with all kinds of bells and whistles, with the choice between Gradle or Maven for your build chain (last time I checked, maybe they're moving away from Maven at this point). You follow the steps and get going. You can set up a project as fast as the time it takes to Google the exact name of that npm/pypi package.
Sure, you'll want to check your settings before pushing your first code to prod, but the same is very much true for any other "default" deployment.
The same is very much true for other "boring" platforms as well, such as dotnet these days. Getting started is quick and easy.
Java will have a significantly longer setup process if you decide to throw out all the work that's been done for you and implement your own boutique web server and routing system, but that's not a realistic scenario for most companies.
I imagine most of the Java horror stories people recall come from the days where there were no good Java libraries and everyone was reinventing the wheel. Sometimes there are weird dependencies that stop being maintained and rather than fix the problem, companies opt to stick to ancient versions of Java and the JVM, but that's not really a Java problem either, that's a supply chain issue.
I don't understand what the higher barrier to entry is supposed to be like in practice. If you know the basics of backend development in any language, you can get started. Learning to place annotations on top of endpoints is a five minute tutorial process, not dissimilar from how setting up routes in any other language takes reading a page or two to get right.
The only barrier to entry I can think of is that you probably want the full version of IDEA which costs money, though you can use all of its features for free by sticking to the EAP release if you're tight on money.
> I imagine most of the Java horror stories people recall come from the days where there were no good Java libraries and everyone was reinventing the wheel.
My memory of java is from about 2007 and I had a pretty negative memory of it. I recently joined a company that primarily does java development and it's amazing what 15 years of progress can do. It's night and day. Using IntelliJ instead of eclipse alone is a big jump.
The thing is, as a C#/.NET dev, those tools weren't that great 15 years ago, either. But I'd been keeping up with the progress in that ecosystem, using it day to day, so it's easy to forget.
> A competent Java programmer is not slower than a competent Python programmer. Time to market won't suffer.
A fast horse is not slower than a fast car.
Languages and ecosystems shape how people think. For example, you will find that Java and Python programmers have very different values and principles. Given same options, they will make extremely different choices. Clearly this is going to have at least some effect on time to market.
I found Java to be a land of overengineering, verbosity, and anti-patterns. The infamous "Hammer Factories" [1] post screams Java to me.
In what way? Sure, gradle can build faster, but the amount of compilation time the frontend need that barely does anything is orders of magnitude more than any maven run.
Because nothing in Python is magic. There isn’t a single language feature in Python that somehow magically makes you more productive. All of the Python language features are also present in other languages.
And productivity to me is not how fast I can bang out a solution to a small problem. I can do that in many languages no problem. Productivity to me is being able to effectively maintain very large (million+ lines) code bases. Not having types is a productivity killer in that scenario. And Python being a slow languages (when not calling C libraries) makes it even worse.
But hey if you feel more productive using Python that’s great! More power to you.
People generally do interviews in Python if given the choice. Coding in Python being quicker is well known in the community.
For why Python is more productive:
Dictionaries (maps), sets, (generic) lists, tuples are first class citizens of the language with simple syntax.
Typing is dynamic, which means generics, abstract base classes, interfaces and tons of typical boilerplate code, which you would use in Java, are simply speaking omitted entirely.
Extensive library, which is easy to access by pip.
It would be very weird indeed for a developer not to be more productive in Python than say Java.
It should be fairly obvious why the hundreds of Google engineers were run into the ground by a small team of Python developers.
Nothing you mention is unique to Python. C# (for example) has all of that. And no there is no agreement in “the community”. Just look at the very long dynamic vs. static typing discussions we have all the time on HN.
And if you think that typing a few fewer characters will make you more productive then we clearly don’t agree on what it means to be productive. Programming is not about typing fast :)
And pick any two random developers using the same programming language and you will probably find that they vary dramatically in productivity.
And please don’t worship Google developers like they are made of magic fairy dust. I have worked with people who ended up joining Google and they were OK but not great developers.
There is definitely a higher barrier to entry with Java, and starting new projects involves a bit more setup, but that is never the bottleneck. You start a project once. You work on it every day after that. The time it takes to set up the build system is a drop in the bucket compared to the rest of the work. Maybe it will take your company a few more hours to get to market because of that? Big deal.