
Show HN: Algorithm Cookbook in Rust - EbTech
https://github.com/EbTech/rust-algorithms
======
rectang
MIT license is good, but I always wish that sample code was available under
CC0 -- and presented with explicit permission to copy and paste without
preservation of notices. (A request to link back optionally when practical is
fine.)

That makes it easier for sample code to achieve the ends of maximum code reuse
and popularization of the underlying technology.

~~~
jay-anderson
Agreed. I once tried to submit a small snippet I found on stackoverflow to an
open source project. Stackoverflow user content is licensed under creative
commons, cc-by-sa (see [https://stackoverflow.blog/2009/06/25/attribution-
required/](https://stackoverflow.blog/2009/06/25/attribution-required/)). I
included attribution, but it was rejected. I totally understand why. CC0 is
much preferred in this case.

~~~
guelo
FYI, newer Stack Overflow code is licensed under an MIT license with a link in
code comments serving as attribution. See
[https://meta.stackexchange.com/questions/272956/a-new-
code-l...](https://meta.stackexchange.com/questions/272956/a-new-code-license-
the-mit-this-time-with-attribution-required?cb=1)

~~~
jay-anderson
Looking at that link I don't think it was implemented. The footers on stack
overflow pages still indicate cc-by-sa.

------
rustacean
Thank you. But it seems not finished? I am trying to implement some basic data
structures and algorithms in Rust, but the compiler nearly kills me. Is there
any data structure & algorithms implementation tutorials for Rust newbies,
like Learning_ Rust_With_Entirely_Too_Many_Linked_Lists[1]?

[1]:[http://cglab.ca/~abeinges/blah/too-many-
lists/book/README.ht...](http://cglab.ca/~abeinges/blah/too-many-
lists/book/README.html)

~~~
kazagistar
Data structures and algorithms are possibly the hardest part of Rust to dive
into unless you have a really good reason. The best advice for newbies is to
learn with other stuff and use existing algorithms. Of course, if you are
trying to implement stuff for a class or something similar then you might be
out of luck, and might consider trying the Rust IRC and such to work through
the errors as they come up.

~~~
freeordead
So what is the point of a language in which things are hard to implement?

~~~
tomjakubowski
It's not any harder to correctly implement a data structure, even an
"advanced" one, in Rust-with-unsafe than it is in C++-with-exceptions. I don't
know where this meme comes from.

~~~
wuch
I don't think this claim is completely unfounded from perspective of people
coming to Rust from other languages. Consider for example:

* Poor ergonomics of raw pointers. Lack of arrow syntax, verbose pointer arithmetic (at least now there is an experimental offset_to).

* Once you have pointers in data structures, properly specifying lifetimes is now your job. Compiler is no longer your friend, but an whisperer of evil (Compiler: Of course it safe. It has 'static lifetime, it must be safe. How do I know, you ask? I saw you dereferencing a pointer).

* Cyclic data structures (without additional layer of indirection) require unsafe, or reference counting and dynamic borrow checking.

* Need to account for zero-sized types when doing pointer arithmetic.

* Need to uphold Rust invariants in unsafe regions of code - forming non-unique mutable references to the same memory is hardly unusual when working with cyclic data structures, or in general (consider for example a swap without checking if memory locations are identical).

It seems to me that Rust moves part of required work from users of data
structure to the designer / developer of data structure. You need to invest
more work upfront, but once done users don't need to be on constant lookout
for accidental API misuse that results in undefined behaviour.

~~~
baq
Agreed but don't you have to do all this in C/C++ too if you want your data
structure to be really safe? Except perhaps zero sized types.

~~~
wuch
No, those are Rust specific things. For example, aliasing mutable references
in C++ is potentially dangerous, but not undefined behaviour per se.

Regarding making a "really safe" data structure, this is quite tricky
question. Safety means quite different things in those communities. Moreover
those different concepts of safety are not readily transferable between
languages, at least not in useful sense.

In Rust you would say that data structure is safe if it doesn't cause
undefined behaviour when used without any unsafe user-code. Essentially once
you write a safe data structure the safety is enforced by a compiler, even in
a presence of malicious user-code (as long as it avoids unsafe blocks of
code). In C++ on the other hand, a user would have only themselves to blame if
they broke a precondition expressed somewhere in a documentation and caused
undefined-behaviour.

This is exactly why I would postulate that writing correct data structure in
Rust, as opposed to say C++, may require more effort. For similar reasons
using dependent types doesn't make programming any easier. Of course, this may
turn out to be a worthy investment in the long run.

------
cyber1
"My other goal is to show developers that C++ and Java kinda suck" \--
really?!

~~~
sidlls
Yeah, it's a pretty poor way to represent Rust to an audience that is
ostensibly it's target audience.

~~~
Buttons840
Any developer who can't name something that "kinda sucks" about their language
probably isn't ready to learn a new language.

~~~
sidlls
The quoted comment isn't about particular shortcomings in a language, it's a
blanket pejorative, and it doesn't reflect well on the author's credibility.

------
zeotroph
A graph with the members first, next, and endpoints is not exactly self
explanatory, something better than a "A compact graph representation" comment
would be nice.

Especially since the ownership model of rust makes the classic graph
representation of edges owning nodes impossible.

~~~
fpoling
It is only impossible​ using safe Rust. Unsafe code blocks should allow to
represent this behind safe API.

------
gerty
To add to the list, here's my rust-noob implementation of the Kalman filter.

[https://github.com/rbagd/rust-linearkalman](https://github.com/rbagd/rust-
linearkalman)

~~~
daniel_rh
GPL3 means it's not very reusable in any projects that aren't GPL3. Have you
considered a BSD or MIT license? or CC0 if you want to get code reuse? Or at
the very least LGPL2

~~~
cyphar
Maybe that's what they want. Personally I use GPLv3 for any project I can,
because my priority is user freedom and not code reuse.

~~~
legulere
Which of the four freedoms (ignoring that only freedom #0 and #2 apply to
users) is violated by using more liberal licenses like MIT or CC0? Freedom #0
is clearly violated by GPL projects: GCC for years tried to be prevent to be
run as a library or in combination with other programs. Running ZFS or the
better proprietary graphics drivers on Linux is a bit questionable legally.
GPL being incompatible with app store rules kind of breaks freedom #2 and #3.

~~~
cyphar
> Which of the four freedoms [...] is violated by using more liberal licenses
> [...]?

None of them [which, as you probably know, goes without saying because they're
both free software licenses]. The problem is that a project using a
lax/pushover license is that the project can be used as a tool for violating
user freedom. For examples of this, see the PlayStation and other such
products which were developed thanks to the existence of free software under
lax/pushover licenses.

As an aside, the thing that personally made me care about the prolonged
effects of copyleft is that I realised that if I wanted to contribute to a
world without proprietary software, every non-copylefted program that I wrote
was potentially acting against my intentions. You might not see it that way
(and I didn't see it that way for a long time), but that's why I made my
decision.

> Freedom #0 is clearly violated by GPL projects: GCC for years tried to be
> prevent to be run as a library or in combination with other programs.

That is simply not true, and is a non-sequitur to boot. It _is_ true that the
GNU project decided to make it hard to create proprietary modules [or
otherwise external modules] for GCC, but nothing stopped a user [in principle]
from doing either of those things. The GPL doesn't require a project to make
themselves usable as a library.

> GPL being incompatible with app store rules kind of breaks freedom #2 and
> #3.

But "app stores" are acting against user freedoms, which is why you can't
distribute GPLv3 software [without additional permissions] in most "app
stores".

In fact, I would argue the GPL is doing its job well here. It's preventing the
re-distribution of free software in a way that harms user freedoms. That's
sort of the whole point. Just because you don't care about how "app stores"
treat users doesn't justify claiming that copyleft is acting against users
here...

------
bogomipz
This is great. I am curious if anyone else knows of a similar cookbook for
Golang.

~~~
peferron
I have implemented quite a few algorithms and data structures for fun here
[1]. It's not authoritarive by any means, and not everything is in Go (there's
also some Rust, Swift, TS and JS), but maybe a few things could turn up
useful.

[1] [https://github.com/peferron/algo](https://github.com/peferron/algo)

~~~
bogomipz
Awesome. Thanks for the links.

------
sjroot
Thanks for sharing this. I did a deep dive into Rust when I was tasked with
implementing an interpreter[0] for school, and found the language to be very
enjoyable to work in. While I have tried to convince other friends to try it,
they still object citing a steep learning curve and the thought that it will
never replace C++ or Java in mainstream development ecosystems. It is
resources like these that will help lower that barrier to productivity. :)

[0] [https://github.com/sejr/core-interpreter](https://github.com/sejr/core-
interpreter)

------
simplehuman
Just a heads up: please put github tags

------
amelius
Offtopic/meta. I'm wondering about a technology that allows us to NOT re-
implement an algorithm cookbook every time a new language shows up.

~~~
Groxx
yea, I'm convinced it's possible to at least save a ton of work there.
Probably not for optimized libs, but something is much better than nothing.

Rust though might be an example where such a thing wouldn't work (had it
already existed), since the type system is legitimately different. But some
things might work, and even a test suite you could develop against would be
wonderful.

~~~
lmm
An ABI that could express sum types would be a huge step forwards for the
computing world.

.net and the JVM sort of achieve this, but at the cost of going managed for
everything. That's mostly fine (and possibly entirely fine, to be honest; very
few people who think they need non-GC actually do), but there are still a few
diehards who insist on non-GC, and Rust is pretty much the first good language
to have that option in a comprehensive way.

