Java has had hot code swapping that works in some cases, but not all. If one of the toolkits you use doesn't support it, or you're working in one of the library dependencies for your project at the same time you're working on the project (e.g. you're working in foo and bar at the same time, and bar uses foo.jar at runtime), you can't use it.

Maybe I'm just unlucky, but in all the places I worked Java hot code swapping covered such a tiny sliver of the work we did that none of the developers used it more than a few days per year.

I suspect the real killer feature of Node.js for people coming from Java and C# is the development cycle. Edit, save, hit F5 in the browser. Despite everything ugly about Javascript, that's handy.

Granted, you can get that with Perl, Python, and Ruby too and if you restrict yourself to certain Java and C# features you can also have it there. But in practice I think a lot of server side programmers first saw the instant feedback loop of Node.js first, and fell in love with it.

That's either:

import java.util.List;
import java.util.Arrays; (or equivalently but not recommended, import java.util.*;)
List<Integer> nums = Arrays.asList(1,2,3,4);

or
java.util.List<Integer> nums = java.util.Arrays.asList(1,2,3,4);

Most other languages have literal syntax for lists, sets, etc... by default, and you don't have to waste your time with imports to use data structures that 70% of your source files will include anyway.

I've been using them for years on Windows and Linux. The Linux client has been clunky in the past, but it seems stable (albeit slow) now.

If you want to go full-free-software, I recommend Tahoe-LAFS (https://tahoe-lafs.org/trac/tahoe-lafs) you can run your own version with any server provider you want, or buy their service https://leastauthority.com/ ...the last time I tried to use it, the setup was too complex to be worth the hassle and I gave up. But that was nearly five years ago, it may be much more user-friendly now.

At least for me, 3. follows from 1. I hate them because they're so dishonest with their sales and billing.

I've actually had a really good experience with Comcast support staff, service technicians, and sales staff at their offices. Their sales and billing teams on the phone are hopelessly disorganized and deceptive - presumably intentionally slow. But every time I walked into an office and explained what my billing problem was, it was fixed in three minutes.

Plus:

1. Cable television brochures lie worse than politicians, and everyone knows it. That "Bundle that adds television service for just $10 more than you're paying for internet" doesn't include the $7 regional channel fee, $5 regional sports fee, $7 monthly equipment rental, $9 monthly DVR network service fee, two year contract with a $30 price jump after the first year, and $5 charge applied to customers that handle their own billing instead of providing the vendor with their banking information so they can use auto-billing. You're actually adding $58 per month across the two years to your bill, not $10. Netflix et al don't lie on their price advertising like that.

2. Most of these customers are going to have internet, Netflix, and Amazon Prime anyway.

P.S. I try to avoid brand groupthink too. I guess we're both stupid.

And I should have added, I am not condemning you for your choice. I respect it. I'm kicking around the idea of making the same choice with respect to mobile phones, since my Motorola Android device hasn't received some major security fixes since it was all of nine months old. I wonder if the FSF would send back my dues if they knew. :) I'm just saying that it's bad for all of us that the freedom-respecting choices are so rare and so poor.

Yes, locked. Can you take the movies you buy on iOS and legally transfer them to your Linux or W10 laptop? Can you buy any laptop you like and put MacOS on it? When your iPhone stops receiving security updates from Apple, do you have any choice other than "trash it" and "run without security fixes"? When Apple decides to change some core feature you don't like, can you fork the code - or pay someone else to fork the code, or take advantage of a fork someone else made - to go back to the old behavior? Can you port the applications you like to other hardware? Operating systems?

Yes, locked. Now again, I'm not saying the situation with Android is better. While Android has the potential to be as open as a typical Linux distribution like Debian or Gentoo, in practice it's nearly as bad as Apple in most respects and worse in a few key respects - namely, security upgrades over the life of a product.

Contrast all of that to running a free software environment like Debian, Gentoo, Arch, Fedora, Suse, etc... or even FreeBSD and its derivatives. Moving movies around is technically possible. Any hardware with drivers is supported and you have the freedom and legal right to create or help fund the create drivers for other hardware. Security fixes are indefinite, typically when hardware is dropped from Linux kernel support it's 15 years or more after it stopped being sold to consumers. That's freedom. No locks. It's what we should have everywhere.

If you work at a place that puts a lot of stock in KLOC metrics, you have bigger problems than deciding what JVM language to use.

If all other things are equal between two languages, a developer will be more productive in the one that lets them accomplish more in fewer LOC without sacrificing readability. So just to be crystal clear, I'm not advocating you compare, say, idiomatic Java with obfuscated Perl that uses every Perl 5 implicit variable abbreviation trick in the book. That Perl may do twenty times as much per line, but good luck maintaining it. (I'm not knocking Perl. Well-written Perl is excellent. We use it for a lot of tasks at work. But that's because everyone working on it is far too smart to show off how clever they are by writing unmaintainable, unreadable abbreviated junk.) But for any Java program much more than a hundred lines wrong you can write a Kotlin/Ceylon/Scala equivalent with the same logic that's 50-90% shorter.

You're right, and I'm sorry I didn't make that clearer. The extra 100ms was for the JVM startup, and the actual execution speed of Java is very fast.

If you want to see a good illustration of Java's speed, look at the Techempower benchmarks. In some cases Java still has the performance lead over C++. Only in one or two benchmarks does C++ have a substantial lead, and even then it's not even a 2x advantage.

It's not 8 times slower. It takes 100 ms extra to start, and then runs almost as quickly as C.

Check out the Great Computer Language Shootout Game, or the Techempower framework benchmarks.

Oh, on top of the reasons you stated there's one more: a lot of these wireless chips, GPS, etc... license components or software from other vendors, and the manufacturer may not have the right to release their code as open. This is one of the objections I think AMD raised when they were asked to make the code for their Platform Security Processor open source.

Everything is locked because the current market makes that the profitable way to go. We've got to figure out how to put the incentive towards opening everything. I realize I'm being idealistic and I don't have a concrete path forward. But consider that, for example, if you get a device driver expected into the mainline Linux kernel then you don't have to backport security fixes to older kernels. You can just use the latest kernel to supply customers with the fix. So that would be a great motivator for companies to open things - but consumers just take for granted that newer security fixes flat out aren't coming.

I absolutely grant that iOS is better than Android in this respect. But even if it's a royal pain in the neck to get LineageOS or some other Android Open Source Project fork onto smart phones, at least it can be done. There's some interaction with open source. The iOS may provide longer product life, but you are locked solidly to Apple.

Nonsense. Even with Java 8 the Java language is years behind Scala/Kotlin/Ceylon.

1. If you want to make a Java class with 6 different fields that are set in the constructor and then final, with idiomatic Java syntax that's 16 lines of code. If you follow Java convention and make getters for the 6 fields you're up to 34. Scala, Kotlin, and Ceylon have things like a Scala case class or equivalent to handle it one line.

2. Java 8 does better with language literals for constructing lists, sets, and maps. But it still doesn't have the convenience of val nums: List[Int] = List(1, 2, 3, 4) in Scala or equivalent in others.

3. Java doesn't have convenient constructor overloading and default constructor or function input parameters. If you want to call a function that has 3 different optional inputs in any combination in Java, you either have to do lots of foo(null, null, null), foo(x, null, null), foo(null, y, z), foo(x, null, z), etc... or declare eight different versions of the function. Scala/Kotlin/Ceylon have default parameters, so you declare one function and still never pass in nulls.

4. Java if statements don't return anything. Scala and Kotlin (and Ceylon?) have if statements return a value, so that instead of using the ternary operator you can do y = if (x > 7) "bigger than 7" else "less than 7".

5. Java doesn't allow operator overloading. Scala goes berserk with it (I'm not a fan). Kotlin and Ceylon allow limited operator overloading in places where it makes sense. In both languages you can make a class that holds, say, imaginary numbers (1 + 3i) and then use operator overloading to manipulate them with regular +, -, /, etc... instead of Java's .add, .subtract, etc....

6. Java still has checked exceptions that must be declared and thrown in code that uses a lot of the older standard library. Scala, Kotlin, and Ceylon let you use try/catch when it's appropriate but doesn't force you to declare or catch checked exceptions.

So Java is in a constant game of catch-up with these languages, and even with the improvements in 8 and 9 it's still nowhere near as clean and straightforward to use as these three.