Hacker News new | past | comments | ask | show | jobs | submit login
Java Is Underhyped (jackson.sh)
362 points by Jaxkr 66 days ago | hide | past | favorite | 786 comments

For my use cases, Java has all the wrong compromises:

- not high level enough to compete with Python/Ruby/JS/PHP, etc

- not low level enough to compete with Rust/D/Nim/Zig

- not specialized enough to compete with Erlang/R/Go/Julia

- not opinionated enough to compete with Lisp/Haskell

So why use Java ? It's good, it's fast, it's productive, it's well supported, battle tested and documented for decades with a huge pool of devs. And many companies already use it and the tooling is excellent.

But those are not sufficient reasons for me.

Python is older than Java, well supported, battle tested, documented with a huge pool of devs. But it's way better for high level stuff, data mangling, scripting, gluing, and for most web dev stuff.

If I want a distributed system or something with a lot of I/O, Erlang and Go will always be better than Java. Sure, they are less widespread, with all the stuff it implies, but for such a nice need, I will pay the price hapily: my goal is optimization for the use case. Same for stuff that needs to go fast or have a small footprint, I'm not going Java if I can go Rust.

If I want to have fun, Java is out of the loop. Better sharpen my inner weirdness by fighting with some exotic lisp. Why try productive ? I wanna enjoy myself, not run a business.

So Java is not a bad choice. It's an excellent tech. I just don't have a use case for it.

Your premise is that you are able to chose a language based on how appropriate it is for a specific use case. This alone shows you are not the typical user of Java!

Java is typically used in larger or long-lived organizations. It is rare to start new projects from scratch. Most development is maintenance and extension of existing systems. Even if you start a greenfield project, it would be most prudent to chose the same platform and language which is already used in the organization. An alternative language would not only have to be better, it would have to be very significantly better to make up for the overhead and headache in maintaining code in multiple languages - never mind the increased difficulty in hiring and training developers.

Geeks tend to evaluate language based on how appropriate they would be for a greenfield project with no organizational baggage. But this is an extremely rare use case for most business.

HN often has reports about startups rewriting everything from scratch every four months, when a new language or platform becomes fashionable. But this is not the world where most developers live.

> Even if you start a greenfield project, it would be most prudent to chose the same platform and language which is already used in the organization.

Anecdotally, I see a trend of greenfield projects moving from Java to NodeJS. I can't think of too many organizations that have zero web presence, and basically any modern web presence requires the use of JS, so there's almost always some JS expertise built into the organization.

Development is going the other way at my org. Our JS services quickly became "out of date", and nobody wants to put in the massive effort required to bring them up to modern JS language features, build tools, and libraries.

In contrast, our Java upgrades remain painless. Many of our JS services have been merged back into older Java back ends

> there's almost always some JS expertise built into the organization.

That is usually part of the front-end team that don't do the backend SQL work. Tho team that would get assigned the work for a backend greenfield would be versed in Java.

It’s surprisingly rare for things to split like that. At most companies people will be more skilled at front end or back end work, but it’s rarely a clean separation with front end vs back end teams.

That’s an outgrowth of most projects being quite small. Paying a team or 20+ people to work on one thing is freaking expensive to the point where it needs major benefit or huge company to be worth it. On the other hand maintaining lots of little projects that all automated something can easily pay for a single developer at even fairly small companies. Across tends of thousands of small and midsized companies you get a lot of such teams which grow and shrink, split off and merge over time.

> It’s surprisingly rare for things to split like that.

THIS. The product is blended and so must the teams be. Among all the full-stack developers I've worked with, the "frontend" or "backend" designators tended to describe preference or strength, rather than limitation.

Those are pretty strong assertions with no statistics to back them up. It doesn’t reflect the ecosystem I work in.

I think you underestimate the number of huge companies that see major benefit from large teams working large development efforts.

I don’t know where you would even look for that kind of statistics for companies that might use Java. That said, America has:

1,829,875 companies with 5-9 employees 779,922 companies with 10-19 employees 467,634 companies with 20 - 49 employees 170,749 companies with 50 - 99 employees

Of that a few are pure software companies, but it’s far more common to want to automate something. Which often means outsourcing it, but then they simply can’t afford these kinds of large projects.

At the other end only 23,553 companies have 1,000+ employees. Yet even at that scale it’s not guaranteed to have large development teams in house, a single hospital can have 1000+ employees and use mostly 3rd party software with a few generalists to stitch everything together.

Clearly you’re not going to arrive at a good answer starting from first principles. Industry research groups have the numbers, but they’re locked behind paywalls.

Starting from the other end, the Stackoverflow survey has 50% of devs identifying as full-stack. Most surveys have Java as the #2 programming language, where it’s been for the last 20 years. That says nothing about how those devs are organized among teams, but I don’t think it points to such arrangements being “rare”.

Their 2020 survey has: “About 55% of respondents identify as full-stack developers, and about 20% consider themselves mobile developers.”

I always took that kind of a breakdown to mean most website developers where full stack with embedded etc being their own categories. With majority full stack teams including various specialists as needed, which fits my experience over the last 20 years.

However, Android is Java and is frequently used as a front end. As things grow I normally see teams split by system, so I can see mobile being split off as their own team becoming more common even if it’s the still the minority. That said, it’s teams managing the backend teams which would be considering Java vs NodeJS and based on that 55% I think most teams are familiar with JavaScript.

Yes of course, don't fix what's not broken.

It's orthogonal to my point though.

Python projects that start to grow has a tendency to become hard to manage in a way that I have not seen in Java at all.

Java is like you say not the greatest at anything but it is also not the worst at anything. Its great for projects where the you don't know what you should optimize for or don't care.

If java is to boring maybe kotlin is the way to go. I really like kotlin and in my personal experience the only downside is that the IDEs is not as good as the java counterparts yet.

I write software in Java. I can't stand python - too wishy-washy.

But my main complaint about Python is trying to use someone else's software. Then it degenerates into a maze of twisty little passages of trying to install the correct set of dependencies, not knowing where those files are installed (which makes it difficult on a cluster, as you may need to do the install on every node separately). Then you try using pip and it fails because some element of what it is trying to install isn't compatible with your operating system for reason 1. So you try anaconda instead, and that fails in a different way, like it runs a C compiler on some file (!?) which fails because $REASON. I have numerous examples of Python software where I have followed the (detailed, precise) installation instructions, and it doesn't work.

Whereas with Java, you just dump the necessary jars into a directory, include them in the classpath, and it works.

Don't get me started on R.

I came to say say that's not a language problem, that's a packaging problem. But that would be misleading.

The reason packaging is still a problem in Python are linked to the language:

- to get perfs, you need compiled extensions, which java doesn't need. So a Jar can be fast and portable, while in Python it's an "or" proposition. Wheels help, but they still are OS dependent, so you need a build per OS.

- PYZ arrived very late in Python, while WAR were a very early thing in Java. Few people even know you can distribute a whole Python program in a single zip file with dependencies using something like shiv (shiv.readthedocs.io). So few people do it, and it's a shame. We do it for 0bin though: https://github.com/Tygs/0bin/releases. And it doesn't solve the wheel problem, although nuitka does but it a higher prices to pay.

- packaging tooling have been a mess for 2 decades. Setuptools/distutils/setuptools2, easy_install/pip, and setup.cfg/setup.py/pyproject.toml. We failed as a community on this one. It's getting better, but it's a slow process.

- the Python community is at least half composed of amateurs. It's a good thing for the dynamism of the community, but it also means the software are not very polished. Hard packaging + amateurs = packages that are releases when they reach "just good enough" stage, not one inch more. It also means you'll get things like leaking stack traces, config files in src and the likes.

So yeah, compared to Java, Python packaging and distribution sucks.

But compared to rust all packaging and distribution for all languages do, so there is that.

>the Python community is at least half composed of amateurs.

or, even worse, scientists.

And most recently, tons of self styled "Data scientists". This has, IMO, diluted the rabid rhetoric of the 90's/oughties python community which is good, but replaced it with people who don't know and don't care what good code even looks like, so it can be difficult to work among them.

I feel sometimes that they pride in writing shitty, unmaintainable code; that they do it on purpose. One of the ways they enjoy life is to disregard all "best practices". And I'm not talking about some high-level OOP principles, but the basics - like keeping consistent code style, or even writing some tests.

The previous crowd with love for monkeypatching everything and hate for abstraction other than dictionaries wasn't too pleasant, too.

lol I was just sitting here thinking I miss my Python job and not having trouble with IntelliJ detecting changes in dependencies and how frustrating it is to invalidate caches and reindex the whole project multiple times before I can run tests for the dependency change. I regularly miss the testing libraries we used, too -- it was so absurdly clean and easy to build robust mocks in our DJango stack (and I set up that tooling, largely on my own iniatiative, based on my team's feedback, so it's not like I'm just like wishing other people had already done the work). Now I work with a bunch of Java devs who use to work for Amazon and somehow use that as an excuse for not caring about tests, our ci-cd tools, and all these other things I'd gotten use to thinking of as standard in my past life as a Python dev.

Code style! Hah. First day on the job I asked about that and was told nobody cared and everybody had their own preferences.

... I'm very bitter today. I'm working on it.

This sounds more like a people problem than a language problem to me.

I’m in this forks and I have a hard time disagreeing.

Everything is jupyter notebooks, to the point where example documentation is delivered as notebooks and services run notebooks as it’s apparently easier to do that than to get people to write their code properly. “Oh but data exploration” they say, which is fine, but you shouldn’t be doing data exploration in your prod ML pipeline anyway, and you’re writing code, it’s really not that hard to follow some even rudimentary practices.

So... Java is bad, but let's ignore Python's problems.

I'm forced to use Python at work, because data scientists demand it, and I can rant about your "good for data" language for at least 24 hours straight.

Python isn't great at anything specifically, but it's crap in a few specific places. No multithreading? Fine! But then Python core libraries are crap at IPC, when multiprocess is the preferred way of parallel computing!

> So... Java is bad, but let's ignore Python's problems.

I don't know where you read either of your propositions in any of my comment.

And I quote "But it's way better for high level stuff, data mangling, scripting, gluing, and for most web dev stuff."

You've listed things that rely on full stack of libraries and deployment options.(except scripting) As someone who has the pleasure to work with Python - Python is horrible at a lot of these things, in spite of the beauty of the language itself.

> Python isn't great at anything specifically

Python is the best language in the world for small tools under 500 lines to solve glue and data munging problems.

Python is too explicit to be the greatest, but it's popular nontheless.

It certainly doesn't help that the software I'm interested in is written for science, so there is a tendency to make it work just well enough on the author's machine to allow a paper to be published, and then abandon it.

There is a clear training problem in science. But I believe part of it is that the knowledge on how to write good software is stuck in companies. You can't learn it in school either. I keep hearong about companies that have to make their new hires unlearn what they learned in class... So where would scientists learn good practices? (in my experience books arent the answer either)

I don't think it is primarily a problem in training. It is a problem in incentive. For the most part, scientific software is written to fulfil a goal, and usually that goal is in order to publish a paper. Paper publication is what scientists are judged on, not the quality of the software they write. The software only needs to work well enough to get the paper published. Once the paper is published, all incentive to maintain or improve the software disappears, especially if the message of the paper is primarily the results obtained using the software, because then all of the citations will be referring to those results, not the software.

There are two main exceptions to this rule. One is when an actual software engineer ends up working as a scientist and having to write papers (like me). Then, the paper is more likely to be about the software itself, and the citations of the paper are from people who have also used the same software. This creates an incentive to make the software high quality, in order to get those citations. The other exception is when an institute decides that the world needs a decent piece of software to fulfil a vital role, and actually funds its development.

Oh, I should probably mention - I just helped out with a programming course for undergraduate medical science students. Most of the time I was tearing my hair out about the terrible programming practices being taught by the module leader, who admittedly had absolutely no computer science qualifications whatsoever (and in fact didn't know the difference between a forward slash and a backslash).

I think a solution to this is to recognise software quality as a common benefit, and divert funding towards it, allowing real software engineers to have an actual meaningful career in university. Universities are usually all over common benefit stuff, so you would have thought this would be easy enough. The Research Software Engineer programme in the UK is a start.

Is shiv better than pyinstaller? When turned my script into a binary with this, it took 10 seconds extra on every execution just to start running the script (Eg to just print the help message). I found that to be unbearable since this was a command line script that was invoked anew for every execution

They don't serve the same purpose.

Pyinstaller builds bundle the python binary with the project. It works without a Python installed on the system, is not portable and the resulting binary is fat. It also can fail in numerous way and be slow, but end users will find it the easier to use when they work.

Pyz files just contains python code. Shiv produce them by bundling your code and the dependencies, but you still need a Python installed on the system to run that. You pay the cost of zipping only on the first run though, after that, it's unzipped. And their are portable if you use no binary wheel. It's light and easy to get right.

In that sense, they look more like War files in Java.

Pyinstaller, like cx_freeze and nuikta are for end users.

Pyz are for devs.

If you're not already using the --noupx flag for pyinstaller, you can probably cut that startup latency at least in half. With UPX enabled, the executable has to be decompressed every time it is called. The space saving tends to be minimal and not worth it, definitely not for a CLI where startup latency much more directly impacts the user experience.

Java is so much worse on this front.

> with Java, you just dump the necessary jars into a directory, include them in the classpath, and it works.

Ant, maven, or gradle, and then some jars, somewhere? What's the classpath and whats $JAVA_HOME for this project?

Oh and now I have to make it work in the IDE too, click through a billion menus and dialogs, sync the build system, sync the dependencies, configure runtimes and classpaths, try to rebuild for the 10th time, pray.

Nobody has started a project with Ant in the last decade. Of all the Java projects on Github Ant is probably not even 1%.

> Oh and now I have to make it work in the IDE too, click through a billion menus and dialogs,

You click "Project from existing sources" in IntellIJ and it will recognize both Maven and Gradle projects and just work?

Sync the dependencies? configure runtimes and classpaths? What? With Maven and Gradle? Your talking Ant here.

I'm talking about a maven project I have to use sometimes at work. Let me walk you through all the shit I had to do:

  - Install and set the right java version system-wide
  - Copy some config files for the project system-wide (granted, this is not java specific, but still)
  - Click in some IDE menu to enable some build settings
  - Click in some IDE menu to install some "Lombok" plugin
  - Click in some IDE menu to select the right jdk
  - Click in some IDE menu to edit the run configuration:
    - select main class
    - paste program args
    - paste env vars
    - select right “Use classpath of module:” option
  - Click in some IDE menu to fiddle with "Spring Loader path": modules, dependencies, reorder the dependencies (!)
  - Click in some IDE menu to configure getting the actual logs
  - Click maven-sync, rebuild-project multiple times, restart IDE until it suddenly works
The first guy who got it to work had to write a guide with screenshots!

I know you will say, this is all fault of whoever made this crap project, or my fault for not fixing it. However this was my experience, and it has been similar every time in my life that I had to touch some java project (although this last one is the worst).

I've interacted to a ton of Java projects. And with a ton of various other commercial and Open Source projects.

In my experience (sample size of hundreds of projects), Maven projects are <<by far>>, on average, easier to build and manage than most other languages. The repo structure is standardized, the build cycle is standardized, the built packages are always in the same place, etc.

The Java installation is a 1-time think. It's also a quick google away. I see this complaint a lot, I never understand it. It's plain and simple bikeshedding: someone complaining about a 1-time task that takes 5 minutes in total.

The rest of the stuff is IDE specific and I have no idea why you'd have to configure "getting the actual logs"?

Well Java is arguably one of the most IDE-reliant mainstream languages. It's completely unusable and unergonomic without the myriad of constant code generation and fixing as you write.

Treating the IDE like a separate problem is not realistic with java.

With e.g. Rust, I can use vim, vscode, whatever floats your boat.

> no idea why you'd have to configure "getting the actual logs"?

Some genius java logging library, I can only guess.

IMO it's the other way around. Java has some of the best IDE's around so everyone uses them. You can code in notepad and compile with maven but why would you?

With Rust you code in VIM because there's nothing better. Improving Rust IDE's has been one of the teams big focuses for years. Everyone codes in random text editors because there's no amazing IDE.

With rust yoy don't need to constantly generate code. Vim is just perfect, if you have rust-analyze you get inline errors, code completion, jump to definition, autoimport, autoformat...

You don't need to constantly "extract method", move to class, generate all these mountains of classes by rightclick. This says a lot about the language.

But the main point is that with rust it actually just works: there is one way to set global toolchain and per project/dir. You're not required to also click through a million menus and dialogs and copypaste stuff and sync and rebuild and restart to get the editor barely working.

> With rust you don't need to constantly generate code.

In Rust, macros generate code on build. In Java, Annotations Processors do. I don't see a big difference between these approaches, besides Java's mechanism being older and crustier. Rust macros generate tons of code.

> if you have rust-analyze you get inline errors, code completion, jump to definition, autoimport, autoformat...

Last time I checked, Rust analyzer was in alpha/beta. Java has all this and it's battle-tested. Including language server for VScode and other lightweight editors, and several options for build plugins that auto format.

> You don't need to constantly "extract method", move to class, generate all these mountains of classes by rightclick.

Lombok, or one of the popular Builder libraries, gets rid of all this boilerplate. I don't generate anything using IDE. In my experience, most Java user don't. There's many mature libraries for geting around class ceremony.

> there is one way to set global toolchain and per project/dir. You're not required to also click through a million menus and dialogs and copypaste stuff and sync and rebuild and restart to get the editor barely working.

You are right. Rusts build system is simpler and better integrated. But Java has amazing build tools, maybe the best out there. A properly configured maven project will compile, test, and run with one command. And it will import into your IDE with a simple "import project, yes"

I have worked on a ton of Java projects over the years and never had to deal with most of what your describe.

> Well Java is arguably one of the most IDE-reliant mainstream languages. It's completely unusable and unergonomic without the myriad of constant code generation and fixing as you write.

True, but with IntelliJ 99% of what you wrote is auto-configured.

Eclipse needs a bit of hand-holding, but almost everything you described is due to project configuration.

> Some genius java logging library, I can only guess.

That's your problem, you're assuming that Java is dumb and its libraries are dumb. They're not. I'm reasonably sure that <<all>> mainstream Java logging libraries log to console by default.

The previous engineer must have been a marvel of a developer to manage to screw even that up.

What I'd say is: Java, especially older enterprise code, had a ton of over-engineered patterns. These are slowly fading away, except for Spring, and even Spring's simpler these days. Java also tends to have some low quality and a ton of average but unmotivated working devs on Java projects. So yeah, there's that ecosystem problem.

But for example, if you'd start a new project and you approach Java with an open mind, it's one of the most powerful and flexible techs available. And it's much more modern than the stereotypes imply.

> with IntelliJ 99% of what you described is auto-configured

It is not, that's what I'm saying. And I don't understand why, if IntelliJ is the de-facto IDE. I'm sure that a fresh project is a one-click import, but an average project that isn't fresh anymore, always have similar IDE-setup-magic problems. At least in my experience over the years.

I code in Java, Scala and Python using an IDE just because I like to not remember the documentation to the code.

I know plenty of people who don't use a formal IDE. This "I don't use an IDE" is a stupid flex.

Me too, that's why I have vim setup with language-servers. I get inline type info, code completion and so on.

It's not a flex, simply a matter of preference: I find using the mouse too irritating, others prefer it because it's simpler.

But that's not my gripe, my gripe is that setting up IntelliJ, the one defacto standard IDE to actually work is some voodoo ritual of a dozen steps and restarts and so on.

In my experience even Eclipse does a pretty good job of importing Maven projects without needing to tweak things.

Surprisingly, or maybe not, slf4j requires an implementation to be provided at runtime to log anything.

You can write java with vim, without any trouble. It’s just that Java has the very best IDEs available and I would be stupid to not use them.

100% lombok can only be developed on eclipse. They have an open issue to make it compile on intellij...

I don't know if something changed, but for sure 2 years ago I used Lombok with IntelliJ.

I don't mean lombok as a library, which works. I mean developing lombok itself

Ah, sorry, haven't done that. It sucks if it's Eclipse only :-(

However I'd expect Lombok users to outnumber Lombok devs 100k to 1 :-)

Specially since it can only done in Eclipse xd

> The Java installation is a 1-time think. It's also a quick google away. I see this complaint a lot, I never understand it. It's plain and simple bikeshedding: someone complaining about a 1-time task that takes 5 minutes in total.

I frequently find that the particular constellation of build tooling and libraries particular projects have requires a particular version of the jvm and all the environment variables set up correctly. In some other languages there is widely used tooling to manage the install and use of the appropriate platform version for the project.

If you're working with a variety of projects, fiddling with the installed jvm and java_home and friends is not a one time thing.

> I know you will say, this is all fault of whoever made this crap project

It is. There's really no excuse for that. If it's been similar every time then you've worked on crap every time.

Building a java project should be (and is on projects I work on) as easy as installing a jvm and running either maven or gradle to build it. End of story.

"Install some lombok plugin" is only necessary if you want the IDE to understand lombok, IntelliJ will just pop up a box saying "Want this?" and you click "Yes". I don't see what's so onerous about that.

The rest you describe is really down to poor developers.

No offense, but regardless of how right you might be, you come off as a bit of a condescending asshole. Like "Oh, you don't know that there's a more efficient way to do things? There can't possibly be any explanation other than you're literal human garbage and presumably have brain damage!". Come on, get off your high horse.

I'm really not on my high horse here, if you have a team working on a java project that's that hard to build, they're doing it wrong. Doesn't even matter what the language is really.

So "no offense", but shove it.

There's a difference between - "anything can be turned into an non-compiling pile of crap" and "this ecosystem comes as a pile of crap".

> I know you will say, this is all fault of whoever made this crap project, or my fault for not fixing it. However this was my experience, and it has been similar every time in my life that I had to touch some java project

Yeah that’s a crap project. My experience was always that mvn install / ./gradlew run will just work. On all three OSs. And if I happen upon a decade old random jar file, and run java -jar something.jar, it will just work in the great majority of time. I think no other platform has it this smooth.

IDE's can be fiddly, and anyway I don't think it's good to depend on an IDE for building.

The project could have been set up instead with the "Maven wrapper"(1) which provides "mvn.cmd/sh" scripts at the top level of the project to fetch and run the proper Maven. So after cloning the project, all you have to do is set a proper JAVA_HOME if it's not already set, and then do "./mvn clean package" at the top of the project to do a complete build. The IDE's will then set themselves up properly if you import the project as a Maven project, and will sync with changes to the Maven pom.xml whenever it changes (Intellij does at least). That's really hard to beat.

(1) https://github.com/takari/maven-wrapper (Being integrated into Maven itself soon).

I can (and often do) build from CLI, that is much smoother. I tried using vim on java, but honestly you need an IDE for all the constant code generation and incessant fixups by mouseclicks that are needed. Vim+coc is more than enough in the other languages that I use.

You're living in a parallel universe from the rest of us. IDE isn't necessary (and positively odd) for building Java.

He is. VsCode (or any editor) + the Eclipse Language Server is more than enough. His complaints about debugging is because he doesn't know about attach debugging.

You do need to be able to build from IDE when you set breakpoints to debug.

Your IDE should be able to connect to any JVM that has been launched with the proper VM arguments.

We occasionally do remote debugging at work. It’s just a matter of copy/pasting the correct JVM incantation into the IDE.

I feel the parent comment was about editing, not building.

I can find maybe only one or two things from this list related to Java, both not reflecting current state of affairs. You do not make the need to have a run configuration a language or platform fault, do you?

If you're using IntelliJ from JetBrains, there should be an option to store the run profiles for the project in the version control system.

Even if your project is so messy, then you should be able to just to version a working setup (maybe needing to figure out how to make the correct JDK version be used across different machines) and after that it'd become a question of just having to check out the project from the version control system and click a green button in IntelliJ.

This most likely wouldn't solve all of your issues, but at least would help make onboarding slightly less painful and slow.

Isn't this rather overblown ? The first 5 steps appear to be a ONE-time framework and system setup for your IDE - and this assumes you have multiple JDK's. You certainly don't need to repeat this for every project.

The run configuration can be automatically created by Intellij by attempting to execute a runnable class. You only need to set program args and env vars if needed - and that would be true for ANY language or program.

The spring loader path appears to be specific for this project.

The run logs are independent of Java. Thats just getting program logs.

There is no need to maven-sync and rebuild-project multiple times, unless you are explicitly refactoring the project module/build structure. Once you have imported a maven project, you can simply click build.

You left out Gradle installed/downloaded options, Gradle version, Gradle JVM version, Gradle plugin auto-upgrades and the unholy mess this lot can create.

This is why we virtually all use the ./gradlew script that manage all of that by itself on every platform... No global installation of gradle should ever be done.

You say this as if python could do any better

I think you work at the same company as me!

This is one of the main reasons why I won't work with Java. Everything is much more complex and unnecessarily arcane compared to other languages.

Guess I'm nobody. I created a simple Swing (desktop) app in Java a couple of weeks ago. The process was something like:

Create new Java project in IDE Add no dependencies Use the built in IDE tooling to create a runnable JAR and tick the box to export the Ant build to a build.xml file.

Why would I want to complicate things by adding Maven/Gradle to the mix?

I will give you the secret trick of senior developers: don't be the one who manages the build process, otherwise leave the project asap.

And I will also give you the secret trick of superninja senior developpers: be the one who manages the build process, so you will never EVER be fired.

The complexity of maven is well understood and battle tested. The complexity of a custom build is not. In my opinion it is of a far more concerning sort of complexity.

It's an Ant build file - nothing complex at all. If you no or few dependencies and are comfortable managing them manually, Ant is fine.

Non-networked applications don't tend to need to be so paranoid about keeping up to date with the latest versions of dependencies.

We're probably optimizing for different things. I'm normally optimizing for easy onboarding of someone new. If this is a personal project with few dependencies then ant is probably good enough.

And what if you want/need to add dependencies? A lot of them.

Sure _then_ you might opt to use Maven or Gradle.

My point is there are a wide variety of application types out there, not everything is a web application, not everything needs to use a complex build and dependency management system.

Yeah, but if you do know Maven, it scales down to small projects. The configuration for a simple project is trivial.

So just use Maven and save anyone coming after you a bunch of trouble when they have to extend your project ;-)

This method is useless for most projects, so yes, you are nobody.

I only had to go a few comments to see someone (the person you're responding to) think Java is the same as it was 15 years ago.

I have done 10+ years of Java development and 1 year of Python. And I disagree, Java packaging is better. You can package all your dependencies in a fat jar like Spring boot does and you only need to run it with java -jar lib.jar and you are good to go.

Dependency management is a mess in the Python world and my number 1 complaint. You have pip, pipenv, poetry, anaconda, to manage your 3rd parties. And if you want to avoid conflicts and have consistent runtime you need to create a virtual environment to install these libraries and redownload everything.

Otherwise libraries are installed user or system wide, in a directory that depends on the Python version that you use but they are not versioned there.

With Maven you don´t have the issue. Your 3rd parties are downloaded in a global cache directory (the Maven repo) and are all versioned. For the delivery you can either provide them all and have the runner set the CLASSPATH or have them packaged into a single jar.

Great, but you will actually want to write some code, so you have to do this insane IDE setup clickfest.

I am not saying Python's packaging is any good, it sucks. But you can't realistically ignore Java's IDE shitshow.

It’s pretty much an import project and done. If not, then someone really fcked up that build file.

But this happened to me every time I had to use any java project over the years. Maybe I'm just unlucky.

Please try OSS java projects and educate your build guy. Java the language may have lots of complaints but from the build/packaging point of view its actually one of the best languages out there. And very, very consistent.

Huh, as a consultant having touched many java code bases, they are all basically the same. Import the maven pom into intellij and run the main class. The folder structure, the code conventions etc are basically the same at every client and every project I've ever seen in java.

All needed is having the correct version of Java, and maybe give maven a password so it can access private libraries. It's dead simple.

And more importantly: it's the same everywhere.

Yeah, people under-estimate badly how useful the Maven conventions are, because they've never seen them in the C/Python/whatever world.

I haven't used Maven in a bunch of years.

But source code goes in src/main/java. Test code goes in src/test/java, resources (images, files, whatever) go in src/main/resources, test resources go in src/test/resources. There is a pom.xml file that contains dependencies, and if it doesn't, it points to a parent which <<does>> contain them.

There might be submodules and they all are folders containing another pom.xml. That pom.xml generally points to the main pom.xml.

Etc. There's a bit of tedium in there, but <<it's always the same>>!

The level of consistency is something most ecosystems dream about.

And you know what? That means that you can use your spare brain cells for actual creativity or hard work.

Well, this could be true for some legacy projects with old tooling, but this is not how things work today. You install the IDE, checkout the code from Git and let IDE get a proper version of JDK for you and fetch dependencies from Maven central to local repo. You really should not copy jars anywhere or set environment variables.

> Oh and now I have to make it work in the IDE too, click through a billion menus and dialogs, sync the build system, sync the dependencies, configure runtimes and classpaths, try to rebuild for the 10th time, pray.

That is not my experience at all. I dont have to rebuild work project many times. Creating new scratch project for playing in is easy and fast. Dependencies are managed by maven and I rarely have to deal with that beyond added dependency tag.

I have no clue what you're talking about.

Maven can build a nice fat executable jar, with just one XML block added to the pom.

I've opened a 5year unmaintained project with IntelliJ yesterday - click package and got a working executable.

I opened another project built with SBT... and guess what? No errors!

Let's try that with a Python project (LOL!)

> I can't stand python - too wishy-washy.

That's an interesting take; my experience has been (at least the community) is quite proudly dogmatic on the One Right Way To Do It, for all values of "It".

I also don't like Python, but I think for different reasons and perhaps a bit less than you.

Never used R, but I understand it to be quite fiddly.

> my experience has been (at least the community) is quite proudly dogmatic on the One Right Way To Do It, for all values of "It".

This hasn't been true lately. Python is growing ever more complex.

I hear you and agree to an extent; my suspicion is the influx of non-CS self-styled "data scientists" using Python for all the ML hype has diluted the historical rabidness.

But, for people still working in "computer science-y" domains, I haven't seen the historical dogmatism lessen; in many cases people are digging in.

R is an analysis tool. You don't write software in R.

Well, maybe _you_ don't write software in R. Others can write a pretty capable server[0] using just that.

[0] https://github.com/opencpu/opencpu/tree/master/R

Of course you can write anything in R but that doesn't mean it will be possible to maintain the codebase for the next 10 maybe 20 years including dev team changes.

In other words R is wrong tool to use for building the software just from maintainability standpoint.

I agree that in general one would not use R to engineer software. However I disagree regarding low maintainability.

I've seen very complex R packages that have been around for 30+ years. They are actively maintained. Applying good design principles, unit testing, modularity - all that is very much doable in R.

And you will want to write software in R, especially if the purpose is to support the very activity of working with R packages and to expose the R statistical environment over HTTP. Case in point, the software I link to, in my comment above.

Most python software use the standard venev setup with pip and requirements.txt, and most java software are distributed as fat jars. Nobody manually sets up dependencies anymore.

As a Java/Python/Go developer I can say that packaging is a solved problem as of 2021.

That's really not true.

I like to point out Airflow as an example. It's still a complete nightmare to deal with and it has many steps for just packaging the application.


I have less trouble packaging and running a 3 year unmaintained Maven Java application, than actively maintained Airflow. And let's not forget that I can target Java 8, without having to install Java 8 on my machine. (Which only adds to Python's complexity)

What do you mean about R? Its packaging and distribution system is great!

Python's packaging is a lot better with Poetry. Use Poetry and build the wheel with poetry build. The lockfile lets you create an exact virtual environment.

Like you mentioned, wheel files are not nearly as customizable as JARs. You can easily pick & choose the dependencies to include in JARs (fat JARs) and change namespaces of dependencies via shading to prevent collisions.

I've generally found it easier to add JARs to Spark clusters compared to attaching wheel files to PySpark clusters.

I'm all for a good project-based package manager for Python, but I have tried Poetry several times over the last years and not once has it worked as intended. It always failed to install packages for some reason.

I have to say that I use Python a great deal and I just never run into these issues. Nor have I ever even used Anaconda, I just use virtualenvs and pip and it all works.

It's my guess that you are using a lot of Python libraries that are wrappers around C or C++ libraries which have dodgy cross-platform support, because I can't see another way this is happening. If so, it's hardly fair to blame Python for that...

You are kind of right. Install non standard stuff in python is sometimes pain. BUT you can do it absolutely right. Also most of the time only few packages make you trouble. So you just need sometimes a fix for them. That's it. You even can download it and make it completely offline. Instagram is running on python... so it is battle tested. By the way, I would always try to avoid anaconda in production.

> main complaint about Python is trying to use someone else's software. Then it degenerates into a maze of twisty little passages of trying to install the correct set of dependencies, not knowing where those files are installed

Java is far worse on this front. Let's take a look at JEE or Spring - The entire experience is akin to summoning a demon with waving reciting correct incantations in correct places while having no idea about what even goes on in the background. There are MessageChannels, MessageProducers, ClientFactories that interact in mysterious ways and initiated in also very mysterious ways. And then there's EJB's and their containers which are just blackboxes of automagic.

Or how about Hibernate?

Well, it does considerably more things than a hello world python app. So at least compare it to Python’s full blown backend server with ORM and the like.

Django: zero dependencies for years, you could literally copy paste the code and it worked, ORM included.

It now has 2 dependencies. It is a 1000 times easier to use than hibernate, despite being one of the worse ORM in Python.

That the problem with old Java libs like Swing or Hibernate: they have been designed for the 90' and don't leverage the potential of what a modern Java version can do.

You can use lean Java persistence frameworks with lesser dependencies if you wish. I think mybatis only has 4/5 dependencies and 2 of them are the the standard slf4/logback dependencies.

There are many modern java libraries that are very lean and mean out there and package into small-sized redistributable assemblies.

Pointing to Swing or Hibernate is akin to pointing to GoLang of 2012 or Python of 2001.

I've seen plenty of even small Java projects becoming hard to manage as well. The design pattern hell is a thing.

You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :)

Not to say Java is not a great language for big projects, it certainly is well equipped for that, especially because it has superb tooling available on the market.

But I've done plenty of big projects in Python, some ended badly, some ended great. Not to mentions dropbox, youtube and instagram are testaments to Python can be used in large projects.

So I don't think Python is unsuitable for big sized projects. You certainly do have to worry about different problems than in Java, especially for projects that started without type hints. In my experience though, you reach less architecture dead ends with Python because the language is so flexible that a bad decision early on can easily be transformed or worked around even very late in the project without much fuzz.

So I don't use "size of the project" in my consideration to not user Python/Go/Rust/etc over Java.

> You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :)

I LOL’d at this joke (again) because it’s true, but if we’re honest, it’s also unfair. ProblemFactory is a bad idiom, rather than anything to do with Java The Language. You could (and IMO, probably should) just use a new Problem().

Java The Language was very stable for a very long time, so IMO the hype and fads got built on top. First we have a constructor - no, now we need a factory, but how to construct a factory? I know, let’s use another factory! All in the same unmodified language.

Likewise, how do we configure an object? First we have methods, but languages are cooler, so let’s build a DSL, no wait let’s use a fluent API so it just looks like a DSL!

I one had a dev replace a constructor call with a fluent builder, so now in the single use case where the object was ever created, we got five LOC where previously we had one.

His code was idiomatic, it was bad engineering, but it wasn’t Java the language.

Java is a pretty great language, but some of the crap people stuck on top of it was (and still is) a nightmare for readability and reusability. I use Go these days, and prefer their more basic approach to engineering, but there is much I miss from Java-the-language.

> I LOL’d at this joke (again) because it’s true, but if we’re honest, it’s also unfair. ProblemFactory is a bad idiom, rather than anything to do with Java The Language.

The Factory pattern’s pervasive use in Java was in large part a fairly direct consequence of JavaBeans requiring nullary constructors, so that the normal constructor work for a Bean had to be done elsewhere, i.e., by a Factory. Now, Beans was just a core part of the first-party enterprise framework that was central to the ecosystem and not strictly part of the language, but its not completely unrelated, either.

I’m not going to say you’re wrong because you are probably right :) but I don’t remember things happening in that order. JavaBeans was a super early Java spec and it introduced some (IMO) poor idioms, such as the mandate to use getters/setters. And I certainly agree that JavaBeans had a huge influence over the rest of Java culture (for the worse IMO).

But my memory is that pervasive use of Factories came along many years later, and seemed to be driven by the perceived needs of TDD, for example to provide instances of mock classes in unit tests. And I thought the factory pattern itself came from the GoF, but I might be misremembering.

That said, I’m not trying to contradict you. It’s likely that there was more than one driver for the pervasive adoption of factories. In any case it was a bit of a nightmare for a while, hopefully things are improving there now.

> And I thought the factory pattern itself came from the GoF, but I might be misremembering.

It did, and GoF certainly influenced OOP outside of Java, too. But EJB created a need into which the Factory pattern was really the only solution. (GoF precedes EJB and even Java.)

But certainly its not the only thing; Java hit popularity right around the time GoF was most influential; OOP languages whose ecosystems developed earlier (e.g., C++) or later (e.g., C#, though GoF-heavy code isn’t unheard of there) wouldn’t be as influenced by it, all things being equal. Java just had the perfect combination of language features, early specs like JEE (which included Beans), and timing to be naturally inclined for maximum naive GoFism.

On the other hand, JavaBeans was a simple pattern to understand and use, and the old OO dream of "software components that can be plugged together" actually worked: it was not uncommon for JavaBeans-compliant classes to work well together, even if the development teams never even heard of each other.

The crap people created on top was typically responses to deficiencies in the language, whether they knew it or not.

Stuff like "everything is a class".

I don’t think that’s true at all. Like most languages, Java has its share of deficiencies - I’d personally put null handling, type erasure and brain dead Optionals near the top of my list of things I’d change if I was King of Java - but fluent APIs and factory methods didn’t even start with Java, and have nothing to do with “everything is a class”.

What is wrong with Optionals?

Optionals can be null, so dereferencing them can still cause an NPE. Also the syntax is horrible.

I know the excuse that they are just meant to be used to wrap the return value of a function that might be null, rather than as a guard against NPEs, but that just means we’ve got a crappy, verbose Optional class ... and NPEs.

It was the most half assed attempt to fix the billion dollar mistake [0] anyone could have come up with. It needed syntax and compiler support, not a stupid wrapper class.

[0] https://en.m.wikipedia.org/wiki/Tony_Hoare

Sorry but of course Optional can be null because of Java’s type system. Objects can be null, Optionals are objects. I’d rather it have been different from the beginning but now that it’s here it’s really not something that should change. Just never let anyone get away with returning a null for an optional... though I can imagine the scenario where in. A framework that might cause it to happen. To have special rules for Optional in Java is the wrong answer for a blue collar language at this level of adoption and age. They said they never want to make a change as big as generics again.

I think you’ve read me out of context. Of course I understand why Optionals can be null, I was just pointing out - literally in defence of Java - something I don’t like.

I don’t really get your other arguments. I think the problem has been solved better in other languages including Swift, Kotlin and Rust, and Java could have learned from them, but didn’t. I can’t see why direct language support couldn’t have been added to solve this “billion dollar problem”. Even the Elvis operator would have helped.

Likely to be addressed with the ongoing effort for value types. Optional + prudent use of @NotNull annotations can get you most of the way there already in practical terms.

I have a saying for that: design patterns are a language smell.

Ha. Good one.

I'm absolutely convinced that's true for some of them. I was never 100% convinced it was true for all of them.

Design design does lead community culture.

Java also had the unfortunate destiny of becoming popular at the time where "OOP all the thing" was a mantra in tech circles. Also design pattern were all the rage.

Those things have a huge inertia, and while Java is not a much more flexible language, the image stuck, to the point that new comers still implement singletons in the wild.

> Java also had the unfortunate destiny of becoming popular at the time where "OOP all the thing" was a mantra in tech circles.

Java was a product of “OOP all the things”, it wouldn’t have existed without it.

Java created that hype to market itself. OOP all the things probably wouldn't have been a thing without it, for instance.

It was very much a marketed language and a language designed to be sold to top heavy corporations. This fueled a lot of the crappy design decisions, the hype and the culture.

> Java created that hype to market itself. OOP all the things probably wouldn't have been a thing without it, for instance

“OOP all the things” predated (and led to) Java, it wasn’t a product of Java (C++, Objective-C, Object Pascal and, well, a bunch of other things from the late 1980s and early 1990s were where it got started.) Java was about a decade into it.

There's a big difference between "OOP is cool" (which Java didn't invent) and "OOP ALL of the things".

But Java clearly didn’t “OOP all the things”, unlike earlier languages like Smalltalk. Java primitives are not objects (despite the fact that I often found myself wishing they were), and static methods are actually just functions. These days Java even supports first-class functions.

I know not everyone will agree with me, and that’s fine, but I always found Java to be far more pragmatic than, for example, C++, which well and truely predated Java.

> Java is a pretty great language, but some of the crap people stuck on top of it was (and still is) a nightmare for readability and reusability

I think that applies to literally every language. Bad programmers write bad code, regardless of whether it's Go, Java, Python, Bash, or Assembly.

Yeah I was teasing a bit.

Same goes for Python. Reading the hacky code of a geographer for his SIG system is rarely a fun day.

Yeah - look it’s a really valid criticism about idiomatic Java, and is one of a (fairly small) number of reasons I prefer Go these days. I ended up writing a heap of non idiomatic Java and enjoyed it immensely. But you do get a bit tired of going against the grain.

> You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :)

I think this joke is probably about as dated as the versions of java it was made about.

Unfortunatly, I know a lot of devs that don't even know it's a joke.

Singleton is still a design pattern used in the wild.

I'm not going to argue there are lots of ridiculous patterns out there, which seem to be embraced and encouraged by the various frameworks that a lot of developers seem to rely on.

Why bother setting things up explicitly in the way you want when you can declare things as injected, other things as singletons, and then have no real idea why it all went horribly wrong?

It's starting to be the same in Python though.

Inertia is huge in our industry, and the HN bubble doesn't gives a good picture of it.

Behind corporate firewalls I now see things done the way they were 10 years ago: packaging, string handling, concurrency...

I assume it's the curse of being popular and old.

And java has been popular for longer than Python, so inertia is even stronger. It doesn't matter if it has lambda since V8 if people still believe the best practice is to pass fat objects around.

The cool devs don't use the Singleton pattern anymore, we use @ApplicationScoped.

(Poe's Law disclaimer: yes, that was light sarcasm.)

Generally the Python codebases I've looked at have been more straightforward and therefore more immediately readable than Java codebases. You could write a simple codebase in Java, but if so many people use it to write complex monoliths, maybe the language does have some (in my view negative) influence.

> You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :)

It's a funny joke, but it maligns a harmless pattern identical in FP to a function returning a function.

While FP coders would brag about how awesome high-order functions are, we just keep mocking our own style for some reason. Factories are very powerful when used right.

The problem with Python today is that it only plays nice with C... which is a problem, since it's integration with JVM is probably more important today than 10 years ago.(Spark, Hadoop, etc)

Python is good for quick projects, but if you're writing a project with more than 2000 lines of python something's going wrong. The apparent ease of python becomes an unmanageable web of complexity. In the end you woukd have less headaches if you just used a proper statically typed language.

Dropbox, Youtube, Google, Instagram and NASA tell a different story.

And me too.

Scaling a Python project complexity is not harder than scaling Java, the things you have to be careful about are just different.

Are you the only person working on it? How big are we talking here, because I’ve worked on a few Python projects that fall in the region of “a couple to a few thousand lines” both by myself and with a team. Working by myself was significantly easier but Python definitely hits a “tangled mess” point, regardless of how disciplined I was.

In comparison one of my personal projects is in Rust and while that’s currently maybe only a thousand lines it’s already significantly easier to deal with.

> Python projects that start to grow has a tendency to become hard to manage in a way that I have not seen in Java at all.

Mypy is excellent. It has two-way type inference like Haskell. Good usage means catching almost all type errors before running.

So is PyCharm, which is IntelliJ for Python.

I use mypy + type annotations diligently and while it’s a big improvement upon plain Python, it misses a lot of stuff and definitely not nearly as good as a proper static type system. I’d say it gives you maybe another 15% more “scalability runway” before pythons complexity catches up again.

Except for the fact that absolutely every Java library is typed and maybe 0.1% of Python libraries are typed.

I used Kotlin in a large codebase, and one of my only complaints is the compile times. We use Gradle for our build system, and relative to Java it is slooowwww. But we like the other benefits of Kotlin, so it's worth it in the end. But if they could get compile times down, it'd be the perfect language imo.

1.5.0-RC was released a few days ago and contains rewritten compiler code which promises significant speed improvements.

It sure does, I updated everything a few days back and was really amazed. Everything is faster, even syntax highlighting.

We're already using the new IR compiler on 1.4, but I'll check out 1.5!

How large is the codebase? I moved to kotlin from scala and find the compilation to be rapid in comparison.

Fwiw, I’m normally on a beefy desktop so I might just be brute forcing this issue.

11,503 files, 1,431,195 lines of code. (spread out over <50 Gradle modules).

I think the main problem is that Gradle doesn't have the same support as Java for ABI compatible changes, so invalidation of modules are more common.

This article points to ABI as an open optimization problem in kotlin:


I think you're right - ABI compatible changes are likely the culprit.

"the IDEs is not as good as the java counterparts yet"

How do you mean? What IDEs are you referring to? Kotlin is fully (and very well) supported in IntelliJ Idea - unsurprisingly so, given that it's JetBrains own invention...

Though I prefer Kotlin to Java I can't fathom why IntelliJ's Kotlin tooling is still so inferior to its Java tooling when it was JetBrains who invented Kotlin as a Java replacement.

What are you missing specifically?

You say Java is not X enough to compete and then list things that Java has successfully competed with for years and continues to have a very wide lead over now, with the exception of Python and JS in limited circumstances -- the browser and machine learning.

The reason Java does compete so successfully is that it is high level and yet provides a virtually unmatched combination of performance, maintainability and observability (including always on, low-overhead deep profiling). None of the alternatives you mentioned come close. This is why it continues to be a top choice at Amazon, Apple, Netflix, Google, Alibaba, Uber, Soundclous, and almost all Fortune 500 companies. Saying it is "out of the loop" is either wishful thinking or delusional, depending on your perspective. It's just not the reality.

I'm just exposing my own selection criteria. It's not an absolute metrics.

I'm just saying, "to me, that's why I never end up using java".

Java is good enough for the vast majority of things. But so is Python.

And for specialized things, there are better choices available to me.

I'm not a Fortune 500 though.

> But so it Python.

For a very different definition of "good enough," i.e. unless you're working on a large codebase maintained by a large team for years, need high performance, or need deep low-overhead observability. So Java is "good enough" for a much wider selection of "serious" (large/mission-critical/long-lived/ high-performance) software.

> And for specialized things, there are better choices available to me.

That's OK, but in reality Java does very successfully compete with almost all the languages you've mentioned; it is they that, in practice, find it very hard to compete with Java.

Dropbox, instagram, google and youtube all were written in Python at some point. Languages don't scale, architectures do.

But even when the language became the bottleneck, they went the road of rust and go, not the road of java.

Again, not to say Java is not used by those companies with great success.

Python is a distant fifth place at Google today behind Java, C++, JavaScript and Go. It may be behind Typescript too at this point.

Performance critical, lower-level servers are typically written in C++ at Google - think things like Spanner or GCS. Google only allows a very restrictive C++ subset.

Application servers are typically written in Java or Go. Which is preferred depends on the organization.

Google of course makes extensive use of Guava and Guice, and Bazel, which itself is written in Java.

There is an absolute mountain of Java at Google. Pretty sure it's the most used language by LOC.

As if LoC was a usable metric when it comes to a language as verbose as java.

Plus all the boilerplate coming not from the language but the OOP design patterns.

No one said it was a usable metric for anything other than the fact that a lot of Java is written at Google.

I bet it has more to do with their HQ location and feeling trendy than anything else.

Well, it's true popularity in tech is not necessarily related to quality.

Trending does have an impact.

But by experience, having a killer feature, and a good adoption story usually does much more.


- PHP: easy to make web page in 2001

- JS: monopoly on the client side web

- Go: simple concurrency and binary production

- Rust: borrow checker

- Python: "yes, you can do that too. Also in 2 lines"


re Python: "...All actual work is done by C libraries though, you could just as easily use BASIC instead"

Well, believe it or not, VBA is doing to have to do with Python competition in Excel in a not so distant future:


> While we don’t have specific plans to announce at this time, we have been researching the topic, conducting customer interviews, and are working with the Python team at Microsoft so we can build a plan that we think can address the scenarios you told us about and ensure it can run wherever Excel runs.

Any long time developer on MS stack knows that actually means "thank you very much but no".

They just hired Guido, the father of Python, at Microsoft.

So, I would not be so sure.

Yeah, because he did so much for Python tooling at Google.

Google is hugely invested into Python, especially the data engineering branch. TensorFlow, Jax, etc. Though they will probably get replaced by Dex lang, they even dropped Swift 4 Tensorflow to focus on Dex [1]. The language looks very Pythonic compared to Julia which is a 180-degree turn in terms of language design.

[1] https://github.com/google-research/dex-lang

All of the Tensorflow underlying libraries are implemented in C++ and nowadays usable from almost any language with native interop.

As for Dex,

> Research language for array processing in the Haskell/ML family

> This is an early-stage research project, not an official Google product.

Where is Python?

Take a look at the code examples, looks like Python & Numpy + Haskell had a baby. And yes, it is developed by the creators of PyTorch (the irony) and some of the guys from Tensorflow, Jax and S4TF at Google Research & DeepMind. Read their paper here, it's pretty interesting. [1] It may never become an actual production language but it is many times more interesting than both S4TF and Julia.

[1] https://openreview.net/pdf?id=rJxd7vsWPS

Oh this looks nice.

But it’s also a google side project, so previous experience dictates that it’ll be dead somewhere between arrival and 5 years time.

- Ruby: "yes, you can do that 5 different ways in 1 line"

Ruby: Buggy async io for 20 years

Ruby, readable Perl since 1995.

My main issue is that people writing Java (or for the JVM) because of their backgrounds (app-level code printers) almost completely disregard how that code works on the JVM, at scale, in a highly responsive and/or high throughput service. You can't just use a big, "safe bet" framework like spring, which taints EVERYTHING in that project, write a simple REST API and then do heavy work "in the background" without side effects.

"Running Java" requires detailed system engineering / ops expertise specific to how the JVM works and can be tuned, and all too often, how specific frameworks internally pile their abstractions on top of each other. Problem is, a modern "Java app" is a pile of large frameworks and libraries.

As a system engineer, I HATE Java applications written by clueless programmers. They are difficult to handle and I often have to dig in and fix bad usage of framework features that somehow passed code review by equally clueless "senior" developers. I then get to spend a day to find out why this or that connection pool in there managed by this or that library does not handle its connections correctly, just to find the magic framework level variable that tunes that specific screw. Stuff of nightmares.

Every Java project is also __severely__ underdocumented. That's because even if you write documentation for YOUR code, the framework has books of documentation on ITS specifics, and includes high-level libraries which THEMSELVES have heaps of specific documentation. Climbing the tree until one arrives at actual standard library calls is like climbing into clouds and hoping to see the sun some day.

IMO terrible Java code is partially due to how good the JVM is. Performance is within spitting distance of native code, so people can do TERRIBLE things and it won't tank performance.

Endless abstraction, loading giant things into RAM, looping over every item in huge arrays. Blocking server threads for minutes at a time. In most languages you would be punished severely with awful performance or OOM. Java chugs along until things get horrifically bad.

I think it’s not a language problem. Frontend devs can be just as clueless, and don’t even get started on bad programmers writing in low level languages. Basically, the reason Java become so popular at the time was the bad programmers writing leaking, segfaulting programs in c++. Now they write bad programs in Java that “works” when one looks at it from an angle and is lucky.

>"Running Java" requires detailed system engineering / ops expertise specific to how the JVM works and can be tuned

> almost completely disregard how that code works on the JVM

As an occasional clueless programmer, I've had occasion to touch systems written in Java. Could you point me at some resources?

What he wrote is not specific to Java. At scale, any program written in any language will require detailed knowledge. This includes "simple" languages like golang.

Reality is complex, and for non-trivial programs complexity is going to be somewhere.

> "Every Java project is also __severely__ underdocumented. That's because even if you write documentation for YOUR code, the framework has books of documentation on ITS specifics, and includes high-level libraries which THEMSELVES have heaps of specific documentation. Climbing the tree until one arrives at actual standard library calls is like climbing into clouds and hoping to see the sun some day."

This weaknes stems from Java being OO. On larger projects you start to have abstractions which tend to be insucfficiently documented or the documentation not being updated with changes. Throw in some helper classes here and there, from a certain point of complexity of the project from an outside perspective the whole thing looks like being obfuscated.

> Python is older than Java, well supported

WELL SUPPORTED???? Have you ever coded a real thing in python?

I'm getting "Warning, no longer supported" console messages in all my basic well established tools and libraries written in python because a guy that lives in a world of academics and theory and not in a world of business and delivery dates decided that python3 was not going to have backwards compatibility with python2 because they made a massive irreparable disaster when they designed python2.

That is not a professional tool for multi-million dollar companies, that is a toy for spoiled nerds. Exactly the same that Visual Basic 5-6 were when I was starting. Extremely easy to use and extremely fast, at the price of been garbage for anything larger than a toy app.

And because all the kids learned that at uni and went to create the next thing in it like PyTorch and TensorFlow, now you have to do all the real code in C / C++ to handle what python can't in terms of speed an reliability, doubling you code base, your Dev teams, and the needed skill set.

I have been programing in java in large multinationals for 10 years and I used python every single day for the past 3 years for what its useful: small hacky scripts to increase productivity. The real sh*t that manages you cellphone towers, you home-banking, you online shopping, your logistic chain and your android cellphone apps, all things that I have worked on, gets done in Java.

Dropbox, Instagram, Google, Youtube, reddit and Nasa all have been heavily Python powered for a decade.

I myself have coded a streaming platform getting half a million user every day in Python. Baring the CDN to store the content, it runs on 2 servers, one for the DB.

So real things get done in Python pretty well.

In case of the Dropbox please read this:

_But as the company grew, new engineers who joined couldn’t understand the code. Clever code is usually short and cryptic, written by and for the individual who came up with it, but is hard for anyone else to understand—and nearly impossible to maintain. Guido called this “cowboy coding culture”. He recognized its value in our early stages of trying to implement things quickly, but knew it wouldn’t be sustainable over time, so he decided to speak up in his own quiet way._

And now they'll have to rewrite everything in programming languages where maintenance is not a burden.

[0] https://blog.dropbox.com/topics/company/thank-you--guido

Your last point is not supported by your link - this is an article praising Guido, the creator of Python, and remarking how good Python is.

Sorry, my bad. They already started rewriting core components in Rust.

Here you go:


To me Java is like a garbage truck. You get to work, start it up, do a nearly invisible but absolutely essential duty, then, at the end of the day, you turn it off and go home.

No one dreams about garbage trucks or puts one in a car show but they’re there and ready to go right back to work when you are.

It's horses for courses. Some plus points for Java:

- you can integrate code from hundreds of developers fairly safely (knowing that no one has changed the default behaviour fo builtins and different dependencies won't clash).

- the syntax, although not the most succinct is fairly easily readable and maintainable by other developers.

>the syntax, although not the most succinct is fairly easily readable and maintainable by other developers

I dislike that people conflate simple languages with easy to read code.

Low level verbose abstractions make code harder to read - going through the layers of IFactoryRepositoryLocatorBullshit because the language abstractions suck doesn't make it easier to read code.

It makes the code more accessible, in the sense that you can probably find some 20$/hour devs to read through that and spend a day solving something that should take a couple of hours most.

Good high level code express the problem domain without boilerplate and let's you focus at problem at hand - Java is terrible at that.

"IFactoryRepositoryLocatorBullshit" really has nothing to do with Java the language. That's just how some developers choose to design their programs.

What specifically is Java terrible at? I find Java to be as expressive as most mainstream languages. Certainly no less expressive than, say, Python or JavaScript.

>Certainly no less expressive than, say, Python or JavaScript.

Java can't even have a free standing function without 6 lines of boilerplate minimum and 2 levels of indentation to start.

Nominal static typing with weak generics and no almost no compile time programming support - you end up mucking with reflection or code generation if you want to do anything metaprogramming related or non trivial higher order functions - JavaScript and Python just deal with it at runtime, and if you need to type it out - you can still generate types that convey to the user what the result will be (the underlying code doesn't have to be typed)

Java 8 has been there for 7 years now. You can have a free-standing function in a single one-liner expression.

Function<String, String> fn = parameter -> parameter + " from lambda";

Using annotations and cglib, you can do all the meta-programming you want.

And how do you expose that function globally ?

Annotations and CGLib -> reflection nonsense and boilerplate - if you tried that and compare it to something like a dynamic language with open types (eg. JS/TS) you are just being dishonest if you're saying the two are anywhere close to comparable.

I remember doing a node ORM extension where I just injected standard revision management primitives into the entity as a part of repository. That would take an insane ammount of work in Java in comparison to get the same API functionality (namely it was mostly transaparent to the consumer)

> And how do you expose that function globally ?

Just like anything else. Put it in a package and just static import it from where-ever you need it.

Umm, cglib https://github.com/cglib/cglib is not reflection - its bytecode enhancement. You can inject, create types dynamically, modify types dynamically - all of it is possible. What you just stated is quite straightforward in Java actually and can be fully transparent to the consumer. It's by no means an "insane amount of work".

Now, if you bring up hot language features - sum types, etc - I agree that Java falls behind. But the stuff you offered as criticisms, Java actually excels.

> - you can integrate code from hundreds of developers fairly safely (knowing that no one has changed the default behaviour fo builtins and different dependencies won't clash).

It's exceedingly rare for this to be untrue of Python — it's technically possible to hack builtins but there's intense community pressure against doing that.

> - the syntax, although not the most succinct is fairly easily readable and maintainable by other developers.

This is sort of true but it misses the aspect which makes Java hard to maintain: the language being less capable means that you end up with more boilerplate syntax which has to be understood when reading it and the patterns that produces tend to be the long-term maintenance issue instead.

> This is sort of true but it misses the aspect which makes Java hard to maintain

The boilerplate syntax you talk about comes from like java 1.4.

Modern Java is quite expressive with streams and lambdas. If one does employ the Java Beans convention than yeah, he/she has to autogenerate a few getters setters, but those don’t occlude the actual logic.

And frankly, empirically, Java is anything but hard to maintain. You would be hard pressed to find many languages that continue to manage at the scale Java apps routinely handle.

Yeah, it’s (typical business monstrosity) hard to understand, probably has many thousands hours of technical debt, but it just works, and more things can be added to it (and occasionally with much more work, removed as well).

> The boilerplate syntax you talk about comes from like java 1.4.

I was thinking about things I've recently seen in new Java 15 code, so no. There are lots of old APIs in the Java language and popular libraries, and while things like streams are quite powerful, they're far from universal. I still see developers cranking out code which has to do what is built-in in other languages.

As a simple example, not having multiple return means that you end up with worse APIs in some cases or small classes which exist to wrap a couple of things — not necessarily terrible but it means that you've just taken on maintenance work for something which would be trivial in other languages. That extra code isn't exactly a huge lift but when you add things like that up regularly it's not hard to understand why all of the good Java developers I know are keenly following things like Kotlin which give more expressiveness without giving up all of their familiar tools.

Yeah, multiple returns does come up from time to time, but nowadays with records you at least have named tuples in with one line declarations. And if you don’t save the return type, I’m sure the escape analysis will get what you are doing, so it won’t be heap allocated.

But I do agree that there is space for improvements here.

It's true that Python programmers don't often hack builtins, but they still do things which aren't possible in Java.

For example: imports inside functions instead of at the top of the file (because the import does work, but the configuration hasn't been set up yet).

An example of this is an internal package at my workplace which makes a external service request at import time.

I felt literal pain reading this.

It's also True for Go, Rust, Haskell, etc.

But even for Python (which syntactically speaking is probably the easiest to read of all the list), if your team scale, you just scale the tooling with it.

The Python ecosystem is very rich in tooling for enforcing best practices. Poetry will manage dependencies cleanly. pylint will let you check that builtins are not overriden. Mypy will check for types.

So of course, it's not as good as Java, but again, the post is about compromises the language make, which are not the proper ones for me, personally.

You use Java because it is low risk. I think it might be lower risk than any other language in terms of design patterns, hiring, library support, run-time surprises, etc.

The language itself isn’t great though. Java solutions tend to be bloated and make it hard to decipher the underlying domain logic.

I certainly wouldn’t pick Java for a small team of experienced developers.

Progressively slower development seems like a pretty massive risk these days, where not being able to chase a competitor's big feature can be the death knell to your company.

Though it seems java in general attracts a culture of slow moving bureaucrats which doesn't necessarily translate into higher quality (in fact, I'd argue it translates into worse quality).

> Progressively slower development seems like a pretty massive risk these days, where not being able to chase a competitor's big feature can be the death knell to your company.

You are conflating to different layers. Not being able chase a competitor's big feature can be the death knell to your company, yes. But this does not mean that building your business software on stable and proven foundations is a high risk. On the contrary you want to be fast moving with your business features not with keeping up with quicksand under your feet. I.e. a stable well understood basis, is IMHO a prerequisite to moving fast above of it.

In addition to my arguments above, one still has to consider whether a tool matches the problem. Writing an Excel plugin in Java is probably a very bad idea (I really don't know, I just assume that anything based on .NET would be a better fit), although both Excel and Java value long term compatibility. If you want to follow the latest trends in AI without really understanding what is going on, it is probably best to follow all the tutorial about AI and use Python. But if you plan to hire people that understand the details of AI libraries, you might come to the conclusion that the AI libraries on the JVM also provide the basic blocks you need, the higher levels are customized to your application anyways.

To come back to the original point, a technology or programming language is not good if it moves fast, it is good when it fits your problem, doesn't create too many new problems, is well understood by you and your team and is maintained.

You're the one conflating my argument here. What I'm pointing out is this: there's somewhat of an assumption that java moves slow yet steady, therefore not generating the code mess other languages get blamed for, ending in either an undecipherable mess, or degradation of development quality and speed. The idea being that java makes one more likely to win the marathon in favor of losing the sprint. Whereas many other languages can only win the initial sprint, become messy, and then proceed to be unable to move with competitors anyway later down the line.

In practice, I've barely ever seen this assumption truly come to fruition. I see java codebases degrade, become undecipherable messes filled with reflection, inflate themselves to become incredibly hard to understand or work with, at similar rates. I still see JSPs throwing garbled stacktraces that barely help understand what's wrong. Still see business shoot itself in the foot because it said "this should never happen", so the code is made under the assumption it doesn't happen, because null is still available and no one uses optionals, and 2 months later you have clients show you another NPE after going through 15 layers of business-modifying logic and people spend a week uncovering how the situation can take place (or worse, it is retroactively sealed up and the actual bug is still there). If there's some magic spell that helps java become less messy than other static languages or even some dynamic languages, I have yet to see it.

At that point, one has to question: what are we losing the sprint for? Are we truly increasing the odds of us winning the marathon? Not even its most espoused benefits, libraries, write once work everywhere, etc., seem to be remotely unique anymore. The only two answers I see, are legacy, and the number of java devs available. Lose a java dev, no problem, just pop in another. Want to rewrite the app in a different language, or even in less verbose, modern java? Good luck convincing management firmly believing that a rewrite of one month is more costly than pushing out features at 1/10th the speed post-refactor for another 2 years.

And yet... That is what I got from a less than 2y/o Python application.

Java isn't the problem. People lacking a broader view are.

I highly doubt the progressively slower development claim.

I agree that Java is low risk from a manager responsibility perspective: nobody has been fired for choosing it for a long time.

Now, from a project success perspective, I think it's not. I've seen a lot of Java projects fail, over engineered, full of spaghetti code, riddle with inscrutable abstraction, stuck in a glue of badly designed architecture that has been fossilized by the type system.

I'd say from a project risk perspective, it's a pretty average language, it has pros and cons, but they balance each other.

I have seen a lot of projects fail over the years, for many different reasons, but I have never seen a project fail due to the choice of programming language.

> I've seen a lot of Java projects fail, over engineered, full of spaghetti code, riddle with inscrutable abstraction, stuck in a glue of badly designed architecture that has been fossilized by the type system.

Sure, but do you really think the same organization would have produced perfect simple elegant error-free code is Haskell or Smalltalk (or whatever "better" language you are comparing to) under otherwise same requirements, deadlines, resources and management?

I'm not saying languages doesn't matter. A better/more appropriate language is like having a bigger screen or a better chair. All else being equal, it will increase productivity and make developers happy. But it will not make or break a project. The things that will break the project: Bad/unclear specifications, bad management of change requests, lack of testing, unrealistic scheduling, lack of customer feedback, bad communication or conflicts among developers.

It's an anwser to "You use Java because it is low risk". I just don't think it's immune in any way.

Of course Java project are not immune to failure, that is not what "low risk" means! In this context it means the risk is lower for certain specific problems - e.g. unable to hire developers, show-stopping bugs in the platform which never get fixes, lack of documentation, abandonware.

Choosing a less popular platform (like say Clojure or CoffeeScript or whatever) might very well increase productivity compared to the conservative choice. But slightly increased productivity will not save a project, while the additional risks involved could very well sink the whole project. Which is why most businesses seek to reduce risk rather than maximize productivity when it comes to development platforms.

Imagine adding to the list of risks for a new project the term "low talent pool" and "head engineer leaving".

Many languages haven't been popular long enough to have a nice pool of experienced engineers to pick from. Java has that advantage, which not many languages have.

> Java projects fail, over engineered, full of spaghetti code, riddle with inscrutable abstraction, stuck in a glue of badly designed architecture that has been fossilized by the type system.

these are properties of a poorly designed project, and isn't due to it being java.

You may be able to causally link the failure to the people on the project being "incompetent" - but that's not really the fault of java!

i say java is a pretty good language, if you have large teams, with varying levels of competency amongst the members. As long as you have somebody good to do the overarching design and direct the project, it would do relatively OK.

if you have a small, elite team, then it may not be the right choice (depending on the team).

Well, law of big numbers. Java is used everywhere. For every failed Java project, there is many successful one as well. And honestly, chances are that team would have failed in any other language as well.

I generally agree, except the part about the low risk of runtime surprises. Java's type system is so weak that it doesn't even prevent null from inhabiting almost every type. The programmer is then forced to manually reason about when a value can be null or not, and of course humans can easily make mistakes in doing so. This inevitably leads to NullPointerExceptions at runtime when a project becomes sufficiently complex. Type systems of "low risk" languages prevent such mistakes by offloading this kind of error-prone reasoning from the programmer to the machine.

> Java's type system is so weak that it doesn't even prevent null from inhabiting almost every type.

"So weak"? You do realize that this is basically where every language was less than a decade ago?

Yes, Java's type system "so weak". Just because many other popular languages have similarly weak type systems doesn't make them less weak. Also, as a long-time Haskell user, I can assure you that nullable types were nothing new even several decades ago. Perhaps you have only worked with object-oriented languages, where nullability is typically the default (which is a bad idea).

There are tons of languages with non-nullable types that are much older than that. C++, basically every ML-influenced language, Prolog, Erlang, Tcl.

A decade ago Idris, Agda, Haskell had been around for a time already, there hasn't been that much advance in 10 years. And a decade ago it was also a commonly argued that Java isn't getting a lot in return for its very basic static types, vs simplcity and expressivity that dynamic languages get.

I like Java, but that's weak argument.

We're in 2021, not decade ago.

What language sees wide spread use without at least a decade in gestation? Java, ironically, but cutting edge languages take longer than a decade before making it to the blue collar programmer's floor. I mean the number of people that struggle with even stuff like generics still is amazing and that has been around for 17 years at this point so 10 years is nothing.

And java has excellent static analysis, so if you want to you can prevent every single npe.

> So Java is not a bad choice. It's an excellent tech. I just don't have a use case for it.

The language is underwhelming, the JVM is great.

It is, but if all you want is a JVM, Java is still probably the worse choice over Scala or Kotlin

The exact opposite is true. Scala's and Kotlin's syntactic sugar comes with tonnes of overhead and additional allocation. Java is pretty raw compared to them and allows you to stay closer to the C-spirit and thus retain more control over the side effects of the code you write.

You can write Scala to pretty much just look and run like old school Java if you want.

I haven't seen any benchmarks, but I doubt a Scala app written idiomatic style would be any slower than the Java version written in idiomatic style.

Also, what is this C spirit we are trying to stay close to? I'm certainly not interested in any "C spirit"

The C spirit I'm referring to is the raw, verbose and low-level-ish nature of writing code in C. For high-performance/low-latency Java apps it is absolutely crucial to have this level of control over code and resulting instructions emitted by the compiler. On the other hand - if you don't care about it and want to focus on domain-level stuff you absolutely can. This is what I find the most appealing about Java.

Yeah, absolutely. It's objectively worse than most languages.

Python's tooling is horribly underdeveloped... And you notice that when moving from Java to Python. And all the solutions are at this point in time are hacks.

If I needed to waste more time on hacking a setuptools script, to get a file placed into /usr/local/lib/shared... I'd rather use Go or Rust.

There's a lot of very reliable distributed systems written in java. But if something goes wrong, and it will, because distributed systems, you will not want to debug it. And because java is very enterprisey, distributed java developers are expensive. You're competing with faang salaries.

What other platform would you want to debug? There is basically no better one then the JVM when it comes to profiling. Exceptions are detailed with stack traces, you can even attach a profiler in production and let it run there because of the negligible overhead with flight recorder. Hell, there are even debuggers that can run your program backwards.

most things on the erlang virtual machine? Debugging elixir is fantastic.

There are ways to deal with this problem. Debugging of microservices can be efficient and you don't have to hire the entire team of experts.

Java is great when you need speed approaching Rust/C++ but don't actually need to be the fastest.

It's way easier than C++ and will get you 80 percent of the way there in terms of performance

This is oversimplifying probably. The JVM can make your non-optimized code faster than your non-optimized c++ code.


Kotlin solves most of the problems for us while leveraging the benefits of the JVM.

Long term, Kotlin will only stay relevant on Android.

They cannot fully embrace the JVM while targeting ART, JS and native at the same time.

With respect, you're wrong. I say this because we're now seeing widespread adoption of serverside Kotlin at places like Google and Amazon. With the support of Google and Jetbrains they can target whatever they want.

With respect, welcome to the Kotlin version of #ifdef, where language features depend on the underlying runtime.

That 3D graphics library using SIMD and value types from JVM on ART or JS?

Good luck achieving the same perfomance and memory semantics.

Kotlin/Native has already been rebooted as its memory model was incompatbile with JVM libraries.

It’s worked out ok for scala (though i don’t think anyone cares about it for android). Obviously a lot of code that only works on the JVM, because a lot of people just don’t care about native/js. But most core libraries will have ‘shared’ pure scala code and then have the platform specific implementations in separate folders. This is all fairly standardized with sbt plugins to do all the heavy lifting.

From the app side you just don’t use classes that you can’t use?

It will be interesting to see how things like Valhalla and Loom will pan out.

Did it?

The main company behind Scala changed its name and now also offers Java consulting.

Unless the project requires Spark, there is little reason to even care Scala exists.

Then there is the version 3.0 where they started having brain damaged ideas like changing the whole syntax.

Scala today is Kotlin in 10 years.

One benefit of being old in this industry is having survived multiple fashion waves of guest languages on each platform, then watching how those guest languages fade while the platform languages adopt some of their features.

Or even how whole platforms become irrelevant making it a complete moot point regarding whose languages are on the platform.

How is Kotlin going to support the SIMD interface? It really sounds like #ifdef for every platform, unfortunately.

Definitely. There has been a consistent increase in non-Android Kotlin jobs in the last 12 months according to Indeed.com.

Back in 2010…

There has been a consistent increase in Scala jobs in the last 12 months according to Indeed.com

What's the state of server-side Kotlin now, is it usable and what kind of JVM are cloud hosts running it on? Kotlin seems like one of the best languages out there.

We use it in production with spring boot and deploy a single jar file on azure. Works pretty well

We're using Kotlin with Spring at the moment and everyone on the team prefers it over Java. I suggested Kotlin when they laughed at my suggestion of using Clojure. Ah well.

Kotlin is widely used internally at Amazon. In both AWS and retail.

Not only usable, but becoming very widely used. It's no different from Java for deployment.

Yes, I think today the languages worth focusing on are Kotlin, Swift and C#. They are similar in many ways and come with built-in nullability. They are also platform languages offering excellent tooling and a productive development environment.

Are there many companies seriously using Kotlin for large projects outside of the Android space?

Yes, our stack is Spring Boot + Kotlin on the back side, TypeScript + Vuejs on the front. We’ve millions of unique visitors each month, and we’re pretty satisfied with the stack.

Cash App uses Kotlin Multiplatform, including server-side code, https://kotlinlang.org/lp/mobile/case-studies/cash-app

Google, Amazon, hundreds of F 500's

Absolutely. Kotlin is *widely* used for backend code at Amazon.


JVM != Java.

We are talking about Java as a language, not the JVM as a platform.

You can also run Python on the JVM.

Although, some Java compromises are definitely linked to the JVM.

>You can also run Python on the JVM.

Jython is stuck on 2.7 and unmaintained.

Graal's implementation of python is maintained and up to date with python 3.

You're missing the other JVM-based languages, notably Scala.

Scala has a "tunable" level of PL feature usage; you can write very Java-esque Scala at the beginning and slowly incorporate more advanced features.

The key thing about these features are that once you understand what they do, it allows you to write fewer lines of code overall. Fewer lines typically means fewer bugs, and it communicates intent with more clarity (at least to developers who are familiar with the patterns).

This makes it easy to onboard new devs who may not know a lot of Scala and let them be productive from day 1 (writing Java-style Scala) while advancing their skills towards more fancy idioms.

I have stayed away from JVM-land after taking a different tack in my career trajectory, but I worked at Twitter about a decade ago when they were transitioning to a JVM-based stack and were early adopters of Scala. It was really a joy to be able to simultaneously get my work done while uncovering all of the new cool language features!

I almost considered using Java instead of Erlang for a project I started working on. For one, my mind is still stuck in trying to model systems in a very OOP way, and I was (am?) struggling with OTP. I figured I could pull in Akka to get some of the nice Erlang stuff.

But Erlang was just such a good fit for this project. I wasn’t so huge on the Java version of Akka. I also briefly looked at Scala, but I avoid Scala for similar reasons to C++ and Haskell. The nativess of a lot of the features I wanted to Erlang just looked better and it will be a cool homage to the language’s roots.

Also this is probably more my fault, but I don’t really understand how distribution works anymore. Supposedly Oracle JDK is no longer supported and you’re supposed to package a JVM with your application, but all the big Java apps still require me to have a system wide JVM to run them? OpenJDK seems to work fine for now.

Also after toying with a LAPB implementation, I’m so mad other languages don’t have a good type for dealing bit level data. Bitstrings are a godsend.

OpenJDK is basically the Java JDK. Oracle JDK is only a “fork” of it, but they have complete feature-parity. Oracle only provides paid support for current and older versions of OpenJDK (similarly to many other vendors)

So you can just install OpenJDK from a package manager, use the jlink tool and create your own small “JRE” that you want to bundle. Jpackage can create a platform native executable from that, that is either an installable exe, .deb, rpm or MacOS’s format (I forgot it’s name)

Those are all the wrong reasons in an enterprise environment. Seasoned Java developers would laugh at you if you would tell this to their face

What I love about Java is, that I can update the runtime without being afraid to break something. I also love the mature eco system. What's also great is that the compiler catches most code issues before you try running your code.

What I don't like is the module support introduced with Java 9, which is vastly inferior to OSGi.

Python is generally less performant. Go has a smaller ecosystem.


Yes, but that's my point.

If I don't need performance, Python is ok.

If I do, I won't go Java, I will choose something that is built for performance. Python is good enough for 99% of my performances need. The last 1%, jumping to java is not a big difference, I'll use rust or go.

I won't use go for the ecosystem, but it's unique characteristics: easy concurrency, dead simple binary production. Java can't beat that. IF I need an huge ecosystem, I'll go Python.

For the need for Java, I would need this very specific sweet spot where I need just enough speed, and just a rich ecosystem enough to justify it, and nothing that is a killer feature in alternatives. And a situation where compromise over this is not possible.

It never happens to me, that's all.

> Python is good enough for 99% of my performances need. The last 1%, jumping to java is not a big difference, I'll use rust or go.

Whilst I roughly agree, that's still a bit too simplistic.

In particular, we might prefer something like Rust to write a performance-critical algorithm, but that forces us to make a decision:

- Do we stick with Rust for everything else (networking, data plumbing, etc.)? This forces us to confront the ecosystem problem.

- Do we wrap our algorithm as a library for other languages (like Python)? This forces us to confront interoperability (ABIs, FFIs, cross-language dependency management, etc.).

There's lots of room in between these extremes for other pareto-optima, like Java.

Also, we often need to consider latency and throughput separately, rather than just "performance". Java is a pretty stark example, since it's pretty slow to start but reasonably fast when left running (compared to native binaries like Rust, which are low latency and high throughput, or scripting languages like Python which are high latency and low throughput).

Agreed, it's just a general overview, I skipped a lot of nuances for the purpose of conveying my main message.

Java is orders of magnitude faster than Python for code that doesn't spend all of its time waiting for IO. Java perf and Go perf are about the same.

But not Rust.

And Go is better if you do I/O.

That's my points. Compromises.

I'm not saying "Java is bad". I'm saying, "I have no use case where I, personally, would use Java over something else."

I do know other people have use cases for it.

I just don't, because those compromises don't make sense for me.

Where is Rust AWT? Not to mention Swing, JavaFX, or even an whole mobile ecosystem.

Well, if we create a desktop app, the Python + C bindings will be a better choice for my own project. Easier to dev, equivalent perfs, equivalent libs (and the QT Rad is excellent).

Java does have android right now, although it has to share with ReactNative, Xamarin and flutter. Again, for different compromises.

So apparently Rust isn't that better than.

Java also has the IDE ecosystem between Netbeans, Eclipse and all JetBrains offerings, with exception of Apple and Microsoft offerings.

It's not a matter of better. The original comment is all about what compromises work for me, and why I don't have a use case for Java.

You are trying to move the debate toward the quality of java, which is was never my point.

Not at all, I though your point was how Rust and Go are a much better option.

> If I do, I won't go Java, I will choose something that is built for performance. Python is good enough for 99% of my performances need. The last 1%, jumping to java is not a big difference, I'll use rust or go.

So given that, I am curious where are those GUI alternatives with the required perfomance in Go and Rust.

So you are in the very niche use case where:

- you need a GUI

- you need perf beyond what Python is capable and you identified it clearly in advance

- you can't use numpy / multiprocessing / cython, pypy or they won't give you the perf you need

- you can't find a main hotpath you can optimize with a 5 lines c or rust extension and write 99.99% of your app in python. Or you don't want to bother.

If you ever find yourself in this very use case, then yes, use Java.

But I never found myself in this very precise use case.

> multiprocessing

Please.... That's literally the worst option for python on this planet. For all "just do multiprocessing" the tooling is horrible garbage. Then we get to Twisted and Gunicorn the Spring Framework of Python world.

No, he is in need of writing production quality software together with his medium to big sized dev team and he doesn't want to introduce maintenance burden into his project 10 years from now. Software will get improved during it's lifetime and not overwritten from scratch every 2 years.

With external contractors arriving to work on a foreign code base just for a couple of Jira tickets as per department budget.

To be fair, even people deep in the Java ecosystem don't like its desktop application/GUI support.

Its only saving grace is that all other cross-platform GUI systems also suck, and if you're doing everything else in Java it might be the path of least resistance.

Only the people that are too lazy to actually learn how to do it properly,

"Filthy Rich Clients" by the nowadays Android UI architects


"Swing Hacks: Tips and Tools for Killer GUIs" by Joshua Marinacci, well know in the UI research community


And then commercial libraries like


For ordinary desktop apps, javafx is quite good. It’s a hidden gem in the ecosystem.

(Though I haven’t tried its mobile “backend”)

> Java is orders of magnitude faster than Python for code that doesn't spend all of its time waiting for IO.

It's hard to separate the absolute performance of Java the language from Java the culture where inefficient patterns or attempts to implement dynamic behaviors in some framework code defeat the JIT (not to mention the benefits of type-checking). If you have a team which cares, it should be faster but the average business app I see does not have that team and will, if lucky, perform within the same order of magnitude as Python.

Having got back into Java a bit recently I was surprised how fast it was (coming from python/Perl and php).

Speed doesn’t matter always, but when it does it Java feels snappy. Our programs our command line based so our framework use is limited. Also the built in data structures are nice. I still find getting Java’s set up painful, which is a huge impediment for us using it more.

Well, that same team would have trouble even writing complex python apps as well, without types

(yeah I know it has type hints now)

Even IO heavy code, it is much easier to write multithreaded async code for the jvm than it is for python

If it's just about I/O, then no, threads in Python are super easy:

    import random
    import time
    from concurrent.futures import ThreadPoolExecutor, as_completed

    def hello(seconds):
        print(f"Starting hello in {seconds}s")
        print(f"End of hello in {seconds}s")
        return seconds

    # At the end of this blocks, it automatically join() and clean
    with ThreadPoolExecutor(max_workers=2) as executor: # 2 tasks in parallel max

        # this send jobs to threads via safe queues
        a = executor.submit(hello, random.randint(0, 5))
        b = executor.submit(hello, random.randint(0, 5))

        # this collect results from queues in order of completion
        # sync is automatic
        for future in as_completed((a, b)):  
And if about network I/O only, you can get even more perfs using asyncio.

Threads in Python are only inferior to Java threads when it's about using several CPU.

Are python threads still limited to one core? That’s always been a nasty limitation.

I do enjoy in python that it is quite easy to utilise multiple processes in a code-light fashion, but some things are more natural as threads.

Java and Go are roughly equal in performance (seriously, look up the benchmarks). If you're using go for it's concurrency primitives, kotlin has equivalents.

I got into Go for a while, but if I'm honest, it's a kludgey language. Half the reason it has taken off as it has is simply down to the fact that it's backed by google.

> The last 1%, jumping to java is not a big difference

That's where you're wrong, kiddo.

Oh, I'm afraid I can't claim that sobriquet anymore unfortunately.

But that's not the point. The point is that, for the 99%, staying on a slower language is ok. For the last 1%, I'll skip Java and go to Rust/Go. If I have to do a rewrite for perf sake, I'm not going to go half way.

But you are not going to get higher performance in Rust/Go.

Rust can literally contain inline asm so yes, you will. But even without that, the startup time is always going to be faster.

And for IO, you will get faster perf in Go more easily. Sure, you can finely tune your Java code to get there, but it's a lot harder.

It in both cases it will eat up way more memory.

There is a reason Google, that did use heavily Java internally, is now moving to Go, a language they custom designed for concurrency.

Well, project loom will make the JVM arguably a better platform for concurrency.

Basically every language is more expressive there (even Java), GC is much much better - in benchmarks it is not as obvious only because Go avoids creating garbage most of the time, but it can’t always be avoided; and the platform is incomparably richer on the JVM side.

I wouldn't say Google is really "moving" to Go. It's an option, but plenty of projects new and old continue to choose Java.

You're right, but:

* performance is not really an issue for most software ("97% of the time, premature optimization is evil"). A well designed software doesn't suffer from performance issues with current computer performance, unless you do AI or bleeding edge graphics or science simulation.

* there are ways to speed up performance sensitive parts with something else than java, for example by using C/C++, would it be with a python module or cython. Not ideal, but generally you gain performance by adapting your design, not by changing languages. A garbage collector is rarely predictable, hence java is not a good fit for performance.

* I remember playing minecraft with friends, and the server was regularly crashing because it was out of memory, or something like that.

The OP brought up performance reasons to choose language. :shrug:

> I remember playing minecraft with friends, and the server was regularly crashing because it was out of memory, or something like that.

I've seen this, but I don't think you can really use one server program running out of RAM as indicative of much. I do still find the pre-setting of max memory on the command line a little bit odd though.

Performance as an issue is massively overstated in high level languages. CPU intensive hot paths are rarer than people think, I/O performance is a bigger deal than people think and there's more hyper optimized code written in performant languages that you can call directly than most people realize.

A lot of graduates think that compsci jobs involve optimizing algorithms or some shit coz they did that type of thing as undergrads, so they port that attitude across.

It's also the reason why pypy was massively hyped for a while and then not really used all that much. It was solving the performance problems python never really had.

It's true, that the situations in which you care about it are few. The most recent performance issue I've come up against is actually java's startup time, because for reasons unknown my client decided java AWS lambdas were the way to go, has quite a large, complex codebase built around it, and now has complaints about startup latency.

I have noticed some younger engineers on C++ projects doing some kooky things "because it's more optimal", and have taken time to explain to them that the micro-optimisations they're using impact readability, are going to be done by the compiler anyway if they're at all useful, and are likely to be several orders of magnitude less relevant than some lock somewhere, or a bit of IO, or whatever.

Pre-setting max memory seems odd these days, when everything runs in docker, with its configurable memory limits.

Handling process memory usage pre-docker wasn't so easy.

I don't think I've ever worked on an application where performance wasn't a problem. The ability of programmers to write slow software grows faster than computing power does.

> well designed software

Ah, there's my problem. Maybe at some point I'll get a chance to work on one of those.

> I remember playing minecraft with friends, and the server was regularly crashing because it was out of memory,

Could be a problem with the logic/design of the server rather than a problem with Java? Despite memory being GC'd, you can still run out of it if you just keep allocating stuff. The important thing about Java is that it doesn't suffer from the usual C or C++ memory exploits.

Python code which uses stuff mostly from the standard libraries isn't really that slow. Parsing a JSON? Call a wrapped C function. Process a media file? Call a wrapped C function. If you keep the actual CPU-intensive stuff in C code, the ops executed by the Python interpreter can be negligent.

That Python's performance doesn't matter because you can write things in C instead is faint praise indeed.

You don't need to write it. The ecosystem is already chock full of compiled extensions. That's kinda the point.


I didn't, thanks.

I think that there are use-cases in which java is more performant than his low-performance options, and can be as performant as his high-performance options, while providing a much larger ecosystem.

I think the parent poster actually makes a very weird set of choices - "when my high level choice, python, is not cutting the mustard, I am happy to throw away breadth of support entirely in the name of optimisation."

It's up to him what his preferences are, of course, I'm not saying they're wrong as much as personal.


Perhaps you could enlighten me then? Rather than just posting low-effort, content-less, drive-by snark?

The OP even says they're just posting their own selection criteria in other comments.


Thanks for your constructive input to the discussion then.

Don't forget that Java first appeared in the late 90s and is a language of its time. That's not say that it hasn't evolved, but many of the decisions and choices were of that era.

- Java: 1995

- Python: 1991

The first and second half of the 90s where very different times when it came to programming.

Furthermore Python and Java set out to solve very different problems, which is reflected in their design decisions.

I agree mostly. Some good use cases for Java:

- cryptography: It has a wide range support of symmetric/asymmetric algorithms from legacy to modern ones.

- XML and SOAP with Web Service Security in particular.

- Modeling large business concepts because of static typing, Objects inheritance and polymorphism, no memory management while still being performant. I would not use Python for that but other languages can compete C#, Scala, Kotlin, maybe Typescript.

Python and Ruby both would fit the bill perfectly for all those use cases for me.

The cryptography module in Python is awesome. lxml and sud deals with XML and Soap in a blink.

Modeling large business concept is a joy with dataclasses, and the language will never be the perf bottleneck.

Now I understand that if you are experienced with Java, it would solve all those problems perfectly.

But again, I would not, personally, gain anything by using it for this.

I think the problem is because of the virtual machine, instead of being compiled to an executable. I mean GraalVM is great - but why did it take so long to develop? I mean Sun could still be alive if developers and users had instant startup times, could have easily deployed Java to servers and clients, and that it was not only faster but used way less memory.

The virtual machine is (was?) the whole point. You can run the same binaries on your dev box or your server, whatever flavour of server that happens to be.

Startup times are not an issue on servers as processes are typically long-lived anyway. It is a bit of an issue on serverless (lambda etc.) but that’s a relatively new thing. High memory usage is generally poor tuning - if you give the JVM 1gb it will use it and avoid GC until it needs to. Sometimes it’s poor coding too, I’ve seen web APIs accepting files as base64 encoded json strings which is horrific server side.

Graal is very clever, but that memory example is nonsense. I just tried the Find example they give and whether the graal version beats the java version is completely dependent on Xmx.

Obviously I don't have their dataset, so it's not exactly the same test.

edit: In fact the numbers in the blog are so far off mine they may accidently have been testing /usr/bin/find.

It didn’t take too long, there was AOT compilers available two decades ago as well.

There was just not much interest in it, because performance gets worth, and startup time is seldom interesting. (Pretty much only command line tools would require faster startup, and recent serverless)

And memory usage is a tradeoff. Though most of the time java could run with almost half of the currently used memory, it is unnecessary work to GC if memory is available.

> I think the problem is because of the virtual machine, instead of being compiled to an executable.

I learned Java on gcj (gcc support for Java), and it generated executables. I've no idea why they killed it. Maybe someone more in the know can explain.

> not opinionated enough to compete with Lisp/Haskell

Interesting - you seem to be saying that Lisp is very opinionated. If that was your intent, may I ask why? Your experience doesn't jibe with my experience as a Common Lisp user, which is that Lisp isn't opinionated enough, and gives you too much flexibility (in some cases).

I have the exact same criticism about Python.

Well, that's the point of opinion isn't it ?

You perfectly nailed how I feel about java.

If you are talking about Erlang and D etc then your uses are unusual and not typically commercial and so I don't put much value in your response. No offense intended though.

If I can choose, I won't use Java either. Some jobs in the past requires me to use it, since it's popular. However, nowadays I can just use Python since most of my job is about data engineer.

> If I want a distributed system or something with a lot of I/O, Erlang and Go will always be better than Java.

Based on what?

Java is very high level - it runs on a VM and manages memory for you.

I think the opinion you're trying to convey is "not untyped enough".

Ever heard a technology called GraalVM ?

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact