Earlier quoted context omitted.
Same question for .net or C# Why should anyone use it over Java? Ms is hostile towards its developers, it creates new versions of things, deprecates previous versions, uses confusing naming for newer versions.. etc.
Because your employer is dick-deep in Microsoft psychosis. I've been a .NET dev for a decade now. It's perfectly serviceable, but I wouldn't say I truly love the language anymore, but I would take it over Java any day. Entity Framework and LINQ are gifts from the Gods. I have never used an ORM that even comes remotely close. Also, C# is big in the gaming world. I am working on a game right now, and I was not impresse…
Java 27
291–300 of 427 posts
Re: Java 27
#292Earlier quoted context omitted.
> the situation is very much the opposite when it comes to Rust. It isn't, and the problem isn't Rust specifically, but all low-level languages. They can offer very good performance (often better than Java) when small. But as they evolve over time, or are very large to begin with, they become much harder to keep performant. This is for pretty fundamental constraints of low-level language that I mention in another com…
> Time and again we see Rust or C++ programs spend 30-50% on memory management. 30-50% of what?
Re: Java 27
#293Earlier quoted context omitted.
Go has null pointer dereference problem. Rust is too low-level for typical enterprise app where requirements changes twice a day. You end up spending time and tokens fighting with borrow checker. C# is MS product, which is no-go for some folks. Kotlin probably would be the answer.
> Go has null pointer dereference problem. Which Java famously does not have. > Rust is too low-level for typical enterprise app where requirements changes twice a day. You end up spending time and tokens fighting with borrow checker. In my experience, you do not spend tokens fighting with the borrow checker anymore, newer models are smarter. But it might not be ideal for a lot of CRUD applications. > C# is MS produc…
Have you worked on large (>500KLOC) codebases with an agent? Not only do you have to be an expert at the language, but even if you're lucky and everything is fine, Java code is likely to be particularly fast by comparison, because the agents aren't very good at manual optimisation, especially as the code grows (they're even worse than humans at that, and humans aren't great at manual optimisation of large codebases, either, which is one of the problems the JVM set out to solve; in fact, agent-written code in a low-level language gets pretty slow well below that size). Oh, and the long build times certainly don't help.
Re: Java 27
#294Knock knock Who's there? long pause Java
Re: Java 27
#295Re: Java 27
#296C# dev here: it’s amazing how different this is from a Microsoft release. First off, Oracle are doing versions at approximately twice the cadence. But also, and I’m guessing this is a function of the much larger Java audience: things rarely get two preview versions in a proper release. Updates in beta versions, yes, all the time. It also feels like Microsoft are bundling a lot more into the platform and leaving less…
Re: Java 27
#297Earlier quoted context omitted.
I ported a moderate sized java project to golang. Test suite runs order of magnitude faster now. There isn't much change in terms of the architecture. Pretty much the same algos and data structures. The whole dev tooling runs on a 16 gb mac without swapping now. I used vs code for both
Isn't this mostly about java cold start costs? It might be that other people are optimizing for steady-state performance, not transient startup performance.
Java tooling taking up a lot of ram was a major motivation for me. I have done a lot of Scala as well. I don't think either Java or Scala in the real world beat go on performance for most cases. I don't doubt that in some cases jvm can do better but at least before Valhalla delivers all the promises, in real world, I am doubtful.
I have been a Java/Scala user almost for the majority of my career. I doubt I would pick jvm over golang going forward though. Also not having to deal with OOP is a plus.
Re: Java 27
#298C# dev here: it’s amazing how different this is from a Microsoft release. First off, Oracle are doing versions at approximately twice the cadence. But also, and I’m guessing this is a function of the much larger Java audience: things rarely get two preview versions in a proper release. Updates in beta versions, yes, all the time. It also feels like Microsoft are bundling a lot more into the platform and leaving less…
Seems about right
Re: Java 27
#299Earlier quoted context omitted.
and the costs they are willing to pay. Go/Rust just kill everything else (except maybe C++) for performance and resource needs. JVM requires so many resources just to run small apps.
Quite the opposite, and the reason is that you can't extrapolate from small programs to large ones. Low-level languages (like C++) incur some significant overheads as they grow large (because of essential constraints of low-level languages that prevent them from doing certain optimisations that matter mostly in large programs), and these are exactly the overheads the JVM is designed to reduce. In small or short-lived…
Caffeine's next release has roughly 25% higher read throughput, with unchanged write throughput, thanks to fixing a false sharing mistake. That won't be visible in real workloads, but is fun nonetheless (500M reads/s on 8 cores).
Re: Java 27
#300Earlier quoted context omitted.
We have a java monorepo of relatively large size and sophistication, driving our entire fintech, and I haven't seen a NPE for years. Use NullAway and it basically makes the problem go away. Our application won't build if it detects a potential NPE.
Congratulations. You've added another build tool and sprinkled your code with ugly annotations and ifs and Optional Optional.of(x).map(y) all over the place to get the same thing you'd get by moving to Kotlin. I get it why this seems like a less drastic change, but this saddens me. Kotlin solves more issues with the type system (smart casts, reified types, immutability by default), without sacrificing readability. Un…