Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Google Java Perl Programming Python Stats

Google's Go Language Surges In Popularity (infoworld.com) 252

2016 saw a big spike in the popularity of Go, attributed to the rising importance of Docker and Kubernetes. An anonymous Slashdot reader quotes InfoWorld: Ranked 65th a year ago in the Tiobe Index of language popularity, it has climbed to 16th this month and is on track to become Tiobe's Programming Language of the Year, a designation awarded to the language with the biggest jump in the index...which gauges popularity based on a formula assessing searches on languages in popular search engines...

Elsewhere in the index, Java again came in first place, with an 18.799 rating while C, still in second place, nonetheless continued its precipitous drop, to 9.835% (it had been 16.185% a year ago). In third was C++ (5.797%) followed by C# (4.367%), Python (3.775%), JavaScript (2.751%), PHP (2.741%), Visual Basic .Net (2.66%), and Perl (2.495%).

The article also cites an alternate set of rankings. "In the PyPL index, the top 10 were: Java, with a share of 23.4%, followed by Python (13.6%), PHP (9.9%), C# (8.8%), JavaScript (7.6%), C++ (6.9%), C (6.9%), Objective-C (4.5%), R (3.3%), and Swift (3.1%)."
This discussion has been archived. No new comments can be posted.

Google's Go Language Surges In Popularity

Comments Filter:
  • by Anonymous Coward on Sunday October 16, 2016 @06:38PM (#53087603)

    I looked for use cases a while back and couldn't find anything except crawlers.

    I hate how easily programmers jump on a bandwagon.

    • by Lisandro ( 799651 ) on Sunday October 16, 2016 @06:51PM (#53087659)

      It fills nicely the niche between low and high-level languages. You get C-like semantics, modern data structures, memory management and high performance with fast compiled binaries.

      Also, it is one of the few languages out there where concurrency is not an afterthought.

      • by Tough Love ( 215404 ) on Sunday October 16, 2016 @08:40PM (#53087979)

        You get C-like semantics, modern data structures...

        Modern data structures without classes or generics? This is where I checked out on Go after initially being interested.

        memory management and high performance with fast compiled binaries....

        And no way to avoid the memory management, a crippling problem shared with Java that makes it a bad choice for many applications (e.g., low latency financial transactions). Face it, Go is a bland language with really only one thing going for it: promoted by Google. Much like C# is promoted by Microsoft, which didn't overcome the mind share issues of that platform either.

        It's just not clear what problem Go solves better than any alternative. If you want highest performance and lots of big team software engineering support, you go with C++. If you need managed memory and access to the copious supply of 2 year diploma programmers and don't mind throwing a bit more hardware at your problem you go with Java. If you need to churn out web2 sites as fast as possible then Node or Python. It's just not clear where the demand for Go is supposed to come from. From where I sit, Go is just another pretender to the Java throne, not any less bland than the incumbent and decades late to the party.

        • There is more than one way to skin a data structure (or cat?). Classes that you may fine in languages you like isn't the only way to create software.

          As for generics, I am very confident that Go will eventually have them, but you are indeed correct that it does not have them today. Rob Pike is more than likely looking towards some strong use cases in production that would have been better with generics than without them. He seems very caution to add big unwieldy whiz-bang features and is willing to suffer so

          • by lgw ( 121541 )

            As for generics, I am very confident that Go will eventually have them, but you are indeed correct that it does not have them today.

            This kills Go for me.

            One of the big problems with C++, C#, and Java is that generics were an afterthought (and still are, in Java). Those mistakes were made a long time ago now. For a new (-ish) language to repeat that mistake just makes no sense.

            Yes, your language needs to have strongly typed container classes, and not just those in the standard library. Go natively supports strongly typed maps and dynamic arrays, which is nice and all, but how was it not obvious that it needs a mechanism to make more s

            • It's probably not as big a deal as you're thinking. Go's support of interfaces covers most of the operations you might want to perform using generics, even if it's sometimes a bit cumbersome to implement.
              • Go's support of interfaces covers most of the operations you might want to perform using generics, even if it's sometimes a bit cumbersome to implement.

                People had some excuse for that kind of low quality language design a few decades ago, when generics weren't as well understood, when computers had little memory, and when writing compilers was hard. There is no excuse today.

              • Go's support of interfaces covers most of the operations you might want to perform using generics, even if it's sometimes a bit cumbersome to implement.

                Not really. Go supports limited generics of course such as on the usual arithmetic operators and of course on the builtin structures. Imagine trying to program go without generics at all.

                And because it doesn't have user defined generics, when your problem doesn't map well on to one of the builtins, you get all that annoyance. I mean sure you can work around

            • by DrXym ( 126579 )
              The lack of generics does seem a bit weak. I've read a few articles trying to work around lack of generics and some of the suggestions are borderline comical - one suggested way was to copy and paste the same code around a bit. Another was to write a script which machine generates code from a template.

              Personally I think Rust does generics pretty well. A generic function or struct takes one or more type args which are supplied at compile time. The generic normally enforces the types it will accept based on

          • Rob Pike is more than likely looking towards some strong use cases in production that would have been better with generics than without them. He seems very caution to add big unwieldy whiz-bang features and is willing to suffer some tedious C-like software in the interim.

            Go is 10 years old, and Rob Pike has been at this for forty years, and he still doesn't understand the common use cases for generics? Perhaps he should retire and go into Bonsai pruning or something, because language design doesn't seem to

        • by dottrap ( 1897528 ) on Monday October 17, 2016 @12:52AM (#53088807)

          Go was created by Rob Pike and Ken Thompson to solve real problems Google was having with its massive C++ code base.

          The domain they work in is huge scalability, server backends.

          You are right, it is a boring language, and that's just how they like it because Google is trying to solve their very specific problems without creating nightmares of new ones.

          Go is designed to address many of the scale complexity problems they faced with C++, in both human terms and machine terms. In human terms, C++ is a very complex language. In machine terms, the joke was that Go was invented while waiting for a C++ compile job. (Google's build times are frequently measured in hours.)

          Go also addressed scaling problems for other languages. Java, C#, Python, Ruby, NodeJS, etc. consume a lot more resources to spin up their virtual machines. At Google scale, this adds up to needing a lot more hardware, and a lot more power to run the data center, and a lot more cooling needed.

          And since most of Google's server requests have no dependencies with each other, they could build directly into the language mechanisms to support concurrency. (And they make it a point to distinguish between concurrency and parallelism in computer science terms.)

          In the end, Go is a fairly simple language that people from scripting languages can pick up reasonably, while getting pretty decent native performance, and also getting concurrency features which are optimized for their domain.

          • > while waiting for a C++ compile job. (Google's build times are frequently measured in hours.)

            If you're waiting hours for a C++ build you're doing it wrong.

            There is the concept of an unity / "bulk build" where you compile one .cpp file that includes _all_ the other soures. Compilation takes minutes.

            The downside is that if you want to make a single change you need to do a full recompilation.

            • > while waiting for a C++ compile job. (Google's build times are frequently measured in hours.)

              If you're waiting hours for a C++ build you're doing it wrong.

              There is the concept of an unity / "bulk build" where you compile one .cpp file that includes _all_ the other soures. Compilation takes minutes.

              The downside is that if you want to make a single change you need to do a full recompilation.

              Also, don't do insane things with templates. Also don't include more headers than you need to. Also use compiler cache.

              I'm pretty sure the smart people at Google didn't get any of those memos, but hey, let's do the ADHD thing and implement a whole new language platform with a whole new library ecosystem. Because, you know, maintaining more stuff is so much fun, everybody loves doing it.

              What I'd suggest... sure, implement a new syntax frontend if that floats your boat, but make it a frontend to the usual too

              • Re: (Score:2, Insightful)

                by Anonymous Coward

                I'm pretty sure the smart people at Google didn't get any of those memos

                Have you seen the Google Style Guide for C++ when they first released it on svn? It was written for C with classes, some of the desicions were based on having simple text search as only available tool for code lookup, others were base on C++ predating the 98 standard and more based on legacy issues.

                Basically Googles biggest problem with C++ was a large codebase of legacy code nobody wanted to touch and Go solved this by simply throwing everything away, starting from scratch. It means maintaining less since

                • ...Basically Googles biggest problem with C++ was a large codebase of legacy code nobody wanted to touch and Go solved this by simply throwing everything away, starting from scratch. It means maintaining less since they can just chuck decades of work into the garbage bin everytime they hire a new Rob Pike.

                  Ding, you nailed it. With Go they can create a new, large codebase of legacy code that nobody wants to touch, with the added complication that you need to train each new hire for months in the new oddball language that wasn't in the curriculum.

                  • You may be ignoring a very simple point: this "oddball language" is sufficiently simpler than C++ that 1) new hires who are C++ experts won't have any problem with learning it anyway within weeks at most, and 2) new hires who aren't C++ experts won't even have to deal with C++ in the first place. If anything, I would think it broadens the set of potential new hires to rewrite your old services. Of course you could also do it in C++, but most people who touch C++ are more dangerous rather than experts (I kno
              • Also, don't do insane things with templates. Also don't include more headers than you need to. Also use compiler cache. I'm pretty sure the smart people at Google didn't get any of those memos

                Google already has extensive hints on how to work with C++ [github.io] and apparently, not even those helped sufficiently. Also, solving this would only solve the problem of build times, not the problem of existing concurrent code at Google being too hairy. At the very least, in addition to solving the build time problems, a replacement for Go's functionality would have to be developed on top of C++ and the C++ clients rewritten to use it.

          • The domain they work in is huge scalability, server backends....

            It's nuts to sacrifice any performance at all in that context, due to garbage collection. Multiply that wastage by millions. Wrong tradeoff, sorry.

            • Concurrency (plus parallelism to boot) requires either the use of GC (you just don't know in advance when things aren't used by anyone anymore), or the use of atomic reference counting in too many places (slow!), or very complicated custom schemes (some kind of ownership?) that avoid the use of either but then permeate your code with something that you'd like to avoid. And it's not even clear that GC, when well implemented and combined with something that prunes the object graph (mostly structs-as-values an
        • Modern data structures without classes or generics? This is where I checked out on Go after initially being interested.

          You get the same data structures in memory without classes in Go that you get with classes in, say, Java. (Better, in fact, since Go, unlike Java, doesn't force you for all structures to be reference types.) The only limitation is that the common patterns catered for by Java's single inheritance and interfaces aren't present and you have to spell out certain things explicitly. (On the other hand, this force might prevent the emergence of ravioli code in your code base.)

          Regarding "generics", that's a trade-o

          • I don't think I fully understand your "2 year diploma programmers" remark...

            With two years of study under your belt you can be a productive Java programmer but most probably a clear and present hazard to a C++ code base. There is value to the former, I do not deny, but when highest performance and throughput is a design goal, please, just bite the bullet and bring in properly qualified people.

            • Yes, the former I can agree with, although in this respect, Go seems to be to Java what Java is to C++, so the Java preference seems to be more a matter of its entrenchment in the job market. Regarding the latter, I find it strange that using "properly qualified people" (which ought to be used in any case) implies the automatic choice of C++. If I were doing numerics, for example, I really wouldn't try to avoid Fortran to the extent that I'd be forced to go for C++.
          • The only thing that Go has currently missing or not provided in any form whatsoever is intrinsics

            You missed the biggest one which is zero cost memory allocation. Things allocated on the stack are zero cost in C++.

      • by Raenex ( 947668 )

        Also, it is one of the few languages out there where concurrency is not an afterthought.

        They made it more convenient to do the wrong thing by allowing unchecked sharing of variables between goroutines. In other words, they completely left unsolved the major problem with concurrency.

        • sync.Mutex [golang.org]?

          Don't get me wrong, this is otherwise a valid criticism, but Go provides sane locking mechanisms to ensure safe concurrent access to shared resources so it's not the end of the world.

    • by Anonymous Coward

      Go billed itself as a systems programming language. I dont know about that, but Go is useful if you need massive concurrency. Goroutines make it trivial to spin up new threads and keep things in sync. In fact, the entire language seems to revolve around that concept.

      Go is strongly typed, so you get the benefit of eliminating certain classes of errors at compile time. Speaking of which, the compiler produces very fast code.

      Some of the weaknesses of go are that it lacks support for generics (and developers ar

      • Go billed itself as a systems programming language. I dont know about that, but Go is useful if you need massive concurrency. Goroutines make it trivial to spin up new threads and keep things in sync...

        So you can have a zillion threads bogged down in the unpredictable overhead and latency of garbage collection? Ask me why I'm not excited.

        • Be aware that coroutines are not the same as threads. They are much lighter and you can have a lot more.

          Also remember, concurrency is not the same as parallelism. The Go literature tries very hard to remind people of this computer science fundamental.

          Go's primary domain is server backends. The workload is basically handling many thousands of requests per second that are completely independent of each other (embarrassingly parallel). You are absolutely correct that you don't want zillions of threads. Corouti

          • You are absolutely correct that you don't want zillions of threads.

            Putting words in my mouth. I did not say I want zillions of threads. What I don't what is zillions of GC cycles at random times.

        • goroutines are not threads - the Go documentation enforces this point over and over again, because it is not a minor distinction. Now, this doesn't make Go concurrent runtimes "predictable" either, but it is not as bad as you picture it.

          • goroutines are not threads

            What is this nonsense? A goroutine is a lightweight thread of execution. [gobyexample.com]

            light-weight processes (goroutines) [wikipedia.org]

            Let's not pretend that go has some magic concurrency primitive that is anything other than a normal thread launched by the clone syscall. (There are other ways to do threading involving userspace scheduling but they are generally no better than using the standard syscall and typically much worse.) I appreciate the syntactic sugar and the channel concept is nice as a built in, but please, it's not magic

            • Borrowing some C++ parlance, "thread" is an overloaded word. From the language user's perspective, goroutines are threads because they're independently executed, even in parallel on multiple cores. From the OS's perspective, however, they don't exist. Therefore, they can't have anything to do with any syscalls. They just simplify the use of the notion of some fine-grained parts of your computational process being ready to execute while others still have to wait. It's not like you couldn't write stuff like t

            • by Lisandro ( 799651 ) on Monday October 17, 2016 @03:27AM (#53089173)

              Let's not pretend that go has some magic concurrency primitive that is anything other than a normal thread launched by the clone syscall.

              Oh, but it does - though i wouldn't call it "magic". Don't take my word for it: write a small program spawning, let say, 100000 goroutines. See how many system threads are launched.

              From the documentation itself [golang.org]: "They're called goroutines because the existing terms—threads, coroutines, processes, and so on—convey inaccurate connotations. A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space. It is lightweight, costing little more than the allocation of stack space. And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required.

              Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run. Their design hides many of the complexities of thread creation and management."

              You're mixing up concurrency with parallelism. Rob Pike had a couple of very interesting talks on the matter [golang.org].

              • A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space.

                What is simple about that? Have you got any idea about the nature of the mechanism that is required to make code execute concurrently with other code on the same or different processor?

                It is lightweight, costing little more than the allocation of stack space.

                Oh, you mean like a Linux thread created by the clone syscall, with all resources shared.

                And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required.

                Oh, you mean like a Linux thread created by the clone syscall, which only allocates a virtual address range for the stack and faults in actual memory as required.

                Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run.

                Oh, you mean like green threads [wikipedia.org] which used to be the threading scheme of ch

                • Sheeze. Ok, to wrap it up: goroutines are not OS threads like you originally suggested. There's not a a clone syscall associated with every goroutine; in fact, you can limit the number of concurrent threads on a Go process to 1 if you like and have them all run under a single process. See GOMAXPROCS [golang.org].

                  Now, the concept of goroutines is arguably much closer to what's commonly known as "green threads". But again, this is not what you originally stated.

                  • by ( 4475953 )

                    "goroutines" are old wine in new bottles, like everything else in Go. Yes, these come as green threads, fibers, coroutines, lightweight threads, etc., and all have in common that they somehow manually switch between instructions of different green threads without automatically using OS threads. Many Lisp and Scheme dialects, and, of course, Forth use them for many decades. They tend to come with a performance hit, though, and the GP is right that they are easily outperfomed by modern OS-level threads for

                    • What about large number of concurrent tasks? That's actually the use case they're designed for. Nobody is interested in a small number if all solutions to that have adequate performance. That's a non-issue.
                • Rob Pike may have gottent out of touch with just how efficient and scalable Linux threads really are.

                  The interesting question is, given how much Linux-dependent Google is when it comes to almost anything, whether this was actually discussed inside Google. Given their level of Linux involvement, they must have people coping with both Linux threading and Go code rewrites. Maybe you could ask him personally?

      • Go is easy for moderate concurrency, but I would argue that it's not great for massive concurrency.

        I would be OK writing desktop application and games in Go instead of Java or C++. It needs some libraries, but it is interesting in that it primarily builds static binaries instead of linking to shared libraries.

        • Go has supported building packages as shared libraries [google.com] for a good while now.

        • I would be OK writing desktop application and games in Go instead of Java or C++.

          In the context of videogames (my line of work), "needs some libraries" means "would need to rewrite the entire videogame ecosystem from scratch." In other words, not a chance in hell, no matter what the virtues of the alternate language happens to be. The videogame industry isn't moving away from C++ as it's primary language anytime soon, mostly due to sheer inertia. Every major game engine and 3rd party or platform library is written in or has interfaces available in C/C++.

          • Any shift in implementations is not made any easier by C++'s piss-poor interoperability with other languages anyway, so there's that.
      • by lgw ( 121541 )

        I dont know about that, but Go is useful if you need massive concurrency. Goroutines make it trivial to spin up new threads and keep things in sync. In fact, the entire language seems to revolve around that concept.

        I don't see that it makes concurrency any easier than Java, C#, or modern C++. Sure, it's easier than C, but it's a garbage collected language, so why would you compare it to C?

        My opinion is this: If you just need a general purpose programming language, go doesn't give you anything new. It sits in a strange place where it is not c but also not quite high level, so you get high-levelish things (such as goroutines) but you still need to deal with c type annoyances.

        You are better off with python, java, c# or even c++ in most cases.

        Well put, I should add "Python too" to the above.

      • > Go billed itself as a systems programming language.

        They backed off on this claim a while ago. It's popularity and main use case has been as a server backend language.

        Because the language compiles to native code and is closer to the hardware, everybody lumped it in with "systems" programming languages.

        As a server language, it meets its objectives well. The native aspects give it an advantage over languages like Ruby (Rails), JavaScript (NodeJS), Python with smaller memory footprints and ability to take

    • Gogs is a GitLab clone written in Go.

      It runs on low CPU machines since it's not written in Ruby.

      • Surfed in to try it... gogs.io works in Chromium, barfs in Firefox. Not an auspicious start. So why is Gogs better in Go than Java or C++, other than as a promotional thing?

    • by OrangeTide ( 124937 ) on Sunday October 16, 2016 @08:46PM (#53088009) Homepage Journal

      I'm a long time C programmer, and I like Go a little better than C for concurrent programs. It's not quite as ground breaking as something like Erlang, but it's quite a bit easier to throw something together to run reasonably well on a cluster than say Java. I wouldn't want to write a kernel in Go, but it's pretty hard to displace C in that niche.

  • I wish the standard library came with more goodies (Python can really spoil you in that sense) and that it was a bit more expressive - generic programming f.ex. would be a godsend. But hose will probably happen in the future. It is an otherwise fast, clean and well designed language, which thanks Baby Jesus isn't obsessed with OOP.

  • by chrism238 ( 657741 ) on Sunday October 16, 2016 @06:48PM (#53087645)
    I understand that it's a failing of us humans to comprehend multi-dimensional data, but reducing a programming language's "popularity" to a single value really helps no-one. But because we're obsessed with such things, at least choose measures that place the weightings back into the hands of those that wish to match the data to their needs. Try the IEEE Spectrum interactive rankings: http://spectrum.ieee.org/stati... [ieee.org] where Go performs even better - except for jobs.
    • IEEE lists a rating of "71.9 out of 100" for Go for both mobile and embedded programming. That doesn't make any sense: Go has little support for either use case right now. And the fact that the numerical rating is identical suggests a tiny sample size or other problems with their calculation.

  • Anyone else find Go's syntax horrible and avoid the language completely because of it?
  • by melted ( 227442 ) on Sunday October 16, 2016 @09:13PM (#53088107) Homepage

    I bet half the people who said "C" actually meant C++. There's really no reason to use C except in projects that are already in C, since C++ is an almost exact superset of C. So you can write everything in a procedural style, but still use STL and strings, and other minimal conveniences.

    • Forcing projects to C avoids possible bugs and unreadable code from cowboy programmers on your team using some of the more esoteric features of C++.

      It also is a requirement for embedded systems, which includes everything for an arduino and their bigger cousins.

      • by BESTouff ( 531293 ) on Monday October 17, 2016 @02:51AM (#53089089)

        Forcing projects to C avoids possible bugs and unreadable code from cowboy programmers on your team using some of the more esoteric features of C++.

        This ! I've been working in several embedded systems companies, and we always have avoided C++ precisely because of this.

        It also is a requirement for embedded systems, which includes everything for an arduino and their bigger cousins.

        (OTOH not really this, I'm seeing more high-level languages, even JS, everywhere)

      • by AmiMoJo ( 196126 )

        Arduino uses C++.

        Another issue for embedded system is that C++ doesn't like type punning and other useful but potentially dangerous functions. Also, goto makes C++ programmers cry.

    • Plenty of people prefer C, because they think C++ generally sucks.

      You may disagree, but there are plenty of people who disagree with you.
  • what popularity means is that you have the most people that don't know wtf they are doing and there isn't a simple answer.

  • by Anonymous Coward

    You may note this massive, unprecedented serge is usage happened at the same time as pokemon go got very popular.

    It will drop massively over the next few months because the system wasn't picking up references to the language, rather false positives to pokemon.
       

  • By searches on popular search engines. Uhm....

EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER

Working...