MASTER’S THESIS 2020 Transitioning from C to Rust in Media Streaming Development Samuel Johansson, Ludvig Rappe ISSN 1650-2884 LU-CS-EX: 2020-06 DEPARTMENT OF COMPUTER SCIENCE LTH j LUND UNIVERSITY EXAMENSARBETE Datavetenskap LU-CS-EX: 2020-06 Transitioning from C to Rust in Media Streaming Development Samuel Johansson, Ludvig Rappe Transitioning from C to Rust in Media Streaming Development (An Industrial Case Study) Samuel Johansson Ludvig Rappe [email protected] [email protected] February 25, 2020 Master’s thesis work carried out at Axis Communications AB. Supervisors: Elizabeth Bjarnason, [email protected] Jonathan Karlsson, [email protected] Srimanta Panda, [email protected] Examiner: Björn Regnell, [email protected] Abstract Rust uses static types, a strict compiler, and a unique ownership system, in order to make guarantees about memory safety without the use of a garbage col- lector and without sacricing performance. This paper presents a case study of evaluating a programming language tran- sition from C to Rust through the creation and usage of a Programming Language Transition Framework. We found the Programming Language Transition Framework to be a helpful tool for evaluating a programming language transition, but there is room for further improvements. We found Rust to provide a far superior developer experience, while still performing on par with C. However, Rust’s ownership system gives it a steep learning curve even for those with prior experience in programming. Given that the impact on performance is acceptable, and that build system integration can be done successfully, we deem it feasible to transition from C to Rust in this case. Keywords: Rust, C, Programming Language, Framework, Performance, Usability Acknowledgements First and foremost, we would like to thank Axis Communications AB for giving us the op- portunity and resources to conduct this Master’s Thesis. We would also like to thank our supervisors at Axis, Jonathan Karlsson and Srimanta Panda. They have provided us with invaluable help and feedback, mostly regarding Axis- specic tools and the build environment, but also concerning the report and the Program- ming Language Transition Framework. Last, but denitely not least, we would like to thank our supervisor at LTH, Elizabeth Bjarnason. She has helped us formalise the scope and methodology for this thesis and without her this thesis would not have been possible. In addition to this, she has also provided us with invaluable feedback regarding the report, how to conduct interviews, and much more. Contents 1 Introduction 1 1.1 Context . .1 1.2 Case description . .2 1.3 Purpose . .2 1.3.1 Research questions . .2 1.3.2 Approach . .3 1.4 The four levels aected by a programming language transition . .3 1.4.1 Execution level . .3 1.4.2 Programmer level . .3 1.4.3 Toolchain level . .3 1.4.4 Management level . .3 1.5 The Rust programming language . .4 1.5.1 Language features . .4 1.5.2 Cargo . .7 1.6 Contributions . .7 2 Related Work 9 2.1 Overview . .9 2.2 Impact on Execution level . 10 2.3 Impact on Programmer level . 11 2.4 Impact on Toolchain level . 12 2.5 Impact on Management level . 13 3 Research Method 15 3.1 Overview . 15 3.2 Literature study . 16 3.3 Programming Language Transition Framework . 16 3.4 Interviews . 17 3.5 Programming in Rust . 18 3.6 Focus Group . 19 CONTENTS 4 Programming Language Transition Framework (PLTF) 21 4.1 Factors . 21 4.1.1 Execution level . 21 4.1.2 Programmer level . 24 4.1.3 Toolchain level . 25 4.1.4 Management level . 27 4.2 Usage . 28 5 Results 29 5.1 Execution level . 29 5.1.1 Evaluation of performance . 29 5.1.2 Performance requirements . 37 5.1.3 Focus group insights . 38 5.2 Programmer level . 39 5.2.1 Evaluation of programming in Rust . 39 5.2.2 Developer perspective on programming languages . 46 5.2.3 Focus group insights . 49 5.3 Toolchain level . 49 5.3.1 Evaluation of Rust tools . 49 5.3.2 Common tools among developers . 50 5.3.3 Focus group insights . 51 5.4 Management level . 52 5.4.1 Evaluation of Rust’s impact on software projects . 52 5.4.2 The current impact on software projects . 54 5.4.3 Focus group insights . 56 6 Discussion 57 6.1 How to evaluate a transition from C to Rust (RQ1) . 57 6.1.1 Execution level . 58 6.1.2 Programmer level . 58 6.1.3 Toolchain level . 59 6.1.4 Management level . 59 6.2 Consequences of transitioning from C to Rust (RQ2) . 60 6.2.1 Execution level . 60 6.2.2 Programmer level . 61 6.2.3 Toolchain level . 63 6.2.4 Management level . 64 6.3 Challenges of transitioning from C to Rust (RQ3) . 65 6.3.1 Execution level . 65 6.3.2 Programmer level . 65 6.3.3 Toolchain level . 65 6.3.4 Management level . 66 6.4 Threats to validity . 66 6.4.1 Construct validity . 66 6.4.2 External validity . 66 6.4.3 Reliability . 67 CONTENTS 7 Conclusions 69 7.1 Summary . 69 7.2 Future research . 70 Bibliography 73 Appendix A Interview Guide 79 Appendix B Focus Group Guide 83 Appendix C Summary of the nal Programming Language Transition Framework 85 CONTENTS List of Figures 1.1 Hello, world! in Rust[37]. .4 3.1 An overview of the case study. 16 5.1 The execution times for the C and Rust version of the element, for dierent input sets. The execution times for each input set are the average of 100 runs. O and X mark the average execution time for C and Rust, respectively. 31 5.2 The execution times for the C and Rust version of an element written by the developers behind the framework, for dierent input sets. The execution times for each input set are the average of 100 runs. O and X mark the average execution time for C and Rust, respectively. 32 5.3 The latencies for the C and Rust version of the element for dierent input sets. The latencies for each input set are the average of 1000 runs. O and X mark the average latency for C and Rust, respectively. 33 5.4 The latencies for the C and Rust version of an element written by the devel- opers behind the framework, for dierent input sets. The execution times for each input set are the average of 1000 runs. O and X mark the average latency for C and Rust, respectively. 34 5.5 The maximum memory usage (maximum resident set size) for the C and Rust version of the element for dierent input sets. The memory usage for each input set is the average of 100 runs. The average maximum memory usage of each version has been rounded to the nearest integer. O and X mark the average memory usage for C and Rust, respectively. 35 5.6 The maximum memory usage (maximum resident set size) for the C and Rust version of an element written by the developers of the framework, for dierent input sets. The memory usage for each input set is the average of 100 runs. The average maximum memory usage of each version has been rounded to the nearest integer. O and X mark the average memory usage for C and Rust, respectively. 36 5.7 Attempting to mutably borrow two elds from a struct that is protected by a mutex. This code does not compile (see error message in Figure 5.8). 40 LIST OF FIGURES 5.8 The error message that is produced when attempting to compile the code in Figure 5.7. 41 5.9 A working version of the code in Figure 5.7. 41 5.10 The output from rustc when compiling a program containing a function that tries to return an integer value despite being declared to not return anything. 43 5.11 The output from GCC when compiling a program containing a function that tries to return an integer value despite being declared to not return anything. 43 List of Tables 4.1 A summary of the factors in the PLTF. 22 5.1 An overview of which methods yielded results for the dierent factors. 30 C.1 A summary of the factors in the Programming Language Transition Frame- work, including changes suggested by the focus group. The changes are in italic. 86 LIST OF TABLES List of Acronyms API Application Programming Interface PLTF Programming Language Transition Framework IDE Integrated Development Environment OSS Open Source Software RAII Resource Acquisition Is Initialisation LIST OF TABLES Chapter 1 Introduction Today, there exist more programming languages than you can shake a stick at, and their number continues to rise. Choosing which languages to use can be a dicult task, as dierent languages oer dierent features. That task is also made more dicult due to the fact that one language is seldom strictly better than another. Instead, languages are often better in some areas and worse in others. After having used a certain programming language for some time, a new language could be released that may be better suited for your application. How do you determine whether or not you should transition to this new language? In this chapter we present the context of the thesis, and briey describe Axis Communi- cations AB and its Streaming department. In addition, this chapter also gives a short intro- duction to the.