Live data from Hacker News

Java Is Underhyped

jackson.sh

791–800 of 808 posts

Re: Java Is Underhyped

#791

Earlier quoted context omitted.

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 comp…

> 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.

Re: Java Is Underhyped

#792

Earlier quoted context omitted.

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 comp…

> 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.

Re: Java Is Underhyped

#793

Earlier quoted context omitted.

> 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. O…

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…

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.

Re: Java Is Underhyped

#794
post #458

Earlier quoted context omitted.

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 organizatio…

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

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.

Re: Java Is Underhyped

#795
post #351

Earlier quoted context omitted.

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 yours…

> 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.

Re: Java Is Underhyped

#796
The Java language is proprietary to Oracle. Oracle lost their lawsuit with Google with the SCOTUS finding that Google's use of some declarative code was "fair use". Oracle's license requirements and its litigious history is enough for me to not want to use Java in a product setting.

I personally find the Java language cumbersome and the type system constraining. These days my preferred languages are Python, Go, and C. In my experience, Java is not a good choice for exploratory programming where adapting old code to new use takes significant repurposing effort.

Re: Java Is Underhyped

#797
post #642

Earlier quoted context omitted.

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.

Re: Java Is Underhyped

#798
post #686

Earlier quoted context omitted.

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.

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

Re: Java Is Underhyped

#799
post #615

Earlier quoted context omitted.

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…

> 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…

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

Re: Java Is Underhyped

#800
post #343

Earlier quoted context omitted.

> - 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 maintain…

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.
Post reply on HN