Live data from Hacker News

IT Runs on Java 8

veekaybee.github.io

491–500 of 556 posts

Re: IT Runs on Java 8

#491
post #478

Earlier quoted context omitted.

> but is even less intrusive regarding the necessary code-changes to existing synchronous code. Yes. All existing blocking IO code will become automatically fiber-blocking rather than kernel-thread-blocking, except where there are OS issues (file IO; Go has the same problem). Fibers and threads may end up using the same API, as they're just two implementations of the same abstraction. > Does it impact things from the…

> a fiber that tries to block inside a native call, i.e., when there is a native frame on the fiber's stack, will be "pinned" and block the underlying kernel thread. Doesn't this boil down to the native function blocking the thread? How about the C API/ABI of JNI? Will there be additions there for better supporting concurrency (i.e. not simply blocking)? Or can that be handled today, with something akin to callbacks?

If the native routine blocks the kernel thread, it blocks, and if not, it doesn't. While something could hypothetically be done about blocking native routines, we don't see it as an important use case. Calling blocking native code from Java is quite uncommon. We've so far identified only one common case, DNS lookup, and will address it specifically.

Re: IT Runs on Java 8

#492
post #491

Earlier quoted context omitted.

> a fiber that tries to block inside a native call, i.e., when there is a native frame on the fiber's stack, will be "pinned" and block the underlying kernel thread. Doesn't this boil down to the native function blocking the thread? How about the C API/ABI of JNI? Will there be additions there for better supporting concurrency (i.e. not simply blocking)? Or can that be handled today, with something akin to callbacks?

If the native routine blocks the kernel thread, it blocks, and if not, it doesn't. While something could hypothetically be done about blocking native routines, we don't see it as an important use case. Calling blocking native code from Java is quite uncommon. We've so far identified only one common case, DNS lookup, and will address it specifically.

Nice. So going 100% async is a real possibility?

Re: IT Runs on Java 8

#493

Earlier quoted context omitted.

Hacker News ranks at #959 in the US. It didn’t get that rank from just being geared toward startups with Tier 1 engineers. Look on the front page right now and see how many stories are about startups. That didn’t change in the last five years. It’s always been about technology in general. HN’s front page 10 years ago: https://news.ycombinator.com/front?day=2009-05-10 HN’s front page 5 years ago https://news.ycombinat…

We’re both making points based off anecdotal experience, so who knows. I have been a reader for the last 7 or 8 years, but my experience is just one subjective data-point. Having said that, the most apparent change to me is in the tone and substance of the comments rather than the front page. And it isn’t a huge change. Just noticeable for me.

You don’t have to use anecdotal experience. You can use the same link format for any day that Hacker News existed and see the same thing.

Re: IT Runs on Java 8

#494
There is nothing that wrong with Java 8, honestly.

Have we done better since? Debatable, but maybe. But there certainly hasn't been a quantum leap. Two step forwards and one step back, more like (and sometimes the reverse).

Just the title shows you how much maturity the article can muster, and the rest doesn't really hold up better.

Re: IT Runs on Java 8

#495

In the majority of companies it's simply not possible to operate on the bleeding edge the way HN articles would have you believe you should. Besides the obvious issues around the value of rewriting stable legacy systems on new platforms, there are also man power issues. You need tier 1 developers to live on the bleeding edge because any problem that comes up (and they will come up) largely requires you to solve it yo…

> provides little concrete value to the business The concrete value doing such things add to our business is happy staff (which you mentioned), which means the best people don't leave, and stat excited and productive for the long term. Also, when hiring, because it helps us get the best people to join us in the first place. It's not just about "bleeding edge", it's about giving dev teams the freedom to do that if the…

The costs of doing such things include...

1. Half-done projects started by some happy staff who then went on to start the next project in the next shiny new thing and either more-or-less completed by someone who was just about capable of cut-n-pasting without understanding or who decided that some new shiny thing needed to be added to make the rest wonderful.

2. A monstrous stack of projects in 637 different programming languages, frameworks, ideologies, coding styles, and indentation levels, guaranteed to require rewriting for any change. Result: 638 different things.

Re: IT Runs on Java 8

#496
Honestly I would choose Java and not Go, Elixir etc. if I was writing software for an insurance company or other customers that demand complex business logic.

Re: IT Runs on Java 8

#497
post #456

Earlier quoted context omitted.

CPython is 100 times slower and has no multi threading support (CPython is single threaded). JVM code can outperform native C code. The JVM supports many advanced languages (Scala, Clojure, Kotlin) and it can even run Python code (Jython) faster than CPython. For concurrency it has this ultra powerful library https://akka.io (Up to 50 million msg/sec on a single machine. Small memory footprint; ~2.5 million actors pe…

Jython seems to be much, much slower than CPython, actually: https://pybenchmarks.org/u64q/jython.php The only benchmark where it's faster is the one involving threads, which makes sense. CPython definitely has multi-threading support, but it also has the Global Interpreter Lock preventing threads from actually executing bytecode at the same time. Jython doesn't. People have written patches that successfully remove t…

I consider that as basically no multithreading support. CPython multithreading is useless in comparison. Those benchmarks indicate that the Jython compiler is far from optimal. The equivalent code rewritten in Java would be an order of magnitude faster. https://julialang.org/benchmarks/ (note the single Python outlier there is the result of calling a C library for matrix calculation). Anyway, the JVM and CPython are fundamentally not comparable. One is interpreting, and the other is a JIT compiler. There are Python JIT compilers that would make a better comparison. However, as a language, Python is not optimal for large codebases. Comparing the languages only (not their implementation), Python is good for small scripting tasks, Java is better for very large scale projects.

Re: IT Runs on Java 8

#498
post #242
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…

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). The technology is certainly impressive but it isn't equipped to deal with the modern world. It is trivial to run 10 Node.js applications in the memory of one JVM application. This never used to be a problem, but n…

I haven't tried serverless, but shouldn't that be Java's cup of tea?

The JVM can load code dynamically and adapt the runtime to the work load. Maybe there is a framework missing, so those that provide serverless starts a new JVM per function call, but they shouldn't really have to do that.

Re: IT Runs on Java 8

#499

Earlier quoted context omitted.

Well, other than the fact that it only supports Linux and MacOS.

Is that true? The build instructions are for a Posix-like evironment, but I haven't actually looked to see if the actual implementation supports Windows yet. As someone who runs Windows and Linux about equally, in differing proportions over time, I do find it disappointing that some (b)leading edge JVM and Java features don't support Windows yet.

> I do find it disappointing that some (b)leading edge JVM and Java features don't support Windows yet

Seems understandable though. Java is primarily a tool for heavyweight Unix servers, after all. (This is of course an empirical claim, and I have no source, but I'd be surprised if I turn out to be mistaken.)

Makes good sense to go with the strategy of building an industry-strength technology before investing the time to handle Windows.

Re: IT Runs on Java 8

#500
post #465

Earlier quoted context omitted.

They didn't "theoretically" open source it - they actually open sourced it. I get why people used to shit on Microsoft, but Microsoft has demonstrated over a number of years that its changed under Satya. > However the way that this always works is that there is a base that can be written in, but anything non-trivial will have pulled in something that, surprise surprise, is Windows only. Outside of desktop GUIs, this…

No, Visual Studio does notrun on macOS. Visual Studio for macOS is a fork of MonoDevelop.

So because it’s not the same code base but it is produced by the same company with the same purpose? It’s not “Visusl Studio Code”? Was Photoshop not Photoshop on Windows when the assembly language optimizations were different between PPC and x86?
Post reply on HN