Just because there might exist tradeoffs doesn’t make them matter to someone. If you’re using a Linux distro then you’re already living off thousands of decisions made with tradeoffs and it’s hardly feasible to be informed or care about all of them.
I would have agreed on instinct but everyone replying with which features they actually use seems like it pretty much makes up all the major available features. Maybe having all these features is necessary to appeal to every individual’s needs rather than one power user who uses them all?
Because a harness doesn't just "drive" the LLM. e.g., there's code in claude code that detects if the user's prompt shows they're angry, and they react to those prompts differently. (they use regex on "wtf", etc.!)
I care more about hiding AI related articles than I do about AI-authored content in articles. Feels like most of the content on HN is now AI related and it’s just exhausting. Anyone have a way they’re correcting this balance of content, like a browser extension maybe?
I have default "AI" keyword and domain filters as a separate toggleable option (so you can keep your personal filters separate) in my HN extension (which I really need to add recent model names to):
people have done regex-filtering hn clones, ai to detect the ai, etc. been a few show hns. but threads like this would get caught up in that (no perfect solution).
i just manually hide anything ai related.
first pass: hide anything related to AI on front page.
second pass: is there anything interesting left on the front page?
sadly the answer to the second question is often no nowadays :/
One obvious answer is that people probably don’t want to write a whole parser and wire up new steps in their build pipeline just to do something simple like get the name of enum cases as a string.
Without taking a stance on whether in-language meta programming facilities are good or bad, it’s not hard to find examples of cases where people find it useful to have them.
You get to choose between UB, a crash, or handling the error — same as most other languages.
It’s not a reliability issue of the language if as an author of software you choose to crash in your failure handling cases. Claiming otherwise is either disingenuous or a failure to understand what actually happened.
No, it's not the "same as most other languages". C and C++ are actually the only mainstream languages that suffer from UB to this extent.
The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt. And blaming the crash on the author, saying they "chose to crash", is exactly the same as blaming UB on the author of C code, saying they "chose to double-free".
> The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt.
This is totally false. It's not in the least hard to avoid crashing.
match some_result {
Ok(value) => { // handle the value },
Err(e) => { // handle the error condition }
}
The fact that Cloudflare chose to handle a result with the "panic if this result is an error" function is 100% on them, not on the language. Blaming the language is like claiming that any language which has assert is a problem because the assert can crash your program. Yes, that's what it's there for, so don't use it if that isn't what you want.
And don't give me the "the method name isn't obvious enough" argument you used elsewhere. That holds no water. It's basic Rust knowledge to know that "unwrap" will panic if the value is an error (or None if it's optional). If the engineers writing the code didn't know that, then the problem is they didn't bother to learn how their tools work, which again is not the language's fault.
What UB? This has nothing to do with UB; it'd be well-defined in any language. It's equivalent to this python snippet:
config = load_config()
if !config.valid():
sys.exit(1) # config is corrupt. restart pod
Did Python do something wrong by letting users call `sys.exit`? No. This is a deliberate crash. Under other circumstances, crashing might have been a valid strategy, but here it turned out to be a bad choice, since Cloudflare's infrastructure was restarting the service with the same bad config every time.
Sys exit does not crash. It raises a SystemExit exception, which can be caught on any layer above it. Given that python uses exceptions for trivial things like loop termination this can be considered normal flow control.
Yeah, and in Rust you can catch the panic from `unwrap()` with panic::catch_unwind. You just don't, for the same reason you don't catch SystemExits. If a SystemExit is being thrown, it's because you want to crash; if you don't wan to crash, don't throw a SystemExit.
If I could choose between UB and a crash I will chose the crash every time. The sooner the better, preferably in test. And that's where CF's real failure was.
It really won't. The only reason I could think of is if there were a Sphere(Sphere*) constructor, which would be weird, and is also not the case [1]. There is also no reason to use a vector<Sphere*> since Sphere is not part of an inheritance tree; a vector<Sphere> would've done just fine removing the calls to 'new' in that blog post.
Overall, I think this post is on the low end of the quality spectrum. I think the author is a bit confused about things, like they've been doing JS and picked up C++ only recently. Nothing bad about it, but I would do some more reading before posting much of anything.
I've done it before to integrate rust into polyglot build systems. There's a surprisingly long history of build systems trying and failing to implement rust builds without the "happy path" of simply wrapping cargo. As far as I know no one's ever succeeded.
The problem with giving each team a repo and an API surface is that you create API boundaries where your organizational boundaries are, not necessary where your service boundaries are. And as your organizational structure evolves over time, your repo and API boundaries lag behind since it’s so difficult to make large scale shifts to the code.
I don't see that as a bad thing. By creating granules you constrain that evolution such that nobody ends up with half of a thing. Without those boundaries, people who don't understand the code may motivate organizational structures which don't make sense.
That's where I've been for a few months: The work of prior gatekeepers now run through the middle of what we're responsible for. It feels like we bought a house online and when we showed up the kitchen is in one country and the bathroom is in another so we have to clear customs several times a day and we have to hold a summit with the friends of the previous owner if we want to change anything--even things in the interior. The architect of the reorg would never have done this if the natural boundaries had been a bit more apparent, i.e. as a list of repos to be assigned to the new teams.
I'd prefer large scale shifts to come by replacing an old repo with a new one (or one with two, or two with one, or by open sourcing one which you no longer care to maintain). Maybe that slows down the organizational rate of change, but if the alternative is pretending to have changed in a way which isn't actually sustainable, then maybe slowing down is better.
More recent commentators have noted a corollary - for software projects with a long lifetime of code reuse, such as Microsoft Windows, the structure of the code mirrors not only the communication structure of the organization which created the most recent release, but also the communication structures of every previous team which worked on that code.
reply