This makes multi-core performance a non-starter. Sure, you can run more INSTANCES of the language with multiple cores, but you can't get any single instance of a script to run any faster than what a single core can do.
Take Java for instance. It runs the garbage collector in parallel with the program itself so what you'll find is a lot of single-threaded apps end up using say 110% CPU time or more. Programs never written for multiple cores get a speed-up from running on them.
There's no reason scripting languages can't also do GC, or speculatively compile into native code on another core.
I will give you two tips for avoiding memory leaks (these are more important than avoiding segmentation faults, because they are harder to detect and debug).
Valgrind helps immensely. It will find most memory use after dealloc, double-frees, leaks, and seg faults. And it gives you a stack trace showing you exactly where the problem is.
I had a coworker diagnosing a problem for hours and couldn't figure out wtf was going on, so when he asked for help I made him run valgrind and it showed a memory use after free in 5 seconds. He knew full well about valgrind, but he's just incompetent You'd have to be not to use it when writing C code.
Yes!! Because it feels more responsive thanks to its use of several process..
How responsive does it feel when you leave Chrome running and switch over to Unreal Tournament 3? Or Warcraft? I've never needed to close out firefox because I always have an idle CPU for whatever else I'm working on.
So my point is that the market might have more important factors than 'feeling responsive'. Like for instance 'dont have to close a bunch of tabs in order to play a game'. You don't know what those factors are, I don't know what they are. Only the invisible hand knows...
No user cares about the architecture unless if gives them actual benefits. Firefox addons undeniably give huge benefits to many users.
The only architectural feature of Chrome of note is separate processes per tab. But is that a benefit?
First of all, any crash is unacceptable, and I've been running beta firefox on a daily basis at work and the last time it crashed for me was several months ago. So this is basically no benefit. The only real benefit for stability is running flash in a separate process, which firefox already does with nspluginwrapper.
Now performance. Chrome can make better use of multiple processors, which is great, but it means if you have two tabs open with flash on your dual-core then all your other programs have to compete for resources instead of having an idle CPU to use. Or if you are single-core then you have twice as many procs competing for resources with everything else, making everything else more sluggish. Granted, those are bullshit reasons technically BUT what matter is only what users actually prefer and not what is technically 'best'. Users might prefer all their other apps to be snappy more than their tabs to multitask well.
Memory usage. Chrome can recover memory better when a tab closes, but it wastes more memory for a tab to be open (duplicated images, etc). And once there are ad-ons that need to coordinate among multiple processes, is memory going to explode with each tab? Uncertain. Remember that Java also uses the same concept of a separate process per 'thing' and look how well that works out when you have lots of them running at once.
Frankly, if you give people a 'taste test' between firefox with chromifox theme (makes it look like Chrome) and Chrome, I think you'll find the browser architecture, except to geek fanboys, is pretty low on the totem pole.
When people say they want adblock and noscript and you say "just edit your hosts file" you sound like another fanboy making up excuses. When I was using adblock I had */ads/* and a bunch of others that are not even possible with a hosts file.
As for NoScript, I'm not a huge fan of it (its more of a pain then anything else
Wha? NoScript can occasionally be a mild hassle, but it basically automatically block all annoying ads automatically AND all that useless unrendered crap like google-analytics AND in practice it makes your browsing a hell of a lot more secure than separate processes.
Every scenario where data integrity is of importance to the user.
That's scenario 1 I posted, a 3rd party (the user).
Consider an application like PostgreSQL.
That's scenario 2 I posted, a program that rewrites part of its file. I even specifically mentioned databases.
So your answer then is no, you can't think of any other situations. Which means that the vast majority of programs do not need to call fsync in order to be properly coded.
A program such as KDE or gnome storing settings files is not a case where the user expects data integrity. In fact, if for example you change screen resolution and it crashes the computer it's better for the filesystem to lose the change. Calling fsync is not appropriate for these programs, because the write-new-file + rename-to-original scheme is all that need be done. Except on dysfunctional filesystems such as pre-patch ext4. But that is not a fault of those applications.
Pretty sure no one in their right mind would call using fsync() barriers a "huge burden". There are an enormous number of programs out there that do this correctly already.
Name one scenario where fsync should be necessary other than:
1) to give a third party assurance the data is on disk, for instance so the user can run 'sync' then hit the power strip without shutting down (assuming they also wait N seconds for the actual drive to save the data). 2) rewriting data back to an existing file... like for instance something a database might do.
Are there any other case where fsync should be necessary? fsync is like a crypto program zero'ing the memory where you password was stored... it's a good thing, but shouldn't be required in order to have the FS work correctly.
That brings up another point, almost nobody is ready for the second remark either (write might return after a partial write, necessitating a second call)
That's because read/write to disks is considered a 'quick' operation, so it never returns with a partial write. And they are never interrupted because they are restartable and automatically restart.
The code you gave is necessary for pipes and sockets, not for files.
But you never create and write to a file as a single operation,... Having the file system spot what your application is trying to do and reversing the order of the operations would be... tricky
Generally in these cases you do:
1) create a new file 2) write contents of new file 3) close it 4) mv file onto original file
-or-
1) open existing file 2) trunc(0) it 3) write new data 4) close
In the first (better) approach the FS only has to do something special at step 4... it only has to finish writing the data for the source file before saving the rename.
In the second, the FS only has to associate the trunc with the data to some extent. For instance, the trunc shouldn't be written to the log if the data is going to stay around for 120 seconds... the trunc can be written to the log when the data actually starts being saved to disk. But certainly if the whole data + close is done before anything needs to be written the FS can do something intelligent to avoid data loss.
So I don't really see why it's so hard as you are saying it is.
POSIX tells you what you can expect from file system calls. Data committed to disk as soon as an fwrite or fclose returns is not something you can or should expect.
But you should expect that a rename that deletes another file doesn't get saved onto the drive before the data is saved. Why? Because the most important job of any filesystem is not losing data. And that kind of data loss is completely preventable with little (if any) performance cost.
POSIX formalizes a 30+ year-old view of the filesystem. Just because it says you have to use fsync several times in order to safely get the data saved doesn't mean we can't or shouldn't improve on that.
The proper sequence is to create a new file, sync, rename the new file on top of the old one, optionally sync.
You forgot to sync the folder containing the file...
It's kind of retarded that without gratuitous syncs you can write a file, rename it over the original, crash, and end up with a zero-byte file and deleted original. That's what happens when metadata and content data are not 'in sync', so to speak.
If the program finishes writing then renames the file overtop of the old file version there should never be a problem, even if the application does not ever sync anything (should, not won't). The filesystem should guarantee that a crash at any time during "cat >new; mv new old" results in either just the original old, old and new, or new renamed to old. In any case, 'old' should be data-complete regardless of any syncs the program does or doesn't do.
The application doing a sync all the time is just throwing a monkey wrench into the works. On ZFS you might get lots of tiny records causing overhead. On some other FS you might cause it to need to write lots of other data first. At least in this case, and for trunc(0), the application shouldn't be messing with the FS.. the FS should do the right thing.
So, I pretty much have to be a browser-hacking geek to opt-out? It pains me when programmers complain how stupid users are. I feel sorry for them most of the time.
No, you just have to go to google and type "firefox disable autoupdate". The first page of results tells you what you need to know, and it's ridiculously simple.
If you don't know how to use google, and can't follow a two-line set of instructions, then yeah you might have trouble. But we aren't talking about browser-hacking geek level, we're talking basic competence.
It's like complaining that you can't hang fuzzy dice from your car mirror because there's no hook for them. Well, that's partly true because there's no fuzzy dice hook, but if you can't figure out how to do it then that's pretty sad.
The C example from google was running 2262 x 1680? That's a pretty hefty projector that has that kind of resolution. Fact is you're being retarded, and so are the mod's that marked you insightful.
The actual quake demo on their NaCL page, in trunk, runs at 800 x 600, which is exactly the same resolution as the java examples. The only difference is the NaCL version runs at 40 fps on faster hardware instead of 200+ fps.
As to why it doesn't work for OS... There is no reason the basic concept wouldn't, aside from the performance penalty and increased code size. (Though further compiler optimization could minimize or eliminate some of that).
Java generally runs at ~30% slower than C. Unless NaCL can run faster than this then there's no point in it. The demo talk shows it running Quake at ~40 fps. Java quake runs at 200 fps, on a much slower computer.
Please explain to me why that's "worse". Do you honestly believe that the rich should pay more for cellular phone service just because they can?
Because at 30k/year you might only have 10% of your income that you can save or invest with. But at 230k/year that number jumps to more like 50% (after taxes).
And if the point of the airwave tax is that we're all collectively sharing the spectrum, then yes people should be taxed in a graduated sense just like other progressive taxes.
And if current javascript engines are faster than the standard python implementation's engine, no problem in there as well: python with it is nicer, higher level syntax can be seamlessly translated to javascript and run on javascript backends for at least two different projects (Pypy [codespeak.net] and pyjamas [pyjs.org]).
...which is kind of my point. Javascript is / will be the lingua franca for dynamic languages.
Finally: Python is there already, it is not "going" anywhere.
Neither has COBOL, also once the 'plain spoken' language without all that 'algorithmic programming' weird syntax...
Python syntax drops some punctuation so that the language resembles the way we do think our algorithms when we address our problems (at least in western Languages like English and Portuguese).
Again, "ADD 1 TO COBOL GIVING COBOL".
For instance, can you name a single programming language besides COBOL that has not used tokens to delimit blocks?
One of the strrnghts in python is exactly the ease to open and manipulate files - to single method calls and you have the data in memory, ready for manipulation - and you just admited javascript can't read files at all.
But really that's a weakness of python then, isn't it, because that only takes a 'standard library' function that's a few lines long... stat, open, read/mmap, return. There's nothing special about it, and a single developer could write that function in a few minutes for spidermonkey, for instance.
Python gives you the Rosetta stone for a project combining any other languages you'd like.
I can see where this is going... a Shamwow?
I'll just cut to the chase. There are and will be two universal interface languages:
* C for compiled languages * javascript for dynamic languages
Javascript is a really, really simple language (in the same nature as C). On the implementation level it's name:value pairs. C for comparison is basically address:value pairs. This gives a nice simple universal platform that anything else can be built on. Python does not have this simple layer that everything is built on.
Javascript also has a syntax that can be used in non-file situations such as a command-line (a javascript shell). Javascript syntax is also a direct dynamic language equivalent to C, which has succeeded in the developer marketplace.
Currently what you find is that Javascript does not have a good interface to the system, without native javascript APIs for open, read, etc, and without a standard set of hooks into C programs. This is entirely because of javascript starting in the web browser, but what you'll see is people developing these and then python going the way of the dodo because javascript can do all the things python does, and better, but it can also do other things such as being the universal glue for dynamic languages.
If you walk into the computer science department at MIT, basically all the faculty have a Mac, and fully half the students do. These people are not buying Macs because they saw a cool ad on the bus - they're buying them because a Mac is the best tool available.... Yeah, they're more expensive.
Pretty sure if you're going to pay $50k per year on your education then the 'best tool available' is a butler of some kind. If having somebody carry your books and supplies around saves you even a couple hours it's well worth it. Also, they can drop rose petals in front of you... can you Mac do that?
Article doesn't say what interactions the adult mice had with their offspring. The benefit may have just been passed to the next generation through regular learning, modeling, etc.
I don't know about lab mice, but rat packs have a pretty complicated social structure (for example nominating food tasters to try new sources of food) so I'd bet that mice can teach their young a lot more than researchers might suppose.
Except they're not because you're basically forbidden direct access to any system resources! Any gains that you would traditionally expect to be able to make through use of C or assembly are right out the window, and that is acknowledged right up front.
Protecting processes from each other in a traditional system accounts for ~20% overhead on hardware designed to make this fast (google: singularity research papers). Java generally runs ~%30 slower than C.
It's plain to see that cutting out memory protection has potential. This particular project will almost certainly fail, but that has more to do with network effects than anything else.
All virtualization has a cost, and I'm not sure that this is the way to handle the problem.
If you write over random memory locations does your whole system crash? No, because your program is running in a virtualized memory space. Your traditional linux or NT style system is using virtualization, and it's a much bigger and clumsier hammer than a typesafe language.
And yeah, grant me a little hyperbole on the "blood oath" comment. The supplemental agreement that I have to sign before I get access to live user data is fairly scary. No blood, but scary enough even so. Google is serious about user privacy.
This is civil law. You might also break criminal laws, but that's a completely separate issue from any agreements you signed with google.
An injunction is not scary ('stop stealing data from google'). A request for specific performance won't be granted if it's impossible, would be undue hardship, contract is terminable at will or vague or unconscionable, etc. So no big deal there.
So it won't be materially worse than bankruptcy. That's serious, but anybody with the ability to get hired by google can recover from that. Again, it sounds like histrionics to me.
Slashdot Mirror
This makes multi-core performance a non-starter. Sure, you can run more INSTANCES of the language with multiple cores, but you can't get any single instance of a script to run any faster than what a single core can do.
Take Java for instance. It runs the garbage collector in parallel with the program itself so what you'll find is a lot of single-threaded apps end up using say 110% CPU time or more. Programs never written for multiple cores get a speed-up from running on them.
There's no reason scripting languages can't also do GC, or speculatively compile into native code on another core.
I will give you two tips for avoiding memory leaks (these are more important than avoiding segmentation faults, because they are harder to detect and debug).
Valgrind helps immensely. It will find most memory use after dealloc, double-frees, leaks, and seg faults. And it gives you a stack trace showing you exactly where the problem is.
I had a coworker diagnosing a problem for hours and couldn't figure out wtf was going on, so when he asked for help I made him run valgrind and it showed a memory use after free in 5 seconds. He knew full well about valgrind, but he's just incompetent You'd have to be not to use it when writing C code.
Yes!! Because it feels more responsive thanks to its use of several process..
How responsive does it feel when you leave Chrome running and switch over to Unreal Tournament 3? Or Warcraft? I've never needed to close out firefox because I always have an idle CPU for whatever else I'm working on.
So my point is that the market might have more important factors than 'feeling responsive'. Like for instance 'dont have to close a bunch of tabs in order to play a game'. You don't know what those factors are, I don't know what they are. Only the invisible hand knows...
and you are still missing the point ...
And you're missing the point.
No user cares about the architecture unless if gives them actual benefits. Firefox addons undeniably give huge benefits to many users.
The only architectural feature of Chrome of note is separate processes per tab. But is that a benefit?
First of all, any crash is unacceptable, and I've been running beta firefox on a daily basis at work and the last time it crashed for me was several months ago. So this is basically no benefit. The only real benefit for stability is running flash in a separate process, which firefox already does with nspluginwrapper.
Now performance. Chrome can make better use of multiple processors, which is great, but it means if you have two tabs open with flash on your dual-core then all your other programs have to compete for resources instead of having an idle CPU to use. Or if you are single-core then you have twice as many procs competing for resources with everything else, making everything else more sluggish. Granted, those are bullshit reasons technically BUT what matter is only what users actually prefer and not what is technically 'best'. Users might prefer all their other apps to be snappy more than their tabs to multitask well.
Memory usage. Chrome can recover memory better when a tab closes, but it wastes more memory for a tab to be open (duplicated images, etc). And once there are ad-ons that need to coordinate among multiple processes, is memory going to explode with each tab? Uncertain. Remember that Java also uses the same concept of a separate process per 'thing' and look how well that works out when you have lots of them running at once.
Frankly, if you give people a 'taste test' between firefox with chromifox theme (makes it look like Chrome) and Chrome, I think you'll find the browser architecture, except to geek fanboys, is pretty low on the totem pole.
Edit your hosts file to block all ad servers. Its quick and painless.
www.example.com/index.html
www.example.com/ads/annoying.swf
When people say they want adblock and noscript and you say "just edit your hosts file" you sound like another fanboy making up excuses. When I was using adblock I had */ads/* and a bunch of others that are not even possible with a hosts file.
As for NoScript, I'm not a huge fan of it (its more of a pain then anything else
Wha? NoScript can occasionally be a mild hassle, but it basically automatically block all annoying ads automatically AND all that useless unrendered crap like google-analytics AND in practice it makes your browsing a hell of a lot more secure than separate processes.
Every scenario where data integrity is of importance to the user.
That's scenario 1 I posted, a 3rd party (the user).
Consider an application like PostgreSQL.
That's scenario 2 I posted, a program that rewrites part of its file. I even specifically mentioned databases.
So your answer then is no, you can't think of any other situations. Which means that the vast majority of programs do not need to call fsync in order to be properly coded.
A program such as KDE or gnome storing settings files is not a case where the user expects data integrity. In fact, if for example you change screen resolution and it crashes the computer it's better for the filesystem to lose the change. Calling fsync is not appropriate for these programs, because the write-new-file + rename-to-original scheme is all that need be done. Except on dysfunctional filesystems such as pre-patch ext4. But that is not a fault of those applications.
Real data thieves ... only have to hear your password
Damn, and here I thought I was safe because my voice is my password...
Verify me.
Pretty sure no one in their right mind would call using fsync() barriers a "huge burden". There are an enormous number of programs out there that do this correctly already.
Name one scenario where fsync should be necessary other than:
1) to give a third party assurance the data is on disk, for instance so the user can run 'sync' then hit the power strip without shutting down (assuming they also wait N seconds for the actual drive to save the data).
2) rewriting data back to an existing file... like for instance something a database might do.
Are there any other case where fsync should be necessary? fsync is like a crypto program zero'ing the memory where you password was stored... it's a good thing, but shouldn't be required in order to have the FS work correctly.
That brings up another point, almost nobody is ready for the second remark either (write might return after a partial write, necessitating a second call)
That's because read/write to disks is considered a 'quick' operation, so it never returns with a partial write. And they are never interrupted because they are restartable and automatically restart.
The code you gave is necessary for pipes and sockets, not for files.
But you never create and write to a file as a single operation, ... Having the file system spot what your application is trying to do and reversing the order of the operations would be... tricky
Generally in these cases you do:
1) create a new file
2) write contents of new file
3) close it
4) mv file onto original file
-or-
1) open existing file
2) trunc(0) it
3) write new data
4) close
In the first (better) approach the FS only has to do something special at step 4... it only has to finish writing the data for the source file before saving the rename.
In the second, the FS only has to associate the trunc with the data to some extent. For instance, the trunc shouldn't be written to the log if the data is going to stay around for 120 seconds... the trunc can be written to the log when the data actually starts being saved to disk. But certainly if the whole data + close is done before anything needs to be written the FS can do something intelligent to avoid data loss.
So I don't really see why it's so hard as you are saying it is.
POSIX tells you what you can expect from file system calls. Data committed to disk as soon as an fwrite or fclose returns is not something you can or should expect.
But you should expect that a rename that deletes another file doesn't get saved onto the drive before the data is saved. Why? Because the most important job of any filesystem is not losing data. And that kind of data loss is completely preventable with little (if any) performance cost.
POSIX formalizes a 30+ year-old view of the filesystem. Just because it says you have to use fsync several times in order to safely get the data saved doesn't mean we can't or shouldn't improve on that.
The proper sequence is to create a new file, sync, rename the new file on top of the old one, optionally sync.
You forgot to sync the folder containing the file...
It's kind of retarded that without gratuitous syncs you can write a file, rename it over the original, crash, and end up with a zero-byte file and deleted original. That's what happens when metadata and content data are not 'in sync', so to speak.
If the program finishes writing then renames the file overtop of the old file version there should never be a problem, even if the application does not ever sync anything (should, not won't). The filesystem should guarantee that a crash at any time during "cat >new; mv new old" results in either just the original old, old and new, or new renamed to old. In any case, 'old' should be data-complete regardless of any syncs the program does or doesn't do.
The application doing a sync all the time is just throwing a monkey wrench into the works. On ZFS you might get lots of tiny records causing overhead. On some other FS you might cause it to need to write lots of other data first. At least in this case, and for trunc(0), the application shouldn't be messing with the FS.. the FS should do the right thing.
You look for an answer until you find it or give up.
Oh, so (i) you don't understand the question, then (ii) you look for an answer, (iii, A) you find it (how? how will you know you found it?)
Once you have found the answer only then will you understand the question, grasshooper.
So, I pretty much have to be a browser-hacking geek to opt-out? It pains me when programmers complain how stupid users are. I feel sorry for them most of the time.
No, you just have to go to google and type "firefox disable autoupdate". The first page of results tells you what you need to know, and it's ridiculously simple.
If you don't know how to use google, and can't follow a two-line set of instructions, then yeah you might have trouble. But we aren't talking about browser-hacking geek level, we're talking basic competence.
It's like complaining that you can't hang fuzzy dice from your car mirror because there's no hook for them. Well, that's partly true because there's no fuzzy dice hook, but if you can't figure out how to do it then that's pretty sad.
Well if you're talking about SPARC it would be the x64%4 architecture.
* Tired of opt-out upgrades.
about:config
app.update.enabled = false
* Awesomebar is awful not awesome
browser.urlbar.maxRichResults = 0
* Firefox 3 includes "security" functionality
Well "generally" people prefer not to lose their credit card numbers and such.
* Somehow infected with pop-up window Spyware
... which is why you "probably" shouldn't have disabled the security features, or been using firefox 1.
have you ever looked into coding an extension for FF? It's horrid horrid stuff
And it's better than any other browser.
So basically you have no real complaints about firefox... which is why your post is troll.
The C example from google was running 2262 x 1680? That's a pretty hefty projector that has that kind of resolution. Fact is you're being retarded, and so are the mod's that marked you insightful.
The actual quake demo on their NaCL page, in trunk, runs at 800 x 600, which is exactly the same resolution as the java examples. The only difference is the NaCL version runs at 40 fps on faster hardware instead of 200+ fps.
As to why it doesn't work for OS... There is no reason the basic concept wouldn't, aside from the performance penalty and increased code size. (Though further compiler optimization could minimize or eliminate some of that).
Java generally runs at ~30% slower than C. Unless NaCL can run faster than this then there's no point in it. The demo talk shows it running Quake at ~40 fps. Java quake runs at 200 fps, on a much slower computer.
Please explain to me why that's "worse". Do you honestly believe that the rich should pay more for cellular phone service just because they can?
Because at 30k/year you might only have 10% of your income that you can save or invest with. But at 230k/year that number jumps to more like 50% (after taxes).
And if the point of the airwave tax is that we're all collectively sharing the spectrum, then yes people should be taxed in a graduated sense just like other progressive taxes.
And if current javascript engines are faster than the standard python implementation's engine, no problem in there as well: python with it is nicer, higher level syntax can be seamlessly translated to javascript and run on javascript backends for at least two different projects (Pypy [codespeak.net] and pyjamas [pyjs.org]).
...which is kind of my point. Javascript is / will be the lingua franca for dynamic languages.
Finally: Python is there already, it is not "going" anywhere.
Neither has COBOL, also once the 'plain spoken' language without all that 'algorithmic programming' weird syntax...
Python syntax drops some punctuation so that the language resembles the way we do think our algorithms when we address our problems (at least in western Languages like English and Portuguese).
Again, "ADD 1 TO COBOL GIVING COBOL".
For instance, can you name a single programming language besides COBOL that has not used tokens to delimit blocks?
One of the strrnghts in python is exactly the ease to open and manipulate files - to single method calls and you have the data in memory, ready for manipulation - and you just admited javascript can't read files at all.
But really that's a weakness of python then, isn't it, because that only takes a 'standard library' function that's a few lines long... stat, open, read/mmap, return. There's nothing special about it, and a single developer could write that function in a few minutes for spidermonkey, for instance.
Python gives you the Rosetta stone for a project combining any other languages you'd like.
I can see where this is going... a Shamwow?
I'll just cut to the chase. There are and will be two universal interface languages:
* C for compiled languages
* javascript for dynamic languages
Javascript is a really, really simple language (in the same nature as C). On the implementation level it's name:value pairs. C for comparison is basically address:value pairs. This gives a nice simple universal platform that anything else can be built on. Python does not have this simple layer that everything is built on.
Javascript also has a syntax that can be used in non-file situations such as a command-line (a javascript shell). Javascript syntax is also a direct dynamic language equivalent to C, which has succeeded in the developer marketplace.
Currently what you find is that Javascript does not have a good interface to the system, without native javascript APIs for open, read, etc, and without a standard set of hooks into C programs. This is entirely because of javascript starting in the web browser, but what you'll see is people developing these and then python going the way of the dodo because javascript can do all the things python does, and better, but it can also do other things such as being the universal glue for dynamic languages.
If you walk into the computer science department at MIT, basically all the faculty have a Mac, and fully half the students do. These people are not buying Macs because they saw a cool ad on the bus - they're buying them because a Mac is the best tool available. ... Yeah, they're more expensive.
Pretty sure if you're going to pay $50k per year on your education then the 'best tool available' is a butler of some kind. If having somebody carry your books and supplies around saves you even a couple hours it's well worth it. Also, they can drop rose petals in front of you... can you Mac do that?
Article doesn't say what interactions the adult mice had with their offspring. The benefit may have just been passed to the next generation through regular learning, modeling, etc.
I don't know about lab mice, but rat packs have a pretty complicated social structure (for example nominating food tasters to try new sources of food) so I'd bet that mice can teach their young a lot more than researchers might suppose.
Except they're not because you're basically forbidden direct access to any system resources! Any gains that you would traditionally expect to be able to make through use of C or assembly are right out the window, and that is acknowledged right up front.
Protecting processes from each other in a traditional system accounts for ~20% overhead on hardware designed to make this fast (google: singularity research papers). Java generally runs ~%30 slower than C.
It's plain to see that cutting out memory protection has potential. This particular project will almost certainly fail, but that has more to do with network effects than anything else.
All virtualization has a cost, and I'm not sure that this is the way to handle the problem.
If you write over random memory locations does your whole system crash? No, because your program is running in a virtualized memory space. Your traditional linux or NT style system is using virtualization, and it's a much bigger and clumsier hammer than a typesafe language.
And yeah, grant me a little hyperbole on the "blood oath" comment. The supplemental agreement that I have to sign before I get access to live user data is fairly scary. No blood, but scary enough even so. Google is serious about user privacy.
This is civil law. You might also break criminal laws, but that's a completely separate issue from any agreements you signed with google.
An injunction is not scary ('stop stealing data from google'). A request for specific performance won't be granted if it's impossible, would be undue hardship, contract is terminable at will or vague or unconscionable, etc. So no big deal there.
So it won't be materially worse than bankruptcy. That's serious, but anybody with the ability to get hired by google can recover from that. Again, it sounds like histrionics to me.