3 ms·

It was ridiculous. They seriously wanted to rewrite everything in Java, including office and web browsers. It was 10 times worse than the recent “rewrite in Rus

by whobre 1y ago

It was ridiculous. They seriously wanted to rewrite everything in Java, including office and web browsers. It was 10 times worse than the recent “rewrite in Rust” mania and way more unrealistic.

klntsky 1y ago
RIIR is justified in most of the cases because in the past the only reason to use a GCd language was memory safety for most of the apps. RIIJ was justified too, because people believed the web will end up being java applets all the way down.
- cenamus 1y ago
  And RIIJ also gives you memory safety
  - mdaniel 1y ago
    And plausibly sandboxing, too, since the JVM used to carry a policy language with it that allowed granting access by package (or by public key, IIRC), a vestige from its days of running in the browser. But they recently killed that whole feature due to disuse
  - throw0101c 1y ago
    > And RIIJ also gives you memory safety I think Java helped in the mainstreaming of memory safe and GC languages, especially in more corporate spaces where C/C++ was still mostly still a thing. Certainly sysadmins were using a lot of Perl during that time, but for "real" enterprise software, I don't think dynamic-ish languages were as accepted. The use of Perl and rise of Python widened the Overton window.
epcoa 1y ago
Well all the parts that you didn’t write in XML and XSLT, etc.
Disposal8433 1y ago
I remember some greybeards hyping the CPUs that could run Java bytecode (it existed for a short time). I was a junior C++ fanboy at the time and I already knew that they were wrong.
- brabel 1y ago
  Were you right because you knew something they didn't, or you were just as irrational (maybe more given you were "a junior"?) but got lucky in being stuck with an opinion that eventually turned out right?
  - holowoodman 1y ago
    Everyone with lower-level systems programming or hardware experience did know after taking a look that Java bytecode was unfit for direct execution by a CPU. All the bits that you need to make decoding and execution fast in hardware were just missing. And the instruction set is complex in a way that makes the most complex CISC instructions look almost like RISC. You basically would have to put another decoder stage into processors, to make java bytecode into CISC and that into RISC. Only applications and web people did believe that particular part of the hype, because they didn't know what it took. And IBM consultants believed it because IBM always managed to sell some weird CPU extension for big dollars that did weird stuff, like their "decode XML extension".
    - wpollock 1y ago
      Unfix for an x86 CPU. But that architecture wasn't as locked-in back then. For example, the Intel 432 CPU was designed to support OO languages. I believe it was designed with Ada in mind, and with GC support and other VM support. Java Bytecode would probably have run well on it.
      - holowoodman 1y ago
        It wasn't locked in, but the general trend even back then was towards RISC, or at least CISC plus superscalar execution (meaning the processor translates to RISC internally). All the more complex instruction sets were a failure for a reason. Performance was just not there, and bytecode interpretation in software is more flexible.
more_corn 1y ago
Agreed. I lived through it and it was seriously overhyped.
II2II 1y ago
Two points: The hype accomplished something that would be otherwise impossible: it established Java as a language in what was likely record time. Consider another popular language: Python. It was created about 5 years earlier, yet it rose to prominence about a decade later. Or consider Rust. It is, in many respects, as significant as Java. While major developers were shipping significant applications written in Java within 5 years, Rust is only creeping into important software a decade after its introduction. The second point is its easy to underestimate the dominance of Microsoft in those days. You think that Microsoft is dominant today, well, that's nothing compared to the late 1990's. Microsoft's market share was closer to 95% for the PC market. The workstation market was starting to crumble due to competition from Microsoft and Intel. About the only thing that was safe were mainframes, and that was highly dependent upon one's definition of safe. Nearly everyone who was competing against Microsoft wanted to see a chunk taken out of them, which meant pretty much everyone since Microsoft had its fingers in so many markets. And, as it turns out, nearly everything did have to be rewritten. Sometimes it was to deliver SaaS over the Internet and sometimes it was to target mobile devices.
- zozbot234 1y ago
  If I had to pick a language that's "as significant as Java", I'd pick Golang way before Rust - and Golang has found significant success. The first genuinely usable version of Rust was only out in late 2018, so it's way too early to argue about its slow and "creeping" adoption curve. > The second point is its easy to underestimate the dominance of Microsoft in those days. You think that Microsoft is dominant today, well, that's nothing compared to the late 1990's. Microsoft's market share was closer to 95% for the PC market. By the late 1990s Linux had become a viable platform for a whole lot of things, and people were beginning to take notice. Most obviously, that probably put a big dent into the adoption of Windows NT as a server OS on x86 machines, which had been progressing quite well until the mid 1990s. That also probably helped Java because it meant you could seamlessly run your server workloads on "toy" x86 machines or on more "serious" platforms, without changing anything else.
giantrobot 1y ago
I was excited about ApplixWare Anyware Office[0] around 1999-2000. I'm pretty sure I got a copy bundled in a boxed copy of SuSE or RedHat. It was the first time I'd really seen a real productivity application written as an applet. It was an interesting idea that was eventually delivered by JavaScript. [0] https://www.applix.com/applixware/anywareoffice.html https://www.applix.com/applixware/anywareoffice.html
jmyeet 1y ago
There are design decisions you can reasonably question in Rust but the big one that justifies its existence is memory safety. It's simply too important. Not everything needs it but key infrastructure, most notably Web browsers, do. I predict we will be having buffer overrun CVEs in C/C++ code for as long as we have C/C++ code. The realities of writing safe, multithreaded C/C++ on processors with out-of-order processing, context switching and branch prediction is simply too complex to get right 100% of the time. Rust makes writing certain code difficult because it is difficult to do/ C/C++ fools you into believing something is safe because you've never encountered the circumstances where it isn't. We have tools like valgrind to try and identify such issues. They're certainly useful. But you'll be constantly chasing rabbits. I've seen thread and memory bugs in production code written by smart, highly-paid engineers at big tech companies that have lain dormant for the better part of a decade. That's why Rust exists.
- holowoodman 1y ago
  Problem is, unsafe rust is as crappy as C/C++ safety-wise, just with worse tooling. And lots of things that C/C++ does can't be done without unsafe rust. Rust will never take over and something like C/C++ will always be with us.
- izacus 1y ago
  Every single language we use to write software outside C++ is memory safe. It's important, we got it years ago. With Java.
hodgesrm 1y ago
> It was ridiculous. They seriously wanted to rewrite everything in Java, including office and web browsers. There's another perspective. Many people were looking for something like Java well before it was released: VM-based, portable, modern object-orientation features, etc. Case in point: databases. In the early 1990s I worked on a project at Sybase that attempted to rewrite SQL Server from the ground up to bring in object [relational] support. The team focused on VM-based languages as a foundation, which were an area of active academic research at the time. Built-in object support, portability, and ability to support code generation for queries were among the attractions. The project started with Smalltalk (slow!), then moved to an acquired VM technology (it was bad!), and finally a VM we designed and built ourselves. These gyrations were a key reason why the project failed, though not the only one. When Java came out in 1995--I got access to the alpha release in September--it met virtually every requirement we were trying to fulfill. At that point most attempts to build new databases on other VM tech became instantly obsolete. (Other vendors were also looking at VMs as well.) Not coincidentally Nat Wyatt and Howard Torf, a couple of key engineers from our project, founded a start-up called Cloudscape to pursue the Java route. They created the database we know today as Derby. Somewhat more coincidentally, Java became dominant in American DBMS development after 2000. Examples including Hadoop, Druid, Pinot, HBase, etc., are just a few of the examples. I say "somewhat more concidentally" because at that point most of us saw Java as simply more productive than C/C++ alternatives for building reliable, high-performance, distributed systems. That view has obviously evolved over time, but between JIT, dev tooling, and libraries it was definitely true in the early 2000s. It helps to remember how difficult C++ was to use at that time to understand this perspective. In summary, a lot of the hype was the usual new technology craziness, but Java also met the needs of a population of people that went far beyond databases. There was a basis for our excitement. Just my $0.02. Edit: typo
burnt-resistor 1y ago
I remember the Java hype c. 1999. It was such jumping the shark ultrahype of the platform, the language, and OOP. The one thing it did though, it allowed me to produce an installer for a niche DOS-based building code text search engine and JNI allowed calling the functions to produce a Windows 95/NT desktop shortcut (a .PIF). I even added a feature where it was per-customer skinnable with a .BMP.
mike_hearn 1y ago
Not that unrealistic. Google Docs is written in Java, for example.

by whobre 1y ago

It was ridiculous. They seriously wanted to rewrite everything in Java, including office and web browsers. It was 10 times worse than the recent “rewrite in Rust” mania and way more unrealistic.

klntsky 1y ago

RIIR is justified in most of the cases because in the past the only reason to use a GCd language was memory safety for most of the apps. RIIJ was justified too, because people believed the web will end up being java applets all the way down.

cenamus 1y ago
And RIIJ also gives you memory safety
- mdaniel 1y ago
  And plausibly sandboxing, too, since the JVM used to carry a policy language with it that allowed granting access by package (or by public key, IIRC), a vestige from its days of running in the browser. But they recently killed that whole feature due to disuse
- throw0101c 1y ago
  > And RIIJ also gives you memory safety I think Java helped in the mainstreaming of memory safe and GC languages, especially in more corporate spaces where C/C++ was still mostly still a thing. Certainly sysadmins were using a lot of Perl during that time, but for "real" enterprise software, I don't think dynamic-ish languages were as accepted. The use of Perl and rise of Python widened the Overton window.

epcoa 1y ago

Well all the parts that you didn’t write in XML and XSLT, etc.

Disposal8433 1y ago

I remember some greybeards hyping the CPUs that could run Java bytecode (it existed for a short time). I was a junior C++ fanboy at the time and I already knew that they were wrong.

brabel 1y ago
Were you right because you knew something they didn't, or you were just as irrational (maybe more given you were "a junior"?) but got lucky in being stuck with an opinion that eventually turned out right?
- holowoodman 1y ago
  Everyone with lower-level systems programming or hardware experience did know after taking a look that Java bytecode was unfit for direct execution by a CPU. All the bits that you need to make decoding and execution fast in hardware were just missing. And the instruction set is complex in a way that makes the most complex CISC instructions look almost like RISC. You basically would have to put another decoder stage into processors, to make java bytecode into CISC and that into RISC. Only applications and web people did believe that particular part of the hype, because they didn't know what it took. And IBM consultants believed it because IBM always managed to sell some weird CPU extension for big dollars that did weird stuff, like their "decode XML extension".
  - wpollock 1y ago
    Unfix for an x86 CPU. But that architecture wasn't as locked-in back then. For example, the Intel 432 CPU was designed to support OO languages. I believe it was designed with Ada in mind, and with GC support and other VM support. Java Bytecode would probably have run well on it.
    - holowoodman 1y ago
      It wasn't locked in, but the general trend even back then was towards RISC, or at least CISC plus superscalar execution (meaning the processor translates to RISC internally). All the more complex instruction sets were a failure for a reason. Performance was just not there, and bytecode interpretation in software is more flexible.

more_corn 1y ago

Agreed. I lived through it and it was seriously overhyped.

II2II 1y ago

Two points: The hype accomplished something that would be otherwise impossible: it established Java as a language in what was likely record time. Consider another popular language: Python. It was created about 5 years earlier, yet it rose to prominence about a decade later. Or consider Rust. It is, in many respects, as significant as Java. While major developers were shipping significant applications written in Java within 5 years, Rust is only creeping into important software a decade after its introduction. The second point is its easy to underestimate the dominance of Microsoft in those days. You think that Microsoft is dominant today, well, that's nothing compared to the late 1990's. Microsoft's market share was closer to 95% for the PC market. The workstation market was starting to crumble due to competition from Microsoft and Intel. About the only thing that was safe were mainframes, and that was highly dependent upon one's definition of safe. Nearly everyone who was competing against Microsoft wanted to see a chunk taken out of them, which meant pretty much everyone since Microsoft had its fingers in so many markets. And, as it turns out, nearly everything did have to be rewritten. Sometimes it was to deliver SaaS over the Internet and sometimes it was to target mobile devices.

zozbot234 1y ago
If I had to pick a language that's "as significant as Java", I'd pick Golang way before Rust - and Golang has found significant success. The first genuinely usable version of Rust was only out in late 2018, so it's way too early to argue about its slow and "creeping" adoption curve. > The second point is its easy to underestimate the dominance of Microsoft in those days. You think that Microsoft is dominant today, well, that's nothing compared to the late 1990's. Microsoft's market share was closer to 95% for the PC market. By the late 1990s Linux had become a viable platform for a whole lot of things, and people were beginning to take notice. Most obviously, that probably put a big dent into the adoption of Windows NT as a server OS on x86 machines, which had been progressing quite well until the mid 1990s. That also probably helped Java because it meant you could seamlessly run your server workloads on "toy" x86 machines or on more "serious" platforms, without changing anything else.

giantrobot 1y ago

I was excited about ApplixWare Anyware Office[0] around 1999-2000. I'm pretty sure I got a copy bundled in a boxed copy of SuSE or RedHat. It was the first time I'd really seen a real productivity application written as an applet. It was an interesting idea that was eventually delivered by JavaScript. [0] https://www.applix.com/applixware/anywareoffice.html https://www.applix.com/applixware/anywareoffice.html

jmyeet 1y ago

There are design decisions you can reasonably question in Rust but the big one that justifies its existence is memory safety. It's simply too important. Not everything needs it but key infrastructure, most notably Web browsers, do. I predict we will be having buffer overrun CVEs in C/C++ code for as long as we have C/C++ code. The realities of writing safe, multithreaded C/C++ on processors with out-of-order processing, context switching and branch prediction is simply too complex to get right 100% of the time. Rust makes writing certain code difficult because it is difficult to do/ C/C++ fools you into believing something is safe because you've never encountered the circumstances where it isn't. We have tools like valgrind to try and identify such issues. They're certainly useful. But you'll be constantly chasing rabbits. I've seen thread and memory bugs in production code written by smart, highly-paid engineers at big tech companies that have lain dormant for the better part of a decade. That's why Rust exists.

holowoodman 1y ago
Problem is, unsafe rust is as crappy as C/C++ safety-wise, just with worse tooling. And lots of things that C/C++ does can't be done without unsafe rust. Rust will never take over and something like C/C++ will always be with us.
izacus 1y ago
Every single language we use to write software outside C++ is memory safe. It's important, we got it years ago. With Java.

hodgesrm 1y ago

> It was ridiculous. They seriously wanted to rewrite everything in Java, including office and web browsers. There's another perspective. Many people were looking for something like Java well before it was released: VM-based, portable, modern object-orientation features, etc. Case in point: databases. In the early 1990s I worked on a project at Sybase that attempted to rewrite SQL Server from the ground up to bring in object [relational] support. The team focused on VM-based languages as a foundation, which were an area of active academic research at the time. Built-in object support, portability, and ability to support code generation for queries were among the attractions. The project started with Smalltalk (slow!), then moved to an acquired VM technology (it was bad!), and finally a VM we designed and built ourselves. These gyrations were a key reason why the project failed, though not the only one. When Java came out in 1995--I got access to the alpha release in September--it met virtually every requirement we were trying to fulfill. At that point most attempts to build new databases on other VM tech became instantly obsolete. (Other vendors were also looking at VMs as well.) Not coincidentally Nat Wyatt and Howard Torf, a couple of key engineers from our project, founded a start-up called Cloudscape to pursue the Java route. They created the database we know today as Derby. Somewhat more coincidentally, Java became dominant in American DBMS development after 2000. Examples including Hadoop, Druid, Pinot, HBase, etc., are just a few of the examples. I say "somewhat more concidentally" because at that point most of us saw Java as simply more productive than C/C++ alternatives for building reliable, high-performance, distributed systems. That view has obviously evolved over time, but between JIT, dev tooling, and libraries it was definitely true in the early 2000s. It helps to remember how difficult C++ was to use at that time to understand this perspective. In summary, a lot of the hype was the usual new technology craziness, but Java also met the needs of a population of people that went far beyond databases. There was a basis for our excitement. Just my $0.02. Edit: typo

burnt-resistor 1y ago

I remember the Java hype c. 1999. It was such jumping the shark ultrahype of the platform, the language, and OOP. The one thing it did though, it allowed me to produce an installer for a niche DOS-based building code text search engine and JNI allowed calling the functions to produce a Windows 95/NT desktop shortcut (a .PIF). I even added a feature where it was per-customer skinnable with a .BMP.

mike_hearn 1y ago

Not that unrealistic. Google Docs is written in Java, for example.