teepark
This reminds me of "latency numbers every programmer should know". Work with the standard library and other well-conceived go projects and you gain the intuition that error handling and bit-twiddling arithmetic don't belong together. That's the real story here, and OP's article is way wide of the mark.
Nobody's real-world code is being slowed down by 500% because all real world code is doing much more than just checking errors. All I see from these results is a 15-16ns cost to using errors.Is versus an additional boolean.
Even the examples ("GetValue") hint at an extremely common use case: reads from a data store. A case where single-digit milliseconds is considered "all good performance-wise" for the most common SQL databases, clocking in at 100000x the time scale of errors.Is.
Facta is modernizing the CFO stack for mid-market companies, starting with accounting's month-end close. Come help us empower some of the most undervalued employees (accounting, controllers, finops teams) with tools that automate away their tedious manual workflows.
We are looking for product managers, designers, sales, and engineers.
Fintech | Typescript, React, Go, serverless AWS
Facta is empowering finance and accounting professionals with a suite of modern software tools that work in tandem with general ledger services to speed up monthly close, get their teams out of spreadsheets, and get critical finance data in front of decision makers faster.
See our open roles at https://jobs.lever.co/facta
Twisted was right and I was wrong
cache: http://webcache.googleusercontent.com/search?q=cache:ZDGnKBh...
actually it could use row-level locking since it uses row-oriented storage and fcntl locks can be applied to a set of bytes within a file. it could also do file-level locking on tempfiles with names derived from the table name and primary key of the row.
anyone with actual knowledge of it care to chime in with what it does do?