4,354 karma · joined August 11, 2014
<div data-parent-id="1234" data-category="Article">
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.
> 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.
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.
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.
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.
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.
In fifteen years of using Python, the only people I see getting burned are, conveniently, the folks writing blogs on the subject. No one I've worked with or hired seems to be running into these issues. It's not to say that people don't run into issues, but the problems seem exaggerated every time this subject comes up.
I've also been through several code audits, and other than sharing the "word" audit they're not the same thing. Audit in this context is the ability to follow how some numbers were derived, and to check how the work was done. It's so that the 3rd party that hired them can confirm the numbers a 1st party are showing are what they say they are (and if not, are they close enough).
Accountants are confirming things comply with GAAP or IFRS, and pointing things out when they don't and asking for clarification. They'll be checking that liabilities were properly structured, and reflected in how profit was derived. They'll be reviewing deferred revenue schedules to make sure next year's pre-paid subscription revenue isn't recognized in Q4.
A financial auditor is going to be looking at the assumptions of the forecast, and working backwards to confirm the methodology. They'll confirm that Q4 2026 projections used the prior years average multiplied by quarterly constant. Or they'll find a results from an ARIMA/Prophet model with notes to "see X". Maybe they'll catch an Excel formula error or 2, but they'll unlikely mean much compared to what else could be wrong.
Accounting audit usually involves accountants/CFO going through how the accounting system accounts are structured, and how those accounts get turned into the three financial statements (cash flow, income statement, balance sheet). You might have a unique accounting scenario where large expenses can be amortized over several periods, and an auditor will check how that reporting schedule was produced to net out what everyone is looking at on the financial statements. Maybe there was an acquisition that didn't quite pan out and there's an impairment charge that had material differences. Maybe your business collects cash upfront but reports deferred revenue. Maybe your company offers a product warranty so there's a non-trivial accrual schedule to consolidate warranty liability.
I worked at a company that convinced the SEC that it generated revenues from its published content over a 5-year period, allowing it to amortize expenses over that revenue-generating period while front-loading revenues over the first 18 months. Eventually the SEC changed the rules and expenses were expected to be reported in proportion to revenues.
There's a lot of ways those numbers can be put together, with a lot of different rules for how cash, revenue, and loss can be represented and disclosed. The kinds of errors I've seen encountered are less Excel formula errors, and more fundamental issues with account structures and how numbers are being strung together to reach what is reported.
The impression I've received is that what matters during the audit process is not if there are mistakes and errors, but if they lead to material changes that alter the trajectory of any decisions being made.
Absolutely, though they're generally orders of magnitude smaller than the table file unless you're INCLUDE'ing lots of columns.
There's pg_bulkload which supports parallel writers as well as deferred index updates until the loading process is complete. Not sure how it compares to what MySQL offers out of the box, but I definitely agree that the MySQL tooling ecosystem in general has a leg up.
PostgreSQL tables are known as heaps, which consist of slotted pages where new data is written to the first page with sufficient free space. Since it's not a b-tree and you can't resolve a row with just a primary key without a table scan, Postgres uses the physical location of the row called a tuple ID (TID, or item pointer) that contains the page and position (slot) of the row within that page. So the TID (10, 3) tells Postgres the row is in block 10 slot 3 which can be fetched directly from the page buffer or disk without having to do a tree traversal.
When PostgreSQL updates a row, it doesn’t modify the original data directly. Instead, it:
1) Writes a new version of the row to a new page
2) Marks the old row as outdated by updating its tuple header and relevant page metadata
3) Updates the visibility map to indicate that the page contains outdated rows
4) Adjusts indexes to point to the new TID of the updated row
Old rows continue to accumulate in the heap until the VACUUM process permanently deletes them, but this process can impact normal operations and cause issues.
Overall this means Postgres does more disk I/O for the same work as MySQL. The upside is Postgres doesn't have to worry about page splits, so things like bulk inserts can be much more efficient.
CodeWeavers released an annoucement when Gaming Portal Toolkit was announced.
https://www.codeweavers.com/blog/mjohnson/2023/6/6/wine-come...
I once had an auditor tell me that the books are allowed to be wrong, but should be wrong consistently. I've even run into the timestamp issue, which generally turned out to be a non-issue unless the wrong date was used (like order date vs. shipping date for revenue recognition) or a considerable number of errors caused dates to end up in a different reporting period. If you're dates are consistently a few hours off, then they'll be consistently off across reporting period boundaries and that can easily be explained to an auditor.
> the necessity to batch reconciliation processes between these layers
I've never seen a reporting period closed without accountants making journal entries for manual adjustments. These can often be material changes.
> An accounting system does not convert currencies at will
This is correct, but for internal reporting you might need to. An accountant and cash flow will capture the important conversion rate when the funds are expatriated, but your finance dashboard showing sales in euros will have an executive that wants to see it in US dollars. It's impractical to use the conversion rate from the transfer that could happen weeks or months after the reporting period, so you come to a compromise of using a X-day FX moving average that's "close enough" and everyone's happy. What goes in your 10-K/Q will be a different story.
You can pay the cost for something upfront, and the cost of maintaining it, and in the long term paid too much for something you didn't actually need.
Alternatively you can wait to pay it until you're certain you need it but the work involved has become much more significant, in which it can cost more than it would have to have built and maintained it from the beginning.
Compounding the issue is the build-up-front scenario costs fade with time and you don't really think about them, but build-when-you-need-it always creates a stir even if the costs are less overall than build-up-front.
Either way something will go wrong no matter how many times you predict where the cards will fall.
Shout out to Tractor Wars, which I never expected to enjoy as much as I did.
I pointed out that you don't get an audience for free, and that seems to have further upset you.
Doesn't look like the issue is on my end. You could have used the opportunity to correct my understanding, instead you decided to be rude.
What I'm reading is someone wants all the upsides with none of the downsides. No one is entitled to an audience, especially that of another, just because they've produced some good or service. Participating in capitalism requires either time or money, usually both, and even then you're not guaranteed success.
Valve has been banning accounts for circumventing region restrictions for as long as the feature has existed, and long before Sony added their games to the platform. Just because these policies were designed to appease rights holders doesn't change the fact that it's at Valve's sole discretion to enforce compliance (at risk of losing publishers).