Hacker News Reader

Comment by belter | Hacker News Reader

None of the memory problems of C++, the speed of C++ most of the time. Thousands of high quality libraries, a JVM that is a marvel of engineering after 20 years, tooling for development, monitoring and introspection of exceptional quality. Many of the internal tools at the largest Cloud developed in Java. Most enterprise level software. NASA extensive use of Java. A team behind the development who has stunning common sense in resisting the latest fads. Support for IEEE 754 that took years. AOT compilation...The infra behind most internet banking sites out there. Use in high speed trading.

What else do you want from the ecosystem?

View on HN

What would be a modern IDE for Java?

I remember programming Java in Eclipse. And it was powerful for the time, but everytime I read bloated, I automatically think Eclipse since then..

IntelliJ is very good.

https://www.jetbrains.com/idea/

and also FOSS (Apache 2): https://github.com/JetBrains/intellij-community (as well as PyCharm found in the "python" subdirectory)

Another rather new option is VSCode + the Java plugin

Eclipse has seen vast development in the last few years and is fast and easy to use these days.

>” None of the memory problems of C++”

I’m sorry, I’m calling BS here. You can still leak memory in Java.

You can leak memory in any language. That’s an impossible bar. The problems op is referring to is obviously about memory safety.

Java obviously isn’t thread safe like Rust is, but it’s typically safer than C++ on that front too.

Rust isn’t thread safe either. It’s borrow checker will attempt to correct you but you can still run Rust unsafely.

As I understand it Rust's unsafe is designed so you can encapsulate unsafety behind a safe interface.

It's up to the programmer to verify the safety of code using unsafe. But it they do so correctly then you can rely on the borrow checker to verify that everything else is safe.

This means that when you run into a thread safety bug in Rust code you should only have to look at the unsafe blocks to find the culprit.

With that said, I think it is important to mention that if you go off the safe path in rust and you do hit such a bug, your current execution is no longer trustable, it could have corrupted the heap, introduce UB, and die with a segfault, etc.

In java, race conditions can enter illegal application state, but their scope is much more limited. NPEs are 100% safely handled, etc. you can only get off the safe road with using Unsafe unsafe, and manipulating the JVM’s inner state which is not even allowed by default. Depending on application, this difference may matter a lot!

There are two kinds of leaks IMO. The one where your algorithm allocates gigabytes needlessly (and cannot be avoided by language design) and more insidious stuff like having to unsubscribe from an event handler for your object to be dereferenced.

Isn't that true in any language that lets you allocate memory?

Shitty code is shit in any language. What's your point?

var list = [];

while (true) { list.add(1); }

Here you are, which language won't leak memory here?

Also, which language will let you connect to a prod instance without a performance hit to get some stats on the heap and its allocated objects? Hell, you can even list every instance of a type as I've recently learned.

>var list = [];

> while (true) { list.add(1); }

idk, I don't think endlessly growing memory usage is really what a leak is, a leak is really when you have no way of accessing the allocated memory to free it (ex. dropping the last remaining pointer to a `alloc`'d block in C) or the opposite in garbage collected languages: accidentally holding onto a strong reference to objects that should be freed.

> the opposite in garbage collected languages: accidentally holding onto a strong reference to objects that should be freed

So basically what I gave an easy example of. Sure, it won’t look like this in practice, you probably accidentally keep adding to a list, or a cache, but basically this is what happens. The former kind of leak can’t happen with tracing GCs.

You can. But you have to try rather hard.

> None of the memory problems of C++

Every time I see something like this I roll my eyes... C++ doesn't have any "memory problems".

There are sometimes human problems, such as thinking one is capable of coding without understanding the (basic programming) concept of a pointer. But that's because the human's dumb, not a language problem. (This argument also sometimes comes from those who do understand basic programming, but are only familiar with C++98.)

> Thousands of high quality libraries a JVM that is a marvel of engineering after 20 years

I reluctantly have to agree. :)

"But that's because the human's dumb, not a language problem."

If everything is the programmer's fault for being dumb, then Brainfuck is an excellent system language.

> Every time I see something like this I roll my eyes... C++ doesn't have any "memory problems".

You can choose which report you would prefer: Microsoft's, Google's 65%, ... I'm sure they just hired bad developers that don't understand pointers.

Sure, human problem, but if no human can use the tool correctly, then surely there is some problem with it. And no, that doesn't mean that memory unsafe languages don't have a place, but we really should have a very good reason for going down that road.

I understand pointers, yet I can’t be trusted never to make a mistake with them. “Each mistake will go uncaught and become an unpredictable catastrophe” is a language problem when your target audience is made of meat.

> C++ doesn't have any "memory problems"

Well, every time I see someone claim this, I roll my eyes.

It must be hard being perfect. The rest of us will keep looking for solutions for mortals.

Reply on news.ycombinator.com