somejan
However all the Java shops I hear about are also looking into Kotlin at some level of adoption. From all the new JVM languages Kotlin integrates the best with the existing Java environment and for displacing a language in an existing niche an easy upgrade path is the most important. So I think Kotlin will become an important language in the JVM ecosystem, it will just take a long time because these types of businesses are conservative in their tech choices.
And then the author suddenly stops and ignores the next obvious question: where do gold, silver and gemstones get their value from? The simple answer is because people like to have them and their supply is more or less fixed (which causes people to believe they won't suddenly lose their value). The exact same thing applies to bitcoins: bitcoin is the store of value.
The US already tried once to make a certain type of currency it couldn't control illegal: in 1933 it forbid anyone to own gold. That didn't make gold worthless any more than it will make bitcoins worthless. The only thing I believe that could do that to bitcoin is if it is replaced by another digital currency.
But if even this overhead is too much you can compile python without treading support.
The only effective difference would be that the entire database would become a single unit instead of a collection of separate hashes. Both an attacker and your webapp need to carry this extra weight of a monolithic blob of un-dividable data. It probably won't really slow down an attacker trying to brute force it if he has the data, but it may be more difficult to get the data in the first place.
But if an attacker has access to, say 10% of the hashes, he'll still be able to brute force 10% of the user accounts with weak passwords.
A different way to get a similar result of requiring a huge amount of data to be able to start cracking, would be to treat the database like a huge bloom filter: treat the database as a huge bit array of (say) a petabyte, hash the user's password with a hundred different hash functions (but with scrypt-like slowness), and use those 100 hashes as 100 indexes into the array to set the corresponding 100 bits. To verify a password, create those same 100 hashes and check if all 100 bits are set. Now, if an attacker has access to a part of the database, he won't be able to determine with certainty of any of his guesses at the user's passwords are correct.
Yet a third way to accomplish the same goal: pre-generate a petabyte of random data. To hash a user's password, apply a standard scrypt, then based on the resulting hash, generate a 100 pseudorandom offsets into the petabyte of data. At each of those 100 offsets, read a few (say, 16) bytes from our petabyte of random data, and finally store a hash of (scrypt_result + huge_data[offset1] + huge_data[offset2] + ... + huge_data[offset100]). You'd still have one hash per user, but to check a hash you also need access to a huge block of random data. The block of data functions in a way as an additional system-wide salt.
Anyway, there are more ways to get to a similar result as the OP's proposal. I'm not sure if it buys any additional security or if it's just more of a hassle for the webapp implementing this, but at least it's fun to think about.
In the real world, the innocent bystanders matter, code is written as much for other people to understand as it is for computers to execute. I think that instead of plastering over all your content with sweeties, languages should be designed in such a way that the sugar is not necessary by choosing the right fundamental concepts, so programmers can understand what's going on. Learn to cook with the right ingredients, and learn when to add spices. And when not to.
For another example of a syntactic sugar friendly design, have a look at C macros.
But filesystems have been in use long enough that most bugs have been fixed or worked around in the tools. And of course the guys who invented the 'filesystem' didn't have any databases to use instead.