Yes - that's right : people mostly shouldn't need to hold such high Bitcoin balances to buy things. What's in the way is the state interfering so you can't change dollars for Bitcoin with your bank and there aren't services that do that which are convenient enough. In time this will change so you can just make Bitcoin payments from your checking account.
Banks make money by borrowing from one person and lending to another at a higher interest rate. They can do this in Bitcoin just as well as in US dollars.
Money has three functions : unit of account, store if value, medium of exchange. Cryptocurrency isn't great at the first two, but if we presume the scaling problems will be solved then it is pretty good at the latter because it doesn't require you to trust the banking system. So there is an unbundling of the functions of money described by Eugene Fama originally and then tidied up and better articulated by Tyler Cowen and Randall Kroszner in their book on the New Monetary Economics in about 1992.
Its completely irrelevant what the price of Bitcoin is for its usefulness as a medium of exchange.
This medium of exchange aspect is very important because it makes banks no longer special since its possible in time to make payments without a banking system. Thus the role of the state in regulating banks can disappear eventually - no deposit insurance, no bailouts and no too big to fail.
Credit can be provided by funds because the information asymmetry of banks no longer applies when you can port your banking records via API.
I think its a much better store of value (because of the lack of influence from banks) than a medium of exchange. It's very slow, has high fees (currently) and to buy the vast majority of goods you will eventually need to change it back into your own country's currency which will require your bank anyway. Unless I'm missing something...
"This medium of exchange aspect is very important because it makes banks no longer special since its possible in time to make payments without a banking system."
Most people don't want to have the whole of their wealth reliant on a hash they could lose though. They want to be able to talk to "customer service" if they need to.
It's a big world out there. Would you ever imagine that D would be taking market share from... Extended Pascal? But there's a naval architect who designs great big ships with a 500k sloc codebase he is exploring porting to D. Web guys get the attention but enterprise users are a much bigger world than just that.
If something is growing very quickly then saying it hasn't yet dethroned C, so it won't ever be significant seems to me to be a bit brittle thinking. Compound growth and the passage of time - thats what has been underway for some time now.
I did not compare D to C, but rather to Rust, Swift, and Go. Compared to D, Go already has huge marketshare. Rust, similarly, excels in spaces that D does not endeavor to work in (no-managed-runtime settings), and is beginning to see adoption in areas where performance is critical.
From what I have seen of D, it provides a C++ without some of the cruft, but without trying to solve other issues with C++-like languages (for eg: usefulness of Algebraic Data Types). Why should someone choose D today over Go or Rust for any project? I have yet to see a convincing answer.
> Why should someone choose D today over Go or Rust for any project?
D over Go: D has much better language mechanisms for abstraction and programming in the large.
Go over D: Go has an incremental, mature GC.
Rust and D do not quite target the same application domains (though there's overlap), so it's difficult to compare them. Insofar as they do (D with @nogc and @safe), the tradeoffs become rather complicated.
The Dcompute kernel language (which for the most part is plain D, the compiler is completely reused) has the usual set of restrictions that any kernel languages have:
no exceptions, recursion, runtime (which is what betterC is about), function pointers.
It still has all the the features that make D great, sane templates (will work across both host and device to a degree), ranges, CTFE (no need to precompile you lookup tables) and so on.
Garbage in, garbage out. Github's language detection isn't perfect, and people in the D community simply aren't particularly focused on marketing and popularity contests. See here for example :
Auburn sounds makes audio plugins in D and share how they avoid using GC in blog posts. Not that bad even for audio. Sociomantic and Weka both do soft real time.
