> Let’s look at a Rust program that does something non-trivial: ... (a bunch of highly specific explanations of deeply technical details from the very short program source code)
what does this program actually do?
all of this extraordinarily subtle analysis, about rust language specific properties, specific to this individual program, and no actual summary or description of what the program is supposed to do!
what it does is print out a line whenever a file, matching certain criteria, is modified. that's it.
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.
for people who are just hungry for complexity this is an exciting challenge that they can tackle and solve! but that complexity, that challenge, is self-inflicted, almost always incidental and unnecessary work
> 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
But the implementation is simple, especially for such a high-performance language. It fits on less than a single printed page. What more could you expect?
simple isn't measured in terms of SLoC, it's measured in terms of cognitive complexity
the article itself says, clearly, that the (short) rust program requires knowledge of a significant number of non-trivial language features, as well as the behavioral outcomes of all of their combinatorial interactions -- approximately none of which are relevant to the problem that is being solved by that program!
what I expect is that a language adds as little cognitive complexity (overhead) as absolutely possible, when it is used to express a solution to a given problem
what does this program actually do?
all of this extraordinarily subtle analysis, about rust language specific properties, specific to this individual program, and no actual summary or description of what the program is supposed to do!
what it does is print out a line whenever a file, matching certain criteria, is modified. that's it.
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.
for people who are just hungry for complexity this is an exciting challenge that they can tackle and solve! but that complexity, that challenge, is self-inflicted, almost always incidental and unnecessary work