Why Flossbar/Medbar Failed and What We Learned Along the Way
medium.com2 ポイント投稿者 quanticle0 コメント
ATT has provided the best service of any carrier while traveling, so I will use them.
Really? My experience with AT&T while traveling has been pretty awful. In the US, in rural areas, Verizon is better. And outside the US, Google Fi gives you international data roaming as part of the base package. One of the reasons I switched to Google Fi is because it's so much better when traveling. Because I’m in a very very blue state and city
Emphasis on city. Every time I've read something about how the education system in the United States is on the verge of collapse or is collapsing, it's been from a teacher (or has quoted teachers) in a city school district. City school districts are in dire shape. But that's because many city school districts are massively overbuilt for the amount of children they need to serve, and politicians are loath to shutter schools. So these school districts chug along, spending more and more money on buildings and facilities that are hardly used, while, at the same time shortchanging teachers and the education of children. while Java originated the billion dollar mistake
By the "billion dollar mistake", are you referring to null references [1]? But null references were introduced in 1965 in Algol, by Tony Hoare. They long predate Java. There, you can $$$ your way out of data corruption. You can even loss all the data if you have enough replicas and backups.
That's absolutely not true. All the money and all the backups and redundancy in the world won't save you if the data doesn't make it to persistent storage. Even in a totally closed AWS environment, the fallacies of distributed computing [1] still hold. Was there a network connectivity glitch? A latency spike? What happens when two connections attempt to write to the common data store at the same time? The only reason Circle isn't bothering with this market is seemingly that they didn't want to deal directly with retail
That's actually a really good reason! An analogous situation is with e.g. Robinhood and Citadel. In one sense Robinhood is "just" a retail onramp. All their trades go through Citadel. So in theory Citadel could, at any moment, just cut off Robinhood by allowing retail investors to trade directly with them. But that relegates the centralized exchange into the position of being nothing more than a "fiat on-ramp"
That's actually a pretty profitable business. "If you want to interact in any way with crypto, you either have to go through Coinbase or some shady black market crypto dealer," is actually great news for Coinbase. That might seem the case from afar, but once you start writing Haskell and
start experimenting these space leaks, you will notice that:
1. 90% of the space leaks you write end up adding a tiny amount of memory
usage to your functions, mostly unnoticeable. Think thunks like (1 + 2) that
are subjected to demand analysis under optimization.
2. 1-2% of them are serious enough to require profiling your code with
cost-centres.
But that's pretty much the same as in C. The vast majority of memory leaks in C aren't fatal to the program. They just lead to a little bit of extra memory usage, mostly unnoticeable. And then you have the small fraction of memory leaks that draw the attention of the OOM-killer. A tacit admission that detecting code that is leaking memory in Haskell is no easier than detecting code that is leaking memory in C does not speak well for Haskell.