In Rust section-1 <Project: Tools and good bones>, duplicate "part-3" occurs in the document:

• Cargo environment variables
• Store values in memory

I wonder if there is something wrong here.

Follow the example of project 1, using the subject matter in the plan.

Read through the project 1 text and follow the steps as written. The purpose of this is to discover missing information, conflicting information, inconsistencies, and things that can be improved. Then fix them or file issues.

You will find many. No issue is to small. Be detail-oriented.

As you are working and notice problems, either fix them directly in your own talent-plan branch if possible, file issues or write them down.

The projects are intended to pose problems, with gentle suggestions about how to solve them, but not to teach you how to solve them. To learn how to solve the problems, students are intended to read associated "readings" before trying the project. These readings are not written down yet. If you find yourself using a particular resource to learn how to complete the project, make note of that resource in the corresponding "readings" issue for the project.

Do not read the example code on your first work-through of the project, even if you get stuck. Instead ask for help. Later you will go back and read and edit the example code.

This task is divided into two discreet sub-tasks that you may complete separately or together:

• Edit project 1 text #77
• Edit project 1 code #78

And another related task that you may want to contribute to:

• Collect readings for project 1 #79

Here are some questions to think about:

• Each project has an overview describing the task, goals and topics. What is missing from this section that is contained in the text? What is mentioned in this section that is not in the text?

• Each project has a described "setup". What extra steps did you need to figure out for yourself that were not described in the text? Were these extra steps too difficult for the target audience?

• The projects begin by asking you to copy the test cases into your own project, then get the project to build without passing the tests. In this project, was that experience an acceptable way to begin the project? What were the most difficult tests to get compiling? What workflow did you use? Did it frustrate you?

• Each project has a "spec" describing the external interface to the project. What parts of the spec were difficult to understand? What parts of the spec are not reflected in the test suite?

• Are you able to complete the project in the sequence described, or did you have to read forward, jump between sections, implement the code partially and come back to it? How can the project be sequenced more naturally?

• Are there implicit steps that frustrated you or felt unfair? How could we gently nudge the reader in the right direction? How could we add an explicit step to fill in the gap?

• Which material was new to you? Which material was not new to you? Which subjects would you have liked to see in this project?

• Were there words or phrases that you didn't understand? Were there sentences that were too long or complex? Can you rewrite them to be simpler?

• Was there text you think should be cut? Text you think should be added?

• Can you fill in any of the missing content yourself?

• What reading material would help you complete this project?

I can't understand why it's false here, that is, it won't retry if it failed. The first attempt was made without an leader and faid.

Subtask of #88.

After you have written your own version of the project, then read the example project, including the test cases.

The example project needs to represent the very best of Rust coding practices. The test cases especially are the real "specification" for the project, and students will be reading them to figure out what exactly their own code is supposed to be doing. Test code is often written with less care than production code. That will not be the case in this project.

Considerations:

• Code should be idiomatic, but also straightforward. It shouldn't be unnecessarily clever.
• Public items should be documented, without simply repeating the item name. The crate should contain the attribute to deny undocumented items.
• Code should be rustfmted.

As with the text, each project's code needs to be consistent from project to project. Functions with identical specs should be implemented and formatted the same. They should be ordered in the same sequence.

For test cases, each project should contain the previous project's tests, in a consistent and sensible order.

Right now they are entirely independent and differently organized. They should probably both follow a single model.

I have no specific ideas right now.

cc @stn @rleungx

Subtask of #75.

After you have written your own version of the project, then read the example project, including the test cases.

The example project needs to represent the very best of Rust coding practices. The test cases especially are the real "specification" for the project, and students will be reading them to figure out what exactly their own code is supposed to be doing. Test code is often written with less care than production code. That will not be the case in this project.

Considerations:

• Code should be idiomatic, but also straightforward. It shouldn't be unnecessarily clever.
• Public items should be documented, without simply repeating the item name. The crate should contain the attribute to deny undocumented items.
• Code should be rustfmted.

As with the text, each project's code needs to be consistent from project to project. Functions with identical specs should be implemented and formatted the same. They should be ordered in the same sequence.

For test cases, each project should contain the previous project's tests, in a consistent and sensible order.

Read through the project 4 text and follow the steps as written. The purpose of this is to discover missing information, conflicting information, inconsistencies, and things that can be improved. Then fix them or file issues.

You will find many. No issue is to small. Be detail-oriented.

As you are working and notice problems, either fix them directly in your own talent-plan branch if possible, file issues or write them down.

The projects are intended to pose problems, with gentle suggestions about how to solve them, but not to teach you how to solve them. To learn how to solve the problems, students are intended to read associated "readings" before trying the project. These readings are not written down yet. If you find yourself using a particular resource to learn how to complete the project, make note of that resource in the corresponding "readings" issue for the project.

Do not read the example code on your first work-through of the project, even if you get stuck. Instead ask for help. Later you will go back and read and edit the example code.

This task is divided into two discreet sub-tasks that you may complete separately or together:

• Edit project 4 text #89
• Edit project 4 code #90

And another related task that you may want to contribute to:

• Collect readings for project 4 #91

Here are some questions to think about:

• Each project has an overview describing the task, goals and topics. What is missing from this section that is contained in the text? What is mentioned in this section that is not in the text?

• Each project has a described "setup". What extra steps did you need to figure out for yourself that were not described in the text? Were these extra steps too difficult for the target audience?

• The projects begin by asking you to copy the test cases into your own project, then get the project to build without passing the tests. In this project, was that experience an acceptable way to begin the project? What were the most difficult tests to get compiling? What workflow did you use? Did it frustrate you?

• Each project has a "spec" describing the external interface to the project. What parts of the spec were difficult to understand? What parts of the spec are not reflected in the test suite?

• Are you able to complete the project in the sequence described, or did you have to read forward, jump between sections, implement the code partially and come back to it? How can the project be sequenced more naturally?

• Are there implicit steps that frustrated you or felt unfair? How could we gently nudge the reader in the right direction? How could we add an explicit step to fill in the gap?

• Which material was new to you? Which material was not new to you? Which subjects would you have liked to see in this project?

• Were there words or phrases that you didn't understand? Were there sentences that were too long or complex? Can you rewrite them to be simpler?

• Was there text you think should be cut? Text you think should be added?

• Can you fill in any of the missing content yourself?

• What reading material would help you complete this project?

Just getting the outline done helps write the code.

Deleting values from a map is an important operation and adds a second mutating command, making the log more interesting.

Hi Raft assignment maker,

I'm struggling with the raft implementation to pass "test 2a",
and I find this link in the comment does no longer exist in the source files:

By the way, may I ask if the working code of this method

looks anything like this method in the example code?

Because if it does and should work within one line, I'm getting an error, I know I'm not supposed to paste my code here because other people still need to work on it by themselves, so I hope I can get a little hint to make sure it's not the assignment's error but mine.

If there is somewhere I can get some extra material on this labrpc package, that would be really helpful, thanks!

This section anchors the entire course, describing the database architecture, and more importantly, defining the terms used within.

Following previous examples, subject matter from the plan.

As we've progressed and the course has changed, parts of the readme, plan, and project texts have gotten sloppy and inconsistent. Take a pass over and make sure that the materials agree with each other, links work, duplicate text is actually the same, etc. After project 3 is probably a good time to do this.

This project is intended in part for a Chinese audience who may not have strong English skills. There are tool to help enforce the use of simplified language (look into hemmingway). Set up a test harness that scans all the text in the Rust course and verifies that the language used is acceptably simple.

Needs to have one. I haven't thought about what it should contain.

Read through the project 2 text and follow the steps as written. The purpose of this is to discover missing information, conflicting information, inconsistencies, and things that can be improved. Then fix them or file issues.

You will find many. No issue is to small. Be detail-oriented.

As you are working and notice problems, either fix them directly in your own talent-plan branch if possible, file issues or write them down.

The projects are intended to pose problems, with gentle suggestions about how to solve them, but not to teach you how to solve them. To learn how to solve the problems, students are intended to read associated "readings" before trying the project. These readings are not written down yet. If you find yourself using a particular resource to learn how to complete the project, make note of that resource in the corresponding "readings" issue for the project.

Do not read the example code on your first work-through of the project, even if you get stuck. Instead ask for help. Later you will go back and read and edit the example code.

This task is divided into two discreet sub-tasks that you may complete separately or together:

• Edit project 2 text #81
• Edit project 2 code #82

And another related task that you may want to contribute to:

• Collect readings for project 2 #83

Here are some questions to think about:

• Each project has an overview describing the task, goals and topics. What is missing from this section that is contained in the text? What is mentioned in this section that is not in the text?

• Each project has a described "setup". What extra steps did you need to figure out for yourself that were not described in the text? Were these extra steps too difficult for the target audience?

• The projects begin by asking you to copy the test cases into your own project, then get the project to build without passing the tests. In this project, was that experience an acceptable way to begin the project? What were the most difficult tests to get compiling? What workflow did you use? Did it frustrate you?

• Each project has a "spec" describing the external interface to the project. What parts of the spec were difficult to understand? What parts of the spec are not reflected in the test suite?

• Are you able to complete the project in the sequence described, or did you have to read forward, jump between sections, implement the code partially and come back to it? How can the project be sequenced more naturally?

• Are there implicit steps that frustrated you or felt unfair? How could we gently nudge the reader in the right direction? How could we add an explicit step to fill in the gap?

• Which material was new to you? Which material was not new to you? Which subjects would you have liked to see in this project?

• Were there words or phrases that you didn't understand? Were there sentences that were too long or complex? Can you rewrite them to be simpler?

• Was there text you think should be cut? Text you think should be added?

• Can you fill in any of the missing content yourself?

• What reading material would help you complete this project?

Per discussion in #10, the way I chose to to put the binary source at src/bin/main.rs is awkward because it produces a binary called main, which has to be explained. Putting that file somewhere else would do the right thing by default and avoid the subject.

Today I think it would be better to move this somewhere else, probably either src/bin/kvs.rs or src/main.rs. Need to decide which is the better practice. I'm inclined to go with the former, as putting lib.rs and main.rs in the same folder is a bit confusing, with the source for both intermingling.

Subtask of #88.

The instructions there apply.

As an additional consideration, consider that the projects in this course are "additive", and much of the content is carried over from project to project. It needs to be consistent, both in formatting and content.

What to look for:

• Are the sections using the correct header levels?
• Are the "part" numbers in the correct sequence?
• Are the number of blank lines between sections consistent?
• Is the "setup" worded exactly the same wherever the setup is exactly the same?
• Is the spec worded exactly the same wherever the spec is exactly the same?

Subtask of #75.

The instructions there apply.

Note: the below doesn't apply to project 1, but I'm writing it here while I'm thinking about it, so I can copy it to later project issues

As an additional consideration, consider that the projects in this course are "additive", and much of the content is carried over from project to project. It needs to be consistent, both in formatting and content.

What to look for:

• Are the sections using the correct header levels?
• Are the "part" numbers in the correct sequence?
• Are the number of blank lines between sections consistent?
• Is the "setup" worded exactly the same wherever the setup is exactly the same?
• Is the spec worded exactly the same wherever the spec is exactly the same?

Subtask of #84.

The instructions there apply.

As an additional consideration, consider that the projects in this course are "additive", and much of the content is carried over from project to project. It needs to be consistent, both in formatting and content.

What to look for:

• Are the sections using the correct header levels?
• Are the "part" numbers in the correct sequence?
• Are the number of blank lines between sections consistent?
• Is the "setup" worded exactly the same wherever the setup is exactly the same?
• Is the spec worded exactly the same wherever the spec is exactly the same?

Read through the project 3 text and follow the steps as written. The purpose of this is to discover missing information, conflicting information, inconsistencies, and things that can be improved. Then fix them or file issues.

You will find many. No issue is to small. Be detail-oriented.

As you are working and notice problems, either fix them directly in your own talent-plan branch if possible, file issues or write them down.

The projects are intended to pose problems, with gentle suggestions about how to solve them, but not to teach you how to solve them. To learn how to solve the problems, students are intended to read associated "readings" before trying the project. These readings are not written down yet. If you find yourself using a particular resource to learn how to complete the project, make note of that resource in the corresponding "readings" issue for the project.

Do not read the example code on your first work-through of the project, even if you get stuck. Instead ask for help. Later you will go back and read and edit the example code.

This task is divided into two discreet sub-tasks that you may complete separately or together:

• Edit project 3 text #85
• Edit project 3 code #86

And another related task that you may want to contribute to:

• Collect readings for project 3 #87

Here are some questions to think about:

• Each project has an overview describing the task, goals and topics. What is missing from this section that is contained in the text? What is mentioned in this section that is not in the text?

• Each project has a described "setup". What extra steps did you need to figure out for yourself that were not described in the text? Were these extra steps too difficult for the target audience?

• The projects begin by asking you to copy the test cases into your own project, then get the project to build without passing the tests. In this project, was that experience an acceptable way to begin the project? What were the most difficult tests to get compiling? What workflow did you use? Did it frustrate you?

• Each project has a "spec" describing the external interface to the project. What parts of the spec were difficult to understand? What parts of the spec are not reflected in the test suite?

• Are you able to complete the project in the sequence described, or did you have to read forward, jump between sections, implement the code partially and come back to it? How can the project be sequenced more naturally?

• Are there implicit steps that frustrated you or felt unfair? How could we gently nudge the reader in the right direction? How could we add an explicit step to fill in the gap?

• Which material was new to you? Which material was not new to you? Which subjects would you have liked to see in this project?

• Were there words or phrases that you didn't understand? Were there sentences that were too long or complex? Can you rewrite them to be simpler?

• Was there text you think should be cut? Text you think should be added?

• Can you fill in any of the missing content yourself?

• What reading material would help you complete this project?

The goals for this project still aren't clear, or they are not what they should be, or the content of the course so far doesn't support the goals.

The readme contains statements about both, but they don't seem to be clear, or they are not what some people expect. Especially, the goal

convey knowledge relevant to real-world Rust programming, including inherited wisdom and best practices; to look "under the hood" and understand how and why Rust works like it does; to tour the world of Rust documentation and code such that the student can learn how to find answers to their questions on their own.

is too expansive, and doesn't seem to resonate. Reviewers seem to see the project progression and wonder why the lesson plan contains so many topics that don't directly contribute to the projects.

Furthermore, this goal of generally conveying practical knowledge is not PingCAP's goal, it is my own. By my understanding, PingCAP wants students to demonstrate specific knowledge that is relevant to working on TiKV.

I could use help on this since I have tried a few times to express the goals for the course, but questions continue to arise. Maybe if others could suggest clear statements about the goals and audience that would help me reorient.

cc @siddontang @nrc @sticnarf @overvenus @Hoverbear

Different data will make the test bench much different.
I think we should better make the data same.

xiekeyi@ubuntu:~/main$ go test -bench=. -count 10
goos: linux
goarch: amd64
BenchmarkSort-4   	       1	6580828228 ns/op
BenchmarkSort-4   	       1	6088125591 ns/op
BenchmarkSort-4   	       1	6074915582 ns/op
BenchmarkSort-4   	       1	6240114873 ns/op
BenchmarkSort-4   	       1	5943407633 ns/op
BenchmarkSort-4   	       1	6401486420 ns/op
BenchmarkSort-4   	       1	6776108465 ns/op
BenchmarkSort-4   	       1	6284466216 ns/op
BenchmarkSort-4   	       1	5967908212 ns/op
BenchmarkSort-4   	       1	6382395503 ns/op
PASS
ok  	_/home/xiekeyi/main	70.028s
xiekeyi@ubuntu:~/main$ cat a_test.go 
package main

import (
	"math/rand"
	"sort"
	"testing"
	"time"
)

func prepare(src []int64) {
	rand.Seed(time.Now().Unix())
	for i := range src {
		src[i] = rand.Int63()
	}
}

func BenchmarkSort(b *testing.B) {
	numElements := 16 << 20
	src := make([]int64, numElements)
	original := make([]int64, numElements)

	prepare(original)

	b.ResetTimer()

	for i := 0; i < b.N; i++ {
		b.StopTimer()
		copy(src, original)
		b.StartTimer()
		sort.Slice(src, func(i, j int) bool { return src[i] < src[j] })
	}
}
xiekeyi@ubuntu:~/main$ 

In mergesort, do we need to have a return value stand for the res?

I think src is indicated we should not change it.

And this line, I think we should use result: = mergesort(src) is better?

Before others can write any project descriptions, we need one completed to establish the format. Don't need to write the solution or tests now, just get the prose done.

In Makefile:

cargo_test_%:
        RUST_LOG=${LOG_LEVEL} cargo test --lib -- --nocapture --test $*

This command will arrage the test by lexicographical order, therefore, the test order is different from the order in which they appear in the test file.

Sorry to use this issue to ask the question, I believe such a platform should be very beneficial for us who took part in the plan.

The projects themselves do not attempt to explain how to write them, just what to write, along with hints, suggestions, and tradeoffs.

They are intended to be accompanied by lessons and also external "readings". The lessons are on hold for the first iteration of the course, which makes the readings essential.

One of the purposes of this project is to expose new Rust programmers to resources they might know about, so the best material is often going to be blog posts from experts. One of the per-requisites for the entire course is to read The Rust Book, so we can provide the most value by providing readings that are not from the book, often time blog posts by experts. In some cases though individual book chapters are worth linking to. For example, error handling is such a tricky topic that just reading the book's chapter on error handling is not enough - we might link it, but we would definitely link to other resources as well.

Read through the text, identify the problems being solved, find single-page resources that contain potential answers to those problems and add them to the project.

There's currently no section of the project's devoted to this, so add one.

For the MVP, I am only planning on implementing the projects and gathering the required background reading material to implement them. So any lessons will not be written for quite a while. Their presence in the plan is distracting to reviewers.

The questions in project 1 have not worked out.

So let's remove both. Delete the lessons from plan.md, putting their topics back in notes.md under the section listing potential topics. Delete the questions from project 1 and the corresponding answers.

@sticnarf will you do this?

The projects themselves do not attempt to explain how to write them, just what to write, along with hints, suggestions, and tradeoffs.

They are intended to be accompanied by lessons and also external "readings". The lessons are on hold for the first iteration of the course, which makes the readings essential.

One of the purposes of this project is to expose new Rust programmers to resources they might know about, so the best material is often going to be blog posts from experts. One of the per-requisites for the entire course is to read The Rust Book, so we can provide the most value by providing readings that are not from the book, often time blog posts by experts. In some cases though individual book chapters are worth linking to. For example, error handling is such a tricky topic that just reading the book's chapter on error handling is not enough - we might link it, but we would definitely link to other resources as well.

Read through the text, identify the problems being solved, find single-page resources that contain potential answers to those problems and add them to the project.

There's currently no section of the project's devoted to this, so add one.

As discussed in #10, hyper no longer has synchronous APIs, so if we're going to have project 3 and 4 using synchronous networking we need a new plan.

cc @sticnarf

Already in progress: #10

I put main directly in the library to make the command line testable by calling main in unit tests. This doesn't actually work though because the tests can't modify command line arguments of the running process.

Following the example of project 1, with the subject matter from the plan.

Also write the answers to any questions posed by project 2.

These projects are supposed to be accessible to Chinese Rust programmers who may not have great english skills.

Somebody who speaks both well needs to review, looking for phrases and concepts that don't translate well, and simplify the language as much as possible.

Let's wait on this until project 1 has gone through another round of iteration.

Read through the project 4 text and follow the steps as written. The purpose of this is to discover missing information, conflicting information, inconsistencies, and things that can be improved. Then fix them or file issues.

You will find many. No issue is to small. Be detail-oriented.

As you are working and notice problems, either fix them directly in your own talent-plan branch if possible, file issues or write them down.

The projects are intended to pose problems, with gentle suggestions about how to solve them, but not to teach you how to solve them. To learn how to solve the problems, students are intended to read associated "readings" before trying the project. These readings are not written down yet. If you find yourself using a particular resource to learn how to complete the project, make note of that resource in the corresponding "readings" issue for the project.

Do not read the example code on your first work-through of the project, even if you get stuck. Instead ask for help. Later you will go back and read and edit the example code.

This task is divided into two discreet sub-tasks that you may complete separately or together:

• Edit project 4 text #93
• Edit project 4 code #94

And another related task that you may want to contribute to:

• Collect readings for project 4 #95

Here are some questions to think about:

• Each project has an overview describing the task, goals and topics. What is missing from this section that is contained in the text? What is mentioned in this section that is not in the text?

• Each project has a described "setup". What extra steps did you need to figure out for yourself that were not described in the text? Were these extra steps too difficult for the target audience?

• The projects begin by asking you to copy the test cases into your own project, then get the project to build without passing the tests. In this project, was that experience an acceptable way to begin the project? What were the most difficult tests to get compiling? What workflow did you use? Did it frustrate you?

• Each project has a "spec" describing the external interface to the project. What parts of the spec were difficult to understand? What parts of the spec are not reflected in the test suite?

• Are you able to complete the project in the sequence described, or did you have to read forward, jump between sections, implement the code partially and come back to it? How can the project be sequenced more naturally?

• Are there implicit steps that frustrated you or felt unfair? How could we gently nudge the reader in the right direction? How could we add an explicit step to fill in the gap?

• Which material was new to you? Which material was not new to you? Which subjects would you have liked to see in this project?

• Were there words or phrases that you didn't understand? Were there sentences that were too long or complex? Can you rewrite them to be simpler?

• Was there text you think should be cut? Text you think should be added?

• Can you fill in any of the missing content yourself?

• What reading material would help you complete this project?

Today the executable defers to a run function in the library, the intent being to test the cli by calling the run function. This of course doesn't work because unit tests can't modify the args of the running process.

Come up with a way of testing the cli from unit tests and implement it.

One solution is to write the unit tests to run the project executable, which should be compiled ahead of the tests during cargo test.

Then modify existing projects to put application code in the exe.

Related: #16

cc @sticnarf can you give this a shot?

The projects themselves do not attempt to explain how to write them, just what to write, along with hints, suggestions, and tradeoffs.

They are intended to be accompanied by lessons and also external "readings". The lessons are on hold for the first iteration of the course, which makes the readings essential.

One of the purposes of this project is to expose new Rust programmers to resources they might know about, so the best material is often going to be blog posts from experts. One of the per-requisites for the entire course is to read The Rust Book, so we can provide the most value by providing readings that are not from the book, often time blog posts by experts. In some cases though individual book chapters are worth linking to. For example, error handling is such a tricky topic that just reading the book's chapter on error handling is not enough - we might link it, but we would definitely link to other resources as well.

Read through the text, identify the problems being solved, find single-page resources that contain potential answers to those problems and add them to the project.

There's currently no section of the project's devoted to this, so add one.

Subtask of #80.

After you have written your own version of the project, then read the example project, including the test cases.

The example project needs to represent the very best of Rust coding practices. The test cases especially are the real "specification" for the project, and students will be reading them to figure out what exactly their own code is supposed to be doing. Test code is often written with less care than production code. That will not be the case in this project.

Considerations:

• Code should be idiomatic, but also straightforward. It shouldn't be unnecessarily clever.
• Public items should be documented, without simply repeating the item name. The crate should contain the attribute to deny undocumented items.
• Code should be rustfmted.

As with the text, each project's code needs to be consistent from project to project. Functions with identical specs should be implemented and formatted the same. They should be ordered in the same sequence.

For test cases, each project should contain the previous project's tests, in a consistent and sensible order.

Following existing examples.

Also answer any questions posed by the project text.

In the text of project 2, we intended to simplify the bitcask algorithm using only one log file. After some practice, it is found that a single log file makes implementation more complex instead of simplifying it.

So I think we should not ask students to use only one log, and then give instructions of using multiple logs or at least give some hints.

Subtask of #80.

The instructions there apply.

As an additional consideration, consider that the projects in this course are "additive", and much of the content is carried over from project to project. It needs to be consistent, both in formatting and content.

What to look for:

• Are the sections using the correct header levels?
• Are the "part" numbers in the correct sequence?
• Are the number of blank lines between sections consistent?
• Is the "setup" worded exactly the same wherever the setup is exactly the same?
• Is the spec worded exactly the same wherever the spec is exactly the same?

I found in my computer, sort.Slice is about 15s, merge sort in single thread need about 9s. Then I write a base quick sort in hand with go, it is only about 7s in benchmark(sort.Slice slower than hand quick sort maybe because reflect?). Anybody see the same phenomenon？

Implementions is as follow(go version: 1.12.2):

merge sort:

// MergeSort performs the merge sort algorithm.
// Please supplement this function to accomplish the home work.
func MergeSort(src []int64) {
	dst := make([]int64, len(src))
	copy(dst, src)
	mSort(dst, src, 0, len(src))
}

//从src归并到dest
func mSort(src []int64, dest []int64, low int, high int) {
	if high-low <= 1 {
		return
	}

	mid := (low + high) >> 1
	mSort(dest, src, low, mid)
	mSort(dest, src, mid, high)

	for i, p, q := low, low, mid; i < high; i++ {
		if q >= high || (p < mid && src[p] < src[q]) {
			dest[i] = src[p]
			p++
		} else {
			dest[i] = src[q]
			q++
		}
	}
}

my hand quick sort:

func quickSort(arr []int64) {
	qSort(arr, 0, len(arr) - 1)
}

func qSort(arr []int64, low int, high int) {
	if low < high{
		pivot := partition(arr, low, high)
		qSort(arr, low, pivot - 1)
		qSort(arr, pivot + 1, high)
	}
}

func partition(arr []int64, low int, high int) int {
	pivotKey := arr[low]
	for low < high{
		for low < high && arr[high] >= pivotKey{
			high--
		}
		arr[low] = arr[high]
		for low < high && arr[low] <= pivotKey{
			low++
		}
		arr[high] = arr[low]
	}
	arr[low] = pivotKey

	return low
}

benchmark:

func BenchmarkMergeSort(b *testing.B) {
	numElements := 16 << 20
	src := make([]int64, numElements)
	original := make([]int64, numElements)
	prepare(original)

	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		b.StopTimer()
		copy(src, original)
		b.StartTimer()
		MergeSort(src)
	}
}


func BenchmarkNormalSort(b *testing.B) {
	// 16M个整数
	numElements := 16 << 20
	src := make([]int64, numElements)
	original := make([]int64, numElements)
	prepare(original)

	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		b.StopTimer()
		copy(src, original)
		b.StartTimer()
		sort.Slice(src, func(i, j int) bool { return src[i] < src[j] })
	}
}

func BenchmarkQuickSort(b *testing.B) {
	// 16M个整数
	numElements := 16 << 20
	src := make([]int64, numElements)
	original := make([]int64, numElements)
	prepare(original)

	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		b.StopTimer()
		copy(src, original)
		b.StartTimer()
		quickSort(src)
	}
}

Benchmark results as follows:

goos: linux
goarch: amd64
pkg: pingcap/talentplan/tidb/mergesort
BenchmarkMergeSort-12                 1         9503371329 ns/op
BenchmarkNormalSort-12                1       15261800118 ns/op
BenchmarkQuickSort-12                  1         7552893791 ns/op
PASS
ok      pingcap/talentplan/tidb/mergesort       37.860s

We can see that merge sort is faster than sort.Slice，hand quick sort is faster than merge sort.

I also benchmark sort.Sort, found it is slower than sort.Slice

If so, Is it more meaningful to compare parallel merge sort to quick sort in hand, instead of sort.Slice?

The materials for the Rust course can be viewed as a static website.

I did the barest graphic design to accommodate all the features. Somebody with skills needs to make it look good.

There are two types of page on the site: text, rendered from markdown; and slides, rendered from markdown.

Everything is displayed by the same HTML file, index.html. Styles that are common to both types of pages are in style.css; those specific to text pages in text.css; and there is no stylesheet specific to slides yet.

I don't have any ideas for the design right now, though I prefer simple and readable.

The projects themselves do not attempt to explain how to write them, just what to write, along with hints, suggestions, and tradeoffs.

They are intended to be accompanied by lessons and also external "readings". The lessons are on hold for the first iteration of the course, which makes the readings essential.

One of the purposes of this project is to expose new Rust programmers to resources they might know about, so the best material is often going to be blog posts from experts. One of the per-requisites for the entire course is to read The Rust Book, so we can provide the most value by providing readings that are not from the book, often time blog posts by experts. In some cases though individual book chapters are worth linking to. For example, error handling is such a tricky topic that just reading the book's chapter on error handling is not enough - we might link it, but we would definitely link to other resources as well.

Read through the text, identify the problems being solved, find single-page resources that contain potential answers to those problems and add them to the project.

There's currently no section of the project's devoted to this, so add one.

Subtask of #84.

After you have written your own version of the project, then read the example project, including the test cases.

The example project needs to represent the very best of Rust coding practices. The test cases especially are the real "specification" for the project, and students will be reading them to figure out what exactly their own code is supposed to be doing. Test code is often written with less care than production code. That will not be the case in this project.

Considerations:

• Code should be idiomatic, but also straightforward. It shouldn't be unnecessarily clever.
• Public items should be documented, without simply repeating the item name. The crate should contain the attribute to deny undocumented items.
• Code should be rustfmted.

As with the text, each project's code needs to be consistent from project to project. Functions with identical specs should be implemented and formatted the same. They should be ordered in the same sequence.

For test cases, each project should contain the previous project's tests, in a consistent and sensible order.