I also question your notion that Rust forcing you to "think explicitly
about scope and state" will improve the chances of the result being
"understandable". Bad programmers will find a way to write bad code in
any language. But forcing the good ones into a box that is rigid in
order to avoid garbage collection does not strike me as a sensible path to
readable code. (Remember, we are talking about using Rust as a "high level
language" in this thread. I don't quarrel with the basic idea of Rust as a
low-level high-performance language designed for applications where garbage
collection pauses can't be tolerated.) I think it's far better to give
skilled programmers the tools to write well-organized code, as Scheme and
Haskell do, without forcing them into a rigid model. Programming is an art
and there are many ways to do it well, just as there are many ways to play
I think we have such a deep and ontological difference in opinion that it
may not be possible for our conversation to make progress,
I think you are right, though I must say that iin a long life I don't think
I've ever had a difference with someone who referred to that difference as
so I'm not sure how far we should take this. But I absolutely do not think
it is true that bad programmers are the reason there are bad programs (in
reference to the portion of your post I have emphasized).
What is more accurate is to say that bad programs are the result of bad
That is a pretty amazing statement. Have you run software projects? Worked
with a wide variety of programmers? Run big software projects? I have, over
an almost 50 year career. As with tennis or piano playing, there is an
enormous range of skill among programmers. I do not consider C to be a
"good language", but I have seen some beautifully organized, beautifully
crafted C programs. And really bad programs written in "good" languages.
And I will make the argument that in my experience, the determining factor
in the quality of a program is the skill of the programmer. And it is at
the architectural, organizational and algorithmic level that these people
excel. Writing small programs is easy, so that's not what we are
discussing. Writing very large programs is extremely hard and few have the
ability to operate well at the forest level and organize them properly.
Compared to this, the language used is less important, but not unimportant.
Just as the tools used to build a house are important, but not as important
as the work of the architect.
but even then I am unhappy saying that some languages are "bad" rather than
saying that we are all experimenting with finding ways of expressing our
programs so that they are maintainable and extensible under changing
circumstances. Language features matter, much more than human skill in my
opinion. You say so yourself only sentences later, when describing Haskell.
You are completely mis-interpreting what I wrote. What I wrote has the same
meaning as the paragraph I wrote above.
I am also extremely surprised that you find Rust's ownership and
borrowing rules so much more restrictive or rigid than Haskell's rules
around purity and referential transparency. Its inconceivable to me,
Have you done any real implementation in Haskell? You are talking about
theory above. Einstein once said "In theory, there's no difference between
theory and practice". In practice, none of that stuff affects your work
much. Writing Haskell code is very much like writing statically typed
Scheme, complete with tail-call optimization and lazy evaluation. And there
is a large set of good libraries, both official and contributed that you
can draw upon and is a great source of its power (as is true of Python and
Tcl; Tcl is pretty awful as a programming language, but just fine given
Ousterhout's original design goals; but you can do amazing things with it
because of the amount of ready-made stuff in its environment that you can
I would also comment that there is an issue with the complexity of Rust
and the questionable quality of the documentation. I think the combination
results in a language that is inordinately difficult to learn. It may well
be, though, that the documentation isn't where it needs to be yet because
the language is simply too complex (and, from what I've read, has been a
moving target for a long time). I have learned Go in the last year and
written a few Go programs, one multi-threaded. Go and Rust are roughly the
same age, but learning and using Go was far less frustrating than was the
case with Rust, and the documentation was far superior. But Go is a less
complex language than Rust, an d perhaps its superior documentation was at
least in part due to the fact that it is easier to describe.
I don't know or use Go and have never read its docs, but I find Rust's
documentation to be better than any other I have used by a wide margin.
First of all, I have exchanged a number of emails with Steve Klabnik about
The Book and have opened an Issue, where I've contributed a number of
suggestions. It is not my intention to denigrate his work, because there
can be many causes for the aspects of the documentation that I consider
inadequate. He continues to work on it, clearly understanding that it's not
a finished product yet. Documenting this language is a big job and I'm not
at all surprised that the first version has flaws. Then we have the "Rust
Reference", which we are told is not a language spec and "tends to be out
of date" and which I have found to be not terribly helpful.
As for your statement above, I ask again, have you used Haskell (and used
the 2010 Language Report, or Paul Hudak's "Gentle Introduction" or the
library documents or the online "Learn You A Haskell ...")? Have you used
Scheme? The R5RS report is a model for language descriptions. C has been
graced by two books, K&R and Harbison and Steele that are both
fantastically good (and better than the language itself, in my opinion).
Python is very well documented, as is Tcl (Ousterhout's first book is a
I completely disagree. Rust is asking you to deal with memory management
manually, just as C does. Languages that provide garbage collection do not.
That is one less major task a programmer must deal with, freeing up mental
bandwidth for more important things, such as good algorithms and good
I missed this paragraph because of markup issues. This simply isn't true.
While its accurate to say that in Rust you can determine when memory is
allocated and deallocated, unlike most garbage collected languages, it is
not at all like C in that it is an isomorphic question to thinking about
when bindings are created and when they go out of scope.
It is like C in the sense of the programmer being part of the memory
management system, unlike languages with GC support. What the programmer
has to do is quite different in the two languages and Rust provides the
significant advantage of insuring that what the programmer does is correct.
I thought I made that clear in an earlier post, but apparently not.