As I've said elsewhere, I think the interesting and - to my knowledge, unique - feature of Rust is that you get compile time errors if you try to use a pointer after it would have been freed or maintain more than one mutable reference to an object at any time in one thread or across threads. Also variable declarations are immutable by default and must be explicitly marked mutable. I haven't worked with C++ since 2005 and I haven't followed the standard changes, but as far as I know, C++11 and C++14 don't have an equivalent mechanism. So while you can write equally safe and stable C++ code, it requires a lot more careful concentration by the developer.
It seems to me that Servo is the use case. They wanted to start a Firefox redesign from the very beginning, and built a tool that they thought could give them the development experience and software results in a way better than just plain C++11 (since I think Servo was envisioned before the C++14 spec existed).
Thanks for taking the time to answer. I do appreciate it.
I think the carefully analyzed use case and maybe someday successful application is the Mozilla Servo project. Otherwise I agree with your points. I was more curious whether you thought the language design itself was flawed, and if so, how. I'm not a language design expert, this is just curiosity.
I know those projects aren't written in C++. I'm not suggesting they be rewritten in Rust, either. I'm just saying that you have some developers highly skilled at writing secure code working on both projects, and mistakes are still made. Even superb developers benefit from improved tools.
If you feel like going into it, what is Rust lacking?
Every language is a particular compromise between safety, complexity, and performance. Rust clearly puts safety first, performance second, and complexity third but the result isn't that complex and the performance is - no hyperbole - on the level with well written C or C++. Considering the volume of disclosed security vulnerabilities even coming from high profile projects with brilliant teams like the OpenSSL project or the Linux kernel, I think that's a useful target.
It's open source under the MPL license, so unless there's some serious bitrot you should be safe to keep using the last stable release for a very long time.
I don't think Jeff Bezos is good to his workers and I know the Walton family makes its money by grinding its rank and file employees into powder. So there are no heroes here. I think the fact that they're competing is good, I don't want to see either one establish a monopoly.
Walmart isn't selling cloud services, it's making the code it uses to run its own internal cloud as open source. It's a three way win for Walmart:
1. Good publicity (we all hate Walmart).
2. They can use community contributions to their code to make their own internal cloud better.
3. Some other Amazon Web Services customers might use Walmart's code to run their own internal cloud instead of using AWS. That might hurt Amazon profits - in a small way, of course - without costing Walmart anything.
Further, Amazon has always been a tech company. Amazon Web Services was originally built for the company's internal use:
1. Automatically creating, configuring, and adding virtual machines to the amazon.com site when demand spiked around holidays or the release of a hot product. Then automatically shutting off virtual machines and physical servers as demand dropped to save on power and cooling.
2. Adding redundancy between datacenters, so that a natural disaster or connection failure at one Amazon datacenter didn't interrupt services to customers.
3. Providing the distributed redundant storage and data streaming to support their streaming video service.
I don't trust any public cloud with my private data, no matter what company owns it. But in terms of public cloud expertise, Amazon is every bit as good as Google, Microsoft, Rackspace, or any other major player in the cloud space.
The interesting feature of new programming languages is often not what they make possible - you can write any program in the world in assembler, after all - it's what they make default.
Rust doesn't allow null values or null pointers. The Rust compiler automatically frees memory when the last reference to it goes out of scope. Variables are immutable by default. You can't use pointer arithmetic by default. Only one mutable reference to any piece of memory is permitted to exist at any one time by the compiler.
You don't need a new programming language for those features, you can write code in any existing language that follows those conventions. But by making good software development practices the default and having the developer jump through extra hurdles to do things in a way that might be dangerous, the general level of code quality is improved. C or C++ might evolve to the same defaults in 20 or 30 years - but if you want to write low defect systems code quickly today, Rust deserves a look.
Also, the language designers list most of the features they listed and what they drew them from, and some features in the 0.x releases were dropped when they found few practical uses for them.
With that attitude, we'd all be using Fortran, Cobol, Lisp (okay, I like that idea) and Pascal instead of the newfangled stuff.
If you have to sell some relatively obscure language to a big team, or to a corporation or whatever, then yes I agree with you - go with the tried and true (even if it's also painful and tedious) unless you have a hell of a specific killer feature as a reason for using the new tool instead of the old one.
But for smaller side projects, personal projects, experimenting - why not?
Right. Any cloud backup is reliable if you encrypt the data yourself before you give it to the service.
On the other hand, SpiderOak claims they encrypt everything before it leaves your computer, and if you lose your password they insist they can't help you recover your data. Big portions of their code are open source, but not all. You still risk that a hacker or government agency court order will release a revision to the SpiderOak software that transmits your password to their servers. There's also tahoe-lafs from Least Authority, which is fully open source and does encrypt everything before uploading to the service - but the last time I tried it, it was a little irritating to set it up.
I understand your point, but if you were in Mexico and didn't have any money, what then? I presume the answer is, "you're fucked".
So yes, we can drive the cost of our health system way down by cutting socialized and legally required health insurance. But the people at the bottom level will simply die. You may be happy with that, the rest of us are not.
And if you counter that people will not be refused at hospitals - that's only true because the hospital can offset the expenses from destitute patients with higher fees for everyone else. If you take that away with free market competition, the situation will turn south. The whole rest of the first world does not have socialized medicine because they're a bunch of looney communists.
The Android Open Source Project (AOSP) is free for anyone to adopt for any use they see fit, as long as they comply with the terms of the component open source software licenses (GPLv2 for the kernel, Apache license for the rest). Amazon used that to make their own fork. For a while, so did Barnes & Noble. So AOSP has no control over hardware.
But to use the Android name on the resulting products, the companies have to enter a legal agreement with Google. Google could place restrictions on features in those contracts, like requiring :
removable storage
removable batteries
guaranteed software security updates within three months of the disclosure of any bug for the product for a minimum of, say, three years after its release.
Those requirements would help users and slow the crazy planned-obsolescence cycle of Android devices. But Google does not impose those requirements.
- The "systemd Titanic" has dozens of blog posts by Poettering and others explaining all of the design decisions behind it, and I can't fault anything. I've been using it since I switched to Fedora 18 from Ubuntu, and I never had a problem. git has dozen more complex integrated features in it than CVS, and I don't see anyone crying about that. I really don't understand the hatred. Do you want ext2 back, too? How about Linux kernel 2.2? Perl 4? Want to ditch vim and Emacs because they're bloatware compared to ed? Read your mail in alpine?
- Ubuntu Unity's market share is dropping, and GNOME 3 popularity started coming back as they added GNOME 2 UI features back. It was a blip on the radar, not some giant disastrous trend. Cinnamon, XFCE, LXDE, KDE 5, GNOME 3 Classic, and Mate are all very sensible and popular UIs.
- Android pretends to be open but mostly serves the profit engines of Google, Samsung, and the wireless carriers. Of course they're going to screw customers by dropping SD card readers or replaceable batteries. That drives customers to more expensive phones with more built in storage, or more expensive data plans, or newer phones. We should have never trusted the project in the first place.
- Making a mobile site that works as well as native code, even 'native' Java, on a small screen and limited resources is damn difficult.
- Hopefully storj.io and similar ideas make distributed cloud storage as cheap and secure as buying an extra disk and putting an encrypted volume on it.
- Mozilla has two goals with Firefox OS. First, to reverse the trend toward native apps on mobile - and you yourself were complaining about that, so I would think you like it. Second, the world has roughly twice as many smart phone users as traditional computer users, two billion versus one billion, and it's expected that in a few years there will be three or four billion smart phone users. Android and iOS are eating the consumer computing world, and Firefox OS is the best chance we have to prevent the consumer computing experience of the future from being a choice between a bunch of locked down proprietary alternatives.
Car Talk ( https://en.wikipedia.org/wiki/... ) was a one hour weekly radio show broadcast throughout most of the United States for 35 years. It was about 50% customers calling in with car repair and car purchase questions, and 50% puzzles and humor. They ended every show with a fictional list of people that worked on the show, and all of the names I used and hundreds more rotated through the list.
Good points. However, I think the JVM gives you things that might be difficult to add with cgroups and SELinux. But I may be wrong:
1. The JVM zeroes out all memory before handing it to an application, so your applications can't leak information to each other that way.
2. The javap disassembler makes easy decompiling of any Java application into a standard format that has specific references to APIs in the Java standard library, so I imagine it's straightforward to write code that disassembles each Java binary submitted to the Android store and then checks for illegal operations. Disassembling native binaries and scanning the code in an automated way for root exploits and malware is, I presume, technically more difficult. I would guess detecting code that, for example, mallocs a big buffer and then just reads the contents hoping to find a segment that cached your banking password would be difficult.
3. Require any code that your application loads dynamically have its digital signature checked first, and an absent or invalid signature blocks the load.
Otherwise yes, you can block file access and network access, constrain memory usage, constrain thread creation, etc... with security features native to Linux and not to the JVM. If I'm wrong, do correct me.
For that benchmarks site, they run the benchmark 66 times and discard the first run. That stops the JVM startup from counting as part of the benchmark. But 65 runs probably isn't enough for the JIT to kick in, at least not on some benchmarks.
Good points. I meant the code developers write for their applications, not popular libraries. Of course popular libraries get good security audits.
I use OpenJDK on Linux instead of the Oracle JDK, and "apt-get update" or "yum update" (or now on Fedora, "dnf upgrade") takes care of everything for me. For Windows, I just switched to the Azul Systems Zulu build of the OpenJDK for Windows. So far it works fine, but the only use it gets is running Minecraft for my kids. I do everything on Linux.
Sure. Oracle has really goofed with the Java Virtual Machine security. Funny thing, though: the JVM is written in C++. So:
1. You're making my point for me.
2. The JVM today is under a lot of scrutiny for security flaws, and is no longer getting a new zero day discovered every 87 minutes. Your new C++ code, or my new C++ code, doesn't get that same level of scrutiny. If we write our new code in Java, we get the benefits of the security audits in the JVM and aside from JVM errors the JVM prevents buffer overruns, pointer arithmetic, etc...
You're assuming that code spends most of its time computing. It spends an awful lot of time on I/O, and Python is every bit as fast at doing nothing as C is while either language waits for a file copy or data on a socket or the next user keystroke.
I wouldn't write Call of Duty 9 or video editing software or Bitcoin mining software in Python. But a blog? Software to tag mp3s? A media server? They're fine for slow languages. We developers spend a lot of time arguing about speed, but often we're working on projects where the differences are irrelevant.
OOP is intuitive at the micro-level. I have an animal class, and mammal extends animal, and dog extends mammal, very simple and straightforward.
But OOP code in a complex project is, in my experience, always a nightmare to understand. I want my animal reference to a dog object to move. I look in dog and I see that it uses legged-animal-move, which might be from a trait or mixin (Scala or Ruby) or another parent class through multiple inheritance (C++) and it turns out that legged-animal-move needs a reference to the current position of the animal so I need to go back to dog and back up the inheritance chain to animal and grab the position reference, and it turns out the dog is on grass. Now I have to apply the visitor pattern on the grass object visited by the legged-animal-move mover class. As part of that visitor pattern function on grass, I need a reference to any other animals that might be in the same spot to detect collision. So I go up the grass class hierarchy to its great grandparent class generic-position and retrieve its instance list of animals at that position.... and before you know it, to figure out if the dog can move two steps forward I have sixteen files open in my IDE and the debugger is running and I'm looking at things like AbstractSingletonProxyFactoryBeanFactoryManager wondering what I did to piss off god.
To me, the real value of functional programming is that the data you want to understand and the code that's currently manipulating that data is right in front of you. My function takes as an input an attribute map (or associative array, or dict) named 'animal' with things like type->dog name->fido position_x->22, etc... and a second input map with a direction and a distance and as a third input a list of maps in sorted order by position_x. I get the position_x of the first input, use the second input to figure out the path of desired travel, and then use a binary search on the third input to find all possible collisions. There might be a few helper functions involved, but it all takes place right in front of me. One file.
Also - Android was written in Java so developers could work on Windows, Linux, or OS X and so Google could attract the millions of existing developers that know Java around the world. Google didn't pick the language because they wanted the language, they picked the language because they wanted the ecosystem.
Also, arguably JVM applications are easier to audit for security and sandbox than native applications.
1. The Java Virtual Machine loads most of the standard library at startup, which is part of reason it starts so slowly and uses so much memory just for "Hello World".
2. Java bytecode is interpreted and profiled for the first 10,000 or so runs through any code path, so at that point it's not much faster than Python or Perl. Then after 10,000 times through a code path, the JIT-compiler kicks in and uses the profile information to rewrite the interpreted code as native code. Then Java becomes much faster than traditional interpreted languages, though still usually much slower than well-written C++ or C.
3. The amount of memory you allocate to the Java Virtual Machine can have a huge impact on performance for long-running processes. If your process keeps running near the memory limit, the garbage collector will have to run very often, maybe multiple times per second, and you'll spend large amounts of time in garbage collection. If you are able to allocate enough memory that the garbage collector rarely needs to run, that in turn will help a lot.
So if you're benchmarking "Hello World" in Java, or a Java program that has an execution time of just a few seconds, then your benchmarking methods are fine and Java is definitely not what you want. If you're trying to get an accurate evaluation of Java speed for a web server or some other long-running service, you need to test Java running as a web server or long-running service, run the benchmark for a few minutes to get an accurate picture of throughput in production, and tune the memory allocation to see how that impacts speed.
Slashdot Mirror
As I've said elsewhere, I think the interesting and - to my knowledge, unique - feature of Rust is that you get compile time errors if you try to use a pointer after it would have been freed or maintain more than one mutable reference to an object at any time in one thread or across threads. Also variable declarations are immutable by default and must be explicitly marked mutable. I haven't worked with C++ since 2005 and I haven't followed the standard changes, but as far as I know, C++11 and C++14 don't have an equivalent mechanism. So while you can write equally safe and stable C++ code, it requires a lot more careful concentration by the developer.
It seems to me that Servo is the use case. They wanted to start a Firefox redesign from the very beginning, and built a tool that they thought could give them the development experience and software results in a way better than just plain C++11 (since I think Servo was envisioned before the C++14 spec existed).
Thanks for taking the time to answer. I do appreciate it.
I think the carefully analyzed use case and maybe someday successful application is the Mozilla Servo project. Otherwise I agree with your points. I was more curious whether you thought the language design itself was flawed, and if so, how. I'm not a language design expert, this is just curiosity.
You're right, of course. Sorry for the incorrect statement.
I know those projects aren't written in C++. I'm not suggesting they be rewritten in Rust, either. I'm just saying that you have some developers highly skilled at writing secure code working on both projects, and mistakes are still made. Even superb developers benefit from improved tools.
If you feel like going into it, what is Rust lacking?
Every language is a particular compromise between safety, complexity, and performance. Rust clearly puts safety first, performance second, and complexity third but the result isn't that complex and the performance is - no hyperbole - on the level with well written C or C++. Considering the volume of disclosed security vulnerabilities even coming from high profile projects with brilliant teams like the OpenSSL project or the Linux kernel, I think that's a useful target.
It's open source under the MPL license, so unless there's some serious bitrot you should be safe to keep using the last stable release for a very long time.
Thanks for the laugh. I do think Rust has those features.
If you didn't already know it, Walmart is planning to launch an Amazon Prime competitor: http://www.usatoday.com/story/...
I don't think Jeff Bezos is good to his workers and I know the Walton family makes its money by grinding its rank and file employees into powder. So there are no heroes here. I think the fact that they're competing is good, I don't want to see either one establish a monopoly.
Walmart isn't selling cloud services, it's making the code it uses to run its own internal cloud as open source. It's a three way win for Walmart:
1. Good publicity (we all hate Walmart).
2. They can use community contributions to their code to make their own internal cloud better.
3. Some other Amazon Web Services customers might use Walmart's code to run their own internal cloud instead of using AWS. That might hurt Amazon profits - in a small way, of course - without costing Walmart anything.
Further, Amazon has always been a tech company. Amazon Web Services was originally built for the company's internal use:
1. Automatically creating, configuring, and adding virtual machines to the amazon.com site when demand spiked around holidays or the release of a hot product. Then automatically shutting off virtual machines and physical servers as demand dropped to save on power and cooling.
2. Adding redundancy between datacenters, so that a natural disaster or connection failure at one Amazon datacenter didn't interrupt services to customers.
3. Providing the distributed redundant storage and data streaming to support their streaming video service.
I don't trust any public cloud with my private data, no matter what company owns it. But in terms of public cloud expertise, Amazon is every bit as good as Google, Microsoft, Rackspace, or any other major player in the cloud space.
The interesting feature of new programming languages is often not what they make possible - you can write any program in the world in assembler, after all - it's what they make default.
Rust doesn't allow null values or null pointers. The Rust compiler automatically frees memory when the last reference to it goes out of scope. Variables are immutable by default. You can't use pointer arithmetic by default. Only one mutable reference to any piece of memory is permitted to exist at any one time by the compiler.
You don't need a new programming language for those features, you can write code in any existing language that follows those conventions. But by making good software development practices the default and having the developer jump through extra hurdles to do things in a way that might be dangerous, the general level of code quality is improved. C or C++ might evolve to the same defaults in 20 or 30 years - but if you want to write low defect systems code quickly today, Rust deserves a look.
Also, the language designers list most of the features they listed and what they drew them from, and some features in the 0.x releases were dropped when they found few practical uses for them.
With that attitude, we'd all be using Fortran, Cobol, Lisp (okay, I like that idea) and Pascal instead of the newfangled stuff.
If you have to sell some relatively obscure language to a big team, or to a corporation or whatever, then yes I agree with you - go with the tried and true (even if it's also painful and tedious) unless you have a hell of a specific killer feature as a reason for using the new tool instead of the old one.
But for smaller side projects, personal projects, experimenting - why not?
Right. Any cloud backup is reliable if you encrypt the data yourself before you give it to the service.
On the other hand, SpiderOak claims they encrypt everything before it leaves your computer, and if you lose your password they insist they can't help you recover your data. Big portions of their code are open source, but not all. You still risk that a hacker or government agency court order will release a revision to the SpiderOak software that transmits your password to their servers. There's also tahoe-lafs from Least Authority, which is fully open source and does encrypt everything before uploading to the service - but the last time I tried it, it was a little irritating to set it up.
I understand your point, but if you were in Mexico and didn't have any money, what then? I presume the answer is, "you're fucked".
So yes, we can drive the cost of our health system way down by cutting socialized and legally required health insurance. But the people at the bottom level will simply die. You may be happy with that, the rest of us are not.
And if you counter that people will not be refused at hospitals - that's only true because the hospital can offset the expenses from destitute patients with higher fees for everyone else. If you take that away with free market competition, the situation will turn south. The whole rest of the first world does not have socialized medicine because they're a bunch of looney communists.
The Android Open Source Project (AOSP) is free for anyone to adopt for any use they see fit, as long as they comply with the terms of the component open source software licenses (GPLv2 for the kernel, Apache license for the rest). Amazon used that to make their own fork. For a while, so did Barnes & Noble. So AOSP has no control over hardware.
But to use the Android name on the resulting products, the companies have to enter a legal agreement with Google. Google could place restrictions on features in those contracts, like requiring :
removable storage
removable batteries
guaranteed software security updates within three months of the disclosure of any bug for the product for a minimum of, say, three years after its release.
Those requirements would help users and slow the crazy planned-obsolescence cycle of Android devices. But Google does not impose those requirements.
Relax, it's you.
- The "systemd Titanic" has dozens of blog posts by Poettering and others explaining all of the design decisions behind it, and I can't fault anything. I've been using it since I switched to Fedora 18 from Ubuntu, and I never had a problem. git has dozen more complex integrated features in it than CVS, and I don't see anyone crying about that. I really don't understand the hatred. Do you want ext2 back, too? How about Linux kernel 2.2? Perl 4? Want to ditch vim and Emacs because they're bloatware compared to ed? Read your mail in alpine?
- Ubuntu Unity's market share is dropping, and GNOME 3 popularity started coming back as they added GNOME 2 UI features back. It was a blip on the radar, not some giant disastrous trend. Cinnamon, XFCE, LXDE, KDE 5, GNOME 3 Classic, and Mate are all very sensible and popular UIs.
- Android pretends to be open but mostly serves the profit engines of Google, Samsung, and the wireless carriers. Of course they're going to screw customers by dropping SD card readers or replaceable batteries. That drives customers to more expensive phones with more built in storage, or more expensive data plans, or newer phones. We should have never trusted the project in the first place.
- Making a mobile site that works as well as native code, even 'native' Java, on a small screen and limited resources is damn difficult.
- Hopefully storj.io and similar ideas make distributed cloud storage as cheap and secure as buying an extra disk and putting an encrypted volume on it.
- Mozilla has two goals with Firefox OS. First, to reverse the trend toward native apps on mobile - and you yourself were complaining about that, so I would think you like it. Second, the world has roughly twice as many smart phone users as traditional computer users, two billion versus one billion, and it's expected that in a few years there will be three or four billion smart phone users. Android and iOS are eating the consumer computing world, and Firefox OS is the best chance we have to prevent the consumer computing experience of the future from being a choice between a bunch of locked down proprietary alternatives.
Car Talk ( https://en.wikipedia.org/wiki/... ) was a one hour weekly radio show broadcast throughout most of the United States for 35 years. It was about 50% customers calling in with car repair and car purchase questions, and 50% puzzles and humor. They ended every show with a fictional list of people that worked on the show, and all of the names I used and hundreds more rotated through the list.
Good points. However, I think the JVM gives you things that might be difficult to add with cgroups and SELinux. But I may be wrong:
1. The JVM zeroes out all memory before handing it to an application, so your applications can't leak information to each other that way.
2. The javap disassembler makes easy decompiling of any Java application into a standard format that has specific references to APIs in the Java standard library, so I imagine it's straightforward to write code that disassembles each Java binary submitted to the Android store and then checks for illegal operations. Disassembling native binaries and scanning the code in an automated way for root exploits and malware is, I presume, technically more difficult. I would guess detecting code that, for example, mallocs a big buffer and then just reads the contents hoping to find a segment that cached your banking password would be difficult.
3. Require any code that your application loads dynamically have its digital signature checked first, and an absent or invalid signature blocks the load.
Otherwise yes, you can block file access and network access, constrain memory usage, constrain thread creation, etc... with security features native to Linux and not to the JVM. If I'm wrong, do correct me.
For that benchmarks site, they run the benchmark 66 times and discard the first run. That stops the JVM startup from counting as part of the benchmark. But 65 runs probably isn't enough for the JIT to kick in, at least not on some benchmarks.
Good points. I meant the code developers write for their applications, not popular libraries. Of course popular libraries get good security audits.
I use OpenJDK on Linux instead of the Oracle JDK, and "apt-get update" or "yum update" (or now on Fedora, "dnf upgrade") takes care of everything for me. For Windows, I just switched to the Azul Systems Zulu build of the OpenJDK for Windows. So far it works fine, but the only use it gets is running Minecraft for my kids. I do everything on Linux.
Sure. Oracle has really goofed with the Java Virtual Machine security. Funny thing, though: the JVM is written in C++. So:
1. You're making my point for me.
2. The JVM today is under a lot of scrutiny for security flaws, and is no longer getting a new zero day discovered every 87 minutes. Your new C++ code, or my new C++ code, doesn't get that same level of scrutiny. If we write our new code in Java, we get the benefits of the security audits in the JVM and aside from JVM errors the JVM prevents buffer overruns, pointer arithmetic, etc...
You're assuming that code spends most of its time computing. It spends an awful lot of time on I/O, and Python is every bit as fast at doing nothing as C is while either language waits for a file copy or data on a socket or the next user keystroke.
I wouldn't write Call of Duty 9 or video editing software or Bitcoin mining software in Python. But a blog? Software to tag mp3s? A media server? They're fine for slow languages. We developers spend a lot of time arguing about speed, but often we're working on projects where the differences are irrelevant.
OOP is intuitive at the micro-level. I have an animal class, and mammal extends animal, and dog extends mammal, very simple and straightforward.
But OOP code in a complex project is, in my experience, always a nightmare to understand. I want my animal reference to a dog object to move. I look in dog and I see that it uses legged-animal-move, which might be from a trait or mixin (Scala or Ruby) or another parent class through multiple inheritance (C++) and it turns out that legged-animal-move needs a reference to the current position of the animal so I need to go back to dog and back up the inheritance chain to animal and grab the position reference, and it turns out the dog is on grass. Now I have to apply the visitor pattern on the grass object visited by the legged-animal-move mover class. As part of that visitor pattern function on grass, I need a reference to any other animals that might be in the same spot to detect collision. So I go up the grass class hierarchy to its great grandparent class generic-position and retrieve its instance list of animals at that position.... and before you know it, to figure out if the dog can move two steps forward I have sixteen files open in my IDE and the debugger is running and I'm looking at things like AbstractSingletonProxyFactoryBeanFactoryManager wondering what I did to piss off god.
To me, the real value of functional programming is that the data you want to understand and the code that's currently manipulating that data is right in front of you. My function takes as an input an attribute map (or associative array, or dict) named 'animal' with things like type->dog name->fido position_x->22, etc... and a second input map with a direction and a distance and as a third input a list of maps in sorted order by position_x. I get the position_x of the first input, use the second input to figure out the path of desired travel, and then use a binary search on the third input to find all possible collisions. There might be a few helper functions involved, but it all takes place right in front of me. One file.
Also - Android was written in Java so developers could work on Windows, Linux, or OS X and so Google could attract the millions of existing developers that know Java around the world. Google didn't pick the language because they wanted the language, they picked the language because they wanted the ecosystem.
Also, arguably JVM applications are easier to audit for security and sandbox than native applications.
Just to be clear:
1. The Java Virtual Machine loads most of the standard library at startup, which is part of reason it starts so slowly and uses so much memory just for "Hello World".
2. Java bytecode is interpreted and profiled for the first 10,000 or so runs through any code path, so at that point it's not much faster than Python or Perl. Then after 10,000 times through a code path, the JIT-compiler kicks in and uses the profile information to rewrite the interpreted code as native code. Then Java becomes much faster than traditional interpreted languages, though still usually much slower than well-written C++ or C.
3. The amount of memory you allocate to the Java Virtual Machine can have a huge impact on performance for long-running processes. If your process keeps running near the memory limit, the garbage collector will have to run very often, maybe multiple times per second, and you'll spend large amounts of time in garbage collection. If you are able to allocate enough memory that the garbage collector rarely needs to run, that in turn will help a lot.
So if you're benchmarking "Hello World" in Java, or a Java program that has an execution time of just a few seconds, then your benchmarking methods are fine and Java is definitely not what you want. If you're trying to get an accurate evaluation of Java speed for a web server or some other long-running service, you need to test Java running as a web server or long-running service, run the benchmark for a few minutes to get an accurate picture of throughput in production, and tune the memory allocation to see how that impacts speed.