▲ | jonathanstrange a day ago | |
This is a silly article, though I can only speak for myself. First of all, language design is pretty much the last reason anyone should consider when choosing a language. For me as a solo developer who needs to get results in time, the main criteria for choosing Go were compilation speed, development speed, general tooling, and third-party support. Especially the latter is extremely important; I cannot develop all kinds of libraries like e.g. an Excel or Word document parser in-house, I have to use whatever MIT-licensed libraries that are there. I've developed in all kinds of languages in the past: Pearl, Java, C++, REALBasic, PowerMOPS (a Forth derivate in the 90s), Ada, Rust, Python, Java, Racket and various scheme dialects, CommonLisp, ObjectPascal/Lazarus, just to name a few. Out of these, REALBasic was by far the one in which I was most productive. Alas, it became unaffordable and the vendor lock-in really burned me. No more commercial languages or IDEs it is for me. If Ada had a garbage collector, I would probably use it even though the development time is a bit longer. Likewise, I'd love to use CommonLisp and think it's the best dynamic language. But it simply doesn't have enough 3rd-party support, and I'd also be wary about how it runs on mobile platforms. I've got to say I'm pretty happy with Go so far. Is it the ideal language for me? No, because full OOP with multiple inheritance would make my life much easier. But it works, is easy and fast to develop in, and the results speak for themselves. I have no problems with bugs. The explicit error handling may be a bit cumbersome but it forces you to think about and deal with every error, unlike people in languages with exception system who often ignore errors until so far up the call chain that they don't even know what actually happened any longer. I don't see the point of that. If you have an illegal state of an object it doesn't matter if you call the object nil or DefunctInstanceOfBla, you're going to have to deal explicitly with the illegal state. Notably, C# was also in my final selection of languages. For my principal use case - distributed client/server applications with GUI - Go's GUI options were not so stellar and I was thinking about using C# instead. AFAIK, C# is very suitable and a great language, too. I decided against it because of the C#'s bizarrely complex runtime library situation and naming schemes (WTF?) and simply because I would have had to learn it first and already knew Go fairly well. Beware the language aficionados and purists. I used to be one of them, too, advocating Scheme & CL. However, in the end purely practical considerations are always more important. Programming languages are tools for getting things done. |