Rust Koans (2015)

https://users.rust-lang.org/t/rust-koans/2408

by wst_ • 7 years ago

255 50 7 years ago

users.rust-lang.org

azhenley• 7 years ago

(2015)

Anyone care to explain what this is? :)

mrec• 7 years ago

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/

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

vngzs2• 7 years ago

Vim Koans: https://sanctum.geek.nz/arabesque/vim-koans/

teraflop• 7 years ago

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

SOLAR_FIELDS• 7 years ago

They are also a great way to get yourself acquainted with a language - these specific Rust ones sound designed to teach specific lessons but when I was learning Scala I worked through their set of Koans and found it a great way to get used to types, syntax and generally the Scala way

yay_cloud2• 7 years ago

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• 7 years ago

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

thristian• 7 years ago

Also http://thecodelesscode.com/contents

mkobit• 7 years ago

I thought this was going to be similar to 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• 7 years ago

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

• https://github.com/crazymykl/rust-koans/

• https://github.com/dtolnay/rust-quiz

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

vngzs2• 7 years ago

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• 7 years ago

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.

ajross3• 7 years ago

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.

taneq2• 7 years ago

OK, so I wasn't too far off in my (not-yet-Rust-programmer) interpretation of "duck typing is good (or at least more flexible)"?

jkoudys• 7 years ago

As someone who's been deep into rust for only a month, I can't imagine there was a time where macros were any _harder_ to figure out.

That said, using macros that other people have written for me is pretty great. The procedural macros from serde -- Serialize and Deserialize -- are phenomenal. I don't think Rust would have half the value to me writing web apps if I didn't have those.

apo• 7 years ago

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.

djakjxnanjak2• 7 years ago

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• 7 years ago

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.

lmm3• 7 years ago

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

Never say never. Some perfect code, needing no more documentation than the types, does get shipped - look at some of Edward Kmett's work.

Sometimes you can't figure out the perfect solution and have to resort to the crutch of documentation. But it's not inevitable.

cl0ckt0wer• 7 years ago

http://thecodelesscode.com/contents

Koans that cover the whole of software development.

gridlockd• 7 years ago

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

hu3• 7 years ago

People do really get enamored with ephemeral tools.

Retra• 7 years ago

People have built actual cults around far less useful things.

fooker2• 7 years ago

Aren't koans supposed to be short?

geodel• 7 years ago

But Zero cost abstraction Koans can be long.

fooker2• 7 years ago

And I was enlightened.

isoskeles• 7 years ago

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• 7 years ago

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?

Sag0Sag0• 7 years ago

Why?

D_Alex• 7 years ago

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

nestorD• 7 years ago

She strive to have a code with no repetitions, just like their language. As such, if you try and go too far, it might become as understandable as their language.

dodobirdlord• 7 years ago

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.

Rust Koans (2015)

Related Stories