It used to be that every few weeks I would see someone complaining about "wall of text" output from rust, but since we started trimming type names I haven't really seen any. The timing also roughly coincides with Twitter's demise and me not jumping on BlueSky, so it could be that I just lack the visibility I used to have. If you see any, feel free to ping me as I would like to keep knowing about these.
[#]RustLang #Rust
=> More informations about this toot | More toots from ekuber@hachyderm.io
But if it is not just a lack of visibility, then what people were put off by is not error verbosity (a lot of text) but rather useless verbosity (50 lines of text to name a type, sometimes in multiple places). It confirms my biases that we need to keep the information density high, not the textual output short.
=> More informations about this toot | More toots from ekuber@hachyderm.io
@ekuber a though nut yeah.
I feel that I often still feel a bit inundated by having notes and explanations on how to fix stuff on every single warning/error.
In this case the information is locally important, but globally not what I was looking for :D
But I’d rather it be this way, than not enough info when starting out
=> More informations about this toot | More toots from Hemera@meow.social
@ekuber My use case is unusual: windows CLI, no IDE, use a screen reader. But I will admit the large amounts of text on rust build output can make it hard to find specific errors and some just scroll off completely. I also wish I could suppress warnings while I'm trying to fix an error that is getting scrolled out by warnings later on the file.
=> More informations about this toot | More toots from modulux@node.isonomia.net
@modulux I would love to help with making rustc more suitable for people using screen readers or braille ttys.
Are you aware of --error-format=short? How do you cope with the current output beyond verbosity? I worry that the "span labels embedded in user code" output is only useful when you have spacial information, and just becomes muddled otherwise. One option could be to use the json output directly to build a front end optimized for yourself, but would want to avoid pushing people to do that
=> More informations about this toot | More toots from ekuber@hachyderm.io
@modulux How do ASCII-art arrows and underlines work for you? Do they cause problems?
Is terminal able to extract any hierarchy for navigation? (the errors technically are structured, with notes and additional help lines, that on Web or proper GUI would have been navigable)
=> More informations about this toot | More toots from kornel@mastodon.social
@modulux @ekuber Yeah, suppressing warnings would be nice (I bed it can be done somehow, but definitely not sure), but the Rust errors are miles ahead of any C ones. So, thank you.
=> More informations about this toot | More toots from tyrylu@gts.trycht.cz
@tyrylu @modulux consider using --cap-lints allow to silence lint's during development
=> More informations about this toot | More toots from ekuber@hachyderm.io
@ekuber The main grippe I have that sounds like "wall of text" is the ordering of errors and warnings. I often see the following:
When refactoring, there can be a lot of warnings (dead_code) and the only thing I care about is often the first error, but I often have to scroll to see it. Bacon fixes that though.
=> More informations about this toot | More toots from sgued@pouet.chapril.org
@sgued the second case shouldn't happen and should be reported as bugs
=> More informations about this toot | More toots from ekuber@hachyderm.io
@ekuber I didn't know that. I will keep in mind when encountering this in the future and open tickets. I see it sometimes when one error causes type inference to break someplace down the chain, and I don't know how the compiler would be able to "guess" that the errors are caused one by the other. My current holiday project involves a lot of macros, so a syntax error in the macro can lead to the macro outputting compile_error and the compiler can't guess that it's what's causing the errors.
=> More informations about this toot | More toots from sgued@pouet.chapril.org
@sgued @ekuber the compiler is able to insert a special “error” type into type inference so it can use that to determine when one error might be caused by another. It’s not always possible to determine one error is caused by another, but it’s almost always possible to do better.
=> More informations about this toot | More toots from porglezomp@mastodon.social
@porglezomp @sgued to give you an idea of the things we can do
https://github.com/rust-lang/rust/pull/133937
=> More informations about this toot | More toots from ekuber@hachyderm.io
@ekuber
I don't think I'll ever get over how amazing Rust's error output is.
I've long had a keen interest in how humans parse and process information, and how it relates to UI. Things like spacing, color, and other visual indicators can make a huge difference in user experience.
Rust's compiler messages take advantage of this. Specifically the use of whitespace formatting and arrows make it much easier/faster to identify the most relevant information.
Keep up the great work!
=> More informations about this toot | More toots from grendel84@tiny.tilde.website
@ekuber I have my own take on a wall of text. Every once in a while I find myself prototyping some code - lots of todo!(), lots of unused variables, lots of dead code... And one or two actual errors. It would be great if I didn't have to scroll past a few screens of output of rustc complaining about stuff that doesn't matter at this moment...
=> More informations about this toot | More toots from manpacket@functional.cafe
@ekuber I found a different way to deal with "wall of text" though I'm not talking about long type names.
Refactors are where I get hit with lots of output I don't feel like I want or need. When a field is changed from T to Option, the wall of text is N field initializations where I repeatedly get coached to wrap with Some() or whatever else.
I know what's going on. I just need to know where. I started using bacon which has a summary mode giving just the line numbers and error type.
=> More informations about this toot | More toots from onelson@mastodon.social
@ekuber this is to say, I likely would use bacon much at all if rustc had a flag to produce terse summary feedback in a similar way.
=> More informations about this toot | More toots from onelson@mastodon.social
@onelson something with more information than --error-format=short but still less than the regular output?
=> More informations about this toot | More toots from ekuber@hachyderm.io
@ekuber TIL. Maybe --error-format=short is what I have been looking for all this time
=> More informations about this toot | More toots from onelson@mastodon.social
@ekuber It is probably an age bracket thing. I never minded Rust's errors, because I was used to J2EE junk.
=> More informations about this toot | More toots from sayrer@mastodon.social
@ekuber I do not feel that Rust often gives me wall of text output, especially on types. I do rarely grumble at having to look up the full type name in an output file, but only rarely-- usually the output I do have is enough for me to investigate the error.
I spent last summer writing a combined C++/Rust project and I will never, ever, ever complain about Rust's error messages again. I might gently suggest improvements to an already exceptionally good experience. Rust's compiler does such a good job at catching the originating error and stopping the reporting there.
=> More informations about this toot | More toots from ceejbot@toot.cat This content has been proxied by September (3851b).Proxy Information
text/gemini