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'

  • BB_C@programming.dev
    link
    fedilink
    arrow-up
    11
    ·
    1 year ago
    • 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!
    • iso@lemy.lolOP
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      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 :)

  • FizzyOrange@programming.dev
    link
    fedilink
    arrow-up
    10
    ·
    1 year ago

    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?

  • hascat@programming.dev
    link
    fedilink
    English
    arrow-up
    5
    ·
    1 year ago

    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.

  • crispy_kilt@feddit.de
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    I’d rather have long errors and a great type system instead of short errors and a shit type system.

    • iso@lemy.lolOP
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      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.

        • BB_C@programming.dev
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          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.