2,900 karma · joined November 15, 2011
I don't know about those fancy graphical browsers, who has those kinds of resources to just throw at some pretty pictures?
You do lose the market signals about the real cost to insure when you do this though. Ultimately we have to change where we build but that's a HUGE undertaking and it's unclear where the political will for that will come from.
1. email-based "reset passkey" flow -- only as secure as the email it's sent to, and you need to make sure the email is still valid since the user isn't using it regularly as part of their auth.
2. multi-factor "reset passkey" flow -- you have to make sure the user has kept multiple factors (eg backup codes) which they're mostly not using.
Is there something better? Anyone have a good resource?
Will it rent for 10% more or 10% less than something comparable in inner sunset? That's the question.
The recursive query is cool, but how is the performance for graph queries compared to a DB optimized for this use case ?
Eg a TV costs 10% of what it did 20 years ago. Fewer person-hours of work are involved in making one TV. Less of the average home budget goes to TVs than it used to, even while people are buying better tvs.
That’s a massive productivity increase in the lingo of economics.
You could replace TV with solar panels, cars, computers, etc. Less human involvement per good produced => productivity increase.
Better than jobs which are replaceable with automation? For sure.
I don’t know if the AI stuff will play out similarly, there are some differences.
But it seems to me there is an infinite amount of software to build, and when we increase the productivity of software development, we just build fancier software, faster.
The flip side of the coin is over time we spend more of our income on the things that don’t have increasing productivity. Think of housing, education, health care, etc
In this case it's a little more complicated since you also get the principal back in pieces, but you can calculate the price today to create the equivalent of a 3% yield instead of 1.5%, and you'll get a significant price reduction.
CPython is also building a -no-gil compile-time option. If that gets traction, some of the big performance-oriented C extensions like Numpy etc would likely build a non-GIL extension version too.
Then, if RustPython's non-GIL implementation is compatible with CPython's, and their C ABI is compatible, those C extensions might work.
Their github.io page mentions interesting use cases though:
> RustPython can be embedded into Rust programs to use Python as a scripting language for your application, or it can be compiled to WebAssembly in order to run Python in the browser
If I were them I'd focus as many resources as possible on making the stack rock-solid, and away from acquiring more customers or adding more capabilities.
In fact I'd try to down-scope some features if at all possible, like the example they give of disabling app deploys while they're doing platform updates.
We use fly.io at a small scale and it's worked really well for us, but the money is in customers at a larger scale who must have 100% reliability.
I think an alien would find it cute that we believe in this weird thing called consciousness.