Go takes the wheel and lands in top 10, TIOBE index shows
© Shutterstock / Smokovski
What a difference a couple of months can make. Not long ago, we were celebrating Kotlin and its milestone and now it’s all about Go, which has landed in top 10, according to the TIOBE Index for July. What triggered the change? We can only speculate.
What does it take for a programming language to go from the “craze” status to the “here to stay” position? If the answer was obvious, life would be much easier for programmers.
Here’s an example: Kotlin recently wowed the crowd and jumped into the top 50, according to the TIOBE Index and shortly before that Swift cracked Tiobe’s top ten programming languages list.
Where are they now? Kotlin occupies the 48th position (it lost five positions in one month) and Swift is no longer in the top 10 — it now occupies the 12th position. Meanwhile, the top is always populated with the same names: Java, C, C++, Python and C#. What’s the point, you ask? TIOBE said it best:
SEE ALSO: How well do you know your Go trivia?
Go is now in TIOBE’s top 10
Go has officially entered the top 10. Last year, this programming language occupied the 55th position and now it plays in the big leagues.
Perhaps it’s no coincidence that Go has entered the top 10 now. GopherCon 2017 was a fruitful conference, especially since participants got a sneak peek into Go 2 — it’s not here yet but this was the first glimpse we gained of how it’s going to look like.
If you were not at GopherCon but you’d still like to know what Russ Cox said during his talk, you’ll be happy to know that the text of his talk has been uploaded on the Go blog. According to Cox, the idea is to ship the backwards-compatible parts of Go 2 incrementally, feature by feature, as part of the Go 1 release sequence. Let’s have a look at a handful of important properties:
- It keeps the Go 1 releases on the usual schedule
- It avoids splitting development effort between Go 1 and Go 2
- It avoids divergence between Go 1 and Go 2 (migration headaches)
- It allows the team to focus on and deliver one change at a time (that’s one way to maintain quality)
- It will encourage them to design features to be backwards-compatible.
We might start seeing minor changes about a year from now, for Go 1.12 or so. That also gives us time to land package management support first. Once all the backwards-compatible work is done, say in Go 1.20, then we can make the backwards-incompatible changes in Go 2.0. If there turn out to be no backwards-incompatible changes, maybe we just declare that Go 1.20 is Go 2.0. Either way, at that point we will transition from working on the Go 1.X release sequence to working on the Go 2.X sequence, perhaps with an extended support window for the final Go 1.X release.
Although these are just estimations, there’s something to look forward to. Keep in mind that the team is not abandoning Go 1 — they promised to “bring it along to the greatest extent possible.”