> A CEO of a low-code platform articulated this vision: in an “agentic” development environment, engineers become “composers,”

I see we'll be twisting words around to keep avoiding the comparison.

It is the equivalence of saying: Stenotype enthusiasts claim they're productive, but when we give them to a large group of typers we get data disproving that.

Which should immediately highlights the issue.

As long as these discussions aren't prefaced with the metric and methodology, any discussion on this is just meaningless online flame wars / vibe checks.

I'll represent the insufferable Emacs/Vim pricks by saying: Once I read you're using a mouse during development, my willingness to entertain your contrarian dx ideas dropped to near 0.

All the AI websites feel extremely clunky and slow.

I'd even go so far as to deny any submission with more than sqrt(size) walls.

It matters - because Satan can disconnect the centralized nodes.

These decisions require a pretty broad coalition to get a workable plan in front of Trump for him to activate for attention. So there is never 1 single reason, but my 2cents are that:

- Most of the oil export goes to China. Especially with the recent metals kerfuffle, this is a quick way to improve the US' negotiation position.

- The hawks in the army are getting restless and are clamoring for real-world modern drone warfare experience - especially if Taiwan turns hot. Getting a trial run in your backyard in similar terrain is good practice. (Assuming they'll send in an occupying force, and it's contested by china backed insurgents).

If Russian and Iran are skirting sanctions with a shadow fleet, it would make sense to disabling that fleet would weaken them. e.g. https://www.nytimes.com/2026/01/01/us/politics/russia-oil-ta...

The pros for using anyhow are big: Easily stack errors together - eg file.open().context(path) -, errors are easily kept up to date, and easy to find where they occur.

An enum error is pleasing when you're finished, but cumbersome in practice.

It's niche situation that you need to write a function that exposes a meaningful Error state the caller can branch on. If the return state is meaningful, you usually don't put it in the Err part. eg parsers using { Ok,Incomplete,Error }. IMO Error enums are best for encoding known external behavior like IO errors.

For example: The Sender.send_deadline returning { Timeout, Closed } is the exception in being useful. Most errors are like a Base64 error enums. Branching on the detail is useless for 99.99% of callers.

i.e. If your crate is meant for >1000 users, build the full enum.

For any other stuff, use anyhow.

Sure, it’s slightly more error prone than proper enum errors, but it’s so much less friction, and much better than just doing panic (or unwrap) everywhere.

anyhow seems useful in the very top layers where you basically just want bubble the useful errors modeled elsewhere to a top layer that can appropriately handle them. I don't think a crate should abdicate from modeling the error domain any more than they should abdicate from modeling the other types.

I'm not saying the error domain is small per se.

Instead, one argument I'm making: what you're describing about errors bubbling up to the top layer, is what happens with the overwhelming majority of errors in my experience.

Whether the error space is large or small, just wait until you have an immediate need to treat one error different from the rest. It happens, it's just not common.

I didn't steelman the case for when to use enums, but in short: In a tiny error space or as valuable documentation.

(The doc value is undermined somewhat when projects use 1-big-error and functions that eg only returns 3 of the 6 possible errors)

I'm not advocating removing an Error enum. Just that writing one can and should be postponed, saving a lot of maintenance edits.

    what you're describing about errors bubbling up to the top layer, is what happens with the overwhelming majority of errors in my experience.

Yes, it's just harder. We usually have a pretty good idea what callers want from the happy path, but the range of things that callers may or may not want to do in case of an error is very broad.

This is very hand-wavy, but I think we're talking at a very high level of abstraction here. My main point is to suggest that there is more of a balancing act here than perhaps your words suggest.

But that's exactly what you do when you...

>... try to indicate the different types of errors that could occur and what type of information needs to be included to be useful to the caller.

Modelling the error domain means to decide which possible distinctions matter and which don't. This is not self evident. It's you imagining what users may want to do with your errors.

Is it enough for the caller to know that some string you're parsing is invalid or do they need to know what it is exactly that makes it invalid?

If you decide to just pass on everything you happen to know based on your current implementation then you are putting restrictions on future changes to that implementation, potentially including the use of third party libraries.

What if you find a shortcut or a library that makes your parser 10 times faster but doesn't provide this detailed information?

What I see a lot in Rust is that massive amounts of implementation details are leaked via errors. thiserror actually encourages this sort of implementation leak:

  #[derive(Error, Debug)]
  pub enum MyError {
      Io(#[from] io::Error),
      Glob(#[from] globset::Error),
  }

Your example is interesting actually because there are real differences in those types of errors. IO errors are different from the globset errors. It is reasonable to assume that you would want to handle them differently. If your function can actually have both errors as a consumer I would want to know that so I can make the correct decisions in context. If you don't have a way to signal to my code that both happen you've deprived me of the tools to do my own proper error modeling and handling.

You are implying that there is one correct and self evident set of distinctions. I disagree with that. In library design, you're always making assumptions about what users may want. In my opinion, this is even harder when modelling errors, because there are so many possible ways in which callers might want to respond.

>Your example is interesting actually because there are real differences in those types of errors. IO errors are different from the globset errors.

Of course. I'm not complaining about the distinction between io errors and globbing errors here but about the fact that the globset library and its specific error type is leaked.

What if someone (say fastburningsushi) comes along and creates a glob library that absolutely smokes this one? :P

Also, database errors. While the specific error may not be important, knowing whether an error means that a transaction definitely did not commit is valid, as is knowing whether retrying the transaction is likely to be useful. (The common case is retrying transactions that failed due to deadlock.)

I get what is being said, but i disagree with the framing. The "brainwashing" happened in two stages, and the first stage is perfectly logical.

Most people don't want just 1 identity, and they want separate spaces for being different.

If you're already OK with having two accounts on BBS, what is 1 or 2 accounts more for thefacebook.com?

Google when you make a chargeback or your youtube channel has the song of a bird

The other platform also have similar weird cases.

I don't want to be instabanned from ALL the internet just because one site decides I did something wrong for real or imaginary reasons.