Go as a language for learning programming

tl; dr: Go is a rather verbose and rigorous programming language with a very predictable and rapid learning curve, which makes it an extremely successful technology for teaching programming to newcomers!

I just came from the states, after the Google Code-In 2014 Grand Prize Trip, rested and cheerful. For a while I thought of writing a report on what the winners were doing there, how we were received at the Mountain View and about all this, but at some point I realized that all this was completely useless. Most recently, by chance, I had to help my friend with a computer science student at home (there was something like a selection sort). Implementation was required on pascal, and I know pascal very badly, as well as other irrelevant, at most, programming languages, like Ada.

I was struck by lightning and bit by a gopher, after which my body mutated into some kind of kung fu Go crap. In other words, I thought about the potential potential of my pet among the new technologies, Go, as a language for teaching programming to newcomers (read: schoolchildren). It seems to me that Go has everything that in principle can be needed for such a program and even a bit more (for example, at school they could touch on the topic of parallel, in no case concurrent, programming that is not affected, simply because FPS is not able to drive two pieces of code at the same time). Under the cut, in fact, my thoughts on this. By the way, taking this opportunity, I want to say hello to divan0 ! Thank you very much for your educational activities in the thematic hub: Go really needs publicity, because many people still believe that this is some kind of scary crafts from the level of the '80s Plan9 and also, without generalized programming (in every joke there is share jokes), and you tell people the very right things in a language that they understand! There will be no disclaimer, but I strongly do not recommend taking the contents of the article absolutely seriously, because I am a person who has two whole gophers: blue and pink!

Argument number 1. Verbosity and severity

I am terribly annoyed with the word “verbosity”, but if I have already undertaken to write an article, then I need to translate verbose into Russian. Why is verbosity good? Verbosity simplifies the understanding of the code on the screen, since with insufficient verbosity the reader may have questions of the level "And what does this thing finally can do?". You can run into extremes like Haskell vs Cobol for a long time, but the point is clear. Why is verbosity bad? Adherents of the DRY religion repeatedly remind me that there are no generics in Go (generalized programming). Instead of generics offer bootstrapping or code generation. However, the programming language architecture is always a definite deal: manual memory management versus the garbage collector, generics versus bootstrapping, dynamic typing versus static, this can go on forever.
')
As for rigor, then Go makes me very happy. The compiler never makes concessions with the programmer, and any seemingly trifle that in other PL compilers will result in an inconspicuous warning, here it will be a compilation error. You do not play by the rules of the language specification - you will not get a binary, everything is simple. The compiler is so picky that it brings compilation at the sight of an unused module. In my opinion, this is just a crap, as magical, especially if you are 15 years old, you just came into programming and want to do everything “faster”. I just sleep and see a schoolboy at the computer who is trying to compile the program, but fails; then, uttering in his head all the mats that he only knows, returns to the editor to remove the modulename from the include list. Hard? Still would! But you know, such rigidity, it brings up!

Argument number 2. Awesome learning curve

Go architecture has simplicity. Pike was saying somewhere, I don’t remember where, that they really cut out everything that could be cut. For the sake of simplicity, in Go there are no three types of cycles (C-way), but only one (and this is without loss of expressiveness!), In Go there is no advanced type system (but there are magic interfaces!) And in that spirit. I am sure and even ready to put my own slippers on it (expensive sneakers, by the way, foreign ones) that an ordinary student of this kind will not read the language specification, so I will not mention it. Anyway, language, due to its simplicity and moderate verbosity, provides a fast and predictable learning curve. But at least the fact that the memory is managed, already removes a bunch of problems of the level, “so what does this work, does this function work for me? can not be!".

The fact that an experienced programmer fully masters Go, with all its pitfalls, over several weekends, has already been said several times, but this does not make sense in the context of the article. I didn’t train kids on Go, so I don’t have any hard numbers, but I suggest that you use gyrus. What are the three things that take, during the training phase, the most time? The champion is obviously manual memory management and Mr. “I managed to plant the garbage collector for half a run-time” in languages ​​with managed memory. The second place, of course, is the subject of reference links in different contexts (jambs of the level “assigned not by reference, but by value”). Mr. OOP closes the top three, or rather the problems that arise in the implementation of the PLO: “is it private or not?”, “Do I still make the destructor virtual?”, “But how to inherit two classes at the same time ???” and the like.

In Go, memory is controlled automatically, which means it’s hard to mess up. There is a rule that allows you to clearly define (in most cases) to pass a variable by value or by reference: “If you are going to transfer ownership of a variable, then you must pass by reference, otherwise - by value. A standard set of problems with OOP will not appear, because Go has resorted to very beautiful solutions regarding object-oriented programming. Namely, Pike & Co. sawed out classes, all „ambiguous“ inheritance and other encapsulation, offering structures, interfaces, embedding. The problem of encapsulation was decided to be ugly interesting: all the fields of the structure that start with the upper case symbol go out, and everything else remains inside.

I painted a picture, and the conclusions are already to you. It seems to me that everything is very magical.

Argument number 3. Multithreaded programming

I believe that it is very important for children at school to give skills to work with multithreaded applications. You know, a little cool about the fact that a student, whose experience in one way or another boils down to projects of the laba3 level, gets into a real project where a lot of code is being executed at the same time, all resources must be closed for mutexes, besides, all this should be covered with tests ... Computers have long been able to perform several tasks in parallel (parallel! = Concurrent), due to the architecture of the processors and this needs to be used. I believe that along with some classical implementations of some algorithms, parallel implementations should also be given. The same selection sort, for example.

Go got rid of the evil and terrible streams, which the Gorutins came to replace. I think that working with korutinami (= tasks), at the level of understanding, is much easier than with threads. The channel, it would seem, is just a queue, but syntax-level plumes make working with it more intuitive and much more obvious. No matter how long I have been praising Korutiny, channels and select, one way or another, we still run into mutexes. Nevertheless, I think that it is still better than what we see today in other languages, especially speaking in the context of learning.

Little about python

For a while, Python is considered a very good language for learning. Arguments: interpreted, typing, curly brackets - gotta go! I do not want to once again raise srach, but I can say that in terms of the learning curve, Python is a very vile thing. And I also have the opinion that the programmer begins to appreciate the advantages and respect the disadvantages of dynamic typing only after a certain time spent with static typing. I do not think that a newcomer should use bicycling with dynamic types until he really understands what a type is at all. Unfortunately, for a talented programmer Alesha of 8A, this is not so obvious.

the end

Well, that's all. Thanks to everyone who mastered this dump of my mind, I hope that someone was interested. It will be fun if some initiative dude with teaching skills reads and later gives birth to a working educational system! No, it really will be great! Oh yes, do not hesitate to ask me any questions: in the comments and even in a personal!