Hacker News Reader

Comment by another_twist | Hacker News Reader

Go is definitely full of these issues. Java has pretty good perf out of the box due to JIT. The libs may be old but they do their jobs really well. Some common ones like Guava are updated as new features become available. Tbh the collections being mutable isnt really an issue since it gets the job done and reasoning about these things isnt that hard. However I do prefer immutability wherever I can get it.

View on HN

YMMV but I find Java perf less even with the JIT than OcAml/F# .NET/etc for tuned code which generally is what matters when performance is a concern. The auto-boxing, lack of proper generics, etc really make it hard to do re-use in a performant way especially around math like apps, especially if they use any of the "Big" boxing types. There's too much heap allocation you can't avoid. Better than say Node/Python but even F# in .NET will generally do better here in my testing with inline templating/stack types/spans/etc.

Languages with immutability/lazy seq/etc support built in can be tuned faster than a library (compiler help around sequences/streams rather than pure library based ones), and again the lack of stack types can make some of these immutable collections much slower/take up more memory than other language targets. There's algorithms I can't use in Java which I can use in .NET/Rust/C++/etc without memory penalty or lots of unsafe/hacky code.

Why are all java apps super slow like Intellij and require you to play around with heap memory with things like xmx min max etc? I write Java code for a living and it's so dependent on frameworks to do many basic things where you can't really reason about the code. Subtle bugs can come from mutability here, nullability there, hidden state in another place and most coding styles rely on these and use them because it is so easy to do. It's possible, but not idiomatic to write immutable stateless code in Java. Coding in Java is now much more pleasant with records, optionals, sealed interfaces and streams, but it's interweaved with old coding styles so that it negates most benefits of the new patterns

> Tbh the collections being mutable isnt really an issue since it gets the job done and reasoning about these things isnt that hard.

Have you worked in language with immutable collections by default? It's night and day -- no more defensive copies, no more weird ImmutableList wrappers (Guava) which will (interface-wise) say they're mutable but will throw at runtime, no worrying about multithreading, cheap subsequences, etc. etc.

The difference is so stark that I would literally choose a worse[0] language(!) over a better one if it had immutable collections by default.

EDIT: Since you mentioned Java in a sibling comment -- give Scala a try and try working with the collections there.

[0] Within reason, of course :)

Reply on news.ycombinator.com