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.

If I wanted to tweak the Rust project, I’d feel pretty confident I was calling the right things with the right params.

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.

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`.

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.

Most of the code in that module is dedicated to the gui maintenance. The parts that do deal with time are perfectly legible.

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.

I beg to differ.

The easiest way to see this is in US locales, which use 12-hour clocks in GNU 'date' but not other implementations:

  $ date -d '13:00'
  Sat Nov  1 01:00:00 PM PDT 2025
  $ uu_date -d '13:00'
  Sat Nov  1 13:00:00 2025

[1] https://github.com/coreutils/coreutils/commit/1066d442c2c023...