3 ms·

I don't think you can blame this on vendors / cloud providers - many of the worst offenders there use JVM or CLR (looking at you, Atlassian!) But I think your

by theamk 2y ago

I don't think you can blame this on vendors / cloud providers - many of the worst offenders there use JVM or CLR (looking at you, Atlassian!) But I think your other points are pretty good, and match my experience: - The "free and unencumbered" became very important in the internet era. I used to program in Delphi, which is a great visual IDE. I stopped this once I've realized that if I keep going, none of my friends can use my source code. - "macho"-ness, or how I'd call it, "barrier to entry" definitely has a role. For example Java is the language where I saw the most "catch (Exception e) {;}" clauses - which is one of the worst things ever you can do to users. The language itself is good, but the culture around it is often not. I'd also add that all those fancy systems are strongly associated with "single computer, desktop app" setups. Once I've got used to running servers, many of the advantages just disappear: "everything can be debugged?" - your server has no graphical shell, and may not even have JDK installed. If all your experience was local, that's a major problem right there. But OK, you've figured out remote debugging. But it is not very useful now, as you cannot stop the program which is serving live requests; and even if you do, your breakpoints get triggered from different requests. And remote clients time out while you study stack. So might as well write your next server program in Perl + CGI, at least you'd be able to add debug prints easily. (Yes, in the ideal case you'd a working dev environment and not do it live on prod. This was pretty rare though in smaller sites, especially in the 1990's-2000's) The same can be said about "Software can be hot upgraded" - that seems insane, that's how you get a unique snowflake machine which everyone is afraid to touch. Software should be restarted often, to make sure it's reset to a predictable state. And that "Everything is memory safe" means speed penalty, which people actually used to care about. I remember when I got my first webcam, with it's 640x480 resolution. Was I going to be coding the image processing in Java? No way, I wanted more than 1 FPS. It was C or maybe Pascal. What about that game? It's not going to be in Java either.... (And CLR's beginnings were damaged by the strong MS Windows associations, with all the associated fragility of "I've checked some checkbox somewhere one of those 250 control panel tabs and now my web server no longer works. No, I don't remember which one is it". I know it's no longer the case _today_ but we are talking about the past...) And of course being bound to one language was not helping either. If I use Java RPC, only another JVM ecosystem language can use it; but if use text-based HTTP, I can use almost any language ever made. Given all of those reasons, it am not surprised at all that JVM/CLR are used for large business apps, while smaller things are written in other languages. And that means all the cool stuff is going to be C++/C/Rust/Python, while only the boring enterprise apps would be Java.

pjmlp 2y ago
> Given all of those reasons, it am not surprised at all that JVM/CLR are used for large business apps, while smaller things are written in other languages. And that means all the cool stuff is going to be C++/C/Rust/Python, while only the boring enterprise apps would be Java. There is enough cool stuff on Android, and embedded with Java. Also although not Java level, back in the 1990's there were already two attempts to have Smalltalk experience for C++, Lucid Energize C++ (after their Common Lisp pivot), and Visual Age for C++ v 4.0 (which introduced a image like concept for C++ development). Both failed due to hardware resources, and the related cost to have such a capable workstation. However, the LSP idea traces back to systems like Cadillac used by Lucid Energize C++, not surprising given that the main Visual Studio Code (nee Monaco) is Enrich Gamma from Eclipse fame. Delphi and C++ Builder still offer to this day, similar kind of IDE experience, ironically Visual C++ was never as RAD as C++ Builder, nor as visual. Additionally, Clion with clangd and Live++, offers some of the same experience that Energize C++ and Visual Age for C++ tried to make common in the 1990's.
- theamk 2y ago
  is embedded still using Java? I remember all the talk about java-on-a-chip in early 2000's (remember tini, "Java-On-A-Chip" from Dallas Semi?), and all the java on feature phones, but it seems all died out by now. I think the only place which has embdded + java now is one of those desktop/server class PC with gigs of RAM, and multiple gigahertz of CPU, and full-blown linux inside.
  - pjmlp 2y ago
    Of course, and bare metal is still part of the picture, https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/products-services/jamaicavm/ https://www.aicas.com/products-services/jamaicavm/ https://www.microej.com/ https://www.microej.com/ Additionally stuff like Cisco, Ricoh, Xerox,... have subsets that run as mini apps on their devices.
api 2y ago
Good points. A few responses: > "Everything is memory safe" means speed penalty Not much, and sometimes none if the optimizer is smart. See: Rust, Go. The JVM and CLR are not slow either, though they are a little less efficient than the former for legacy reasons... and of course like all benchmarks it will depend on the use case and code. > The same can be said about "Software can be hot upgraded" - that seems insane That's something that has to be engineered properly. I saw it done quite a long time ago via distinct versions distributed and then loaded in place of currently loaded .jar files (Java). Things stayed consistent. This one does require some forethought and developer discipline to do properly but it lets you build insanely high uptime systems without the clunkiness and waste of current approaches. I guess the current approach works too, but this is just so elegant. I agree about this stuff being PC-centric, but that's a function of the era in which it was developed. Nothing intrinsic about these systems prohibits their use in a cloudy environment. They'd just be deployed and used a little differently.

by theamk 2y ago

pjmlp 2y ago

> Given all of those reasons, it am not surprised at all that JVM/CLR are used for large business apps, while smaller things are written in other languages. And that means all the cool stuff is going to be C++/C/Rust/Python, while only the boring enterprise apps would be Java. There is enough cool stuff on Android, and embedded with Java. Also although not Java level, back in the 1990's there were already two attempts to have Smalltalk experience for C++, Lucid Energize C++ (after their Common Lisp pivot), and Visual Age for C++ v 4.0 (which introduced a image like concept for C++ development). Both failed due to hardware resources, and the related cost to have such a capable workstation. However, the LSP idea traces back to systems like Cadillac used by Lucid Energize C++, not surprising given that the main Visual Studio Code (nee Monaco) is Enrich Gamma from Eclipse fame. Delphi and C++ Builder still offer to this day, similar kind of IDE experience, ironically Visual C++ was never as RAD as C++ Builder, nor as visual. Additionally, Clion with clangd and Live++, offers some of the same experience that Energize C++ and Visual Age for C++ tried to make common in the 1990's.

theamk 2y ago
is embedded still using Java? I remember all the talk about java-on-a-chip in early 2000's (remember tini, "Java-On-A-Chip" from Dallas Semi?), and all the java on feature phones, but it seems all died out by now. I think the only place which has embdded + java now is one of those desktop/server class PC with gigs of RAM, and multiple gigahertz of CPU, and full-blown linux inside.
- pjmlp 2y ago
  Of course, and bare metal is still part of the picture, https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/products-services/jamaicavm/ https://www.aicas.com/products-services/jamaicavm/ https://www.microej.com/ https://www.microej.com/ Additionally stuff like Cisco, Ricoh, Xerox,... have subsets that run as mini apps on their devices.

api 2y ago

Good points. A few responses: > "Everything is memory safe" means speed penalty Not much, and sometimes none if the optimizer is smart. See: Rust, Go. The JVM and CLR are not slow either, though they are a little less efficient than the former for legacy reasons... and of course like all benchmarks it will depend on the use case and code. > The same can be said about "Software can be hot upgraded" - that seems insane That's something that has to be engineered properly. I saw it done quite a long time ago via distinct versions distributed and then loaded in place of currently loaded .jar files (Java). Things stayed consistent. This one does require some forethought and developer discipline to do properly but it lets you build insanely high uptime systems without the clunkiness and waste of current approaches. I guess the current approach works too, but this is just so elegant. I agree about this stuff being PC-centric, but that's a function of the era in which it was developed. Nothing intrinsic about these systems prohibits their use in a cloudy environment. They'd just be deployed and used a little differently.