You're missing a match after the = and before guess… on line 25.

The multiple statements on 37, 38, 39 after => also need to be enclosed in a {}.

Also, why is your error message all the way up on the top, far away from the error? Something seems misconfigured.

Once components are written in Rust, working on them will of course, but sure, the “test balloon” itself doesn't.

Don't get me wrong, I'm not against any of that, I just don't get how this variant of the headline could be misleading

This, or a runtime dependency on rustc or something, was my initial impression as well. The link clarifies it pretty quickly though.

The title makes it sound like writing Rust for git will be mandatory

Why weird? This is the phrasing used for some patches in the change set, and it means the same thing as the long version.

Rock on! This is the ideal way to handle this, since it gives everyone plenty of time to work out the kinks.

Weird cutoff on the title. This is the full sentence:

Announce that Git 3.0 will make Rust a mandatory part of our build infrastructure.

I'm interested to see how this goes. Maybe they could work with the gitoxide devs to see if there's some work that's already been done.

Not really sure myself if Git needs to be RiiR, but that's their call to make I guess.

Well, I was talking about the linking performance improvements and the workspace publishing.

I've been meaning to write a script for publishing my crates in the right order, but hadn't done it yet, because just running the publish command for each crate didn't feel robust enough. Now that's a solved problem.

What other large change apart from the linker happened?

Two larger changes that I'm pretty excited for. Nice! 🙂

This is an awesome tool, and I love to see it get a Rust rewrite.

But the one thing I really wish it could do is embed properly in GitHub's markdown UI so that when I click them in READMEs it doesn't have to send me to the asciicinema site.

I'm sure that has way more to do with GitHub than it does asciicinema, but still, that's why I don't use it for my projects. I hope that can change one day.

The post text doesn't seem to get displayed on some clients (Voyager) so I'll attach it here as well:

asciinema (aka asciinema CLI or asciinema recorder) is a command-line tool for recording and live streaming terminal sessions.

This is a complete rewrite of asciinema in Rust, upgrading the recording file format, introducing terminal live streaming, and bringing numerous improvements across the board.

Oh absolutely. In fact, I created a package that currently has millions of weekly downloads that I don't really maintain anymore (someone else volunteered). So I'm pretty familiar with these issues. People burn out or move on or whatever.

The reason I like larger projects is because it's more likely someone will notice if there's a problem. There's no guarantee, sure, but more eyeballs is generally a good thing, and that's how the xz vulnerability was caught so quickly. It's better if a project has a healthy amount of contributors, but all things being equal, I prefer a popular project to a less popular one. How many people would notice an issue in diesel-async vs diesel? How many are like me and would use the async features if it's in the main project, but would hesitate if it's a separate crate?

None of this has anything to do with the quality of of the code or maintainers, it's purely about the number of eyeballs.

These are certainly valid considerations, but I would like to point out that just because a project seems large on the outside that does not guarantee that it has enough maintainers. Most open source projects are still run by a single person. That is still mostly the case for diesel, but also applies to much larger projects like curl. So while it might feel like a „large“ project will protect you from such issues, that’s really no sufficient guarantee. The only way you could make sure to not run into such problems is by auditing all of your dependencies.

Agreed. My point was that you'd probably know more about the relationship between the projects than some rando. I've seen plenty of misinformation from people making claims about projects that don't hold.

And yeah, I've found great crates from smaller projects. That said, I'm always worried about an xz issue where a small, impactful project gets targeted by malware authors and their changes get in because there's not enough people involved in the project. Or maybe it's as simple as the lone maintainer stopping work on the project and the project stagnates. If it's not something I'm willing to step in and maintain or replace myself, I'm going to go with a larger project, even if it's not quite what I'm looking for, and DB libraries definitely fall into that category.

While I can understand your concern, I‘m technically speaking also just some rando in the internet. It’s likely a better solution to evaluate crates a somewhat independently from their authors and and bit more on the actual code, quality and number of other projects dependent on such a crate. Sometimes such crates from someone in the community are real gems.

Awesome! I honestly didn't recognize that the username here and from the repo were the same.

Honestly, the fact that you maintain diesel and diesel-async gives it a ton of credibility. I'll have to play with it! I was mostly worried this was a shim made by some rando in the community and it could break at any time, but if the core maintainer is also associated with the parent project, that's less likely.

Appreciate the detailed context, and thank you for your work!

Well there are a few reasons not to have it in diesel itself. One is that the main crate already is really large. Adding another massive feature like that would make it make harder to maintain. I think about splitting up diesel into multiple parts instead from time to time. The other important reason is that diesel itself is stable, while diesel-async is still a bit in the flux due to the general instability of the async ecosystem and async rust in general. For example we still miss several language features like asynchronous drop or proper async closures that allow to reason about the future they return to provide an actual stable interface for diesel-async. While all of that likely will not result in a fundamental change in the provided interface it remains a breaking change to make adjustments as soon as these features exist and are stabilised. That’s incompatible with the stability guarantee given by diesel itself.

As for having it next to diesel itself: Technically these crates are still separate projects maintained by different set of peoples. Diesel itself is maintained by the diesel core team, where I happen to be a member of that team. That team has a limited amount of capacity. Diesel-async is maintained by myself in whatever time is left after the time I spend on diesel. Sure it would be possible to have it in the diesel organisation as well, but I honestly do not see the relevant capacity there yet. You are welcome to change that. See the linked blog post for details on how you can contribute to that.

I keep looking at the original project and the last discussion is basically them saying it's not feasible. So I guess I just never bothered looking for other crates.

That repo has relatively few contributors, is still <1.0, and if it was easy enough to ship an extension, why wasn't it included in the main repo? Surely it would be nicer to enable an "async" feature instead of have a separate crate, no? Or at least have it sit next to the sync crate?

I think that explains why people either don't know about it or dismissed it.

diesel-async exists for several years now. It’s stable enough to be used by crates.io as database library for serving essential all crates in the rust ecosystem.

At this point I‘m not sure what else to do given that the crate is literally linked from the diesel home page, all relevant issues and literally every else this came up before. I‘m just not sure why people still believe that it doesn’t exist. So maybe someone would be able to explain that?

Not sure yet, a bit too far away to tell. Living in NL though, so could definitely try to join if the tickets are affordable enough for me..

If the spec contains default values why not make a constructor with all the missing fields or implement Default when all fields are covered?

For the first implementation I wanted to keep it simple, I don't exclude that in the future it will change.

Also lol:

Yep, I still need to figure out deep macro testing, for now I use the integration tests and cargo expand. This will absolutely change in the future :)

Thanks for the feedback!

That's dope!

It's sad there's still no async yet though. I keep hoping for a miracle, but that doesn't seem to be happening.

They're trying to replicate npm attacks