This is terrifying. If this, and similar ideas, gain adoption, this will undoubtedly lead to the next financial crisis.
From my understanding, JPMC wants to issue a new coin and make the market for that coin by buying the coin for $1. Then, they plan to use this coin for it's normal banking tasks, such as lending money, except they would use JPM Coins instead of dollars. By using this coin, they would be able to skirt their fractional reserve requirements. Of course, this coin only has value because of trust in JPMC. If this trust or breached, or if external economic events cause a large amount of JPM Coin to be sold, then this will effectively be a run on JPMC. Given JPMC's size and importance in the marketplace, the aftermath would not be pretty.
Skirting fractional reserve requirements is unnecessary, and obviously not the real motivation for this move. The fractional reserve requirements are already so low as to present virtually no constraint on lending. In reality lending is limited mostly by lack of credit worthy borrowers.
I think lending environments are temporary. The current environment has a glut of reserves, but I don't think there's anything systemic about that. Wouldn't this be the best time for JPM to release a new currency, so that it has some runway to gain acceptance before the lending environment changes?
I think you might have misunderstood. JPM will not create a market for the coin or use it for lending. The coin will be 100% backed by deposits in client accounts and used to facilitate instantaneous transfers between clients in order to reduce settlement times (initially it will be utilised for dollar transfers with the possibility of extending it to other currencies and financial assets). Given it will be 1:1 backed by client deposits it cannot be used to skirt fractional reserve requirements (unless JPM changes the terms of issuance).
From JPMorgan’s Q&A on JPM Coin [0]:
> The JPM Coin isn’t money per se. It is a digital coin representing United States Dollars held in designated accounts at JPMorgan Chase N.A. In short, a JPM Coin always has a value equivalent to one U.S. dollar. When one client sends money to another over the blockchain, JPM Coins are transferred and instantaneously redeemed for the equivalent amount of U.S. dollars, reducing the typical settlement time.
Is there any visibility/transparency on how JPM might change the terms of issuance in the future? If not, then the expected value of 1 JPM coin going forward doesn't always match the current face value of 1 JPM coin/1 U.S. dollar, no?
I'm interested to know what percentage in fees/opportunity costs JPM saves when shaving off settlement times by using JPM Coin; if it's the big real reason behind its conception or if there are other plans.
...wait you can just do that? Just declare a "thing" to equivalent but not identical by reference to a dollar and go around laws using dollars because you technically aren't using the dollar?
> ...wait you can just do that? Just declare a "thing" to equivalent but not identical by reference to a dollar and go around laws using dollars because you technically aren't using the dollar?
Yes, they're basically taking dollars out of demand deposit accounts and putting them into brokerage accounts. Demand deposit accounts are liquid, guaranteed with FDIC insurance, and the account holder is entitled to the funds at any time. JPM Coin is theoretically liquid and "guaranteed" by JPM in the form of a promise to purchase it for at least $1 (up until they can't of course) but from the article it seems the funds won't be immediately available to account holders:
> Purchases and redemptions may not always be immediate, but once converted to JPMCoin, transfers should be quick and error-free.
The benefit of JPM Coin for JPM is a quicker/cheaper way to facilitate transfers between and among their various legal entities while also reducing the bank entity's total deposits (which in turn reduces the bank's capital and reserve requirements).
The benefit of JPM Coin for JPM customers on the other hand, is not immediately obvious to me.
I mean for things like CDs and savings accounts, JPM Coin is irrelevant. I'm concerned more if JPM decides to use JPM Coin for higher-risk activities. What happens if they decide they would treat a supply of JPM Coin as a supply of USD, with the knowledge that if things go south, they could change the value of the pegged psuedo-currency and get a slap on the wrist?
Every bank could then conceivably be a central bank, except as a central bank that is profit-driven.
Except they're not doing anything of the sort. They've created a stablecoin backed by their balance sheet. They plan to use it for reducing the friction on payments and payment like processes.
That's it pretty much. TBH if JPM were going to attempt a major violation of their regulatory constraints, I'd expect them not to publish it on their website.
I mean I can't, but JPM might be able to. JPM's an organization with enough significance to the financial system that they (IMHO) could conceivably make people accept one truth that 1 JPM coin == 1 USD.
Best case scenario is that they convince people to treat their thing with value in their sandbox to reduce fees and improve performance for a specific business case (B-2-B payments for example). Or in the case of JPM Coin, they back it with deposits and no value trust is needed. Just limited application.
They aren't issuing loans with JPM Coins, because those coins would have to either be transferred into USD by the loanee or accepted as currency by the school, home seller, etc. Which won't happen.
>I would not trust JPMC but fiat money (dollars, euros, etc) only has value because of trust in governments.
That's not really true. the value of a currency comes from what you can do with it. E.g. I think $20k is a lot of money because I know it is enough to buy a car. That has nothing to do with the government, only the market.
This isn't that surprising. I think the reason for this is that, even though the model is linear, the space of n-grams is so large that there usually is a line that separates any two classes.
The purpose of this work isn't to generate realistic NSFW images. The purpose is to visually represent what a neural network "looks for" when classifying NSFW content. It is very interesting that these generate images strike the viewer as grotesque even though there isn't anything specific in the images that could be called vulgar. This indicates there is some similarity between how a neural network and our brains classify things.
You should definitely CDN your data. A majority of a client-side latency is spent round-tripping to the server. Using a CDN greatly reduces this time.
I don't know your workload, but 60ms doesn't seem that fast. Don't get me wrong, it's pretty good, but for a read-heavy load it seems like this could be optimized to be sub-10 ms at the 99th percentile.
90ms is the mean across all routes. Our post route, with the highest throughput, has 16ms request/response time. We do use a CDN, and we spend a lot of time thinking about performance. Thanks for your insight.
An app I maintained that was doing anywhere from 3 to 50 DB queries per request, 98% of the time was spent in the DB roundtrips. The Elixir code itself took 0.2ms to 3ms.
It's really lightweight. Can't be anywhere near Go or Rust of course but it's provably much faster than Ruby, Python and PHP, and very often outperforms JS on V8.
Most of the overhead I observed in Elixir apps stems either from external network requests (DBs, K/V stores etc.) or CDNs / static assets. Most of the Elixir code is almost invisible in terms of footprint.
BEAM has the benefit of being a register-based VM vs the stack based VM of CRuby but the immutable semantics of Erlang/Elixir negate a lot of the VM and GC advantages.
You should read a bit more on how the various popular benchmarks manage their different code bases and not just quickly believe the graphs. There's a lot of story behind them.
Several languages, Elixir included, are misrepresented due to badly written and non-idiomatic code (caveat: this was true a while ago, I haven't checked lately though). And when its users try and open a PR they are shot down with "We don't allow cheats". No cheats though, just very normal language best practices.
So I disagree with you here. I maintained a ton of Rails and several Sinatra apps and to say they are on the level of Elixir makes me wonder what kinds of hosting budgets we both had access to and were they really so hugely different.
(Sinatra was actually very decent but it being Ruby it doesn't scale well and Erlang/Elixir work much more stably until they start having problems compared to it.)
Again, don't just trust the popular benchmarking suites. You will quickly discover they usually either have an agenda (like the Crystal language creators always showing how quicker it is compared to Elixir, and refuses any Elixir PRs -- seriously no idea what the Elixir community ever did to them) or only pay lip service to representing all languages fairly (like TechEmpower does).
(Edited because I wrote the first version after a nap and it came off sharper than I intended.)
There is an implication here that we (TechEmpower) have rejected PRs that would make the code in our Elixir tests more idiomatic. And if I understand you correctly, when we did so, we explained that the implementation did not comply with the spirit of our tests. To be clear, we do reject pull requests that we believe are cheating (e.g., caching results or other means to avoid specific workloads called out in the test requirements).
Can you point to which Elixir-related PR [1] we rejected on that basis?
Some of our most recent Elixir commits were contributed by a gentleman named Michał Muskała. For example, here are some he characterized as "minor optimizations" [2]. Since he is a one of 16 people on the Elixir language organization page [3], I take his contributions as representative of idiomatic code or at least what the organization wants to represent as idiomatic. Do you have a reason to disagree?
Michał Muskała is a core contributor and his opinion weighs a lot so I am really glad you guys are working with him.
I did check out the PR and his changes seem to be on par with what I've seen in other repositories used in TechEmpower's benchmark. Not cheating, just making sure not to use extra baggage that can severely hamper a framework's performance.
As for rejected PRs, I looked but couldn't find what I roughly had at the back of my head. It was a while ago and since I can't find it now I will have to concede that I remember incorrectly. (Ouch.)
As I pointed out, my info was outdated. I see things have improved in the meantime, which is good news!
Thank you for being responsive and transparent. Much appreciated.
As for CRuby and JRuby, they are completely different runtimes. Not sure they belong in a comparison. Elixir only has one runtime, let's compare with the defaults.
Additionally, why do you use the scripting mode of Elixir (.exs file extension)? Why not compile it (.ex file) and run it? The scripting mode hampers performance. Can you update the gist with a compiled version?
And finally, comparing raw performance isn't really what we argued about here (at least I wasn't). I thought we talked about I/O and concurrency capped environments which are the conditions in which the usual web / API app lives.
Erlang/Elixir shine on a lot of things. But definitely not on raw crunching power -- that much is true and the Elixir community is realistic about it.
I actually even tried compiling the module with HiPE but it made almost no difference so I didn't update the Gist. I've updated it to reflect the tiny improvement it made.
In terms of web, CRuby 1.9+ simply uses OS threads for concurrency and parallel IO. You will run out of CPU resources before "the runtime won't scale" on modern Ruby.
