3 ms·

I've never been a fan of Java due to the GC and the boilerplate and runtime overhead (time but also space) that come with it. But I've always had respect for it

I've never been a fan of Java due to the GC and the boilerplate and runtime overhead (time but also space) that come with it. But I've always had respect for it because it felt so minimal and consistent in its own way, bulky but solid kinda like a BMW car. Now that functional stuff and instanceof fluff is something else. I don't like it either.

kaba0 4y ago
Unless you only prefer low-level languages, Java’s runtime is anything but bulky. It is one of the fastests runtimes out there, so runtime overhead is relative.
- jstimpfle 4y ago
  The runtime might be an efficient implementation of the language, but the language itself (given GC and still no custom value types AFAIK) implies a distinct bulkiness compared to what I am used to. This is as I said my personal feeling when using the language, and is based on the number of keystrokes I've needed in the past to get from A to B, as well as the runtime overhead (memory overhead for many small objects, add in GC and chances are it's very noticeable time-wise too). It much depends on the task of course. My biggest project in Java was a SAT solver years ago, and millions of little clauses did not sit well with it at all. I ended up changing the data organization internally. My first attempt, the natural AOS would have been also the best choice performance-wise in C, but in Java it choked the GC. I had to switch it around to SOA which was quite awkward but it reduced the number of objects from millions to a small constant. Also thinking of the number of lines of code running for JIT, GC, whatever... in the background all the time...
  - kaba0 4y ago
    I get that, and sure enough for certain workloads it is definitely not ideal. But I think you would be surprised at how fast it can actually be. In projects where you can’t get away from object allocation (due to it being less deterministic for example) with some clever trick like arenas and the like, chances are the GC will be actually much faster than malloc-ing them all — and while it may not sit well with you, GC running in the background just amortizes the cost of each deallocation to basically zero time overhead (of course at the cost of memory overhead). But I’m not trying to dismiss your experience or anything, the JVM has its place and of course there are plenty of use cases where it is not the best fit at all.
    - jstimpfle 4y ago
      I said it felt (to me) "bulky but solid kinda like a BMW car" which I think is a fair criticism and also a statement of respect, so what you tripped you up? And that statement was not about the allocation time. But my understanding is that deallocation (GC) is not amortizable to constant for long-lived objects. We can probably agree that having to code a separate class (with object overhead) to represent each little tuple of 2 integers or so, is bulky - programming-wise but also concerning the memory overhead (and possibly GC overhead). Programming in C does not imply using malloc() to allocate individual objects. This is a bad practice.

kaba0 4y ago

Unless you only prefer low-level languages, Java’s runtime is anything but bulky. It is one of the fastests runtimes out there, so runtime overhead is relative.

jstimpfle 4y ago
The runtime might be an efficient implementation of the language, but the language itself (given GC and still no custom value types AFAIK) implies a distinct bulkiness compared to what I am used to. This is as I said my personal feeling when using the language, and is based on the number of keystrokes I've needed in the past to get from A to B, as well as the runtime overhead (memory overhead for many small objects, add in GC and chances are it's very noticeable time-wise too). It much depends on the task of course. My biggest project in Java was a SAT solver years ago, and millions of little clauses did not sit well with it at all. I ended up changing the data organization internally. My first attempt, the natural AOS would have been also the best choice performance-wise in C, but in Java it choked the GC. I had to switch it around to SOA which was quite awkward but it reduced the number of objects from millions to a small constant. Also thinking of the number of lines of code running for JIT, GC, whatever... in the background all the time...
- kaba0 4y ago
  I get that, and sure enough for certain workloads it is definitely not ideal. But I think you would be surprised at how fast it can actually be. In projects where you can’t get away from object allocation (due to it being less deterministic for example) with some clever trick like arenas and the like, chances are the GC will be actually much faster than malloc-ing them all — and while it may not sit well with you, GC running in the background just amortizes the cost of each deallocation to basically zero time overhead (of course at the cost of memory overhead). But I’m not trying to dismiss your experience or anything, the JVM has its place and of course there are plenty of use cases where it is not the best fit at all.
  - jstimpfle 4y ago
    I said it felt (to me) "bulky but solid kinda like a BMW car" which I think is a fair criticism and also a statement of respect, so what you tripped you up? And that statement was not about the allocation time. But my understanding is that deallocation (GC) is not amortizable to constant for long-lived objects. We can probably agree that having to code a separate class (with object overhead) to represent each little tuple of 2 integers or so, is bulky - programming-wise but also concerning the memory overhead (and possibly GC overhead). Programming in C does not imply using malloc() to allocate individual objects. This is a bad practice.