
Rust Koans (2015) - wst_
https://users.rust-lang.org/t/rust-koans/2408
======
vngzs
I remember writing Rust in university a year before this was published. How
far the language has come since then! The title should be updated to include
the date.

The first koan strikes me as a timeless lesson about the advantages of the
borrow checker. I came out of it feeling as if I had learned something, though
it was really what I knew all along: it was one of the reasons I wrote rust.

The second felt tired. Of course OOP limits us to only objects!

The third I can see as a larger story about programming. As it applies to
Rust? Perhaps it is saying that it is OK to crawl through the crack in the
wall between the guards. Or it simply embodies the culture of Rust at the time
- one of a massive group of people getting their hands dirty and getting shit
done.

The fourth truly made me smile. Yes, its lesson about macros was correct - at
least then. I doubt they have gotten much easier to use. However, they are
useful to work with to get a feel for manipulating the raw syntax of the
language. Writing some toys with them is sure to teach you a thing or two
about using the language without them.

~~~
chrismorgan
The second is about the separation of data and behaviour—Rust has structs,
which are purely data, and implementations, inherent and of traits, which
provide the behaviour. This is more flexible than classes which unite the two
and tend to require that everything be in one place, and a Good Thing.

~~~
ajross
> This is more flexible than classes

Meh. Seems pretty 1:1 to me. Skipping the complexity with runtime
polymorphism[1], there's no meaningful semantic difference between a Java
interface or mixin-style C++ superclass or [insert abstraction from your
favorite language here].

Frankly this is one of the bits of Rust that infuriates me, because while it's
not a big deal nor hard to understand, it's _senselessly different_ from the
way the rest of the world does things. It's another obstacle to new
programmers, in a language that is filled with booby traps for the newbie.

[1] Let me state upfront the degree to which I am completely uninterested in
debating the merits of multiple virtual inheritance vs. trait objects. They
both suck. I guess if I had to pick C++ sucks a tiny bit less because you can
implement something like a trait object in straightforward code, where Rust
can't do vtables without boilerplating every method.

~~~
FridgeSeal
> it's senselessly different from the way the rest of the world does things.
> Because every way of doing "x" has already been tried and the way we do
> things _right_ _now_ is hands down the absolute best way right? Less
> snarkily, I think experimentation is good - we come up with new approaches
> and ways of doing things (which could solve any number of previously
> difficult problems) and helps prevent "monocultural" approaches to things.

> It's another obstacle to new programmers... Why is it an obstacle rather
> than just something they learn? You could just as easily argue that the OO
> approach of wrapping up structure and functionality in a single object is
> equally "just another obstacle for new programmers".

> in a language that is filled with booby traps for the newbie.

That's a bit of an unfair statement, Rust has a learning curve, but it is
certainly not filled with booby traps: it goes to great pains to make things
transparent and be upfront about things. C++, JS or PHP are languages that I'd
call filled with booby traps for beginners...

~~~
ajross
> Because every way of doing "x" has already been tried and the way we do
> things _right_ _now_ is hands down the absolute best way right?

Absent evidence to the contrary, yeah. Generations of hackers have been
expressing designs perfectly well with traditional class syntaxes. This is a
long solved problem, and a skill you can rely on when moving between C++ or
Java or C# or python or Ruby or JS (though Javascript tried to get fancy in
this space too and had to bolt on traditional syntax later). But to get stuff
working in rust you have to learn a different metaphor. That's bad a priori
unless there's a clear advantage. And be real: there isn't, it's just syntax
churn.

To wit, if it ain't broke don't fix it.

~~~
lmm
> Absent evidence to the contrary, yeah. Generations of hackers have been
> expressing designs perfectly well with traditional class syntaxes.

On the contrary, what Rust does is a direct counter to the most notorious
pitfalls of "extends" inheritance. Generations of OO experts and advocates
have gone on at great length about "has a" versus "is a" relationships, about
the importance of favouring composition over inheritance, about "SOLID". But
these things are only communicated by oral tradition, so they remain as booby
traps for every newcomer learning to design a system. It's past time that
languages did more to help those newcomers (and to be fair Rust isn't the
first here: Go, Kotlin, and even Java (with its separate keyword for
interfaces) all made significant progress in this direction).

------
apo
_Perfection_ is an interesting one. It states:

> “A perfect interface is one which is impossible to use incorrectly, even by
> accident.”

It illustrates the point by showing how a non-expert can build a complex model
from well-designed parts without even knowing what the end result should look
like.

But then later:

> "... Even an ugly, rickety shed would be more useful than a hypothetical,
> flawless pagoda."

Documentation represents the compromise between a perfect interface and
shipping pressure. The gap can be minimized but never eliminated.

~~~
djakjxnanjak
I’ve worked on projects designed by architects. They had big, beautiful
interfaces defined by types. When I implemented the interfaces, working
systems magically appeared. But it was my job to implement the interfaces.
They didn’t get organic adoption from other engineers. Nobody was voluntarily
choosing to implement their system via the big beautiful interface. These
projects ultimately failed.

Projects I’ve worked on that succeeded had small, comprehensible interfaces.
Engineers can quickly understand how to use them and see what the benefits
are. The pitch is “our service does this one thing you need,” not “build your
entire project by implementing the interface of our type-safe general data
processing system.”

~~~
jimmaswell
That almost sounds like the problem where you need to make people think they
came up with an idea themself to get them on board with it.

~~~
ajxs
It most definitely sounds like a problem with these other engineers. Maybe I'm
a bit out of touch here, but my view is that if engineers are not implementing
services as per the architect's specifications, then they are not doing their
job. If you hire an architect to design your house, and end up with a run-down
shack because the design was complex and the builders didn't feel like working
to the plan you'd be within your rights to seek legal recourse against them.

~~~
IshKebab
Depends - sometimes architects specify things that turn out to be impossible
or impractical to build.

------
fooker
Aren't koans supposed to be short?

~~~
geodel
But Zero cost abstraction Koans can be long.

~~~
fooker
And I was enlightened.

------
yay_cloud2
By the end of the first paragraph, I felt as though I was reading through
Anathem again. I have never read any other writing that gave me flashbacks
like that to Neal Stephenson's style.

~~~
markatto
I assume it's more based on this: [http://www.catb.org/~esr/writings/unix-
koans/](http://www.catb.org/~esr/writings/unix-koans/)

~~~
thristian
Also
[http://thecodelesscode.com/contents](http://thecodelesscode.com/contents)

------
cl0ckt0wer
[http://thecodelesscode.com/contents](http://thecodelesscode.com/contents)

Koans that cover the whole of software development.

------
isoskeles
Shoehorning ideas from eastern philosophy into coding... this needs to die.
Just talk about best practices or something, stop pretending you're a monk
when you're not.

~~~
nudq
> stop pretending you're a monk

In a question _entirely_ unrelated to Rust, how long does a cult have to exist
until it has permission to have monks?

------
mkobit
I thought this was going to be similar to
[https://play.kotlinlang.org/koans/overview](https://play.kotlinlang.org/koans/overview)
. I used that as a quick way when doing other things to slowly learn parts of
the language before diving in, was hoping this would be similar.

~~~
faitswulff
You're likely looking for something like one (or all) of these:

• [https://github.com/crazymykl/rust-
koans/](https://github.com/crazymykl/rust-koans/)

• [https://github.com/dtolnay/rust-quiz](https://github.com/dtolnay/rust-quiz)

• [https://github.com/rust-lang/rustlings](https://github.com/rust-
lang/rustlings) (by one of the authors of The Rust Programming Language, Carol
Nichols)

------
D_Alex
I, of course, understand the "Puom" koan, but I am not sure how to explain it
to my friend... can anyone help?

~~~
dodobirdlord
I think that there are a couple of pieces.

Repetition is better than using a bad abstraction. While it has its issues,
repetitive code is still idiomatic and readable code that can be understood
with a working knowledge of the language. Introducing abstractions requires
that the reader now understand the complexities of the abstraction.
Introducing a sufficient number of bad or leaky abstractions can render code
impossible to understand.

Good abstractions are difficult to create, especially when you must abstract
over functionalities that are subtly different but not in a consistent manner.

Macros (like any code generation tool) are powerful but difficult to use. They
are also arcane, in that they allow you to roam well beyond idiomatic style
and to employ syntax of your own invention.

It follows then that in most scenarios where you imagine you could "clean up"
your code with macros you in fact can't, or you might spend an unreasonable
amount of effort trying with limited success. Even if you do succeed, you
might render your code incomprehensible to anyone other than yourself in the
course of your macro-fication.

------
azhenley
(2015)

Anyone care to explain what this is? :)

~~~
mrec
It's riffing on the old Unix Koans [1], which in turn were riffing on the
traditional Zen Koan format [2].

[1] [http://www.catb.org/~esr/writings/unix-
koans/](http://www.catb.org/~esr/writings/unix-koans/)

[2]
[https://en.wikipedia.org/wiki/K%C5%8Dan](https://en.wikipedia.org/wiki/K%C5%8Dan)

~~~
teraflop
The Unix koans themselves were inspired by the AI koans, from the MIT AI Lab:
[http://www.catb.org/~esr//jargon/html/koans.html](http://www.catb.org/~esr//jargon/html/koans.html)

------
gridlockd
I find the portrayal of Rust adherents as members of a religious cult to be
unflatteringly appropriate.

~~~
hu3
People do really get enamored with ephemeral tools.

~~~
Retra
People have built actual cults around far less useful things.

