You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you have a question or an idea regarding certain content but you want to have feedback of fellow community members
6
+
and you think it may not be appropriate to file an issue open a discussion in our [discussion board](https://github.com/rust-unofficial/patterns/discussions).
7
+
8
+
9
+
## Writing a new article
10
+
11
+
Before writing a new article please check our [issues](https://github.com/rust-unofficial/patterns/issues) and
12
+
the [Pull Requests](https://github.com/rust-unofficial/patterns/pulls) if there are existing issues or someone
13
+
is working on that topic.
14
+
15
+
If you don't find an issue regarding your topic and you are sure it is not more feasible to open a thread in the [discussion board](https://github.com/rust-unofficial/patterns/discussions)
16
+
please open a new issue, so we can discuss about the ideas and future content of the article together and maybe
17
+
give some feedback/input on it.
18
+
19
+
When writing a new article it's recommended to copy the [pattern template](https://github.com/rust-unofficial/patterns/blob/master/template.md) into the
20
+
appropriate directory and start editing it. You may not want to fill out every section and remove it or you might want to add extra sections.
21
+
22
+
Consider writing your article in a way that has a low barrier of entry so also [Rustlings](https://github.com/rust-lang/rustlings) can follow
23
+
and understand the thought process behind it. So we can encourage people to use these patterns early on.
24
+
25
+
We encourage you to write idiomatic Rust code that builds in the [playground](https://play.rust-lang.org/).
26
+
27
+
If you use links to blogposts or in general content that is not to be sure existing in a few years (e.g. pdfs) please take a snapshot
28
+
with the [Wayback Machine](https://web.archive.org/) and use the link to that snapshot in your article.
29
+
30
+
Don't forget to add your new article to the `SUMMARY.md` to let it be rendered to the book.
31
+
32
+
Please make `Draft Pull requests` early so we can follow your progress and can give early feedback (see the following section).
33
+
34
+
35
+
36
+
## Creating a Pull Request
37
+
38
+
"Release early and often!" also applies to pull requests!
39
+
40
+
Once your article has some visible work, create a `[WIP]` draft pull request and give it a description of what you did or want to do.
41
+
Early reviews of the community are not meant as an offense but to give feedback.
42
+
43
+
A good principle: "Work together, share ideas, teach others."
44
+
45
+
### Important Note
46
+
47
+
Please **don't force push** your branch to keep commit history and make it easier of us to see changes between reviews.
48
+
49
+
Make sure to `Allow edits of maintainers` (under the text box) in the PR so people can actually collaborate on things or fix smaller issues themselves.
Copy file name to clipboardExpand all lines: README.md
+13-14Lines changed: 13 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,20 +1,21 @@
1
1
# Rust Design Patterns
2
2
3
-
An open source repository of design patterns and idioms in the Rust programming
4
-
language.
3
+
An open source book about design patterns and idioms in the Rust programming
4
+
language that you can read [here](https://rust-unofficial.github.io/patterns/).
5
5
6
6
7
7
## Contents
8
8
9
9
[Introduction](intro.md)
10
10
11
+
11
12
### Idioms
12
13
13
14
*[Constructor](idioms/ctor.md)
14
15
*[Concatenating strings with `format!`](idioms/concat-format.md)
15
16
*[Privacy for extensibility](idioms/priv-extend.md)
16
17
* TODO stability for extensibility
17
-
* TODO trait to separate visibility of methods from visibility of data (https://github.com/sfackler/rust-postgres/blob/master/src/lib.rs#L1400)
18
+
* TODO trait to separate visibility of methods from visibility of data (https://github.com/sfackler/rust-postgres/blob/v0.9.6/src/lib.rs#L1400)
18
19
*[Collections are smart pointers](idioms/deref.md)
19
20
* TODO leak amplification ("Vec::drain sets the Vec's len to 0 prematurely so that mem::forgetting Drain "only" mem::forgets more stuff. instead of exposing uninitialized memory or having to update the len on every iteration")
20
21
*[Finalisation in destructors](idioms/dtor-finally.md)
@@ -28,6 +29,7 @@ language.
28
29
* TODO FFI usage (By being mindful of how to provide Rust libraries, and make use of existing libraries across the FFI, you can get more out of benefits Rust can bring)
An [anti-pattern](https://en.wikipedia.org/wiki/Anti-pattern) is a solution to a "recurring problem that is usually ineffective and risks being highly counterproductive".
4
+
Just as valuable as knowing how to solve a problem, is knowing how _not_ to solve it.
5
+
Anti-patterns give us great counter-examples to consider relative to design patterns.
6
+
Anti-patterns are not confined to code. For example, a process can be an anti-pattern, too.
Rust is an imperative language, but it follows many functional programming paradigms. One of the biggest hurdles to understanding functional programs when coming from an imperative background is the shift in thinking. Imperative programs describe __how__ to do something, whereas declarative programs describe __what__ to do. Let's sum the numbers from 1 to 10 to show this.
4
+
5
+
## Imperative
6
+
7
+
```rust
8
+
letmutsum=0;
9
+
foriin1..11 {
10
+
sum+=i;
11
+
}
12
+
println!("{}", sum);
13
+
```
14
+
15
+
With imperative programs, we have to play compiler to see what is happening. Here, we start with a `sum` of `0`. Next, we iterate through the range from 1 to 10. Each time through the loop, we add the corresponding value in the range. Then we print it out.
16
+
17
+
|`i`|`sum`|
18
+
| --- | ----- |
19
+
| 1 | 1 |
20
+
| 2 | 3 |
21
+
| 3 | 6 |
22
+
| 4 | 10 |
23
+
| 5 | 15 |
24
+
| 6 | 21 |
25
+
| 7 | 28 |
26
+
| 8 | 36 |
27
+
| 9 | 45 |
28
+
| 10 | 55 |
29
+
30
+
This is how most of us start out programming. We learn that a program is a set of steps.
31
+
32
+
## Declarative
33
+
34
+
```rust
35
+
println!("{}", (1..11).fold(0, |a, b|a+b));
36
+
```
37
+
38
+
Whoa! This is really different! What's going on here? Remember that with declarative programs we are describing __what__ to do, rather than __how__ to do it. `fold` is a function that [composes](https://en.wikipedia.org/wiki/Function_composition) functions. The name is a convention from Haskell.
39
+
40
+
Here, we are composing functions of addition (this closure: `|a, b| a + b)`) with a range from 1 to 10. The `0` is the starting point, so `a` is `0` at first. `b` is the first element of the range, `1`. `0 + 1 = 1` is the result. So now we `fold` again, with `a = 1`, `b = 2` and so `1 + 2 = 3` is the next result. This process continues until we get to the last element in the range, `10`.
[Idioms](https://en.wikipedia.org/wiki/Programming_idiom) are commonly used styles and patterns largely agreed upon by a community. They are guidelines. Writing idiomatic code allows other developers to understand what is happening because they are familiar with the form that it has.
4
+
5
+
The computer understands the machine code that is generated by the compiler. The language is therefore mostly beneficial to the developer. So, since we have this abstraction layer, why not put it to good use and make it simple?
6
+
7
+
Remember the [KISS principle](https://en.wikipedia.org/wiki/KISS_principle): "Keep It Simple, Stupid". It claims that "most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided".
8
+
9
+
> Code is there for humans, not computers, to understand.
0 commit comments