HN user
I think the mindset is usefull personally. When large complex systems are required and economic pressure is applied it can rapidly turn into an dangerous strategy. You will quickly realize that no you can't just build that.
How come I have never seen this tradeoff work in practice?
If you have an int32 or less you can!
Sure. But I'm trying to connect what you said:
you'll come out with superpowers you didn't have before.
with the impressions from the reviewers.
I don't think they got super powers from the book. In fact their outcomes mirrors my own outcomes when going deep into some math topics and then bringing them to work.
This review is not so nice: https://emptysqua.re/blog/review-queue-theory-book/
What will be Amodei's job after we have AIs that are better at evrything than humans? Is the AI going to care about our stock exchange playgrounds that reward the future Antropic stock holders?
Could be boot locked to the original owner Apple account.
How about answering the question and then add details later? IME that tends do work better.
At least if you a test suite that doesn't have to be migrated. I too would like to migrate some services from Python to Rust but my test suite is written in Python so I would have to actually check if the test suite migration was correct manually (I can't event compile it!) before doing the rewrite.
Curious how the test suite was applied. Was it ported from Zig to Rust beforehand?
Works great. No wonder China is eating our lunch.
Can you share that document?
It's in the file metadata:
- LuaTeX-1.17.0
- LaTeX via pandoc
I don't even understand what approach 3 is doing. They ended up hashing the random part of the API key with an hash function that produces a small hash and stored that in the metashard server is that it?
Apple's accidental moat now is taking the rise of hardware prices due to AI eat into their margins and just expand the mac user base.
realizing different systems will have different constraints.
I realize that. There are a few comments already that present use cases where I can totally see using Sqlite as a good option.
Not everyone needs monopolistic tech to do their work
We are talking about localhost Postgres vs SQLite here. Both are open source.
So you are migrating from Sqlite to Postgres because you need it. What is the state of your product when you need to do this migration? Is your product non trivial? Are you now dependent on particular performance characteristics of Sqlite? Do you now need to keep your service running 24/7? Accounting for all of that takes way more than 5 minutes. The only way to beat that is if you still have a toy product and you can just export the database and import it and pray that it all works as a migration strategy.
Yes it might be risky. But most schema evolution changes can be done with no or minimal downtime even if you have to do then in multiple steps. When is a simple ALTER going to be totally unacetable if youare using Sqlite?
Do you know why it is a toy? Because in a real prod environment after inserting 240k rows per second for a while you have to deal with the fact that schema evolution is required. Good luck migrating those huge tables with Sqlite ALTER table implementation
Gets proper backups if you back it up the right way https://sqlite.org/backup.html
I bet that takes more time than the 5 extra minutes you take to setup Postgres in the same box upfront.
What do you recomend as reading material for someone that was in college a while ago (before AE modes got popular) to get up to speed with the new PQ developments?
I read the article and to be honest I don't know where we disagree. I disagree with this quote,
Takes ~10min to revert a bad deploy
A bad deploy can take way over that just in customer or partner management communication.
The other side of this is building safety nets. Takes ~10min to revert a bad deploy.
Does it? Reverting a bad deploy is not only about running the previous version.
Did you mess up data? Did you take actions on third party services that that need to be reverted? Did it have legal reprecursions?
I wouldn't say acceptance of crappy code. I think the issue is the acceptance of LLM plans with just a glance and the acceptance of code without any code review by the author at all because if the author would waste any more time it wouldn't be worth it anymore.
The problem is those plans become huge. Now I have to review a huge plan and the comparatively short code change.
Does that mean CXMT is one inch away from also eating into the DDR5 market?
Maybe they reverted it because they are already planning to get rid of the super rounded corners!
Well Coq has program extraction built in.