Experiments in managing perfectionism

Python

I've been spending a fair bit of time learning new programming languages recently, and I'm quite happy to have the progression be Python to Go to Rust. When learning something new, your motivation gets a boost when you can do lots of things and do it fast. From this perspective, it's hard to beat an interpreted language like Python.

Python is the main language at my previous role, and this choice makes sense given how key ML models were to the business model. Having the data science and engineering share the same language helped reduce maintenance and tooling overheads, as well as provide better context in handoffs.

The drawbacks were speed and lack of types. For speed, we had bindings to C++ on the hot path - the need for speed in an auction setting is clear. For types, we gradually introduced type comments with mypy. Why types? It's easy to introduce bugs when refactoring a codebase with limited guard rails; types are like tests that you get for free.

Go

I had the chance to learn a bit of Go just before RC, motivated partly because it's the main language for Bradfield's CS Intensive course. I was pleasantly surprised to find a lot of tooling we used for Python comes built-in in Go (brief discussion here). Go also has first class support for concurrency; the language is a popular choice for servers given the need to support multiple clients simultaneously. The syntax was surprisingly easy to pick up coming from Python.

Rust

I wanted to know more about the front end at RC, but curiously got into WebAssembly in the first week. I then found out from Tom how Rust has the best from-scratch support for compiling to WebAssembly. Another reason Rust works better is the smaller runtime - the smallest achievable binary size uncompressed from Go is ~2 MB vs ~2 KB for Rust. I'm not as familiar with the finer details, perhaps a sizeable part of that can be attributed to garbage collection in Go.

In summary, Python for fast prototyping and 'glue code', Go for concurrency and Rust for the low level stuff. Next comes lots and lots of practice.

Content: Disruptive innovation

If you've come across the theory of disruptive innovation, Jill Lepore offers an interesting and persuasive take in the New Yorker.

https://www.newyorker.com/magazine/2014/06/23/the-disruption-machine

Love how there's a reference to HBO's Silicon Valley.

It's September 1, let's try something different. Problem - I'm usually wiped out at the end of the day to be articulate (or at least, articulate as I'd like to be). Solution - write notes throughout the day on what I plan to write about.

As an aside, my blog posts are paying off already - I referred to a previous post on the simplest way to compile Rust to WebAssembly, instead of my notes.

WebAssembly

I know. I've been going on about WebAssembly for a while now. Part of it is accountability. It's an incentive for me to learn something I keep going on about to avoid embarrassment. I do believe the responsiveness that WebAssembly provides would accelerate the shift of native apps to be run in the browser. Yesterday I realized it could be even more groundbreaking.

Sara shared what's she's reading on her blog, it's a fantastic list. The post by Andreas Rossberg on Motoko had a link to a comprehensive discussion of WebAssembly in the Communications to the ACM (direct link here), as well as the following quote.

Wasm’s main difference compared to other virtual machines is that it is not optimized for any specific programming language but merely abstracts the underlying hardware, with a byte code directly corresponding to the instructions and memory model of modern CPUs. On top of that, Wasm supports sandboxing through strong modularity and a rigid mathematical specification that ensures that execution is safe, free of undefined behaviour, and (almost) entirely deterministic. Moreover, these properties actually have a machine-verified mathematical proof!

This is in addition to Solomon Hykes, the CTO of Docker, tweeting how had WebAssembly existed in 2008, there would have been no need for Docker. Now I'm puzzled. Why isn't there more hype?

What I can say is the learning resources seem sparse. Perhaps due to things changing quickly. I had been trying to tweak a number of Hello World examples without much success, along the way discovering the myriad of tools available. I gave up and decided to work on the Programming WebAssembly with Rust book instead. The book uses wasm-bindgen for Rust-JavaScript interoperability, but it's not immediately clear how using wasm-pack in addition would help.

I've decided I'm going to come up with my own resources. Watch this space.

The advantage of going through a book is comprehensiveness. In the book I found the answer to a previous question posed - why do you need a web server to run WebAssembly? It turns out cross-scripting rules in the browser blocks reads to the file system.

Re: portability, when I compile Rust on my laptop, the base target is stable-x86_64-apple-darwin, i.e. version-processor-OS. For WebAssembly, it's wasm32-unknown-unknown, i.e. it's designed to be compile once, run everywhere!

Java

Last week I briefly mentioned portability of C, let's complete that thread. C binaries would only work for a specific OS, so C when compiled for Linux would not work on Windows. Java, however, is compiled to Java bytecode that would run on any Java VM by design. Thus Java achieves portability across operating systems, which extends to all JVM-based languages - Clojure, Groovy, Kotlin, Scala. It's the original compile once, run everywhere.

Content: Python interpreters

Coming across RustPython made me look up Allison Kaptur's post on 500 lines or less: A Python interpreter written in Python.

http://www.aosabook.org/en/500L/a-python-interpreter-written-in-python.html

I then discovered this is something she worked on while at RC!

WebAssembly

Following up on the 'watch this space' declaration in last week's post, I created a Github repo on minimal examples to compile and run WebAssembly. It's designed to help consider different options - whether it be Rust or .wat as a starting point, whether to run in the browser or with an independent runtime, whether to extend with Rust-JavaScript interoperability or even go full stack Rust.

In summary, a starting point to those new to WebAssembly to construct a mental model and build on top of.

Learning WebAssembly, I've gone down the path of reading up more on how the browser works. I had actually mentioned wanting to review this in my first week of RC. This time, however, feels a lot more engaging. There's a lot more concepts to make connections with. Most importantly it feels more fun this way; it's not something looked into simply to solve a problem.

Python

Vinayak recommended a PyCon talk by Russell Keith-Magee at our coffee chat last week. I had the chance to watch this talk over the weekend. The talk was illuminating.

First, in thinking about the future of Python, one needs to think about black swan events. A black swan event is an event that is a surprise to the observer with a major effect on the world, but can be easily in explained in hindsight. This being the case, the best way to avoid being on the wrong side of a black swan event is to actively challenge one's own assumptions. The example he used was America's Cup; adhering to this principle has injected innovation into the sailing competition, breathing new life and excitement for many years to come.

Next was the framing of WebAssembly as Python's (or for that matter, all programming language's) black swan. WebAssembly started life as a research project to identify the set of primitive JavaScript operations that will execute in modern browser engines. The result of this work is the ability to run languages other than JavaScript in the browser, and do so in a fast and secure way. He's essentially throwing down the gauntlet, galvanizing the community to embrace this new paradigm instead of simply continuing to do what Python is good at. In this regard, perhaps be more like... the Rust community?

The final point that hit home was Keith-Magee's experience of burnout as a maintainer in the open source community. It's very disheartening to hear some members he had to deal with, who receive a product at no cost but somehow feel a strong sense of entitlement. I felt a renewed sense of appreciation for the open source community, and a continued desire to contribute.

It turned out the talk Vinayak recommended was the talk at PyCon AU 2019! This was also very good, and is more practical re: Python and WebAssembly. The talk covers a bit of history of WebAssembly, tools to help compile Python to WebAssembly, and the future for Python on the web. In a previous post I described how WebAssembly reminded me of Java, it's curious hearing Keith-Magee describe how "wasm has delivered on the promise Java made".

OK one last note about previous posts - I mentioned how some open source projects may need a bit of hand holding. Keith-Magee's current project is called BeeWare and has a spectacular first-time contributors page.

Content: Climbing to the top

OK. Today I'm not just overloading with previous posts but also with content. Things are slowly coming together. I'm reminded of Rainer Maria Rilke in Letters to a Young Poet.

I would like to beg you dear Sir, as well as I can, to have patience with everything unresolved in your heart and try to love the questions themselves as if they were locked rooms or books written in a very foreign language. Don’t search for the answers, which could not be given to you now, because you would not be able to live them. And the point is to live everything. Live the questions now. Perhaps then, someday far in the future, you will gradually, without even noticing it, live your way into the answer.

I'm reminded of Steve Job's Stanford commencement speech on how you can't connect the dots moving forward, you can only connect them looking backwards, so you have to trust that the dots will somehow connect in the future.

That being said, I've only just gotten started. I'm reminded of Terence Tao who, despite all his achievements, speaks modestly of the journey still to come.

https://www.latimes.com/local/lanow/la-me-ln-ucla-math-prize-20140626-story.html

You want to get to the top of the cliff. But that’s not what you focus on immediately. You focus on the next ledge just beyond your reach, because you need to do one clever thing to get up there. And then once you get there, you do it again. A lot of this is rather boring and not very glamorous. But you can’t jump cliffs in a single bound.

Python

I've been a little distracted today, moving between browsers, V8 and JIT. Given the success of JIT, I'm a little surprised it's not more widely adopted by other languages, or perhaps, I just haven't noticed it before.

I also switched back to Python after time spent learning Go and Rust, in light of algorithm interview prep in the coming weeks. It took me a bit of time to adjust, but it felt liberating once I got started. It's like speaking a language without having to search for the words, allowing you to focus on the conversation itself.

Content: Grow the puzzle around you

I know I'm not in the Bay Area anymore when I have to explain what Y Combinator is. YC is a three-month startup school where founders receive coaching on how to refine their product and sell their ideas to investors. Its head-turning record of success has inspired hundreds of other accelerators worldwide, keen to replicate YC's investment and training philosophy (source: The Economist).

You are a jigsaw puzzle piece of a certain shape. You could change your shape to fit an existing hole in the world. That was the traditional plan. But there’s another way that can often be better for you and for the world: to grow a new puzzle around you. That’s what I did, and I was a pretty weird-shaped piece. So if I can do it, there’s more hope for you than you probably realize.