[OSD600 Series] Collaborating on projects


Rust is not as common as other languages like JavaScript and TypeScript, so it was a bit harder to find a partner who was willing to do a code review with me. Eventually, Antonio, who was also interested in learning Rust, contacted me and we started collaborating.

Testing & Code Reviews

Reading someone else code when I just learned the language was both eye-opening and confusing at the same time. There were syntax or language mechanics that Antonio knew but I didn't, and vice versa. It was also nice to see a different approach to the same problem.

I was impressed that Antonio write the logic for parsing CLI's arguments from scratch. I was trying to do that at first, but there was so many edge cases so I was discouraged and just used an existing crate instead.

There were some issues with Antonio's program:

  • The program allow empty value for --input, and created an empty dist #1

  • Code should be separated into modules for readability #2

  • When passing a file as --input, the program exited #3

Antonio also found some bugs on my program:

  • Handled error should exit with code 0 #15

  • dist is generated in the current directory of running the command #14

  • The program crashed when not running from the root directory #13


I wasn't able to fix issue #14 due to the lack of means to get the path to root crate in Rust. From what I have researched, after the program is compiled, Rust does not aware of the file system anymore, so there is no tale where the root of the cwd is.


Testing the code on my own is never enough. Getting my code tested from a different run-time environment and perspective exposes more bugs and potential improvement.

Additional Resources

Read how the SSG paper is built.