[Coding] Python vs. Go – a Sudoku Solver

Posted by Khatharsis on October 27, 2019

Work has not so subtly hinted that the developers learn Go. To get familiar with the rather odd syntax (e.g., declaring the type after a variable name, or square brackets followed by the type for an array) and to have something in place for migrating customers from an older version of software, I wrote a script in Go to read through XML and reformat properties of interest into JSON. Not bad. Then I found an article explaining a Sudoku solver written in Python and I figured why not, let’s implement it in Go. Bad idea.

If I had time to draw up a cartoon, it would be the literal image of a python choking out a gopher. Despite my dislike of Python’s syntax being entirely reliant on the correct number of spaces for indentation-scope, there are a lot of libraries and even native types that make things simple. For example, sets. It’s built-in to the language. I don’t have to hunt down a package. I just use it. I’m not fighting the language to implement an idea.

Go, on the other hand, had me tearing my hair out in frustration. Aside from my beginner’s knowledge of Python and working out fancy shorthands (e.g., [a+b for a in A for b in B] for nested for-loops), I got stumped when the Python code started using sets. I attempted to pull in a Go package for a Set, but the documentation was not comprehensive enough to help understand how to use it. Needless to say, the 83-line solution in Python had blown up to 153 lines in Go and I was only half way there. Without figuring out how to use sets.

Yes, use the correct tool for the job. I thought it would be fun, given I enjoy doing Sudoku here and there and even thought about writing a solver a few years ago, and the added benefit of learning more of Go at the same time. But it was not to be.

I watched a course on Pluralsight on concurrency in Go. Channels and goroutines? Color me dizzy. But perhaps I can write up another parsing engine utilizing those two features for the hell of it. I just rewrote my command-pattern parsing engine in TypeScript to utilize the redux pattern instead. Maybe I can combine the two?