> The last thing you want for that type of programming is a huge, complex virtual machine to worry about. That plus memory issues, slow compiles, complex deploy

> The last thing you want for that type of programming is a huge, complex virtual machine to worry about. That plus memory issues, slow compiles, complex deployments makes it not really in the running. Sorry, but I don't buy this at all. golang also ships with a runtime, that's why binaries are dozens of MBs. The JVM is very configurable, which is what I assume you mean when you say "complex". This configurability is what allows it to be tuned to the task at hand. You can cap the maximum memory it's allowed to use, try out different GCs based on your use cases, etc. Compilation times are not slow the least bit, especially with incremental compilation. Incidentally, for the majority of the time, it takes way less time from when I press the run button for a Java/Kotlin project in the IDE to having it up and running, compared to projects I worked on in golang, where the entire code base has to be rebuilt. People keep repeating things like "memory issues" or "complex deployments". For a long time now, people have been shipping self-contained "fat" or "uber" jars. Running them is as simple as `java -jar program.jar`. And since the JVM defaults to G1, memory usage is generally less - the JVM is tuned for performance at the expense of memory saving, but that can obviously be changed, even more so recently with GraalVM[1]. Java has already been used on embedded systems (including card readers) - even Spring that has a reputation for being "bloated" can run on a Raspberry Pi. [1] https://quarkus.io/ https://quarkus.io/