> and as such it's an almost pitch-perfect example of exactly what's difficult with rust as a language. what this program does is trivial to describe and should have a commensurately simple implementation. but rust makes the programmer care about a dozen? dozens? of details that have no relevance to the problem domain at hand.
As the other comments have said, in other languages you face the same problems, those languages just won't help you handle them. Not all filenames are printable, but most languages don't help you deal with this. Almost all languages have some way that functions can fail and not return the kind of value you wanted - in Rust this is done by having a return type that shows it might return a different kind of value, in other languages this is done by having a novel concept of "exceptions" and you have to worry about whether every function is "exception safe", which is not actually simpler even if it looks like it at first glance. Etc.
> Not all filenames are printable, but most languages don't help you deal with this
literally every filename is printable, the question is only how to render the filename in a "printable" form, which is a function of the filename and the destination output
this isn't an interesting problem, every language and/or its stdlib should have reasonable defaults for this kind of thing. these kinds of details are exactly the kinds of things that a program like the one in the OP shouldn't need to care about, unless they explicitly opt-in to that complexity
> in other languages you face the same problems, those languages just won't help you handle them.
good languages let you handle these sorts of problems, but they don't force you to handle them. whereas rust lifts all of these problems up to the programmer directly and unavoidably and says "hey you need to deal with this"
managing low-level details like ownership or memory management or whatever isn't somehow inherently virtuous or valuable
Nope. Filenames on Unix can be arbitrary byte sequences, and even on Windows they can be characters that don't exist in the current locale.
> this isn't an interesting problem, every language and/or its stdlib should have reasonable defaults for this kind of thing.
It's not an interesting problem until you hit it. OSes should set better standards, but given that they can't or won't, every application needs to handle that case.
> In which case(s) it is the responsibility of the thing that wants to print them to make them printable, right?
Which makes surfacing that responsibility to your application code, as Rust does, better than e.g. silently turning them into empty strings, as some other languages do, no?
i mean in the most abstract sense then yes? but this isn't how rust works in practice. if i try to print(filename) and the program won't compile because filename is `esoteric_string_type&' a` and print expects `abstract trait type SpecificPrintable` or whatever then no this is not a preferable outcome vs. allowing the program to compile and print something that works -- at least in the general case
i mean you can create a file with name `0x01 0x04 0xff 0x0a` but it's not like e.g. `ls` handles this stupidity
As the other comments have said, in other languages you face the same problems, those languages just won't help you handle them. Not all filenames are printable, but most languages don't help you deal with this. Almost all languages have some way that functions can fail and not return the kind of value you wanted - in Rust this is done by having a return type that shows it might return a different kind of value, in other languages this is done by having a novel concept of "exceptions" and you have to worry about whether every function is "exception safe", which is not actually simpler even if it looks like it at first glance. Etc.