It is interesting. When I was learning, I found “mut” way more confusing because it is less precise (it’s one level of abstraction higher, mixes “usual intent/goal” with “what does this keyword do”) so it added an extra layer that I had to mentally back out/elide every time I read the keyword.
I kinda wish it had ended up with something like 'exc` for exclusive, or one of the options you mentioned.
I think it would have made things easier for people to learn a helpful mental model.
There is one tangential thing that I’ve thought about before—it would be nice if there was some way to encode this into the library ecosystem (ie crates.io)
I have no idea how this would be realistically possible though—it’s pretty clear that you can rely on categories that are statically verifiable like “no-std/no-alloc”.
But what mechanism could be used to allow library consumers to distinguish between things like “laser focus on high perf/low-alloc” vs “prioritizes API over perf-at-all-costs” vs “this package is an experiment/Baby’s First Crate/shitpost” ??
They’re all valid choices for different consumers or usecases.
my interpretation of the “clone is the way to go” comment is that it’s in the context of the OP saying “I haven't written much Rust…”, which puts a pretty clear frame around the intended applicability of the statement no?
I don’t taking it at all as being an absolute statement.
Another is MS SQL Server, which lets you run .NET on the database server :D "you can author stored procedures, triggers, user-defined functions, user-defined types, and user-defined aggregates in managed code"
> I can't imagine sitting and stepping through in a debugger 100+ times in the hopes that maybe this time, it will be the run that's just different enough to trigger the bug
Isn’t that where things like breakpoint conditions, data breakpoints (“break whenever X value/field changes”), and dependent breakpoints, work pretty dang well? You just set up the appropriate situation and let it run until it breaks
Thanks! Maybe it would be worth adding a docs example of a proper GH workflow using Depot?
It’s a decent option, but it’s still more complicated (multiple vendors, configuration, etc)
You know what, it could be really nice if y’all could create a simple Depot GH Action that would make things more efficient (for example pass in the repo token so that Depot could pull the repo vs first pulling it from GH into the workflow runner and then ship it over Depot)
Any chance of offering GitHub Runners as a tweak of the underlying “hard parts”?
I’ve had really good luck with this type of offering from BuildJet, except that they don’t offer any ability to have persistent volume between runners. So all of our builds are fast _except_ the ones that build containers, but it’s too much of a pain to have some stuff in GitHub Actions with 3rd party hosted runner and then a totally different system for container builds/test workflows.
I came to similar conclusions.
Tide is IMO the most ergonomic, but its future is unclear in terms of community/maintenance. Its choice to use async-std ended up kind of biting it, since projects have by and large chosen tokio. I have hope for the eventual “swappable async runtimes” initiative, but it’s probably going to be too late to help in these regards.