On Languages
In my first degree I had to learn a language called Pascal, with a big old blue Walter Savitch book and a lecturer who said you can make a computer do anything. He was wrong, or simply didn't understand how little he, or I, knew about computers at the time. This was an industrial design degree and programming was part of the technology/science block given in first year.
Fast forward 8 years and I'm doing an AI degree, with the data structures/101 course being taught in Modula-2, a fix-upped Pascal and I'm thinking not much has changed. After that we had to learn C and Prolog in different courses at the same time. The course lecturers I gathered did this deliberately to keep us flexible. This clearly could work - C and Prolog might as well be the Zerg and Protoss of languages. On reflection I think this is one of the better things that happened to me, education-wise. Since then I have tried to learn the basics of new languages in pairs or more, and if possible digest languages that are reasonably different in approach.
I have been playing around with Erlang, Scala and Go more and more, to the point where I'm able to draw conclusions about them as production languages. I don't consider myself expert in any of them, but like most people in my line of work I have to be able to make judgments in advance of deep understanding. I've also spent time to a lesser extent with Rust, not enough to decide anything much. I've been foostering with Erlang and Scala on and off for years, Go and Rust are more recent.
I wanted to write down what I've found to be good about the languages so far. For context, the production languages I work with most these days are Java, Python and Groovy, indirectly Clojure and Scala (the latter due to Storm and Kafka, platforms I operate with my current employer).
I also want to talk about what's 'wrong' with these languages, and by what's wrong I mean two things. First, absence of features; an example might be the limited static typing features in Go. Second, what I'm going to call 'negative externalities' - aspects that distract from or even outweigh the direct benefits of the languages. Externality concerns are usually more important to me than missing features because of the way they impact engineering quality and cost. In Java an example might be GC pauses or boilerplate. In Groovy or Clojure it might be comprehending stacktraces or runtime type failures that other languages would catch earlier. In Scala it might be compatability or readability. The longer I work in this industry the more I find myself concerned with ergonomic/lifecycle factors and I believe understanding the more indirect aspects of a language helps make better decisions when it comes to selection.
I'll add links here as I write each one up -