Lately I have been learning a lot about Go. I decided a great independent study subject would be to review Algorithms, Fourth Edition in the context of Go. However, this presents a few obsticles that ups the degree of difficulty.
Most notably, the Go language does not support generics. While a widely debated topic, I think that like most tools it is necessary to accept and embrace its characteristics. In the same vein, you can't rail against C# or Node.js for not having a specific select statement for goroutines. You also can't really bolt that kind of functionality on with a third party library, either. You can try, but naive attempts may introduce a fresh set of problems. Rather than rail against the facts, we can be more productive by moving on and focusing on the tools we have at hand for solving the problem.
Idiomatic Go strays away from the traditional approach of ADT (Abstract Data Type) interfaces. Instead of building a coarse interface for a data structure, I predict having a set of fine grained interfaces that more clearly describe intent with regards to the client code.
After spending a lot of time in Node.js, I have gotten used to writing simple programs that execute as a single process as iterations in the event loop. As it turns out, you spend less time worrying about locking code around shared memory and begin taking it for granted. For this endeavor, I can't simply build the naive imlpementation of any given algorithm and presume it to be threadsafe. It might be a decent starting place, but a more pure effort will be to focus on how the implementation will look when done the Go way. That pretty much means using goroutines and strongly typed channels.
This will be an exciting exercise. I'm interested to see how difficult this turns out to be, and if I can stick with it to the end. Perhaps some of my work will make it into a couple of posts. Wish me luck!