The "Java killers"

[Michael Yuan]

Back in 2005, I had the honor of being voted as one of the very first Java Champions for evangelizing Java on the server-side. It is hard to believe now, but back then, most people are doubtful that Java could even be used in server-side applications. Isn't Java a niche language invented to run silly games, known as Applets, inside the Netscape web browsers? Isn't Java very slow? Doesn't it consume a huge amount of memory? Well, those doubts were well-founded. However, Java had one thing going for it. It is beloved by developers. The OOP language design, automatic memory safety, and cross-platform runtime (JVM) were revolutionary at the time. Server-side developers were just more productive in Java. The rest is history.

Since Java became the “king of the server-side”, a challenger technology would emerge every a few years to “kill Java”. It was Ruby-on-Rails for a few years, and then Node.js for a few years. Yet, those challengers had the same playbook as Java — they focus on developer productivity. They are fundamentally managed runtimes with different front end languages. They are too similar to Java to kill Java.

However, as we enter the post-Moore era, computer performance must come from more efficient software, where Java and JavaScript often fall short. Rust and WebAssembly provide Java-like memory safety, security, and portability to server-side applications while delivering high performance.

Read this article in full and discuss in this thread to win a Raspberry Pi 4 kit.

Or, better yet, everyone who completes a programming assignment wins a Raspberry Pi Zero kit.

[Stephan van Hulst]

Interesting. I might take some time out to try and create an application on SSVM.

I just want to point out to you that the general public seems to be unauthorized to view your Google Form.

[Tim Holloway]

This smells like the old "Java is slow because it's interpreted" argument that became essentially meaningless many years ago. Probably over a decade past I ran across a benchmark where a JVM with JIT compiler actually out-performed C with the exception of the floating-point benchmarks.

Java is, of course, horrible slow for small apps like "Hello, world!". You have significant overhead in both time and memory to launch a JVM - although Oracle/BEA and IBM have both experifmented with less transistory Java environments. The JIT compiler will take its cut as well.

But the one thing that a truly high-performance JVM can do that no language that compiles to static code can is to dynamically re-compile code based on observed performance, thus ensuring a more optimal execution given the data and environment at hand.

For example, just about all traditional computers had a conditional branch statement that had two different execution times, generally shorter if the branch wasn't taken and longer if the branch was taken. A static compiler would generate code with that branch in a fixed context and that's where it would live forevermore. A smart JIT VM could monitor that code, note that the branch was being taken more often than not and recompile the bytecodes to ensure that branching was the exception rather than the rule. That's a micro-level optimization, but you can build up from there. And of course, with today's pipelined processors and virtual memory, there are more variables, since you want to reduce paging and "bubbles" in the pipes.

Languages like Rust and Go have their places. Some things really need a better environment than what C/C++ provides but are not suitable for execution in any sort of VM. That doesn't make them "killers", though. Just special tools for critical needs.

[Michael Yuan]

Stephan van Hulst wrote:Interesting. I might take some time out to try and create an application on SSVM.

I just want to point out to you that the general public seems to be unauthorized to view your Google Form.

Google form is fixed. Thank you!

[Michael Yuan]

Thanks, Tim. For many years, the arguments for Java have been "it is fast enough for my use case (web apps)" and "it has the libraries I need". I do agree with them. And to your point, I do believe the JVM is fastest in many common use cases (billions of $$$ have been spent on JVM optimization).

However, the world is changing. If you look at several frontiers of application development:

* AI: there is hardly any Java here. C++ with Python or JavaScript wrappers are the dominant force here. Why? Performance.

* Serverless computing / Function as a service: Java is supported as an after-thought on those platforms since it has a very large memory footprint and cold-start is very slow. One of the key use cases of FaaS is frequent start / stop.

* IoT: Most platforms do not support the JVM due to large memory footprint and un-predictable GC performance.

* Blockchain: This space is almost exclusively Rust and Go. Why? because when developers create new ecosystems, they need to write all libraries from scratch, and Java is no longer their default or first choice.

So, while I agree with most of what you said, I do not believe Java's reign will last forever. For the new generation of developers, it is no longer the first choice.

Tim Holloway wrote:This smells like the old "Java is slow because it's interpreted" argument that became essentially meaningless many years ago. Probably over a decade past I ran across a benchmark where a JVM with JIT compiler actually out-performed C with the exception of the floating-point benchmarks.

Java is, of course, horrible slow for small apps like "Hello, world!". You have significant overhead in both time and memory to launch a JVM - although Oracle/BEA and IBM have both experifmented with less transistory Java environments. The JIT compiler will take its cut as well.

But the one thing that a truly high-performance JVM can do that no language that compiles to static code can is to dynamically re-compile code based on observed performance, thus ensuring a more optimal execution given the data and environment at hand.

For example, just about all traditional computers had a conditional branch statement that had two different execution times, generally shorter if the branch wasn't taken and longer if the branch was taken. A static compiler would generate code with that branch in a fixed context and that's where it would live forevermore. A smart JIT VM could monitor that code, note that the branch was being taken more often than not and recompile the bytecodes to ensure that branching was the exception rather than the rule. That's a micro-level optimization, but you can build up from there. And of course, with today's pipelined processors and virtual memory, there are more variables, since you want to reduce paging and "bubbles" in the pipes.

Languages like Rust and Go have their places. Some things really need a better environment than what C/C++ provides but are not suitable for execution in any sort of VM. That doesn't make them "killers", though. Just special tools for critical needs.

[Derc Zbrojvic]

I'm also watching with interest the rise in use, popularity, and remuneration (especially outside the US) for Python in comparison to Java, even though Python is interpreted and thus slower than Java. It seems very likely to me that it can be a "Java killer" by attracting new and existing players in lieu of Java, especially because of its reputation of being easier to use. (As a long-time Java dev, I won't contest that.) So that would tell me that the world still has lots of room for non-performance-critical but quick-to-rollout projects...

Then again, I'm personally of a skeptical mind, and the above annual surveys (however valid their methodology and conclusions may be... or not) and their purported proof of the rise in both Rust and Python's popularity have received a lot of PR attention in promotion of the respective languages - Slashdot, Coderanch (ha) and some other blogs come to mind. Meanwhile, in my country, mobile networks, banks, German luxury car makers, and a bunch of other big money enterprises still have a high demand for Java developers, and those systems are pretty entrenched and are not going anywhere soon  

As a last remark, it is my personal opinion that the industry fixates a little bit too much on languages and the productivity gains to be had from them, and quite too little on the overall productivity gains that can be had from information availability through proper documentation systems, maintainability through coding practices, quality through proper testing, code reviews and constant skills+experience upgrading, and other organizational factors that happen on a higher level than coding. Unfortunately (in my country at least) it would seem that coders are simply seen as fungible production units with a fixed productivity that should be swapped in and out as the need demands  

[Campbell Ritchie]

Derc Zbrojvic wrote:. . . Python is interpreted and thus slower . . .

What makes you think that interpreted languages are slower than compiled languages?

[Derc Zbrojvic]

Campbell Ritchie wrote:

Derc Zbrojvic wrote:. . . Python is interpreted and thus slower . . .

What makes you think that interpreted languages are slower than compiled languages?

Interpreters do not have the scope that compilers have (else they would be compilers), or the execution metrics that VMs may provide them with (yet?). So they can't really optimize as much as JIT or native compilers.

The top 6 results of this search makes me think so too, because they say so (I haven't bothered to look at more pages).

Anyhow, that was the conventional wisdom (general rule of thumb) taught 30 years ago, and I'd be pleasantly surprised if that gap would be narrowed. But it won't be, because the drawback that make interpreters slow on execution, is at the same time their strength at deployment time (no compilation steps).

All this is not to say that interpreters can't be faster in some very well defined specific areas (as one of the pages from the search point out - the only one bothering to do tests). And if your interpreted application builds off that niche strengths, the more power to you.

[Tim Holloway]

Python is not being used in AI for "performance" reasons. It's being used because it's easier to work with for non-systems people. Python has taken up the rôle that was formerly occupied by Fortran, and offers a lot more ability than Fortrans when you start talking about data structures and system resource access. It's common that the leading lights of a particular technology have a preferred language, though. Sometimes a rather obscure one, alas.

I can separate IoT into three major divisions. The ones using low-level AVR processors (Arduino, et. al. and higher-level processors - Raspberry Pi, Beaglebone and similar systems, And of course, mobile devices. AVRs, it's true lack the resources to run a JVM (so, actually did an IBM System/370 Model 168). Rasbian OS comes with Java pre-installed, although like many people, I actually prefer Python on that platform. And, of course, since the Pi is the popular home for TensorFlow and TensorFlow is used with Python...

On the other hand, until Kotlin came along, Android's primary language was Java/Dalvik. Apple, of course, prefers its own private languages.

Campbell Ritchie wrote:
What makes you think that interpreted languages are slower than compiled languages?

The conventional wisdom in olden times was that an interpreter ran about 10 times slower than native code. One advantage of FORTH was that instead of employing a simple finite-state machine driven interpreter FORTH was a threaded-interpreted language, where the commands compiled straight to function pointers, eliminating the need for a lot of code to dispatch the program elements. Still, FORTH was calling static units which could not be optimised at the macro level. "Could not" meaning it wasn't something anyone wanted to worry about, since it would have been a lot of work for little gain.

Python compilles just-in-time at the file level to create ".pyc" files. I believe that these are bytecodes. And of course "jython" I presume compiles to JVM-compatible class files. As to how much optimisation is done when creating these compiled Python code units I never investigated, but I've not heard anyone bragging about it. Still, a lot of optimisations that would have been unthinkable decades ago are now routine. The curse of Python, of course, is that if a Python file is overlaid with random garbage, you'll never know about it until, say, the year-end tax processing calls on it at 3 AM January 1. I used to work with a mainframe console operator who could be annoyingly cheerful at that hour.

[Frank Mi]

According to a survey of StackOverflow, Rust is the most beloved language in recent several years (link). I'm very interested in this language, but I also heard it is very hard to learn. It lacks enough documentation, a mature IDE, and others.

Do you have any idea that who you think is ideal to learn Rust? Is it easy to transfer from Java/JavaScript to Rust?

[Tim Holloway]

I've done a little peeking at Rust and it's basically yet another attempt to be "C++ without the mace and knives". So knowing Java/JavaScript can help a lot. The main things about Rust over straight C is better memory and thread management, so that's useful when you're developing the "Penguin Killer" OS. It's not a replacement for Java as such, but you can't write low-level OS code in Java on most platforms and some of the language syntax for that sort of stuff is better.

There are at least 2 Rust development plugins for Eclipse. Let us know which you prefer!

[Frank Mi]

Tim Holloway wrote:So knowing Java/JavaScript can help a lot.

Thanks a lot, Tim. it's glad to know my Java and JavaScript knowledge would not be wasted.

Tim Holloway wrote:There are at least 2 Rust development plugins for Eclipse.

I found that eclipse right now has only one Rust plugin, Corrosion, because the RustDT is no longer maintained. I think I can start here.



After some search online, I found this picture from this site (link). It looks like too good to be true. What's the price for it?

[Tim Holloway]

It's probably a bit bogus, since I don't think that Control and Performance are inextricably related. But Rust is definitely aiming for safety.

[paul nisset]

Tim Holloway wrote:paul nisset,
Your post was moved to a new topic.
(This informational message will self destruct in two days)
Mis-classiffied reply

I don't understand why my question was moved.  It was a direct response to this : in the first post in this thread.

everyone who completes a programming assignment wins a Raspberry Pi Zero kit.

The directions the author offered in his contest did not work for me .

[Tim Holloway]

Sorry, I didn't mean to interfere with your chances of scoring free swag. But I'm too blind to see where Docker got mentioned there. And the best place to get help for Docker is in our Cloud forum, I think.

I did a quick check of my own and there's a Rust project at the Docker hub that allows you to create your own custom Rust container from a Dockerfile. If you're a Docker geek. You should also be able to use that info with buildah and podman on your desktop if you like.

Personally, I'd probably spin up an independent VM if I wanted to be able to play with Rust temporarily and not leave lint all over my regular computer when I was done. Vagrant machines can be created, destroyed, and re-created repeatedly with minimal effort and while a VM does require more resources than Docker, there's less likelihood that there would be puzzles introduced by the limitations of working within a container if you have a full VM.

[paul nisset]

Tim Holloway wrote:Sorry, I didn't mean to interfere with your chances of scoring free swag. But I'm too blind to see where Docker got mentioned there. And the best place to get help for Docker is in our Cloud forum, I think.

I did a quick check of my own and there's a Rust project at the Docker hub that allows you to create your own custom Rust container from a Dockerfile.
...

Personally, I'd probably spin up an independent VM if I wanted to be able to play with Rust temporarily .

The instructions mentioned the Rust project and it has been a nightmare to get running. I tried running the   Docker Rust project under Windows yesterday and got errors about it not existing on Docker so I tried to set it up in a Kali virtual machine under VirtualBox but trying to set up Docker for the last hour on the VM has given me a list of hash sum errors from Docker.

I thought the author's project would be quick and easy thing to just check out. I was completely wrong on that.
I don't see his project killing Java any time soon.

[Tim Holloway]

Hmm. It doesn't help that the Windows Fatally-Broken  Component of the Week™ is Windows Subsystem for Linux. But now that you mention it, I do think I got a checksum on the Docker pull myself and that was on a production Docker box.

You could try to build your own Rust Docker image, if you're comfortable with Docker. But a VM with Rust installed natively would be better if there's good docs on that. Rather than mess with a lesser-known distro like Kali, you might want to download a, Ubuntu bootable ("LiveCD") image onto a thumb drive and boot off that. That way you don't even have VM considerations, because - excepting media speed - it's the same as booting natively off a hard drive.

[Tim Holloway]

Also, have you tried the Rust Playground? Then the whole OS issue becomes Somebody Else's Problem: https://www.rust-lang.org/learn/get-started

I'm going to spin up a Vagrant box and try "Rustup". I'll let you know what happens.

[Tim Holloway]

OK. I used Vagrant to spin up a copy of Ubuntu Xenial. It's not the latest/greatest Ubuntu, but I think it's an LTS release, since it has recent updates.

I ran rustup (non-sudo) per the instructions at the previously-mentioned intro to Rust website. With some misgivings (what sane person would name software "clippy"?  

I then tried to run it and it failed. What they didn't tell me (or at least not loudly enough) is that you need a pre-installed C compiler. So...

apt-get update
apt-get upgrade
apt-get install gcc

After installing gcc, I got the Rust "Hello, World!" app to run. Success.

Sadly, under Windows, Vagrant runs in WSL. And WSL is the Broken System of the Week.        

[paul nisset]

Tim Holloway wrote:Also, have you tried the Rust Playground? Then the whole OS issue becomes Somebody Else's Problem: https://www.rust-lang.org/learn/get-started

I'm going to spin up a Vagrant box and try "Rustup". I'll let you know what happens.

Thanks Tim.
I just the got the second state "helloworld" example to run on Docker on a mac. Seems to be the perennial issue of "nothing useful working on Windows 10".

[paul nisset]

After going though  getting the Second State example working  and reading the article "https://www.secondstate.io/articles/is-this-the-next-java-20200713/" ,there is nothing that impresses about this.
It's basically a node app that makes calls to server that runs compiled functions. The article says the "Rust is beloved by developers"  . I would counter the number of developers that it is beloved by is very few .
Maybe if you spend a couple months learning it ,you are forced to feel you love it but there was nothing in  the Rust documentation that made me think "Cool ! I need to know this".

I really don't see what the hype is . There is nothing there, especially if someone has worked with C or C++ before.

[Tim Holloway]

One of the big selling points of Rust is that provides safety to some of the most dangerous types of software.

Unfortunately, for most applications, reliability is held by management to be of little account. In fact, I was terminated from a job position once and the excuse given was that I spent too much time on reliability instead of just "getting it done". This was a shop that considered it more acceptable to reboot one of the production servers once a day when it went South rather than have someone actually fix the offending software.

One of the great virtues of open-source software, however, is that there's rarely the quality-reducing pressure to be "productive" and often a lot of desire on the part of the designers to try out some flashy new technology (not that commercial developers don't also have that itch!). So it's open-source and those rare institutions which still support Research and Development over just pushing any old trash out the door in order to make this quarter's profit goals who tend to make up the early adopters. Only if/when tangible benefits appear is wider acceptance likely. I have little doubt that a lot of people who encountered Java in its early days disparage it because it wasn't lean and clean like C.

[paul nisset]

Tim Holloway wrote:One of the big selling points of Rust is that provides safety to some of the most dangerous types of software.

Unfortunately, for most applications, reliability is held by management to be of little account. In fact, I was terminated from a job position once and the excuse given was that I spent too much time on reliability instead of just "getting it done". This was a shop that considered it more acceptable to reboot one of the production servers once a day when it went South rather than have someone actually fix the offending software.

One of the great virtues of open-source software, however, is that there's rarely the quality-reducing pressure to be "productive" and often a lot of desire on the part of the designers to try out some flashy new technology (not that commercial developers don't also have that itch!). So it's open-source and those rare institutions which still support Research and Development over just pushing any old trash out the door in order to make this quarter's profit goals who tend to make up the early adopters. Only if/when tangible benefits appear is wider acceptance likely. I have little doubt that a lot of people who encountered Java in its early days disparage it because it wasn't lean and clean like C.

There used to be a saying that nobody ever got fired for buying Microsoft. There has always been conflicting goals of business and the development departments. Now that hacking is costing real money ,businesses are actually committing more resources to "getting it right" . Regardless of the tools ,there are a lot of badly written programs out there . Sometimes it's time constraints ,sometimes it is just inexperienced programmers.

Thanks for pointing out one of Rust's advantages .

[Tim Holloway]

I'll believe that last when I stop seeing news of major breaches from major businesses.

But it may interest you to know that Apple has committed resources to working with Rust.

[Michael Yuan]

There is nothing new in computer science. ;) I remember when Java servlets came along, everyone said "but Perl and C++ already do that!". When Hibernate came along, it is the same reaction "JDBC is faster and more flexible!" ...

The "hype" is that many new developers love it, and as a result, new libraries and frameworks will be written for those "new" languages that have the most mindshare. If you look at AI, blockchain, or even recent cloud computing frameworks (i.e., the serverless stuff), most people use JavaScript and Python. However, they are only using JavaScript and Python as "wrappers" or "glue" for applications -- most of the underlying libraries are written in C/C++. That's what gave rise to Rust and WebAssembly.

paul nisset wrote:After going though  getting the Second State example working  and reading the article "https://www.secondstate.io/articles/is-this-the-next-java-20200713/" ,there is nothing that impresses about this.
It's basically a node app that makes calls to server that runs compiled functions. The article says the "Rust is beloved by developers"  . I would counter the number of developers that it is beloved by is very few .
Maybe if you spend a couple months learning it ,you are forced to feel you love it but there was nothing in  the Rust documentation that made me think "Cool ! I need to know this".

I really don't see what the hype is . There is nothing there, especially if someone has worked with C or C++ before.

[paul nisset]

Thanks for your input Michael.
If Web Assembly reaches it's goal of working/interpreted the same in all browsers then that is a step up over Javascript and speedy applications in a browser opens up a lot of possibilities.