Fixing JavaScript's Broken Random Number Generator (hackaday.com)

szczys writes: It is surprising to learn how broken the JavaScript Random Number Generator has been for the past six years. The problem is compounded by the fact that Node.js uses the same broken Math.random() module. Learning about why this is broken is interesting, but perhaps even more interesting is how the bad code got there in the first place. It seems that a forum thread from way back in 1999 shared two versions of the code. If you read to the end of the thread you got the working version, if you didn't make it that far (perhaps the case with JavaScript devs) you got the bad version of the code whose fix is just now being rolled out.

Comments

Javascript? lol!

[Anonymous Coward]

Is there anything about Javascript that isn't shitty and broken? Can we please just take this language behind the barn, shoot it and move on with our lives?

Re:Javascript? lol!

[ickleberry]

We could but all the startup hipsters would be so disappointed

Re:Javascript? lol!

[dshk]

We are using JavaScript for performance critical code and I can confirm that it is the most buggiest, immature technology by far that I have ever seen in my 30 years old carrier. Every second month there is a new browser version for each browser, each with a different set of new critical bugs. We even find JIT compiler bugs regularly!

I simply do not understand why they do not take the free, open source, mature, very fast Java virtual machine, and let the browsers run Java bytecode directly, and let software engineers chose any programming language which best suits their task.

Re:Javascript? lol!

[dshk]

What is the difference between bytecode and obfuscated or simply just complex JavaScript? Do you verify all or even 1% of JavaScript your browser runs? Bytecode can be disassembled into its source language if it is not obfuscated. But JavaScript can be obfuscated as well. Not to mention automatically generated JavaScript, cross compiled from another language. I do not see a difference. Why do you want to verify either bytecode or JavaScript? Bytecode runners wouldn't have more permissions then the JavaScript just in time compilers already have. We rely on the sandboxing in both cases.

Wait, what?

[tibit]

What? Does the ECMA spec dictate the exact implementation of the RNG? If not, then it's not JavaScript that's broken, but the implementation(s) in question. Calling it "JavaScript's Broken RNG" is nonsense unless the language spec mandated or mandates a broken RNG.

Re:Wait, what?

[Lunix Nutcase]

Yeah, seems rather convenient that the part in the Hackaday title and in the article that mentions that this was in Google's V8 engine was left out.

Plus I couldn't help but laugh at the comment to the commit that put in this shitty PRNG:

This is great, I had talked to Ivan once about it before. It's good that we avoid system random for a few reasons, including thread safety / lock holding / etc.

I know nothing of the implementation though, I would have gone with mersenne twister since it is what everyone else uses (python, ruby, etc)

Sounds like some real quality code reviewing there, bub. *golf clap*

Re:Wait, what?

[Anonymous Coward]

You're reading a blog for foolish, angry reactionaries who like to pretend to be smart people. What did you expect? Had you been away for years?

V8 == the only JavaScript engine?

[BitZtream]

Because JavaScript doesn't specify the RNG implementation details, and V8 is the only engine mentioned ass affected in the article ...

Happened, not designed.

[QuietLagoon]

JavaScript was not designed by any regular use of that word. JavaScript happened.