> That should not be a reason why to adopt a feature flag platform
It's one of the two big reasons. First is the ability to rollout features gradually and separate deployments from feature release, and second is the ability to turn new features off when something goes wrong. Even part of the motivation of A/B testing is de-risking.
I would put money on all of big tech and all public companies combined not employing more than 30% of professional programmers. At least in the US only 15% work at a large company (500+).
First extension I've used that perfectly autocompletes Go method receivers.
First tab completes just "func (t *Type)" so then I can type the first few characters of something I'm specifically looking for or wait for the first recommendation to kick in. I hope this isn't just a coincidence from the combination of model and settings...
The argument isn't that complexity is being hidden, but how it's managed and where it shows up in your experience of solving other problems. OP mentions:
> The complexity was always there... it merely shone a light on the existing complexity, and gave us the opportunity — and a tool with which — to start grappling with it
It's not about Rust vs. TypeScript per se but uses garbage collection and borrow checker as examples of two solutions to the same problem. For whatever task you have at hand, what abstractions offer the best value that lets you finish the solution to the satisfaction of constraints?
> they are tightly coupled with the code written around them
Which is where the cost of the abstractions comes in. Part of the struggle is when the software becomes more complicated to manage than the problems solved and abstractions move from benefit to liability. The abstractions of the stack prevent solving problems in a way that isn't bound to our dancing around them.
If I'm working on a high-throughput networked service shuffling bytes using Protobuf, I'm going to be fighting Node to get the most out of CPU and memory. If I'm writing CRUD code in Rust shuffling JSON into an RDBMS I'm going to spending more time writing and thinking about types than I would just shuffling around arbitrarily nested bag-of-bags in Python with compute to spare.
I always thought this was why microservices became popular, because it constrained the problem space of any one project so language abstractions remained net-positives.
> It forces you to deal with that complexity everywhere in your codebase.
The alternative is fighting the abstraction. Imagine trying to write the Linux Kernel in JavaScript or Python. Lot less fighting types in your code, more time fighting the abstractions to achieve other things. Considering a big part of the kernel is types it makes sense to encode complexity within them.
Going "low-level" implies that you're abandoning abstractions to use all the tools in the CS and compute toolbox and the baggage that entails.
Private companies are not obligated to offer services, and in the US the government cannot compel private companies to do so (except rare circumstances). "We will stop offering services if X does not happen" is not coercive, it's an ultimatum. Companies should not be expected to operate in a market hostile to them.
What about privatized utilities then? What prevents e.g. electricity or phone companies from shutting down when they don't like some rules? It's a little more nuanced than "all or nothing".
Losing TikTok for a few hours or a day is perhaps going to make TikTok users more angry at the government than TikTok.
Losing electricity or phone service for a day is going to make people more angry at the utility or phone company, regardless of why the shutdown has happened.
And if a utility threatened to shut down service instead of complying with a new government regulation, you can bet the government would immediately jail anyone involved in that decision.
Covered under "except rare circumstances". Regulations for utilities, telecommunications, transportation, and financial services are the exception and not the rule.
Because it's endlessly profitable and very low risk to run a utility, the company's board is... unlikely to ever decide to do a stunt. For what payoff?
People only use Word or PowerPoint to do a small part in a larger job.
Many people live in Excel and spend much of their day-to-day in it. When Microsoft introduced the ribbon, it was the Excel crowd that was, by far, the loudest and most vocal. Excel has the Microsoft Excel World Championship, a legitimate Esport.
Free of charge is different from free of restrictions. Cloudflare didn't trick anyone into signing up for these plans, and it's never been a secret that they're a for-profit company.
> contradiction between marketing and reality
I think the important distinction is contradiction between expectations and reality. Cloudflare free plan's outside of Pages have never offered "unlimited free bandwidth" but "generous free bandwidth with conditions". It just so happened that for many the "generous" was unlimited, and this precedence somehow convinced everyone that "free plan" meant "unlimited free bandwidth" instead of "generous free bandwidth with conditions".
I'm with parent in the feeling that most the stories of Cloudflare acting in bad faith end up being the customer up to shady shit but expecting Cloudflare to subsidize them because "free plan". I'd be genuinely curious to read about an incident where I didn't side with Cloudflare.
Separate to this issue is that their Sales team employ strategies that the engineering crowd considers distasteful like phone calls, pressure tactics and private pricing. Most engineers never need to talk to a sales person outside retail, so it's a shock when you're suddenly talking to one trained and incentivized to exploit more from larger clients but is instead using those tactics on you. It's unsettling if you're not familiar with it, and leaves a bad taste in your mouth.
> Cloudflare free plan's outside of Pages have never offered "unlimited free bandwidth" but "generous free bandwidth with conditions".
To be clear, Cloudflare's pricing pages have definitely included statements like "we never charge for bandwidth" for the free plan of the CDN. Here's a snapshot from exactly 10 years ago[1].
They removed it after a while, probably because it's just not true, and I don't think they make any such statements on their increasingly complicated pricing pages any more.
The statement is true in so much as you can not be billed for traffic that has occurred without a paid contract in place. Also no mention of "unlimited", and though free is used throughout never "free bandwidth". It also doesn't contradict that Cloudflare can and does restrict or limit services for perceived TOS violations.
In the many years I've used Cloudflare I was never under the impression I received "free unlimited bandwidth", but "generous free bandwidth with conditions".
So if you're on a free plan you never pay for bandwidth, until you're not on a free plan (or any plan). It sucks to be one of the free plan users that doesn't have the ability to make a paid plan work, but I don't understand why Cloudflare needs to keep subsidizing something that wouldn't be tenable without their handout.
> Does that really make a difference if we have to re-write the entire tree node
The I/O write is a fixed cost, but sorting the data to match the pointers would require additional CPU cycles for an outcome that wouldn't really make a difference for subsequent operations.
It's one of the two big reasons. First is the ability to rollout features gradually and separate deployments from feature release, and second is the ability to turn new features off when something goes wrong. Even part of the motivation of A/B testing is de-risking.
reply