71–80 of 187 posts
Maintainer uses AI to find Yubikey's site. Hacker uses AI to research countries without extradition to US. Cops use AI to analyze ransom note. Unfortunately, because the note confidently states that Vietnam has no extradition to the US, the AI recommends paying ransom. Vietnam's currency, the Dong, confused the AI..
the fact that this could easily pass as real says a lot about the state of things.
The dreaded Marcus Chen strikes again.
https://www.reddit.com/r/ClaudeAI/comments/1o3b4q2/just_rece...
According to Pangram, this is likely AI generated, surprised that no one has pointed this out
Not a chance. Far too funny, too well written, too terse while being densely packed with wit. I see zero signs of it being LLM-generated and lots of stuff LLMs have no way of doing. If I am somehow wrong I would salivate at a chance to see the input.
It's easy to be cynical because, yes, both the problems and solutions seem dead obvious in hindsight. But for a long time (and maybe even still), a hacker creed was "move fast and break things." It's great that there's so much momentum in fixing the glaring problems with supply chain systems like npm, but I'm concerned that we're entering a new era of security-related problems caused in large part by agentic developm…
> But for a long time (and maybe even still), a hacker creed was "move fast and break things." Was it? I thought Zuckerberg coined this horrible phrase.
Earlier quoted context omitted.
Why? Honest question. Commons, Guava, Spring, and more seem to take this approach successfully (as in, the drawbacks are outweighed by the benefits in convenience, quality, and security) in Java. Are benefits in binary size really worth that complexity? And before someone says “just have a better standard library”, think about why that is considered a solution here. Languages with a large and capable standard library…
You will have lots of dead code in your build. That dead code might have "dead dependencies" - transitive dependencies of its own, that it pulls in even though they are not actually used in the parts of the crate you care about. In the worst case, you can also have "undead code" - event handlers, hooks, background workers etc that the framework automatically registers and runs and that will do something at runtime, w…
Earlier quoted context omitted.
Many small crates published by large, trustworthy projects are fine and preferable to one large crate that "does everything".
Why? Honest question. Commons, Guava, Spring, and more seem to take this approach successfully (as in, the drawbacks are outweighed by the benefits in convenience, quality, and security) in Java. Are benefits in binary size really worth that complexity? And before someone says “just have a better standard library”, think about why that is considered a solution here. Languages with a large and capable standard library…
Smaller implementations are also easier to review against malware, because there are fewer places to hide. You don't have to guess how a component may interact with all the other parts of a large framework, because there aren't any.
There are also practical Rust-specific concerns. Fine-grained code reuse helps with compile times (a smaller component can be reused in more projects, and more crates increase build parallelism).
It makes testing easier. Rust doesn't have enough dynamic monkey-patching for mocking of objects, so testing of code buried deep in a monolith is tricky. Splitting code into small libraries surfaces interfaces that are easily testable in isolation.
It helps with semver. A semver-major upgrade of one large library that everyone uses requires everyone to upgrade the whole thing at the same time, which can stall like the Python 2-to-3 transition. Splitting a monolith into smaller components allows versioning them separately, so the stable parts stay stable, and the churning parts affect smaller subsets of users.