My layman view is that more compute (more reasoning) will not solve harder problems. I'm using those models every day and when problem hits a certain complexity it will fail, no matter how much it "reasons"
All I want is an iPhone Shortcuts script to delete messages like "Hi" and "Hey" from unknown numbers. I get so many of those and having to delete them is a pain.
Shortcuts does not allow deleting messages apparently :(
I have not tried Bun yet but the long list of features makes me skeptical that it's all solid and bug-free. I'm wishing to be wrong. I'll give it a spin in a future project.
From a project management perspective I'm a little confused why would you spend time on S3 support while you're still not 100% Node.js compatible. Next.js is a very big ecosystem and if you can get Next.js customers onboard you'll grow much more than supporting S3.
I agree with Tailwind's stance on this. You really don't need @apply if you're breaking things down to smaller components. I often see people have things like <ul><li className="long_list_of_classes">text1</li><li className="long_list_of_classes">text2</li>...</ul>. This is where I think we need a linter to warn against things like that. Make those <li>'s a component!
I think everyone who worked at Google in the past has PTSD from having to migrate gRPC schemas. What a mess! Type safety doesn't have to be this costly
With all that AI generated code being pushed, as a leader I wonder which is better? Enforce a ton of e2e so no code that is really well thought through all aspects of the solution can go past CI or does this enable AI to go even crazier and break all sort of best practices to just pass the test?
I'm not trying to be cheeky here. They have literally joked about how TypeScript versions means nothing really. So they can't just announce a new major version and drop enums completely. Maybe with a feature flag this is possible but even then, a fresh tsc --init not supporting enums is not really how TypeScript works