Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JVM Options Explorer

chriswhocodes.com

Post reply on HN
Print view View original

91–100 of 122 posts

Re: JVM Options Explorer

#91

Post by gf000 »

iamcalledrob wrote: post #89
Geezus_42 wrote: post #35

Earlier quoted context omitted.

Sounds to me that deepsun and I are in agreement that an error message should tell you what the actual error was. I.E. ERROR: TLS handshake failed: certificate chain unverified

People give Go's error handing a lot of flak, but I personally love the errors that come out of a quality codebase. Just like your example: single line, to the point and loggable. e.g. writing foo.zip: performing http request (bar.com): tls: handshake: expired certificate (1970-01-01) Exceptions with stack traces are so much more work for the reader. The effort of distilling what's going on is pushed to me at "runtim…

What?

What you write makes zero sense, see my comment here: https://news.ycombinator.com/item?id=47750450

And come on, skipping 5 lines and only reading the two relevant entries is not "much work". It's a feature that even when developers eventually lazied out, you can still find the error, meanwhile you are at the mercy of a dev in go (and due to the repeating noisy error handling, many of the issues will fail to be properly handled - auto bubbling up is the correct default, not swallowing)

Re: JVM Options Explorer

#92

Post by gf000 »

kitd wrote: post #32
deepsun wrote: post #25

Earlier quoted context omitted.

I hate when tools only produce generic "TLS Handshake failed" instead of saying why exactly it failed, where is the problem.

This is the kind of scenario that is served better by Go/C-style error values than exceptions. Error values facilitate and encourage you to log what you were doing at the precise point when an error occurs. Doing the same with exceptions idiomatically often requires an exception hierarchy or copious amounts of separate try/catches. The difference really becomes apparent when trying to debug a customer's problem at 3a…

This couldn't be further from the truth.

There is no ecosystem I would choose over Java when it comes to observability and it's not even close.

Good luck finding your segfault, oom, race condition or just simply lazy logging culture bug with a C/go codebase at 3am.

I will happily see my proper stack trace, heap dump, or connect directly to prod with a debugger with basically no performance penalty.

Re: JVM Options Explorer

#93

Post by gf000 »

jim33442 wrote: post #76
rvz wrote: post #23

All of that configuration and it will always be less efficient than Rust, or even Golang. This is why lots of engineers waste time fiddling with options to tune the JVM and still require hundreds of replicated micro-services to "scale" their backends and losing money on AWS and when they will never admit the issue is the technology they have chosen (Java) and why AWS loves their customers using inefficient and expens…

I still don't get why Java is the only language that needs the heap to be carefully tuned. Like it hogs some memory at start, crashes if you go above a certain amount, and doesn't return memory to the OS when GC'd. Even Python and JS don't have those problems.

You don't have to do anything, it just works.

But eventually someone gonna write the goddamn whole of AWS or Alibaba in the language where you have machines with TBs of heaps (yeah, you read that right), where most other managed languages would just give up instantly - and then you may have to add 2-3 parameters to make it actually run properly in these extreme conditions.

Re: JVM Options Explorer

#94

Post by iamcalledrob »

gf000 wrote: post #91
iamcalledrob wrote: post #89

Earlier quoted context omitted.

People give Go's error handing a lot of flak, but I personally love the errors that come out of a quality codebase. Just like your example: single line, to the point and loggable. e.g. writing foo.zip: performing http request (bar.com): tls: handshake: expired certificate (1970-01-01) Exceptions with stack traces are so much more work for the reader. The effort of distilling what's going on is pushed to me at "runtim…

What? What you write makes zero sense, see my comment here: https://news.ycombinator.com/item?id=47750450 And come on, skipping 5 lines and only reading the two relevant entries is not "much work". It's a feature that even when developers eventually lazied out, you can still find the error, meanwhile you are at the mercy of a dev in go (and due to the repeating noisy error handling, many of the issues will fail to be…

Different strokes for different folks.

The Go errors that I encounter in quality codebases tend to be very well decorated and contain the info I need. Much better than the wall of text I get from a stack trace 24 levels deep.

Re: JVM Options Explorer

#95

Post by gf000 »

iamcalledrob wrote: post #94
gf000 wrote: post #91

Earlier quoted context omitted.

What? What you write makes zero sense, see my comment here: https://news.ycombinator.com/item?id=47750450 And come on, skipping 5 lines and only reading the two relevant entries is not "much work". It's a feature that even when developers eventually lazied out, you can still find the error, meanwhile you are at the mercy of a dev in go (and due to the repeating noisy error handling, many of the issues will fail to be…

Different strokes for different folks. The Go errors that I encounter in quality codebases tend to be very well decorated and contain the info I need. Much better than the wall of text I get from a stack trace 24 levels deep.

Apples to oranges.

Quality java code bases also have proper error messages. The difference is that a) you get additional info on how you got to a given point which is an obviously huge win, b) even if it's not a quality code base, which let's be honest, the majority, you still have a good deal of information which may be enough to reconstruct the erroneous code path. Unlike "error", or even worse, swallowing an error case.

Re: JVM Options Explorer

#96

Post by metaltyphoon »

msla wrote: post #69
metaltyphoon wrote: post #31

Earlier quoted context omitted.

I… didn’t think this makes sense :)

It makes perfect sense: Rust compilers will never beat a human at scheduling every single opcode perfectly based on the deepest microarchitectural analysis short of decapping the chip and breaking out the ol' electron microscope. Whether it's worthwhile to be that efficient over a whole program, as opposed to a preternaturally tight compute kernel, is definitely questionable.

> scheduling every single opcode perfectly based on the deepest microarchitectural

Is that even possible knowing OOE+ branch execution and many other CPU tricks?

Re: JVM Options Explorer

#97

Post by Geezus_42 »

well_ackshually wrote: post #41
Geezus_42 wrote: post #17

Earlier quoted context omitted.

As a sysadmin, not developer, I hate Java almost as much as Windows. The error messages Java apps produce are like coded messages that you have to decipher. I.E. Instead of " TLS Handshake failed" it will be something like "ERROR: PKIX failed". So now I have to figure out that PKIX is referring to PKI and it would make too much sense to provide the domain that failed. Instead I have to play the guessing game.

So your issue isn't with Java, just with shit error messages and devs clearing the exception stack.

I would believe you, except that it is a problem with every Java app I have supported, and there are people in this very thread defending it.

I do not want a stack trace unless I specifically request it. I am not a Java developer, 10 pages in less showing names of packages I don't even know what they are is not useful. It just muddies the water so that it's much harder to make sense of and spot the relevant line; assuming there is a line that actually states the error. I shouldn't need to know what all those packages are in order to figure out why Confluence crashed again or stopped sending emails.

Re: JVM Options Explorer

#98

Post by Geezus_42 »

gf000 wrote: post #92
kitd wrote: post #32

Earlier quoted context omitted.

This is the kind of scenario that is served better by Go/C-style error values than exceptions. Error values facilitate and encourage you to log what you were doing at the precise point when an error occurs. Doing the same with exceptions idiomatically often requires an exception hierarchy or copious amounts of separate try/catches. The difference really becomes apparent when trying to debug a customer's problem at 3a…

This couldn't be further from the truth. There is no ecosystem I would choose over Java when it comes to observability and it's not even close. Good luck finding your segfault, oom, race condition or just simply lazy logging culture bug with a C/go codebase at 3am. I will happily see my proper stack trace, heap dump, or connect directly to prod with a debugger with basically no performance penalty.

That is great for you as a developer. As a sysadmin supporting other people's crap, stack traces and heap dumps are useless beyond forwarding them to the vendor.

Re: JVM Options Explorer

#99

Post by Geezus_42 »

appplication wrote: post #33
thunky wrote: post #28

Earlier quoted context omitted.

Sounds like you'd both be happy if the tool produced both.

This is why stack traces exist. But I agree Java seems to not really have a culture of “make the error message helpful”, but instead preferring “make the error message minimal and factual”. For what it’s worth, the rise of helpful error messages seems to be a relatively new phenomenon the last few years.

A stack trace that is >10 pages in less is not what I would call minimal.

Re: JVM Options Explorer

#100

Post by Geezus_42 »

gf000 wrote: post #95
iamcalledrob wrote: post #94

Earlier quoted context omitted.

Different strokes for different folks. The Go errors that I encounter in quality codebases tend to be very well decorated and contain the info I need. Much better than the wall of text I get from a stack trace 24 levels deep.

Apples to oranges. Quality java code bases also have proper error messages. The difference is that a) you get additional info on how you got to a given point which is an obviously huge win, b) even if it's not a quality code base, which let's be honest, the majority, you still have a good deal of information which may be enough to reconstruct the erroneous code path. Unlike "error", or even worse, swallowing an error…

> reconstruct the erroneous code path

This is only useful to the developers who should be fixing the bug. Us sysadmins need to know the immediate issue to remediate while the client is breathing down our neck. Collect all the stack traces, heap dumps, whatever you want for later review. Just please stop writing them to the main log where we are just trying to identify the immediate issue and have no idea what all the packages those paths point to do. It just creates more text for us to sift through.

Post reply on HN