> Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety.
I don't know about that. Look at the code for the COSMIC desktop environment's clock widget (the cosmic-applet-time directory under <https://github.com/pop-os/cosmic-applets>), for example. It's pretty much unreadable compared to a C code base of similar complexity (GNU coreutils, for example: <https://savannah.gnu.org/projects/coreutils/>).
I think this is a you problem
as in that "isn't the style of code you are used too"
I don't think "how well people not familiar with you language can read it" is a relevant metric for most languages.
Also IMHO while C feels readable it isn't when it matters. Because it very often just doesn't include information you need when reading. Like looking at function header doesn't tell you if a ptr is nullable, or if a mut ptr is a changeable input value or instead is a out ptr. which is supposed to point to unitialized memory and if there is an error how that affects the state of the validity of any mutable ptrs passed in. To just name some example (lets not even get started about pre processor macros pretending to be C functions). In conclusion while C seems nice to read it is IMHO often a painful experience to "properly" read it e.g. in context of a code review.
As a side note: The seemingly verbose syntax of e.g. `chrono::DateTime` comes from there being 2 DateTime-types in use in the module, one from the internationalization library (icu) and one from a generic time library (chronos). Same for Sender, etc. That isn't a supper common issue, but happens sometimes.
I think the Rust example’s biggest readability sin is using the full names of things like foo::bar::Baz instead of just Baz, but I get why they did that. When you import a lot of things into a file the latter way, it’s easy to get lost in “was that a foo Baz or a wiz Baz?” Sometimes it’s easier just to use the long names everywhere to be explicit.
If I wanted to tweak the Rust project, I’d feel pretty confident I was calling the right things with the right params.
That's a style choice that I think comes from former C++ devs.
Java can potentially have the same problem. But because everyone uses an IDE and because it's rarely really an issue, everyone will simply import `Baz` rather than worry about the Foo::Baz and Bat::Baz collision. It does happen in java code, but I can't stress how infrequently it's actually a problem.
I don’t think that’s quite right. I haven’t written C++ since the 90s, and I use IDEs (Emacs and Zed), but I still sometimes reach a mental threshold where I look at my screen and see way too many names to have to hold in my mental buffer, then decide to make them more explicit.
IDK what the state of Emac/Zed is in terms of type information (I'm sure it depends on the language in question). For Jetbrains/Eclipse/Netbeans if there's a question about a type you can ctrl+click on the type and immediately pull all information about it.
In java, I rarely pay attention to the `import` section (and I know most devs at my company).
You can look up `using namespace std;` in google and you'll find a lot of articles saying it's a bad practice in C++. Everyone recommends writing the full `std::cout` rather than `cout`.
All modern editors do that pretty well with language servers now. Specifically, Emacs and Zed do this perfectly with Rust.
I do think it’s down to personal preference. With the fully qualified names, I can look at the screen and follow the flow without having to mouse over the various names in play. For that matter, I could print it out if I wanted to and still have all the information.
I don’t think you’re objectively wrong. It’s more that we have different approaches to managing the complexity when it gets hairy.
I just import them with unique names if there is a collision - Wiz_Baz and Foo_Baz
That's an apples to oranges comparison.
Most of the code in that module is dedicated to the gui maintenance. The parts that do deal with time are perfectly legible.
> pretty much unreadable
I disagree. Both seem perfectly readable, assuming you know their preferred coding styles. As a non-C programmer, I absolutely despise running into #ifndef SOME_OBSCURE_NAME and `while (n) { if (g) {` but C (and in the latter case Go) programmers seem to love that style.
Comparing a bunch of small, barely integrated command line programs to a UI + calendar widget doesn't seem "of similar complexity" to me. Looking at a C clock widget (https://gitlab.freedesktop.org/xorg/app/xclock/-/blob/master...) the difference seems pretty minimal to me. Of course, the XClock code doesn't deal with calendars, so you have to imagine the extra UI code for that too.
https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/sr...
I beg to differ.
A lot of the complexity is to handle localized date formats on systems that support them. Most other implementations of 'date' do not do this.
The easiest way to see this is in US locales, which use 12-hour clocks in GNU 'date' but not other implementations:
I added a test case for that recently, since it is a nice usability feature [1].[1] https://github.com/coreutils/coreutils/commit/1066d442c2c023...
To be fair GUI code is going to be harder to read than a non-interactive utility, in any two languages