Hacker News Reader

Comment by user5994461 | Hacker News Reader

We use Java because Python proved to be too slow.

And because the IDE support (refactoring etc etc), compile time error checking and ease of use more than compensates for Java being a little bit verbose.

Yeah, and they used C because the compilator could optimized stuff the JVM couldn't but now it can. And now Python get type hints so you can have the IDE tools you have with Java like with PyCharm. It's the circle of life.

Not quite correct about type hint. They are only in python 3.

Everyone who adopted python 2 on sizeable codebase is likely stuck there forever, with zero annotations and none of the new tools available, and they'll never be ported back.

You can use type hints with Python 2 in the form of special comments (http://mypy.readthedocs.io/en/latest/python2.html#type-check...). Guido has been working on the type hint project for dropbox specifically to help them to migrate 2.7 code to 3.

But let's be fair, type related tooling in Python are not close to the ones you have in Java yet. It's just that eventually, everything comes around. Java got faster. C++ easier. Python ...toolier ? Etc.

Java got faster and got some functional features.

Python broke all retro compatibility and put all existing sizeable software in a miserable deprecated state with the breaking of python 3.

I don't recall C++ getting easier. The few tools and IDE still fail at decent refactoring and code completion. The C++11 movement is adding few stuff more or less useful, piling on top of the vast amount of already existing complexity.

C++11 makes a LOT of things much, much easier. Yes, it does pile on top of existing complexity because they're loathe to eliminate any backwards compatibility, but the nice thing is that you don't have to use older features or methods of doing things. In fact, if you look multiple serious C++ codebases, it'll almost look like they're different languages, as every project basically chooses a subset of C++ they accept. Realtime embedded code doesn't look anything like desktop application code, for instance, but they're both technically C++.

And as far as I remember even google is only supporting python 2. Their python-go transpiler doesn't support python 3 for example (unless something changed in the last months and I missed it)

Most of the C++ annoyances have already been fixed by Dlang, which interfaces very nicely with C/C++ libraries and code.

And because packaging everything in a jar is easier than pulling 1e3 dependencies for every deployment. Not to mention drpendencies that also require a C/C++ compiler boost or other native libraries.

Yeah and some use C because Java is too slow. The point is, there is nothing new here, the history of computing is repeating itself. It's just now we have better toys, a bigger market and the stakes are higher.

Mmmmm, steak.

I'm french so my english is sometime funny. I didn't mean a piece of meat from a weed smoking cow obviously.

Your English was flawless there, he was just making a joke because stake sounds like steak, and he likes steak

I wrote steak in the first version. I edited back to stake after his/her comment.

FWIW, it is a mistake a native speaker could have made.

Mmmm... misteak

You were completely correct and idiomatic, goatlover just wanted to throw in the pun.

And this is the reason that I've become such a huge fan of Rust... back to the metal, high level interface like Java.

Rust doesn't bring much in that aspect. You could use C++ for performant high level abstraction for many years before Rust. Rust brings memory safety and that's huge. But it's not anything like Java, it's much harder.

Actually, I think it's very similar to Java in terms of what is being offered and at what layer of thought.

It does have a steep learning curve, but it's worth it. The number of concurrency bugs alone that I could have avoided if I had been able to use Rust years ago are sad to think about. Java has great concurrency tools, but doesn't do anything to make sure that your not shooting yourself in the foot.

Java also has JavaFX, which comes with an embedded Webkit browser. I can create my UI with React, or any other HTML/CSS/JS library, and make it interact with code written in Java, Scala, Groovy, Clojure, Kotlin, Ceylon, Frege, etc. very easily. I think this provides all the benefits of Electron, but is even more flexible and powerful.

Do you need to run N programs on N copies of Chrome with JavaFX or use a single VM like all JVM apps do? Because that's the problem with Electron mentioned in the article and that's exactly one place where JVM languages are better.

add nashorn so you have a spare javascript vm just in case...

Yet, this is not as popular as electron. Ask yourself why.

This is basically a terrible argument in and of itself you would do better to flesh out why yourself instead of expecting everyone to conclude your self evident correctness.

Too many JS/web programmers that's why. Plus JS/web programming is way easier and more popular than most of the JVM languages.

i'd guess that there are a variety of things to consider. do you actually have anything to say?

> code written in Java, Scala, Groovy, Clojure, Kotlin, Ceylon, Frege, etc

Your list of 7 JVM languages (both here and in your earlier comment on this submission) seems to be from most widely used to least. Yet in your HN comment from 2 days ago at https://news.ycombinator.com/item?id=14068664 you ordered that list differently, i.e. "Java, Scala, Clojure, Groovy, Kotlin, Ceylon, Frege, etc". Have you changed your mind about the relative adoption of Clojure and Apache Groovy in the last two days?

Not really. Actually, however, there is a recent survey that shows that Groovy is the second most popular language on the JVM, behind Java. Myself, I use Scala, and would like to learn Frege.

Groovy is a quite lovely dynamic language and it's actually the best solution for BDD using Spock. Sadly I still didn't find anything comparable for BDD in all the languages that I use.

> Groovy is a quite lovely dynamic language and it's actually the best solution for BDD using Spock

There's something wrong when a testing framework hacks into a language parser to make the language statement labels have special meanings like function names do, and overload the `|` operator in expressions so data will appear as a table in the source code. "Lovely" isn't the word for that sort of thing.

It's a DSL. And it works very well also because of these operator overloads.

Reply on news.ycombinator.com