61–70 of 437 posts
I've been working in .NET/C# for the past few years, and while I'm happy with it, I still think the JVM/Java are the best ecosystem overall I've worked in. It's amazing how many things the Java ecosystem gets right that .NET gets wrong. For instance, Java introduced the fork/join pool for work stealing and recommended it for short-lived tasks that decomposed into smaller tasks. .NET decided to simply add work-stealin…
Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby. Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine. Java memory management seems weird from a Unix Philosophy POV…
> Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby. Fastest at what, exactly?
With the JVM you basically outsource all the work you need to do in C/C++ to optimize memory management and a typical developer is going to have a hell of a time beating it for non-trivial, heterogenous workloads. The main disadvantage (at least as I understand) is the memory overhead that Java objects incur which prevent it from being fully optimized the way you can with C/C++.
Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby. Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine. Java memory management seems weird from a Unix Philosophy POV…
This is something I greatly value with the recent changes to Java. They found a great way to include sealed classes, switch expression, project Loom, records that feels at home in the existing Java syntax.
The tooling with heap dump analyzers, thread dump analyzers, GC analyzers is also top notch.
Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby. Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine. Java memory management seems weird from a Unix Philosophy POV…
Not anymore, the competition is doing much better these days.
Just going to remind y'all of this: https://www.joelonsoftware.com/2005/12/29/the-perils-of-java... I went to a Java school. I remember my operating systems class involved writing simulated OS code in Java (for example, round robin for context switching). The argument was that it would be easier to understand the algorithms if the hardware complexities were minimized. I understand that sentiment, but I don't think Ja…
A lot of the arguments Joel makes in that article also apply to Python, and pretty much any other higher-level language that doesn't make you think about pointers. Ironically, he points out the Google had a great leap over Microsoft with MapReduce, which was built in Java.
Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby. Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine. Java memory management seems weird from a Unix Philosophy POV…
> Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff. The GC story is just great, however. Pretty much the best you can get in the entire ecosystem of managed-memory languages. You have different GC algorithms implemented, and you can pick and tune the one that best fits your use-case. The elephant in the room is of course ZGC, w…
It is not feasible under the JVM type system. Even once Valhalla gets released it will carry restrictions that will keep that highly impractical.
It's much less needed with ZGC but even the poster child C# from the GC-based language family when it comes to writing allocation-free and zero-cost abstraction code presents challenges the second you need to use code written by someone who does not care as much about performance.
The java.net.Inet4Address and Inet6Address could be more lightweight. For a simple IPv4 address normally representable using 4 bytes/ 32 bits Java uses 56 bytes. The reason for it is Inet4Address object takes 24 B and the InetAddressHolder object takes another 32 B. The InetAddressHolder can contain not only the address but also the address family and original hostname that was possibly resolved to the address. For a…
For my part, most of the Java code that I have written that needs to use IP addresses needs somewhere between 1 and 10 of them, so I'd never notice this overhead. If you want to write, like, a BGP server in Java I guess you should write your own class for handling IP addresses.
I've been working in .NET/C# for the past few years, and while I'm happy with it, I still think the JVM/Java are the best ecosystem overall I've worked in. It's amazing how many things the Java ecosystem gets right that .NET gets wrong. For instance, Java introduced the fork/join pool for work stealing and recommended it for short-lived tasks that decomposed into smaller tasks. .NET decided to simply add work-stealin…
[flagged]
Here's an article from 5 years ago:
https://medium.com/criteo-engineering/net-threadpool-starvat...
But does citing a more-recent article matter to you? Probably not. A source being 13 years old only matters if something relevant has changed since then, and you certainly couldn't be bothered to point out any relevant change to support your otherwise fallacious and misleading comment.
What actually amazes me most about this is that people in .NET seem to want to blame the person writing sync-over-async code like they are doing something wrong, even going so far as to call it an "anti-pattern", when in reality it is the fault of poor decision-making from the .NET team to fold work-stealing into the global thread queue. The red-blue function coloring problem is real, and you can't make it go away by pretending everyone can just rewrite all their existing synchronous code and no other solution is needed.
If all you know is one ecosystem, then it seems you are susceptible to a form of Stockholm syndrome when that ecosystem abuses you.
I've been working in .NET/C# for the past few years, and while I'm happy with it, I still think the JVM/Java are the best ecosystem overall I've worked in. It's amazing how many things the Java ecosystem gets right that .NET gets wrong. For instance, Java introduced the fork/join pool for work stealing and recommended it for short-lived tasks that decomposed into smaller tasks. .NET decided to simply add work-stealin…
[flagged]