Migrate from typed-builder to bon

[Veetaha]

No description provided.

[EdJoPaTo]

Side note: I also added your PR as a remote, and it's a bit annoying when its branch name is the same as in the base repo.

For me its also annoying when I want to create a second PR while another one is already open, so I always name them to prevent name conflicts.

And… @ayrat555 and @Veetaha: why still master, not main? 😇

[EdJoPaTo]

Unrelated to this PR: maybe use url::Url here?

[Veetaha]

Let's keep this change for a separate PR

[EdJoPaTo]

That was my intention. This is only a comment to spark the idea, mainly for @ayrat555

[Veetaha]

why still master, not main? 😇

Protecting the long-lived git tradition 💪

[Veetaha]

Success! Indeed the trait abstractions in bon were causing the difficulty for the compiler. I managed to bring the type checking perf. of the code generated by bon to the level of typed-builder 🎉. This is currently in a quickly-edited version of bon with lots of junk that I'll refactor tomorrow and make a patch release of bon, but it works:

Here are the new compilation timings with bon:

Same measurements but with typed-builder:

There is now a 0.7s difference between the from-scratch-compilation perf of bon and typed-builder, which is much more acceptable (given that bon depends on darling additionally and compilation of bon-macros takes ~1 second, while typed-builder-macro takes 0.5 seconds to compile).

[EdJoPaTo]

I think we should wait a bit for bon to settle. Changes will quickly create a bunch of changes in frankenstein due to its quite heavy builder usage.

I really like its benefits over typed-builder, but I would like to prevent multiple refactorings while bon is still maturing.

Also, there might be ways to improve the usage of bon even further by condensing all into conditions like on String into a single place which would reduce the human mistake rate of it?

[Veetaha]

Hey @ayrat555, @EdJoPaTo I've updated bon to the version 2.2.0 and the diff became much more negative (there is no outstanding #[builder] on structs now, the previous derive(Builder) now works).

I propose to merge this PR. See my comment #196 (comment) about the improvements suggested by @EdJoPaTo I propose to do that in a separate PR to keep the diff low and avoid future merge conflicts.

[EdJoPaTo]

Jut a nitpick, otherwise I think it's a good to merge!

This is definitely a breaking change with the changes of into but I think its worth it.