__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.

I'm not sure if he's made an official statement about his versioning policy, but if you look at https://crates.io/users/dtolnay?sort=downloads, you can see that most of his crates follow the incremental patch versioning style.

Correct, serde does not follow semver.

Well, there is an exit path for those who want to compile from source. If you mean build from source for Cargo users, I believe there's issues with how feature flags interact with transitive dependencies that make this difficult. At least, there's comments on the issue that speak to this. Maybe someone more familiar with Cargo can chime in.

I found the discussion to be mostly very civilized and focused on finding solutions for those affected.

I really disagree with this characterization of the discussion. While there's plenty of more or less dispassionate comments focused on finding a solution, there's a greater number of people from the peanut gallery drowning that out with comments that amount to "I don't like this!" at best and questioning the integrity of dtonlay at worst. I feel like this demonstrates some of the worst features of open source software on github, where a bunch of nobodies feel the need to add their totally useless input rather than participating in good faith to find solutions and make the software better. You even see comments like that here, speculating that dtonlay is trying to break cargo and force people to use bazel, which is just an insanely conspiratorial and bad faith speculative interpretation that is obviously untrue and helps no one.

People have complained about the build time of proc macros for ages in the community. This might be a misguided hack, but the response to this is bordering on a witch hunt, particularly when there is a glaring security hole (build.rs) that most people likely use without second thought every single day. I simply do not believe that most people commenting on this issue are auditing the builds of all their transitive dependencies.

Only some of the providers are based on Terraform. I think it would be incorrect to say it's "powered by Terraform."

However, tailscale focuses on access different devices to each other, while Narrowlink focuses on access to the services trough on the agent as a proxy.

You can easily do the same thing with Tailscale: https://tailscale.com/kb/1019/subnets/.

Could not disagree more strongly that Datomic is well maintained. I'd view it as a significant liability in any organization using it without very good reason. My experience operationally supporting Datomic at even a moderate scale was a total nightmare and soured me on the Clojure ecosystem as a whole.

Well, in the real world, the premise is false, but not because writing memory safe code is in fact easy, but because in aggregate in large code bases it's impossible.

Okay, but using unsafe for FFI is entirely different than the claim that you can only achieve performance optimizations through "dereferencing pointers without anything extra running." The use of unsafe for FFI is unavoidable for obvious reasons.

SQL (ACID) over multiple non-cache-coherent nodes is extremely difficult to pull with regards to consistency, though.

Thats... why it's a toy! I'm really not sure what you're missing here.

Right, just because something is a "toy" doesn't mean it's not still impressive. If someone implemented a "toy" database that could parse and execute SQL queries, distribute data across nodes, etc., you would probably not want to use that in production, but it's still a very impressive project for a single person to pull off, even if it's riddled with bugs. Getting a very complex system to "just barely functional" is still a huge achievement and very cool!

Or, worse, you're reviewing a large diff, see the logger statement but don't notice that the junior whose code you're reviewing forgot to rethrow. Now you've accidentally entered uncharted territory where way more scarier things can happen to your application than just crashing. Of course this shouldn't happen, but it does.

On the other hand, in lots of application code, there's often not much to do other than crash or abort the request, and this can often be safer than trying to proceed along code paths that are almost always under-tested. We've all seen Java code where a junior has decided to swallow an error without much thought. This obviously isn't true for every use case, but failing fast is often a pretty good policy.

https://en.cppreference.com/w/cpp/language/coroutines

But highly doubt you need anything like async/await for this kind of application. In fact, I'd go as far as to say async/await is almost never needed except for building networked services with truly massive performance demands.

This is so helpful, thanks.