Especially the errors related to traits are very difficult to me. Is there a trick? Will I get used to it? Or am I just a failure? :D
Like WTH is this?
the trait bound '(diesel::sql_types::Uuid, diesel::sql_types::Text, diesel::sql_types::Nullable, diesel::sql_types::Timestamp, diesel::sql_types::Timestamp): diesel::query_dsl::CompatibleType' is not satisfied the following other types implement trait 'diesel::query_dsl::CompatibleType': (ST0,) (ST0, ST1) (ST0, ST1, ST2) (ST0, ST1, ST2, ST3) (ST0, ST1, ST2, ST3, ST4) (ST0, ST1, ST2, ST3, ST4, ST5) (ST0, ST1, ST2, ST3, ST4, ST5, ST6) (ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7) and 24 others required for 'SelectStatement, DefaultSelectClause>, NoDistinctClause, ..., ..., ...>' to implement 'diesel_async::methods::LoadQuery<'_, _, models::Artist>
Or this:
the variant or associated item 'as_select' exists for enum 'Option<Image>', but its trait bounds were not satisfied the following trait bounds were not satisfied: 'std::option::Option<models::Image>: diesel::Selectable<_>' which is required by 'std::option::Option<models::Image>: diesel::SelectableHelper<_>' '&std::option::Option<models::Image>: diesel::Selectable<_>' which is required by '&std::option::Option<models::Image>: diesel::SelectableHelper<_>' '&mut std::option::Option<models::Image>: diesel::Selectable<_>' which is required by '&mut std::option::Option<models::Image>: diesel::SelectableHelper<_>'
or this:
the trait bound 'schema::image::columns::id: diesel::SelectableExpression<schema::artist::table>' is not satisfied the following other types implement trait 'diesel::SelectableExpression<QS>': <schema::image::columns::id as diesel::SelectableExpression<diesel::query_source::joins::Join<Left, Right, diesel::query_source::joins::Inner>>> <schema::image::columns::id as diesel::SelectableExpression<diesel::query_source::joins::Join<Left, Right, diesel::query_source::joins::LeftOuter>>> <schema::image::columns::id as diesel::SelectableExpression<schema::image::table>> <schema::image::columns::id as diesel::SelectableExpression<diesel::query_builder::SelectStatement<diesel::query_builder::FromClause<From>>>> <schema::image::columns::id as diesel::SelectableExpression<diesel::query_source::joins::JoinOn<Join, On>>> <schema::image::columns::id as diesel::SelectableExpression<diesel::query_builder::Only<schema::image::table>>> required for '(id, url, width, height, color, updated_at, created_at)' to implement 'diesel::SelectableExpression<schema::artist::table>' the full type name has been written to './target/debug/deps/server-25bcf4cf7c62d3bf.long-type-2030200755981097212.txt' 3 redundant requirements hidden required for '(diesel::expression::select_by::SelectBy<models::Artist, _>, diesel::expression::select_by::SelectBy<std::option::Option<models::Image>, _>)' to implement 'diesel::SelectableExpression<schema::artist::table>' required for 'SelectStatement<FromClause<table>, DefaultSelectClause<FromClause<table>>, NoDistinctClause, WhereClause<...>>' to implement 'diesel::query_dsl::methods::SelectDsl<(diesel::expression::select_by::SelectBy<models::Artist, _>, diesel::expression::select_by::SelectBy<std::option::Option<models::Image>, _>)>' the full type name has been written to './target/debug/deps/server-25bcf4cf7c62d3bf.long-type-3023492822805157679.txt'
- 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!
I usually get errors close in size to this but at the moment I had a diesel to send. I kind of figuring out the problems but it takes time and a few hairs :)
These long confusing errors are near universal in languages / libraries that have complex types. You get the same thing in C++ code that uses template metaprogramming e.g. Eigen.
It is quite annoying but I don’t really know of a solution other than using a library that doesn’t express full expressions as types.
Chumsky does something similar but it also has a
.boxed()modifier you can use to type erase the types at strategic points to keep them a manageable size. I believe Xylem is going to do the same with its statically typed widget tree. Maybe Diesel offers something like that?C++ has had the same style of obtuse errors for decades. They can be a real pain to figure out even if you are used to seeing them.
Diesel is well-known for having some of the worst errors in the ecosystem. This is far from the rule.
Indeed, and the maintainer opened this RFC (I think because of it)
I’d rather have long errors and a great type system instead of short errors and a shit type system.
@iso understood you. Well, its less verbose than cpp and more legible, but, in this case yes, its a lot of lines, but all of them are about the same issue missing trait implementations. Then I think its way easier than c++.
I’m pretty sure there is a better way to read the error logs, I’ve experienced this in many languages but Rust is the hardest. I’ll research this one.
@iso all the errors are the same. Missing trait implementations. Already see c++ template issue with dozens of lines. There are some tools that helps like the below. But if you had 100 missing traits implementations, you will got a 100 error lines report.
https://github.com/zkat/mietteAs 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.
Interesting tool, I’ll try it, thanks
