For AI generated code if previous PRs aren't loaded into context then there's no lasting benefit from the time taken to review and it's blank slate each time. I think ultimately it can be solved with workflow changes (i.e. AI written code should be attributed to the AI in VCS, the full trace and manual edits should be visible for review, all human input prompts to the AI should be browsable during review without having scroll 10k lines of AI reasoning.)

The type of situation I'm thinking about is for example storing a blob in S3, storing metadata and a reference to the blob's path in a database row, sending a message into a queue to trigger some async processing, and updating a cache. It would be nice to be able to do this through a single API or service, and it would be really nice to do all this within some type of transaction abstraction that would allow all operations to pass or fail collectively, really really nice if the whole thing could be pay-as-you and scale horizontally-ish on shared infrastructure without managing nodes or slots or whatever.

I'm not a Postgres user so I don't know how far you can get currently and I should probably look into it in detail. Coordinating blob/ject storage, database, and pubsub operations is a pain point for me presently. I think that overall system design is going to prevent a database-type system from being a good idea for blob storage but I would still like to see someone try to put three systems in a trenchcoat and try to make it work behind one interface.

    data:text/html,

Because of the potential overhang before the billing system catches up I think it would be appropriate to lower the service quotas on this type of account. I'm not sure if the customer can lower their own quotas which would be an alternate cost control strategy but a beginner wouldn't know to think of that anyway. The solution with billing alerts is good at a company level but too much for a beginner in my opinion.

I know unexpected costs were a concern for me when I started using AWS as a student in 2008 and it is still a concern for people in the same situation, just with so much more complexity on top of it all. It will be a tiny fragment of their revenue but as time goes on a higher and higher level of expertise is required to get started, even though you can accomplish a lot with just the free tier. The amount of progress they've made on this issue in the last 13 years is just not impressive.

    document.querySelectorAll(".countdown-calendar__door").forEach(e => e.classList.add("will-open"))

Part of the reason I found the paper I linked to be persuasive is that they predict the EVTOL aircraft only needing 2-3x the total energy of an EV. The energy cost in dollars could be less than gas for an ICE vehicle making the same trip. There are very light aircraft with 100HP engines, I'm picturing something light and birdlike.

The article also compares the range and energy efficiency to electric and ICE vehicles, accounting for the distance reduction by flying in a straight line versus driving on the road. If I recall it doesn't apply any extra value for time savings. The overall energy used in flying could be as little as 2-3x the energy used driving a terrestrial electric vehicle. Combine that with vertical takeoff and no traffic and we're looking at something pretty compelling.

And how much does it really need to cost compared for example to a Tesla? The weight will be more optimized and the safety regulations I assume are much sterner. The technical complexity seems similar but the volume will be much lower. I don't think it really works if you need a pilot's license so full autonomy is probably also a prerequisite for an everyday application.

I think EVTOL will still be embryonic in 2 years, but impressive in 5 years.

1. Memory management

2. Typing

I think your listed languages all have Garbage Collection? It will probably take quite a bit of mental effort to get comfortable with memory management in Rust but it is a valuable topic if you want to understand performance and language runtimes.

I'd suggest watching the 2nd (retrospective) video first, and then the first video if you're interested in more detail.

    javascript:!function(){var e,t;e='body {margin: auto;margin-left: 100px;max-width: 540px;font-family: "Helvetica Neue", Helvetica, sans-serif;}',t=document.createElement("style"),t.type="text/css",t.appendChild(document.createTextNode(e)),document.getElementsByTagName("head")[0].appendChild(t)}();

Edit I don't think it is infaillible, it didn't work on this page, but it works well on pages with no markup. For more complicated site you may try this: https://oxal.org/projects/sakura/bookmark/

I sympathize with the people who are worried this will degrade the Signal app. I like Signal over iMessage and WhatsApp partly because of the purity of purpose of the app. I like Signal because it doesn't create a treadmill of constant change and features added to drive engagement. I like Signal because it doesn't have Stories.

Signal as a messaging app is the best of its category, but there are other near-peers, new messaging apps are created every year, and I have ten other apps on my phone right now with DM capabilities.

I view MobileCoin as unique in the cryptocurrency space as a cash-like, private, fast and efficient payments platform and store of value and as that alone it would be great. My biggest issues with using cryptocurrency in a physical-cash-like way are mostly proposed to be addressed by MobileCoin+Signal:

- The hassle of using a non-custodial wallet, which is needed to truly possess your wallet. MobileCoin promises to let you control your own private-key on a mobile device. The iPhone is the most secure device I own: encrypted, biometric'd, and sandboxed. Having my private key on the phone plus a paper backup of the seed phrase is my ideal scheme for holding amounts under five figures.

- Waiting 10+ minutes for a transaction to go through isn't good enough for everyday use. (Look up Monero and Zcash block times and how many confirmations exchanges require for a comparison.) Faster is better.

- The meaninglessness of addresses: sending coins to a 40-character random string has already caused so much confusion. Linking it to your existing Signal address book is far superior.

- Broadcasting your financial life to the universe just seems imprudent, I think privacy wins over non-privacy for this reason. Privacy has intrinsic value.

- Proof-of-work systems just have a certain inelegance that I'm happy to leave behind. And the last few years in the Ethereum world shows how challenging this can be.

It doesn't address the potential volatility that causes problems for a store of value. Which is a negative but not a deal-breaker in my opinion. It might be addressed with something like Stellar USDC but I really don't know enough about the MobileCoin design to know if it is possible on the MobileCoin network. The technology is still useful for transaction processing, it is just more useful if it is also a stable store of value.

I don't view other cryptocurrencies as a risk to MobileCoin. If someone else can create better technology I'll use it happily and I'm guessing the people involved in MobileCoin would do the same.

I don't view MobileCoin as a risk to Signal messenger, because I think Signal will do a good job, or if they don't, someone else will, and myself and my close contacts will switch apps for the nth time.

The biggest risk to MobileCoin is that there might not be a citizen alive with the legal freedoms to actually use it. I really hope the project succeeds and I think Signal has a unique opportunity and unique credibility to do this. I think it will take 2-3 years to fully play out.

    du -cb $(ldd $(which ffmpeg) | egrep -o "/[^ ]+" | cat <(which ffmpeg) - | xargs readlink -f) | tail -n1

https://github.com/ffmpegwasm/ffmpeg.wasm-core/blob/n4.3.1-w...

Overall I think the wasm size is pretty good, maybe even smaller than the non-wasm binaries to a first approximation.