Live data from Hacker News

IT Runs on Java 8

veekaybee.github.io

291–300 of 556 posts

Re: IT Runs on Java 8

#291
post #85

The funny thing is that from a purely technological point of view, Java (even the 5-year-old Java 8 and certainly recent versions) is far ahead of most other stuff hyped on HN (as well as less hyped stuff). Virtually no other platform comes close to that combination of state-of-the-art optimizing compilers, state-of-the-art GCs, and low-overhead in-production profiling/monitoring/management. And much of the cutting-e…

Great points, but it's actually much simpler than that: if you want static types, you have already eliminated the majority of HN darlings (JS, Python, and Ruby). Where do you? Most developers turn to C++, Java, or C# (not Haskell or F#, for example), and of these, Java and C# are both great for productivity and not daunting for someone just starting out, unlike C++. There was a period after 200x where developers mana…

> Great points, but it's actually much simpler than that: if you want static types, you have already eliminated the majority of HN darlings (JS, Python, and Ruby).

Well, if you ignore mypy and consider TypeScript distinct enough from JS to not count, sure, though TS is if anything more of an HN darling than bare JS (Really, none of those languages has been an HN or developer community darling in years, though Python—due to ML and data science—is less horrible uncool than Ruby and JS right now. (And, yeah, Ruby is left out of the “but I have static type checking available” list...till Sorbet is available later this year.)

> Most developers turn to C++, Java, or C#

I'd be surprised if more than half (most) developers using static typing use those languages and not others outside that set.

Re: IT Runs on Java 8

#292
post #207

Earlier quoted context omitted.

I know little about EE (and I'm certainly not speaking for anyone but myself), but I believe Java EE has lost dominance not because of any corporate decision, but because it simply started losing ground to unstandardized open source projects [1], as opposed to EE's JCP. So people who liked EE wanted to ditch the slow-moving JCP in favor of a faster process, and one question was whether the new project will be able to…

> You also need to realize that it wasn't a negotiation between Oracle and some grassroot project, but among multi-billion-dollar corporations, some of whom have fought Java standards for over a decade, so the process was both legally and politically complex. Yes exactly, I think that is what makes if feel like not the safest choice for many companies.

Java EE has not been the preferred choice for many companies long before this issue, which, I guess, is at least part of the reason why Oracle gave up those projects. I think Spring is the leader, but I am really not too familiar with that entire domain.

Re: IT Runs on Java 8

#293
post #273
post #85

The funny thing is that from a purely technological point of view, Java (even the 5-year-old Java 8 and certainly recent versions) is far ahead of most other stuff hyped on HN (as well as less hyped stuff). Virtually no other platform comes close to that combination of state-of-the-art optimizing compilers, state-of-the-art GCs, and low-overhead in-production profiling/monitoring/management. And much of the cutting-e…

Poor start-up time, terrible application bloat, uninspiring language with poor concurrency support, massive RAM requirements, everything XML, complex tuning required, what a nightmare. No wonder the world is running towards Python and serverless as fast as they can...

Then they discover that even though Python is quicker to develop with, it actually runs much slower and has poor threading support. Since async only gets you so far, you try multiprocessing. It turns out running all those Python worker processes actually takes up more memory and CPU than the equivalent Java app...

Also, most of the things you complain about are not Java: they are the fault of JEE (aka J2EE) and "app servers."

Re: IT Runs on Java 8

#294

Earlier quoted context omitted.

It takes a lot of power to push something that large. A lot of brain power to grock the ecosystem. Outside of the Java bubble, the view is quite a bit different. All that sophistication looks like a wasted effort. Take something as simple as admining the garbage collector. Java has a big selection of GCs, and each has their bunch of knobs for tuning. And you have to pay attention to that stuff. After working with Go…

Funnily enough, Go just chose to solve the problem the other way around: While JVM tackled GC with the code equivalent of lightsaber-equipped drones, Go‘s GC is almost embarrassingly simple in comparison (although it‘s pretty decent by now). The major difference is that the whole Go language and stdlib is simply written around patterns that avoid allocations almost magically. The simplicity of the Reader and Writer c…

Exactly. Go is benefiting from years of hard lessons learned in other stacks such as Java. Having super experienced GC builders involved early on resulted in a language and libraries that work much more synergisticaly with the GC.

It's better to dodge a problem, than to have a baked in problem that requires lots of really smart people to make work arounds.

Re: IT Runs on Java 8

#295
post #85

The funny thing is that from a purely technological point of view, Java (even the 5-year-old Java 8 and certainly recent versions) is far ahead of most other stuff hyped on HN (as well as less hyped stuff). Virtually no other platform comes close to that combination of state-of-the-art optimizing compilers, state-of-the-art GCs, and low-overhead in-production profiling/monitoring/management. And much of the cutting-e…

Great points, but it's actually much simpler than that: if you want static types, you have already eliminated the majority of HN darlings (JS, Python, and Ruby). Where do you? Most developers turn to C++, Java, or C# (not Haskell or F#, for example), and of these, Java and C# are both great for productivity and not daunting for someone just starting out, unlike C++. There was a period after 200x where developers mana…

> eliminated the majority of HN darlings (JS, Python, and Ruby)

Those were the darlings ten years ago (along with CoffeeScript and Clojure). The pendulum has swung back towards types and now the hip ones are Go, Kotlin, Swift, TypeScript, and (to a lesser extent) Haskell, Hack, Reason, and OCaml.

> Java, UML, SQL, and everything else that was used in 199x.

There was the whole no-SQL fad, but lately, even here, I see a lot of people re-discovering and advocating the relational model. Postgres seems to be hotter than MongoDB today.

Much of what is good about Java lives on in Kotlin and Swift. I agree it is unappreciated with today's eyes. Few remember that it was Java that introduced much of the world to garbage collection, memory safety (!), optimizing JIT compilation, runtime reflection, dynamic loading, high quality static analysis IDEs, etc.

UML is garbage. A visual language designed by non-artists with no aesthetic expertise. It deserves to be forgotten.

Re: IT Runs on Java 8

#296
post #44

The HN front page is similar to any community. For example, a car site's homepage will be listing the latest supercars, expensive turbos, rims, whatever... while most readers are driving a $30,000 Civic. The best & brightest in tech are working with the best tools on the biggest problems, and that's what gets talked about, regardless of what the mass is doing.

Exactly right.

Sites like HN and Reddit are aggregators in the literal sense. They take a large volume of data points and reduce it to a select few that get shown to most users. that aggregation function is "most interesting", not "most representative". Those are direct opposites of each other: interesting is almost by definition unusual.

I always find the subreddits that try to explicitly not target polar extremes the most fascinating from a sociology perspective. For example, this photo of a sink faucet is the most mildly interesting submission of the past year:

https://www.reddit.com/r/mildlyinteresting/comments/9ykoe4/t...

Does that mean all other submissions were less interesting, or less mild?

Re: IT Runs on Java 8

#297
post #140
post #85

The funny thing is that from a purely technological point of view, Java (even the 5-year-old Java 8 and certainly recent versions) is far ahead of most other stuff hyped on HN (as well as less hyped stuff). Virtually no other platform comes close to that combination of state-of-the-art optimizing compilers, state-of-the-art GCs, and low-overhead in-production profiling/monitoring/management. And much of the cutting-e…

This. Technically there is nothing I don't like about JVM right now, everything that seems impossible 15 years ago is now solved. AOT used to be bag of hurt with GCJ ( I know I could use Excelsior, not sure if it was free in my time though ), but now even that will be an supported option from Graal. Java the languages still isn't pretty, but it has been much improved. OpenJDK is GPL and apart form the trademark ( ? )…

Support for native code is very bad. The JNI is a pain to use and very slow, IPC is often faster. High performance numerical code often suffers because of poor vectorization. Not to mention tuning the JVM is often needed for critical tasks. Modern GC'd languages like Go have much better memory footprints and the penalty of fast numerical code is much smaller.

Re: IT Runs on Java 8

#298
post #85

The funny thing is that from a purely technological point of view, Java (even the 5-year-old Java 8 and certainly recent versions) is far ahead of most other stuff hyped on HN (as well as less hyped stuff). Virtually no other platform comes close to that combination of state-of-the-art optimizing compilers, state-of-the-art GCs, and low-overhead in-production profiling/monitoring/management. And much of the cutting-e…

It takes a lot of power to push something that large. A lot of brain power to grock the ecosystem. Outside of the Java bubble, the view is quite a bit different. All that sophistication looks like a wasted effort. Take something as simple as admining the garbage collector. Java has a big selection of GCs, and each has their bunch of knobs for tuning. And you have to pay attention to that stuff. After working with Go…

Java HotSpot's garbage collector is significantly better for most workloads than that of Go, because it takes throughput into account, not just latency. Mike Hearn makes the point at length in this article: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...

I predict that over time Go's GC will evolve to become very similar to the modern GCs that Java HotSpot has. Not having generational GC was an interesting experiment, but I don't think it's panned out: you end up leaning really heavily on escape analysis and don't have a great story for what happens when you do fail the heuristics and have to allocate.

Re: IT Runs on Java 8

#299

Earlier quoted context omitted.

> low-overhead in-production profiling/monitoring/management This is a joke, right? The management overhead for the JVM in production environments is huge. It's really hard to get it right.

Not sure what you are talking about. Can you give me some examples?

Tuning the heap size, GC tuning, etc. are often needed to avoid huge GC spikes out of the box. Not to mention performance is pretty meh compared to something like Go for applications where non-trivial compute is needed.

Re: IT Runs on Java 8

#300

Earlier quoted context omitted.

It takes a lot of power to push something that large. A lot of brain power to grock the ecosystem. Outside of the Java bubble, the view is quite a bit different. All that sophistication looks like a wasted effort. Take something as simple as admining the garbage collector. Java has a big selection of GCs, and each has their bunch of knobs for tuning. And you have to pay attention to that stuff. After working with Go…

Funnily enough, Go just chose to solve the problem the other way around: While JVM tackled GC with the code equivalent of lightsaber-equipped drones, Go‘s GC is almost embarrassingly simple in comparison (although it‘s pretty decent by now). The major difference is that the whole Go language and stdlib is simply written around patterns that avoid allocations almost magically. The simplicity of the Reader and Writer c…

The byte buffers that Go's Reader reads from and that Go's Writer writes into cannot in general be allocated on the stack because they are considered to escape. Because Reader and Writer are interfaces, calls are dispatched virtually, so escape analysis cannot always see through them. This is now fixed for simple cases in Go, but only very recently: https://github.com/golang/go/issues/19361

Ironically, Java HotSpot handles the use case of Reader and Writer better than Go does, since when it's not able to allocate on the stack it has fast allocation due to the use of a generational GC with bump allocation in the nursery. By virtue of the fact that it's a JIT, HotSpot can also do neat things like see that there's only one implementation of an interface and thereby devirtualize calls to that interface (allowing for escape analysis to kick in better), something Go cannot do in general as it's an AOT compiler.

Post reply on HN