Miscellaneous cookbook ideas

[brson]

The Perl cookbook or Python cookbook could be a good source of inspiration.

• Declare lazily evaluated constant (lazy_static)
• Maintain global mutable state (lazy_static)
• Unzip a tarball to a temporary directory (temdir + tar + flate2)
• Dispatch work to a thread pool (threadpool)
• Fork a short-lived thread that cheaply references data from the original thread (crossbeam)
• Access a file randomly using a memory map (memmap)
• TODO evaluate this issue and generate more recipes

[brson]

If you decide to implement one of the ideas in the op please say so here to claim it, so others don't duplicate the effort.

[alisha17]

I am going ahead with "Mutate elements of an array in parallel".

[karan1276]

I would like to work on "Dispatch work to a thread pool". I think problem statement "Sort an array of M numbers using N threads" will be optimal for demonstration. In case you had some other problem statement in mind let me know.

[brson]

Awesome. Thanks @alisha17 and @karan1276!

@karan1276 Your problem statement sounds good. I'm interested in seeing your solution.

[budziq]

First of all sorry if I am spamming the thread.

Looking from the perspective of busy programmer with little to no experience in rust (like myself) I would greatly appreciate a systematic and comprehensive approach like in the (already mentioned) perl or python cookbooks.

Please note that large part of the audience will be coming with basic problems (even if already discussed in other sources like Rust by Example ) like:

• basic iterator manipulation (for each / skipping / reversing / collecting / mapping / filtering / zippping / enumerating/sorting)
• implementing custom iterator
• more advanced iterator idioms - flattening nested sequences / cycling / grouping (possibly even with itertools)
• String splitting/concatenation/ struct representation (Display et al.)
• Finding substring occurences / replacing
• stripping unwanted characters from string
• regular expressions
• Dictionary lookup, finding set union / intersection / difference / complement,
• extracting subset
• listing items by frequency
• Basic threading (starting / joining / workqueue / locking / message passing) - there is plethora of usecases for which rayon is not the ideal answer
• recursively listing directories (walkdir)
• date time parsing / manipulation / calculation
• path manipulation
• statting files (testing for existance / size / atime / mtime etc.) / checking dent is a file / dir / link
• decoding/encoding - hex / base64
• implementing callbacks / working with closures
• creating UDP/TCP server
• manipulating files and directories (create / copy / move / delete)

Some intermediate usecases might be:

• connecting to database / performing sql querries
• orm (diesel)
• reading / writing - csv / json / yaml / toml / xml / ini
• processing large xml documents incrementally
• implementing some standard design patterns - visitor / strategy / state machine / builder / factory / command / ...
• creating cyclic data structures
• creating simple rest service
• xml-rpc / json-rpc client / server
• launching unix daemon
• logging
• testing / mocking / expecting failure / catching panics
• various FFI usecases - calling c from rust / calling rust from c / python / ruby

Some other problems that I have personally encountered:

• parsing binary file (I used nom but no parser combinator lib is listed in key crate list)
• spawning process and communicating
• checking if executable exists in the system
• comparing large files (memmap)

@brson Do these examples look reasonable? In order to learn rust I would be willing to implement at least few of the listed examples.

[brson]

@budziq wow thank you for all these ideas. I think almost all of them are appropriate for the cookbook.

I would though like to keep the scope of the cookbook relatively aligned with the libz blitz, where we are working sort of from the inside out, documenting the most fundamental crates first.

If you want to implement any of these examples I encourage you to pick ones that can be implemented with the crates discussed in that thread.

Some areas on your list I don't feel prepared to deal with yet are databases, testing and mocking, RPC.

I'm not sure that patterns are appropriate for this project, but there is at least one project dedicated to Rust patterns specifically.

Thanks so much for jumping on this @budziq. Keep it coming.

[kud1ing]

I've just discovered this and would add the few examples i have:

Cargo

• TODO: Create a project with a binary
• TODO: Create a project with multiple binaries
• TODO: Create a project with a library
• TODO: Create a project with a library and a binary

Dates and times

• TODO: Dates between two dates
• TODO: Today's date
• TODO: Add or substract from a date
• TODO: Difference of two dates
• TODO: Sleep

Development

• TODO: Find out the data type: (i can't find a link to it right now, but i've seen Shepmaster giving this advice on Stackoverflow where you do a let foo : () = ... to let the compiler tell you the exact data type of the right hand side)

Directories

• Files in a directory

Files

• Read a file line by line
• Read a file line by line in reverse
• Read a file into a string

Input

• Read a line

Iterators

• Write an iterator that yields references

Network

• TODO: Download a web page
• TODO: Send an email
• TODO: Serve a web page

Numbers

• Logarithms:

base	for type f32	for type f64
2	log2()	log2()
e	ln()	ln()
10	log10()	log10()
arbitrary	log()	log()

• Random numbers

Performance

What to do when Rust code is slow.

• Compile in release mode

Strings

• Understand the difference between &str and String
• TODO: Concatenate strings
• Multi-line strings
• Write a function that accepts both &str and String
• Choose an advanced string type

[richard-uk1]

Run an external command and collect stdout

[j-haj]

Is there any interest in adding examples for the following crates:

• serde - data serialization/deserialization is a very useful and important tool. It would be a great combo with RPC, although there are no RPC crates in the libz blitz thread
• chrono - another userful crate. Adding a recipe for timing segments of code would be very useful to a lot of people I think (it's a very common question in Python, C, and C++, for example)

[budziq]

@j-haj these are both excellent points!

• i agree on the serde front (it has some representation) . Although I was thinking in expanding the usage with some xml, yml and more toml examples. In regard to Rpc itself. It is a tough nut to crack. There seams to be no community favourite crate for that purpose at the moment so we would have to do some digging and possibly a poll. Our crate inclusion policy has just started coalescing.
• my thoughts exactly on chrono. I was just thinking about adding some date / time manipulation examples. Would you open the tracking issue for chrono to gather ideas?

[j-haj]

@budziq Done! see #324. It appears you may have to add the labels

[gbip]

What do you think about "Send a struct through a TCP connection" ?
In my opinion, using serde with a TcpStream and a TcpListener is something that could be really useful for any kind of server-client application.

[budziq]

@gbip Thanks!

using serde with a TcpStream and a TcpListener is something that could be really useful for any kind of server-client application.

While I think that an example showing basic connection handling and data sending/receiving with std would be beneficial, I'm not loving the idea of "sending struct" or using serde here.

Here's why:

• Communication via passing structs is almost never a good idea, one would have to implement some rudimentary protocol.
• Do we frame, length prefix or delimit the messages/data?
• Which of the serde serializers would we use? Bincode, CBOR,
  MessagePack,Pickle, BSON
  And which should we promote in the cookbook. Any of these are typically used in the context of some protocol and using these directly over TCP would be promoting non optimal patterns.

Personally I'd suggest to implement a basic TCP client server (like echo or datetime http://blog.annharter.com/2015/07/15/three-dead-protocols.html) pointing in the description that this is a basic toy example that should use Tokio/Mio for any kind of performance.