![\"Python,](\"https:\/\/www.nicolas-hahn.com\/images\/program-in-python-go-rust\/python-go-rust.png\")
<\/p>\n<\/p>\n
Update (2019-07-04):<\/strong>\u00a0Some kind folks have suggested changes on the implementations to make them more idiomatic, so the code here may differ from what\u2019s currently in the repos.<\/p>\n This is a subjective, primarily developer-ergonomics-based comparison of the three languages from the perspective of a Python developer, but you can skip the prose and go to\u00a0the code samples<\/a>,\u00a0the performance comparison<\/a>\u00a0if you want some hard numbers,\u00a0the takeaway<\/a>\u00a0for the tl;dr, or the\u00a0Python<\/a>,\u00a0Go<\/a>, and\u00a0Rust<\/a>\u00a0 A few years ago, I was tasked with rewriting an image processing service. To tell whether my new service was creating the same output as the old given an image and one or more transforms (resize, make a circular crop, change formats, etc.), I had to inspect the images myself. Clearly I needed to automate this, but I could find no existing Python library that simply told me how different two images were on a per-pixel basis. Hence\u00a0diffimg<\/a>, which can give you a difference ratio\/percentage, or generate a diff image (check out the readme to see an example).<\/p>\n The initial implementation was in Python (the language I\u2019m most comfortable in), with the heavy lifting done by\u00a0Pillow<\/a>. It\u2019s usable as a library or a command line tool. The actual\u00a0meat<\/a>of the program is very small, only a few dozen lines, thanks to Pillow. Not a lot of effort went into building this tool (xkcd was right<\/a>, there\u2019s a Python module for nearly everything), but it\u2019s at least been useful for a few dozen people other than myself.<\/p>\n A few months ago, I joined a company that had several services written in Go, and I needed to get up to speed quickly on the language. Writing\u00a0diffimg-go<\/a>\u00a0seemed like an fun and possibly even useful way to do this. Here are a few points of interest that came out of the experience, along with some that came up while using it at work:<\/p>\n (Again, the code:\u00a0diffimg<\/a>\u00a0(python) and\u00a0diffimg-go<\/a>)<\/p>\n My initial impression of Go is that because its ability to abstract is (purposely) limited, it\u2019s not as\u00a0fun<\/em>\u00a0a language as Python is. Python has more features and thus more ways of doing something, and it can be a lot of fun to find the fastest, most readable, or \u201ccleverest\u201d solution. Go actively tries to stop you from being \u201cclever.\u201d I would go as far as saying that Go\u2019s strength is that it\u2019s\u00a0not<\/em>\u00a0clever.<\/p>\n Its minimalism and lack of freedom are constraining as a single developer just trying to materialize an idea. However, this weakness becomes its strength when the project scales to dozens or hundreds of developers – because everyone\u2019s working with the same small toolset of language features, it\u2019s more likely to be uniform and thus understandable by others. It\u2019s still very possible to write bad Go, but it\u2019s more difficult to create monstrosities that more \u201cpowerful\u201d languages will let you produce.<\/p>\n After using it for a while, it makes sense to me why a company like Google would want a language like this. New engineers are being introduced to enormous codebases constantly, and in a messier\/more powerful language and under the pressure of deadlines, complexity could be introduced faster than it can be removed. The best way to prevent that is with a language that has less capacity for it.<\/p>\n With that said, I\u2019m happy to work on a Go codebase in the context of a large application with a diverse and ever-growing team. In fact, I think I\u2019d prefer it. I just have no desire to use it for my own personal projects.<\/p>\n A few weeks ago, I decided to give an honest go at learning Rust. I had attempted to do so before but found the type system and borrow checker confusing and without enough context for why all these constraints were being forced on me, cumbersome for the tasks I was trying to do. However, since then, I\u2019ve learned a bit more about what happens with memory during the execution of a program. I also started with\u00a0the book<\/a>\u00a0instead of just attempting to dive in headfirst. This was massively helpful, and probably the best introduction to any programming language I\u2019ve ever experienced.<\/p>\n After I had gone through the first dozen or so chapters of the book, I felt confident enough to try another implementation of\u00a0 Some of the things that I took notice of when writing\u00a0diffimg-rs<\/a>:<\/p>\n I definitely wouldn\u2019t recommend attempting to write Rust without at least going through the first few chapters of the book, even if you\u2019re already familiar with C and memory management. With Go and Python, as long as you have some experience with another modern imperative programming language, they\u2019re not difficult to just start writing, referring to the docs when necessary. Rust is a large language. Python also has a lot of features, but they\u2019re mostly opt-in. You can get a lot done just by understanding a few primitive data structures and some builtin functions. With Rust, you really need to understand the complexity inherent to the type system and borrow checker, or you\u2019re going to be getting tangled up a lot.<\/p>\n As far as how I feel when I write Rust, it\u2019s a lot of fun, like Python. Its breadth of features makes it very expressive. While the compiler stops you a lot, it\u2019s also very helpful, and its suggestions on how to solve your borrowing\/typing problems usually work. The tooling as I\u2019ve mentioned is the best I\u2019ve encountered for any language and doesn\u2019t bring me a lot of headaches like some other languages I\u2019ve used. I really like using the language and will continue to look for opportunities to do so, where the performance of Python isn\u2019t good enough.<\/p>\n I\u2019ve extracted the chunks of each\u00a0 Python<\/strong>:<\/p>\n For Go and Rust, the method is a little different: Instead of creating a diff image, we just loop over both input images and keep a running sum of the differences of each pixel. In Go, we\u2019re indexing into each image by coordinate\u2026<\/p>\n Go<\/strong>:<\/p>\n
\ndiffimg<\/code>\u00a0implementations.<\/em><\/p>\nComparing Python and Go<\/h2>\n
\n
diffimg-go<\/code>\u00a0implementation has none, where the Python implementation uses the fairly heavy third party module (ironically) named Pillow. Go\u2019s standard library in general is more structured and well thought out, while Python\u2019s is organically evolved, created by many authors over years, with many differing conventions. The Go standard library\u2019s consistency makes it easier to predict how any given module will function, and the source code is extremely well documented.\n\n
diffimg-go<\/code>\u00a0implementation therefore requires the user to indicate whether or not they want to use the alpha channel. This small inconvenience wasn\u2019t worth finding a third party library to fix.<\/li>\n\n
\n
kwarg<\/code>\u00a0of any type onto whatever function needs it without having to rewrite every one of its calls. I use this feature quite often in at work, it\u2019s saved me a lot of time over the years. Not having the feature made my implementation for how to handle whether or not the diff image should be created based on the command line flags somewhat clumsy.<\/li>\nvalue, error<\/code>\u00a0from functions wherever something may go wrong. Python lets you catch errors at any point in the call stack as opposed to requiring you to manually pass them back up over and over again. This again results in brevity and code that isn\u2019t littered with Go\u2019s infamous\u00a0if err != nil<\/code>\u00a0pattern, though you do need to be aware of what possible exceptions can be thrown by a function and all(!) of its internal calls (using\u00a0except Exception:<\/code>\u00a0is a usually-bad-practice workaround for this). Good docstrings and tests can help here, which you should be writing in either language. Go\u2019s system is definitely safer. You\u2019re still allowed to shoot yourself in the foot by ignoring the\u00a0err<\/code>\u00a0value, but the system makes it obvious that this is a bad idea.<\/li>\n$GOPATH\/src<\/code>\u00a0instead of the project\u2019s directory (like most other languages). The path for these modules inside\u00a0$GOPATH<\/code>\u00a0would also be built from the URL where the package is hosted, so your import would look something like\u00a0import \"github.com\/someuser\/somepackage\"<\/code>. Embedding\u00a0github.com<\/code>inside the source code of almost all Go codebases seems like a strange choice. In any case, Go now allows the conventional way of doing things, but Go modules are still new so this quirk will remain common in wild Go code for some time.<\/li>\nasync\/await<\/code>, Python\u2019s asynchronous solutions were somewhat hairy. Unfortunately I haven\u2019t written much real-world async code in Python or Go, and the simplicity of\u00a0diffimg<\/code>\u00a0didn\u2019t seem to lend itself to the added overhead of asynchronicity, so I don\u2019t have too much to say here, though I do like Go\u2019s\u00a0channels<\/a>\u00a0as a way to handle multiple async tasks. My understanding is that for performance, Go still has the upper hand here as goroutines can make use of full multiprocessor parallelism, where Python\u2019s basic\u00a0async\/await<\/code>\u00a0is still stuck on one processor, so mainly useful for I\/O bound tasks.<\/li>\npdb<\/code>\u00a0(and more sophisticated options like\u00a0ipdb<\/a>\u00a0are available) is extremely flexible, once you\u2019ve entered the REPL, you\u2019re able to write whatever code you want.\u00a0Delve<\/a>\u00a0is a good debugger, but it\u2019s not the same as dropping straight into an interpreter, the full power of the language at your fingertips.<\/li>\n<\/ul>\nGo Summary<\/h3>\n
Enter Rust<\/h2>\n
diffimg<\/code>\u00a0(at this point, I had about as much experience with Rust as I\u2019d had with Go when I wrote\u00a0diffimg-go<\/code>). It took me a bit longer to write than the Go implementation, which itself took longer than Python. I think this would be true even taking into account my greater comfort with Python – there\u2019s just more to write in both languages.<\/p>\n\n
\n
\n\nlet<\/span> mut<\/span> diff<\/span> =<\/span> match<\/span> image1<\/span>.color<\/span>()<\/span> {<\/span>\r\n image<\/span>::<\/span>ColorType<\/span>::<\/span>RGB<\/span>(<\/span>_<\/span>)<\/span> =><\/span> image<\/span>::<\/span>DynamicImage<\/span>::<\/span>new_rgb8<\/span>(<\/span>w<\/span>,<\/span> h<\/span>),<\/span>\r\n image<\/span>::<\/span>ColorType<\/span>::<\/span>RGBA<\/span>(<\/span>_<\/span>)<\/span> =><\/span> image<\/span>::<\/span>DynamicImage<\/span>::<\/span>new_rgba8<\/span>(<\/span>w<\/span>,<\/span> h<\/span>),<\/span>\r\n \/\/ keep going for all 7 types?<\/span>\r\n _<\/span> =><\/span> return<\/span> Err<\/span>(<\/span>\r\n format!<\/span>(<\/span>\"color mode {:?} not yet supported\"<\/span>,<\/span> image1<\/span>.color<\/span>())<\/span>\r\n ),<\/span>\r\n};<\/span>\r\n<\/code><\/pre>\n<\/div>\n<\/div>\n<\/li>\n<\/ul>\n<\/li>\n\n
Result<\/code>returns either\u00a0Ok(value)<\/code>\u00a0or\u00a0Err(error)<\/code>. This is closer to Go\u2019s way if you squint, but is a bit more explicit and leverages the type system. There\u2019s also syntactic sugar for checking a statement for an\u00a0Err<\/code>\u00a0and returning early:\u00a0the\u00a0?<\/code>\u00a0operator<\/a>\u00a0(Go could use something like this, IMO).<\/li>\nrustup<\/code>\u00a0and\u00a0cargo<\/code>\u00a0are extremely polished implementations of a language version manager and package\/module manager, respectively. Everything \u201cjust works.\u201d I especially love the autogenerated docs. The Python options for these are somewhat organic and finicky, and as I mentioned before, Go has a strange way of managing modules, though aside from that, its tooling is in a much better state than Python\u2019s.<\/li>\n.vimrc<\/code>\u00a0is embarrassingly large, with at least three dozen plugins. I have some plugins for linting, autocompleting, and formatting both Python and Go, but the Rust plugins were easier to set up, more helpful, and more consistent compared to the other two languages. The\u00a0rust.vim<\/a>\u00a0and\u00a0vim-lsp<\/a>\u00a0plugins (along with\u00a0the Rust Language Server<\/a>) were all I needed to get an extremely powerful configuration. I haven\u2019t tested out other editors with Rust but with the excellent editor-agnostic tooling that Rust comes with, I\u2019d expect them to be just as helpful. The setup provides the best go-to-definition I\u2019ve ever used. It works perfectly on local, standard library, and third-party code out of the box.<\/li>\nprintln!<\/code>\u00a0take you pretty far), but you can use\u00a0rust-gdb<\/code>\u00a0and\u00a0rust-lldb<\/code>, wrappers around the\u00a0gdb<\/code>\u00a0and\u00a0lldb<\/code>\u00a0debuggers that are installed with the initial\u00a0rustup<\/code>. The experience should be predictable if you\u2019ve used those debuggers before with C. As mentioned previously, the compiler error messages are extremely helpful.<\/li>\n<\/ul>\nRust Summary<\/h3>\n
Code Samples<\/a><\/h2>\n
diffimg<\/code>\u00a0which calculate the difference ratio. To summarize how it works for Python, this takes the diff image generated by Pillow, sums the values of all channels of all pixels, and returns the ratio produced by dividing the maximum possible value (a pure white image of the same size) by this sum.<\/p>\n\n\n\r\ndiff_img<\/span> =<\/span> ImageChops<\/span>.<\/span>difference<\/span>(<\/span>im1<\/span>,<\/span> im2<\/span>)<\/span>\r\nstat<\/span> =<\/span> ImageStat<\/span>.<\/span>Stat<\/span>(<\/span>diff_img<\/span>)<\/span>\r\nsum_channel_values<\/span> =<\/span> sum<\/span>(<\/span>stat<\/span>.<\/span>mean<\/span>)<\/span>\r\nmax_all_channels<\/span> =<\/span> len<\/span>(<\/span>stat<\/span>.<\/span>mean<\/span>)<\/span> *<\/span> 255<\/span>\r\ndiff_ratio<\/span> =<\/span> sum_channel_values<\/span> \/<\/span> max_all_channels<\/span>\r\n\r\n<\/code><\/pre>\n<\/div>\n<\/div>\n\n\n\r\nfunc<\/span> GetRatio<\/span>(<\/span>im1<\/span>,<\/span> im2<\/span> image<\/span>.<\/span>Image<\/span>,<\/span> ignoreAlpha<\/span> bool<\/span>)<\/span> float64<\/span> {<\/span>\r\n var<\/span> sum<\/span>