2,533 karma · joined October 13, 2019
Allegedly there's a way to cache image layers and artifacts on Github. I've taken to pushing them to S3 buckets so my CI runs can be incremental where possible.
Because I see this attitude a lot, but as someone who has worked primarily at these enterprises (good and bad) I don't think you can think that way without being completely divorced from reality. Not all of us are working with Saudi money from Softbank.
Startups that can't stay cash flow positive might as well be enriched uranium right now. Could be worth a lot of money to the right people, but you're not keeping it around the house.
$/ft^2 is the metric to look for. That correlates with "high end" retail (high dollar items that take up less floor/warehouse space).
I think we could see a boon of brick and mortars that are smaller and more optimized. Just an anecdote, I know of a local music shop that cut its floorspace in half about 5 years ago and started offering staple items as a subscription service (e.g. reeds, guitar strings, bow rosin, whatever), while the bigger items had their shelf space rented out to vendors rather than taking commission on sales. Another anecdote, StitchFix and Bonobos have both provided solutions to the problem of selling clothes without stocking various sizes at a retail location.
There's a lot of opportunity to innovate retail in my opinion. The issue has always been the sales model, and I think that focusing on "big box" stores is wrong - they're just more equipped to weather the storm. Department stores died a decade ago, it just took this long for their bodies to hit the ground. Same for big box retail.
That said, I'd love it if Netflix or Pornhub provided their VOD infrastructure as a service. There's a lot of space for content platforms that don't compete with them directly, but are infeasible to get off the ground.
I think a better question then isn't, "which services should have APIs?" but "which companies should provide IaaS?"
For example a common argument to ban buybacks is that they were illegal prior to 1982. We also had no good place to park savings before 1982, where at the same time we had seen enormous inflation the stock markets had been on steady decline since the mid 1960s. People weren't just losing money due to inflation, they had fewer options about where to put it reliably.
And when it comes to regulation I don't know what the best way to do it is other than letting companies that made bad buybacks die, or bail them out by diluting shareholders in some kind of bankruptcy proceeding.
Business decisions cannot be amoral unless you pretend they don't impact other human beings. That in and of itself is immoral.
And regardless of what you think the purpose of a company is, they are places where friends socialize and families look out for each other. They're social collectives, and people will do social things where those form. Profit motive or not. They are also a social support system, that's what your salary and health insurance are.
And to that point, "doing what they need to do" is synonymous with hurting people for the benefit of others. Removing pay benefits across the board is not prioritizing individuals, but actively harming the people who can tolerate it the least as a group.
The reason this is bad optics is because rational and moral people look at these decisions and see them not as amoral acts like you pretend, but evil ones.
Returning value to shareholders isn't nefarious.
With recent changes to the OS, a decade of instability with every update every year, the recent hard deprecation of 32 bit binaries, and now moving to an unproven ISA for those particular workloads - all while Windows and Linux have closed the gap, mostly... the situation is a bit different.
Longer answer: it doesn't matter as much as you'd think. These companies making huge layoffs are facing an existential crisis, not slimming down for a revenue shortfall.
I swear the most common "crazy story from my vet" is the soccer mom that rescues a litter of puppies that she found on her run...
Video quality is really only necessary when screen sharing, and zoom does OK there.
In particular, the implementation of data structures. Raw memory allocation, usage of pointers, low level concurrency primitives - none of that can be done without the programmer manually enforcing invariants.
But unsafe isn't wanton abandon. You still have to obey the type system and ownership rules.
As for the goal, it depends on the author. Some prioritize one over the other. In general the Rust community these days tries to optimize the balance of safety and speed with as few compromises as possible - which is fundamentally why the language exists.
The simple answer is that globals are expensive. Literally, they cost a lot of money. They introduce bugs that are harder to find, reproduce, and fix. That means introducing a global is a high risk, since it's increasing the expected value of your non recoverable engineering costs.
Rejecting globals is about lowering risk and cost because it's so easy to not use them and toss them out of code review, and it's really easy to work around that limitation.
Gonna remove my more uncivil remark. Basically relying on bug reports and debugging is the software equivalent of waiting for your engine to seize before you change the oil.
e.g. yesterday, Gov. Newsom went on the radio and said something along the lines of "half of people hospitalized were 18-60" (paraphrasing, don't remember the numbers exactly, etc). But something like 2/3rds of our population is that age!
Another thing would be statistics on triage as the outbreak overwhelmed Italy. I'd like to know who was going to the hospitals, who was admitted, who needed to be in the ICU, etc, and how the profile of patients changed as beds got filled.
Nutrition. I've already noticed food purchasing has changed at my local stores. I would like to know if we're exasperating our public health crisis by ruining our diets and if we should be concerned about that moving forward.
And finally, alcohol and drug consumption - particularly by millenials. Anecdotally, many of my peers are drinking a lot more regularly than they normally would during the day and week. There are plenty of memes about it, but I'd like to know if we're looking for hope at the bottom of a bottle for the next few months.
But regardless I don't see the efficacy of bailouts for most companies. Besides a few critical businesses like the airlines and Boeing, the money would do very little to help the workers who have been laid off or furloughed. The government needs to pick up that tab directly, or else the cash isn't going to be used for it.
It actually bit me on the ass a couple weeks ago when installing a rust binary instead of using cargo --install because it shaved ~10 minutes off running a CI pipeline. Had to fall back because the rust bin wasn't linked against musl libc when it was compiled for unknown Linux targets, and the authors don't distribute a musl compatible binary.
I really think that the government should be taking a majority stake in Boeing. They have institutional problems in addition to money problems.
It's a pain in the ass to use, and I wish more people would focus on concise and easily referenced/searched/indexed material in markdown rather than novels written in TeX.
For example, Agner Fog's writings are fantastic content, and awful to navigate. The Rust Programming Language does exist in book form, but I find myself referencing it constantly as a technical manual and it would suck to do that if weren't structured the way it is using mdbook.
For the love of all that is sacred, please stop writing technical manuals like I'm going to ever going to read the whole thing. Every piece of information should be short, fit entirely in a reasonably sized browser window, be indexed for search, and if it lends itself to cross-referencing it should be filled with links to itself.
That's the kind of thing that markdown and site generators using markdown excel at.
For example, iterator invalidation. Which is probably the most common thing I've seen when people use dumb locks to make a concurrent program sound. Either your iterators need to be aware of the lock and hold it through their lifetime (which means practically only one iterator can exist, which is undesirable) or your datastructure needs to be aware of outstanding iterators to it and update them (which means you have added logic to simple mutations, which is also undesirable).
It's problems like that you look for in non-functional languages that require library authors to say things like "this is/isn't thread safe" in their documentation, while providing those guarantees manually. And as a consumer of the library you need to be aware of these things and look for them, and what an error looks like when someone messes up.
I don't know what you're trying to say about stacks/the call stack in functional languages, because they implement their patterns in variety of ways - including locking. It's just about providing particular guarantees in the API, and the benefits of those guarantees are that it prevents entire classes of bugs like iterator invalidation and data races.
There are also all sorts of clever data structures you can use that don't require duplication of the underlying data. The easiest is a singly linked list without insertion. No locks required.
In fact, some structures that lend themselves to immutability represent the hardware better. Take your vector of a billion elements. It probably is too big for L1/L2 cache. Is it actually a billion things next to each other in memory? Not at all.
If you used something like a radix balanced balanced tree to represent your vector, you get amortized O(1) access and mutation can be implemented using copy on write at individual leaves of the tree. And your abstraction is much friendlier with the cache, because it reflects how the hardware works much better than a simple vector.
In practice, immutable data structures can be much more performant at scale than pretty much anything. They're not just convenient for soundness. Trivial data structures like vectors are really only useful when you're talking hundreds to the low thousands of elements, at which point who cares how much memory they take up?
I firmly believe that real world performance is bottlenecked by cache before the slight difference in OoE/pipelines/speculation between Intel and AMD's CPUs. And the metric I really care about is the time it takes to read a cache line and the cache miss penalty. Those two fundamental pieces of the system are the ultimate bottleneck that developers can't deal with.
It's really easy to construct cases where one CPU beats another in either single or multithreaded performance. The hard thing to make a judgement on is how it looks in real world software, and the more cumulative benchmarks are more telling of the quality of the software you bench other than the CPU. Particularly because optimizing for cache is so difficult. It's trivial to hit the memory wall and decide that's it, but it's really hard to decide that your entire architecture was flawed, choice of language was wrong, choice of algorithm or data structure was wrong, etc, A/B two different implementations and pick one that's slightly faster. The ROI isn't there.
There's a philosophical point here though about the nature of "better" as it applies to the real world that makes my belief moot, because even if I'm right it when X% of software that people use runs Y% faster on a particular architecture it doesn't matter if it's because developers wrote and benched their code on that architecture. It's still "better."
All that said, I'm very happy with my Zen2 purchase.
That said compared to other notebooks, MacBooks in similar tiers tend to benchmark quite well regardless of the thermal throttling.