During my career, I’ve written code in C, C++, GNU Make, Perl, Java, Groovy, Ruby, Python and bash. I’ve often wondered what new programming language (or framework) I should learn so that my skills remain relevant. The number of languages and frameworks has blossomed over time, and the size of the industry has increased to support and keep them vibrant.
In the old days, I read books to learn new languages, but in modern Internet times with online tutorials and stackoverflow.com, I haven’t used them as much. Recently however, a coworker loaned me “The Go Programming Language,” published by Addison Wesley and written by intelligent, seasoned software engineers. Studying it reminds me that I enjoy books. They often contain a distillation of knowledge and wisdom that is harder to come by in online mediums.
For example, the Go tutorials explain how to use slices, but they don’t explain the mechanism of how they work, so they were a bit confusing. This book rectifies that gap in my knowledge, and briefly covers other interesting side-topics such as how UTF-8 was designed to be self synchronizing and directly searchable without having to convert it first.
Go isn’t as familiar to me as what I’m used to, so initially I didn’t like Go. I remember feeling the same way about learning Ruby, which is even more foreign than Go. In the end, there are many considerations with using a programming language that matter more than whether it feels familiar or foreign, elegant or boring. John Arundel summed it up well:
…every programming language represents a set of trade-offs. Each language is optimised for different things, so your choice of language should be determined by what suits you and the problems you want to solve with it.
Tradeoffs include, but are not limited to…
- Integration — the ability to integrate with existing systems at various levels — the operating system, foreign libraries and programming languages, network systems and APIs
- Maintainability (simplicity and type checking are great benefits on large projects)
- Speed of compilation (important on large projects where frequent change occurs)
- Performance in production — speed, scalability, memory usage
- Tooling — build system, editors (IDEs), refactoring support, linters, formatters, packaging, deployment, profiling, testing, etc.
- Ecosystem: libraries (availability and quality of those libraries), community
- Backward compatibility
- Industry momentum — pool of engineers, the time to come up to speed, trust, longevity.
Engineers don’t often get to pick the programming language for a project — it’s already been chosen by the time they arrive on the scene. Instead, they get to pick the project or the company they work on or for.