The Rust Programming Language and the Advent of Code 2018

I recently got reminded about AdventOfCode2018. Be sure to check it out before end of december. Till now i did the challenges in rust, perl, bash - no specific language - just depending on the time i have. If you have plenty of time, the challenges from the last years are still available.

Additionally i was looking a little into the programming language rust. The rust package manager cargo feels well designed. Also the language solves quite common issues in programming which makes classic inheritance unnecessary. The tutorial is easy to read and understand but in advanced topics you can see that things still change. The verbose annotation of object lifetime of references was reduced in recent releases and things that should not compile now finally do without issues. The basic data types quite bring everything you need out of the box, except some language features like drain_filter, quite similar to std::remove_if, are only available as unstable features. Therefore I would not recommend using the language in production, but i can already see its potential in the future. Memory related problems are reduced to ownership problems. It must be clear who is allowed to borrow a variable (keeping a reference) for later writing or read only operations. You can not have two writable references, nor have references that outlive the instance. This might cause a lot of confusion and iterations of code if you try to write code in your usual style. The ownership problem looks even worse when trying to communicate between threads. When a thread stops can be decided at runtime, either it is joined or it could be detached and even outlive the main thread. Therefore the classic thread’s lifetime is considered 'static. Solutions, for having threads with a defined lifetime existed: like std::thread::scoped, but it had unforseen issues, related to accessing freed memory. To solve the issue, the library crossbeam provides a different approach to threads with a clearly defined lifetime. Still sharing objects as readable between threads is a challenge. One solution to the object being shared across threads could be by using std::sync::Arc<std::sync::Mutex<Foo>>. An Arc is for atomically accessing things from different threads, while the mutex is required to clearly define who is writing the memory. Otherwise for TcpStreams the handles can simply be cloned (see try_clone) without being in need of using a mutex object.

After reading this article you sure feel the complexity of that quite new programming language rust. But even if the language might not be ready for production, I recommend having at least a first look through the entire tutorial or even to learn it. The concepts might be different, but if you do you will be prepared for the future that is likely to come.