My recent foray into writing and self-publishing a technical book showed me that teaching people what I've learned is what drives me forward. That's especially true for offering the audience a different perspective (like teaching Go developers how to make art with code).
Naturally, I started looking for a way to introduce the beauty of the Elixir language to another programming community. I want to do that by addressing well-known pain points and how they can get solved by Elixir and OTP. And while the language divide between Go and Elixir might be a little too wide for me to present a strong case, Python can be a great candidate because it was Python that prompted me to start searching for alternatives.
See, I still love the language and its ecosystem, but over the past few years, it has become an unmanageable blob of options and alternatives for doing the same things. And new PEPs (Python Enhancement Proposals) are coming all the time. For instance, you can't just use good old classes and objects; there are dicts (which pretty much everyone ends up using), named tuples, data classes, and lately, typed dicts. That is, excluding the myriad of third-party libraries that try to solve the problem of introspecting data in one way or another. The same applies to concurrency - one can choose between OS processes, OS threads (which are synchronized when it comes to CPU-bound ops), green threads, and as of a few years, async functions (which only work with IO that supports async). And yeah, structural pattern matching is probably coming too. It's all quite confusing.
And yet, Python lives on and moves forward. Its ecosystem is massive, offering libraries for solving pretty much any problem one can imagine. The language has deep ties to both the industry and academia. It also has the native interface, which, similar to the NIFs, has allowed Python developers to execute code at native speed since the beginning. Which, of course, was the reason that Python became the de-facto king of ML.
My motivation to write this book is two-fold. On the one side, it's the aspect of teaching Elixir/OTP by analogy. On the other, it's about revisiting stuff from Python, which I might have missed, and, in a way, rediscovering it again.
Do you think that the book will be worth reading? Drop me a line and let me know what you think. Your feedback is more than welcome.