Thu 06 May 2021

The Rustonomicon

The Rustonomicon digs into all the awful details that you need to understand when writing Unsafe Rust programs.

Should you wish a long and happy career of writing Rust programs, you should turn back now and forget you ever saw this book. It is not necessary. However if you intend to write unsafe code — or just want to dig into the guts of the language — this book contains lots of useful information.

Source: The Rustonomicon.

The quest for faster Python

Facebook has released Cinder, used internally in Instagram to improve Python performance, while another faster Python, called Pyston, has released version 2.2 and made the project open source (again).

Python is the world's second most popular programming language (after JavaScript) according to some surveys; but it is by no means the fastest. A glance at benchmarks tells us that Python 3 computation is often many times slower than compiled languages like C and Go, or JIT (Just-in-Time) compiled languages like Java and JavaScript.

One reason is that the official implementation of Python, called CPython, is an interpreted, dynamic language, and its creator Guido Van Rossum has resisted optimising it for performance, saying in 2014 that "Python is about having the simplest, dumbest compiler imaginable, and the official runtime semantics actively discourage cleverness in the compiler like parallelizing loops or turning recursion into loops."

Source: The quest for faster Python: Pyston returns to open source, Facebook releases Cinder, or should devs just use PyPy?, an article by Tim Anderson.

Making the Internet more secure one signed container at a time

With over 16 million pulls per month, Google’s distroless base images are widely used and depended on by large projects like Kubernetes and Istio. These minimal images don’t include common tools like shells or package managers, making their attack surface (and download size!) smaller than traditional base images such as ubuntu or alpine. Even with this additional protection, users could still fall prey to typosquatting attacks, or receive a malicious image if the distroless build process was compromised – making users vulnerable to accidentally using a malicious image instead of the actual distroless image. This problem isn’t unique to distroless images – until now, there just hasn’t been an easy way to verify that images are what they claim to be.

Source: Making the Internet more secure one signed container at a time, an article by Priya Wadhwa and Jake Sanders.