@@ -14,7 +14,7 @@ NOTE: We're interested in the 'HOW' and the 'WHY/WHY NOT' in the report.
...
@@ -14,7 +14,7 @@ NOTE: We're interested in the 'HOW' and the 'WHY/WHY NOT' in the report.
### 1.1 Strengths and weaknesses of Rust
### 1.1 Strengths and weaknesses of Rust
#### Strengths
#### 1.1.1 Strengths
- Catches errors at compile-time:
- Catches errors at compile-time:
* Type errors
* Type errors
* Memory leak errors
* Memory leak errors
...
@@ -28,7 +28,7 @@ NOTE: We're interested in the 'HOW' and the 'WHY/WHY NOT' in the report.
...
@@ -28,7 +28,7 @@ NOTE: We're interested in the 'HOW' and the 'WHY/WHY NOT' in the report.
- Strong documentation - I am thinking about you Rust Book - https://doc.rust-lang.org/book/
- Strong documentation - I am thinking about you Rust Book - https://doc.rust-lang.org/book/
#### Weaknesses
#### 1.1.2 Weaknesses
- Slow compilation time. 3-4 seconds for debug-build, on a 1000 LOC project. This is a weakness because it slows down iteration-speed.
- Slow compilation time. 3-4 seconds for debug-build, on a 1000 LOC project. This is a weakness because it slows down iteration-speed.
- Verbose syntax - If a developer is used to a higher-level interpreted language the Rust syntax may be annyoingly verbose. This may scare developers away from Rust.
- Verbose syntax - If a developer is used to a higher-level interpreted language the Rust syntax may be annyoingly verbose. This may scare developers away from Rust.
...
@@ -38,22 +38,36 @@ NOTE: We're interested in the 'HOW' and the 'WHY/WHY NOT' in the report.
...
@@ -38,22 +38,36 @@ NOTE: We're interested in the 'HOW' and the 'WHY/WHY NOT' in the report.
- Discord
- Discord
- Google hangouts
- Google hangouts
- MSTeams
- MSTeams
- Issues
- Email
### 1.3 Use of version control systems, ticket tracking, branching, tagging/versioning
### 1.3 Use of version control systems, ticket tracking, branching, tagging/versioning
- Git version control
- Github Issue tracking and Project Board
- Github Branching
### 1.4 Programming style guide including how to comment code
### 1.4 Programming style guide including how to comment code
- Programmers writing in Rust should ideally follow the Rust official style guide found here - https://doc.rust-lang.org/1.0.0/style/style/README.html
- The Rust compiler is more oppinionated about style, than most compilers, and will give warnings for many things.
- We did not use any automated enforcement of the Rust official style, but there may be a tool for this. @TODO Check if there is a tool.
### 1.5 Use of and integration of libraries, modules, and other ways for modularisation of your product
### 1.5 Use of and integration of libraries, modules, and other ways for modularisation of your product
One of the goals of the project, was to re-use as much as possible of existing code. This was the main reason Rust was chosen in the first place. The SSI community are already heavily invested into Rust, for many of the same reasons mentioned in section 1.1.1.
### 1.6 Professionalism in your approach to software development
### 1.7 Use of code review
### 1.6 Professionalism in your approach to software development
- Lean development - Work on as few tickets at the same time as possible.
- Remove dead code - Clean up code that is no longer use. Do not write code that is not in use from day 1.
### 1.7 Use of code review
- Pull Requests in Github is at the center of the code review process. Ideally there should be one pull request attached to every branch.
- When the pull request has received a code review, it could either be approved or receive a change-request.
- Once code review is approved, the pull request is merged, closed, the branch gets deleted, and the attached issue-ticket gets a status change from "In-review" to "Done"
