Comment by lelanthran
5 days ago
> What killed that balance wasn't raw speed, it was cheap RAM. Once you could throw gigabytes at a problem, the incentive to write tight code disappeared. Electron exists because memory is effectively free.
I dunno if it was cheap RAM or just developer convenience. In one of my recent comments on HN (https://news.ycombinator.com/item?id=46986999) I pointed out the performance difference in my 2001 desktop between a `ls` program written in Java at the time and the one that came with the distro.
Had processor speeds not increased at that time, Java would have been relegated to history, along with a lot of other languages that became mainstream and popular (Ruby, C#, Python)[1]. There was simply no way that companies would continue spending 6 - 8 times more on hardware for a specific workload.
C++ would have been the enterprise language solution (a new sort of hell!) and languages like Go (Native code with a GC) would have been created sooner.
In 1998-2005, computer speeds were increasing so fast there was no incentive to develop new languages. All you had to do was wait a few months for a program to run faster!
What we did was trade-off efficiency for developer velocity, and it was a good trade at the time. Since around 2010 performance increases have been dropping, and when faced with stagnant increases in hardware performance, new languages were created to address that (Rust, Zig, Go, Nim, etc).
-------------------------------
[1] It took two decades of constant work for those high-dev-velocity languages to reach some sort of acceptable performance. Some of them are still orders of magnitude slower.
> Had processor speeds not increased at that time, Java would have been relegated to history, along with a lot of other languages that became mainstream and popular (Ruby, C#, Python)[1].
I'd go look at the start date for all these languages. Except for C#, which was a direct response to the Sun lawsuit, all these languages spawned in the early 90s.
Had processor speed and memory advanced slower, I don't think you see these languages go away, I see they just end up being used for different things or in different ways.
JavaOS, in particular, probably would have had more success. Seeing an entire OS written in and for a language with a garbage collector to make sure memory isn't wasted would have been much more appealing.
> I'd go look at the start date for all these languages. Except for C#, which was a direct response to the Sun lawsuit, all these languages spawned in the early 90s.
I don't understand your point here - I did not say those languages came only after 2000, I said they would have been relegated to history if they didn't become usable due to hardware increases.
Remember that Java was not designed as a enterprise/server language. Sun pivoted when it failed at its original task (set top boxes). It was only able to pivot due to hardware performance increases.
> I said they would have been relegated to history if they didn't become usable due to hardware increases.
And I disagree with this assessment. These languages became popular before they were fast or the hardware support was mature. They may have taken different evolution routes, but they still found themselves useful.
Python, for example, entered in a world where perl was being used for one off scripts in the shell. Python replacing perl would have still happened because the performance characteristics of it (and what perl replaced, bash scripts) is similar. We may not have used python or ruby as web backends because they were too slow for that purpose. That, however, doesn't mean we wouldn't have used them for all sorts of other tasks including data processing.
> Remember that Java was not designed as a enterprise/server language. Sun pivoted when it failed at its original task (set top boxes). It was only able to pivot due to hardware performance increases.
Right, but the java of old was extremely slow compared to today's Java. The JVM for Java 1 to 1.4 was dogshit. It wasn't hardware that made it fast.
Yet still, java was pretty popular even without a fast JVM and JIT. Hotspot would have still likely happened but maybe the GC would have evolved differently as the current crop of GC algorithms trade memory for performance. In a constrained environment Java may have never adopted moving collectors and instead relied on Go like collection strategies.
Java applets were a thing in the 90s even though hardware was slow and memory constrained. That's because the JVM was simply a different beast in that era. One better suited to the hardware at the time.
Even today, Java runs on hardware that is roughly 80s quality (see Java Card). It's deployed on very limited hardware.
What you are mistaking is the modern JVM's performance characteristics for Java's requirements for running. The JVM evolved with hardware and made tradeoffs appropriate for Java's usage and hardware capabilities.
I remember the early era of the internet. I ran Java applets in my netscape and IE browsers on a computer with 32MB of ram and a 233MHz processor. It was fine.
1 reply →
As you say, the trade-off is developer productivity vs resources.
If resources are limited, that changes the calculus. But it can still make sense to spend a lot on hardware instead of development.