__jem

Right, because endless US involvement in ground wars in the middle east has always been firmly on the side of "concrete facts."

Isn't the point of a dev environment precisely that the intern can drop tables? Idk, I've never had a shared database not turn to mush over a long enough period, and think investing the effort to build data scripts to rebuild dev dbs from scratch has always been the right call.

That's why OsString exists.

You know, minus sexually abusing his sister.

> the return type of MyWidgetFactory() probably isn't.

Isn't the return type of a widget factory method obviously Widget? This doesn't seem like a great example. Of course the method name could be wrong and not enforced at the language level like something between angle brackets, but idk.

I've worked with some databases that are 20+ years old and have outlived multiple application iterations. There's always going to be cruft in this kind of situation, it just comes with territory of supporting applications with real production users for a long time.

Reclaiming the physical storage of an unused column is often a costly and sometimes impossible operation, which is why many legacy applications end up with the equivalent of my_column_final_final_v2. Database administration requires compromises like this sometimes in the name of uptime and data integrity. Big migrations are always inherently a little risky, and from the view of many DBAs, why even risk it just for a bit of clean up? Your schema shouldn't be totally transparent to your application's business logic anyway, so there are better places to enforce naming hygiene.

What is the fact that many foundational ecosystem crate contain unsafe code supposed to prove? That's the entire point of the language. That someone writes a really good regex crate once and then the rest of us don't have to write unsafe to use it. It seems like you have a fundamental misunderstanding about the goals and purpose of rust.

yes, it's harmless in this position but it provides no additional benefits to the select 1 idiom and is suggestive of poor query discipline. it's far easier to say just don't ever use select * in queries.

you're getting downvoted because it's not really a preference, it's pretty widely known to be bad practice and unhygienic in production queries. select * would get your pr rejected and chewed out by dba at every place i've ever worked at. so you kinda just look like you don't know what you're talking about.

I'm not sure this is really an issue with transactionality as a single request can obviously be split up into multiple transactions, but rather that even if you correctly flag the email as pending/errored, you either need to process these manually, or have some other kind of background task that looks for them, at which point why not just process them asynchronously.

Rust is memory managed, it just doesn't have a garbage collector.

Friction with modern devops practices is a big one.

Passing around functions that have already been partially applied means that downstream users can't incorrectly call or accidentally modify the arguments which have already been applied. Whether this actually results in more safety is unclear, as there are other language features or API design that accomplishes the same thing.