5 ms·

Nothing irritates me more than having an unnecessary virtual machine slow down my code by a factor of 2 or more, hogging memory, and putting a huge headwind on

Nothing irritates me more than having an unnecessary virtual machine slow down my code by a factor of 2 or more, hogging memory, and putting a huge headwind on startup times. It all just grates against my engineering soul. It's like riding a bicycle wearing platform shoes. And it's the #1 reason that I will never target Android for my code (also being forced to OOP). It's not like there are thousands of architectures out there. There's x86 and ARM. Which language doesn't already do both, natively? We don't need this JVM anymore, especially in the era of LLVM, though I acknowledge that corporate intertia means it will never die. However please, corporate drones, do not try to push Java into IoT. Give us a break.

brashrat 11y ago
it grates against my engineering soul when so many of my fellow engineers forget that the x86's themselves are virtual machines, microcoded architectures that implement x86's. And that any OS's job upon booting is to present a new virtual machine to the user--which is why the same box can be booted as a Windows machine, a unix machine, or a Macintosh--and so to add some additional code to simultaneously present additional virtual machine abstractions is not bad engineering, it's the very stuff of engineering. Abstractions are an efficient way to reduce the complexity of complex problems, and a virtual machine that allows the same code to run on top of different architectures can't be said to be "unnecessary".
- vegabook 11y ago
  There is no need for the JVM abstraction anymore, since the multiple architectures of the 90s such as Sun SPARC, SGI, Mips, PowerPC, X86, DEC Alpha, AS/400, have been pared back basically to two. Moreover, the more modern abstraction is the LLVM, which is targeted at the right level - compiler writers - without saddling the programmers and users with a bloated code translation layer that they must cart around everywhere they go. The JVM does nothing for a programmer, abstraction wise, that makes Java easier than, for example, Golang.
  - tadfisher 11y ago
    Well, Android also supports MIPS, so there's three. Then there are the 64-bit variants, making six. Then there are the various levels of ARM compatibility and extension instruction sets, like Thumb-1 and Thumb-2. Android supports two broad sets of 32-bit ARM platforms, so in total you have seven target ABIs [1]. All of which I'm sure LLVM makes completely transparent to the developer and ekes out the same level of performance as an on-device JIT. Note that the preceding sentence was sarcasm. In reality, the VM mostly does not exist on Android beyond what's needed for a compatible runtime. The ART compiler emits machine code [2], or with the latest iteration, mostly machine code with stubs for JIT targets. Said code is in ELF binary format. [1] http://developer.android.com/ndk/guides/abis.html http://developer.android.com/ndk/guides/abis.html [2] https://source.android.com/devices/tech/dalvik/#features https://source.android.com/devices/tech/dalvik/#features
    - deleted 11y ago
      [deleted]
    - vegabook 11y ago
      "ekes out", that's rich. After taxing your native performance at least 50%, it's now eeking out performance. Haha.
      - tadfisher 11y ago
        50% over... C? That's quite respectable for a fully-managed OO language. Go can't even get close to that for the non-assembly-implemented parts of the standard lib. The synthetic benchmarks on ART agree with you, BTW. At that level of performance, your primary hits are I/O and UI, and that's not something a faster language target is going to improve. If you are writing tight loops for, say, scientific number-crunching, you should be writing assembly or doing GPGPU anyway. In the real world, with real applications, Java is not the bottleneck on Android; bad programmers and bad APIs are. Swift is pretty cool though.
        vegabook 11y ago
gozur88 11y ago
OOP is fine for mobile platforms, which also have plenty of power to run the VM unless your app is a FPS or something along those lines. To the extent that mobile apps are slow they're usually slow because they're waiting for a server somewhere to respond or the code is just poorly written.
paulddraper 11y ago
I agree. I just haven't found a good enough alternative. The community, the tooling, the development efficiency, the performance, the run-time debuggability, etc. C is painful for abstractions, C++ is not for mortal men, Go is hardly typesafe, Haskell is niche, and Rust only barely hit stability. I'm a wimp and when I'm creating something that puts food on the table, I choose the JVM (Java or Scala).
- tadfisher 11y ago
  Java is the worst managed language, except for all the others we have tried from time to time.
MaggieL 11y ago
There's an experimental version of Scala targeting LLVM. And we already have one targeting JavaScript... The performance of JIT and Hotspot can exceed hand-written C, by the way. If you wanna be close to the (putative) metal, you better be good at it.

brashrat 11y ago

it grates against my engineering soul when so many of my fellow engineers forget that the x86's themselves are virtual machines, microcoded architectures that implement x86's. And that any OS's job upon booting is to present a new virtual machine to the user--which is why the same box can be booted as a Windows machine, a unix machine, or a Macintosh--and so to add some additional code to simultaneously present additional virtual machine abstractions is not bad engineering, it's the very stuff of engineering. Abstractions are an efficient way to reduce the complexity of complex problems, and a virtual machine that allows the same code to run on top of different architectures can't be said to be "unnecessary".

vegabook 11y ago
There is no need for the JVM abstraction anymore, since the multiple architectures of the 90s such as Sun SPARC, SGI, Mips, PowerPC, X86, DEC Alpha, AS/400, have been pared back basically to two. Moreover, the more modern abstraction is the LLVM, which is targeted at the right level - compiler writers - without saddling the programmers and users with a bloated code translation layer that they must cart around everywhere they go. The JVM does nothing for a programmer, abstraction wise, that makes Java easier than, for example, Golang.
- tadfisher 11y ago
  Well, Android also supports MIPS, so there's three. Then there are the 64-bit variants, making six. Then there are the various levels of ARM compatibility and extension instruction sets, like Thumb-1 and Thumb-2. Android supports two broad sets of 32-bit ARM platforms, so in total you have seven target ABIs [1]. All of which I'm sure LLVM makes completely transparent to the developer and ekes out the same level of performance as an on-device JIT. Note that the preceding sentence was sarcasm. In reality, the VM mostly does not exist on Android beyond what's needed for a compatible runtime. The ART compiler emits machine code [2], or with the latest iteration, mostly machine code with stubs for JIT targets. Said code is in ELF binary format. [1] http://developer.android.com/ndk/guides/abis.html http://developer.android.com/ndk/guides/abis.html [2] https://source.android.com/devices/tech/dalvik/#features https://source.android.com/devices/tech/dalvik/#features
  - deleted 11y ago
    [deleted]
  - vegabook 11y ago
    "ekes out", that's rich. After taxing your native performance at least 50%, it's now eeking out performance. Haha.
    - tadfisher 11y ago
      50% over... C? That's quite respectable for a fully-managed OO language. Go can't even get close to that for the non-assembly-implemented parts of the standard lib. The synthetic benchmarks on ART agree with you, BTW. At that level of performance, your primary hits are I/O and UI, and that's not something a faster language target is going to improve. If you are writing tight loops for, say, scientific number-crunching, you should be writing assembly or doing GPGPU anyway. In the real world, with real applications, Java is not the bottleneck on Android; bad programmers and bad APIs are. Swift is pretty cool though.
      - vegabook 11y ago

gozur88 11y ago

OOP is fine for mobile platforms, which also have plenty of power to run the VM unless your app is a FPS or something along those lines. To the extent that mobile apps are slow they're usually slow because they're waiting for a server somewhere to respond or the code is just poorly written.

paulddraper 11y ago

I agree. I just haven't found a good enough alternative. The community, the tooling, the development efficiency, the performance, the run-time debuggability, etc. C is painful for abstractions, C++ is not for mortal men, Go is hardly typesafe, Haskell is niche, and Rust only barely hit stability. I'm a wimp and when I'm creating something that puts food on the table, I choose the JVM (Java or Scala).

tadfisher 11y ago
Java is the worst managed language, except for all the others we have tried from time to time.

MaggieL 11y ago

There's an experimental version of Scala targeting LLVM. And we already have one targeting JavaScript... The performance of JIT and Hotspot can exceed hand-written C, by the way. If you wanna be close to the (putative) metal, you better be good at it.