As I mentioned in my other comment, part of the problem is the list of implementers (which gets included as a suggestion) being too big, and maybe sometimes too complex.
This is not inevitable and unescapable, as your comment may suggest. It is, in part, caused by the lack of (mature) support for some type system features, like HKTs.
Luckily, this is not an inherent eternal limitation it Rust. Although, as I already mentioned, we are probably still years away from seeing this problem being fully in the past.
I take slight issue with your title. Such diesel errors are not your average Rust error.
Looking at the first example, you should have quickly realized that lack of kind abstractions over types (lol no HKTs) since Rust v1.0 is contributing to the verbosity. Maybe in a few years, with features like GATs maturing, expanding in scope, and being used more in the ecosystem, things will get better!
Did it all from neovim, exportPdf = "onSave" as a part of lsp setup, and zathura open in a tiling window manager. zathura auto-reloads the PDF when it changes on disk. So no web editor needed ;)
First class RTL support (which was required for the task at hand) was a very pleasant surprise.
Gotta admit though that I couldn't figure out why typst-lsp didn't work initially. Took me some time to figure out that it needs a git repo and files checked in to work. That probably should be mentioned in the README.
And there was the odd behavior here and there, like setting gradients on text elements in table fields actually setting the gradient over the whole table for some reason. Not sure if it was my fault since I was learning on the go, or an edge case not handled.
As I discovered and mentioned here a couple of months ago, there is a new hyper-util crate that may/should bring a higher-level API interface back. It also predictably brings a hard dependency back on tokio rt. So there is that.
hyper-util was also just mentioned by Sean (hyper dev) in the discussion you linked.
Should have told the auditors that stripping symbols is stupid and counterproductive instead of playing along. That segfault a user managed to hit once and only once with their self-built binary, and that useless core file that was left behind, shall hunt you in your dreams forever.
And I love how that commit was merged with the comment "A further reduced binary size! 🎉". Exhibit number #5464565465767 why caring that much about "dependency bloat" and binary sizes always was, and always will be, a result of collective mania in action.
Yes. That is in part why I mentioned that it's not a real alternative, and mentioned cargo-vendor as a possible basis for a less manual serviceable solution.
Serviceable, but not necessarily good still. Anti-crates.io extremists would still be better off using an alternative crates registry.
That's something that already exists btw. True extremists don't have to wait for the HN leak-promised Good Stuff.
// Add `as_cstr()` to `NixPath` trait first
let some_or_null_cstr = |v| v.map(NixPath::as_cstr)
.unwrap_or(Ok(std::ptr::null()));
// `Option::or_null_cstr()` for `OptionᐸTᐳ`
// where `T: NixPath` would make this even better
let source_cstr = some_or_null_cstr(＆source)?;
let target_cstr = target.as_cstr()?;
let fs_type_cstr = some_or_null_cstr(＆fs_type)?;
let data_cstr = some_or_null_cstr(＆data)?;
let res = unsafe { .. };
Edit: using alternative chars to circumvent broken Lemmy sanitization.
LOL