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%)."
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%)."
But what is it used for? (Score:3, Insightful)
I looked for use cases a while back and couldn't find anything except crawlers.
I hate how easily programmers jump on a bandwagon.
Re:But what is it used for? (Score:5, Interesting)
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.
Re:But what is it used for? (Score:4, Interesting)
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.
Re: (Score:2)
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
Re: (Score:3)
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
Re: But what is it used for? (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:3)
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
Re: (Score:3)
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
Re:But what is it used for? (Score:5, Informative)
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.
Re: (Score:2)
> 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.
Re: (Score:2)
> 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)
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
Re: (Score:3)
...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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Boy, those Google engineers sure are stupid!
I did not say stupid people, I said smart people. With ADHD. Don't believe me, do your own research.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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++.
Re: (Score:2)
Modern data structures without classes or generics? This is where I checked out on Go after initially being interested.
Well, it is your loss. The lack of classes (a blessing) and generics (a curse) means that the language is very performant, at the cost of expressiveness
Excuse me, but it is complete nonsense to suppose that inheritable classes or templates reduce performance, if that is what you mean by generics. In fact, in the hands of skilled programmers, templates are often used to improve performance. And inheritable types has nothing whatsoever to do with performance, again improving it if anything (by allowing you to express a design in a way that is both extensible and performant).
I've seen a shitload of financial transaction code written in Java.
If true, then you've seen a shitload of also-ran financial operations, or else financ
Re: (Score:2)
Excuse me, but it is complete nonsense to suppose that inheritable classes or templates reduce performance, if that is what you mean by generics. In fact, in the hands of skilled programmers, templates are often used to improve performance. And inheritable types has nothing whatsoever to do with performance, again improving it if anything (by allowing you to express a design in a way that is both extensible and performant).
From what I understand, the C++ "vtable" system of class hierarchy implementations sort of breaks down, performance-wise, if you try hard enough. A lot of languages can compute an applicable method once and then cache the result (often in the call site), but apparently, C++ doesn't do anything like this (or at least it didn't when I checked for it years ago).
Re: (Score:2)
Re: (Score:2)
Excuse me, but it is complete nonsense to suppose that inheritable classes or templates reduce performance, if that is what you mean by generics. In fact, in the hands of skilled programmers, templates are often used to improve performance. And inheritable types has nothing whatsoever to do with performance, again improving it if anything (by allowing you to express a design in a way that is both extensible and performant).
You're wrong. Depending on the implementation, generics can indeed come with a performance hit; the main example is Java, where type erasure and runtime casts are involved.
There's currently no generics support in Go but, based on what the language currently is it (statically typed, no operator overloading, type interference on variable declarations, etc.) a generics implementation will have to be "magic" in some way - that is, it cannot simply be implemented as a code rewrite before compiling.
Re: (Score:2)
You're wrong. Depending on the implementation, generics can indeed come with a performance hit; the main example is Java...
I was talking about C++, or did the reference to templates not make that clear?
Re: (Score:2)
Not quite, no. The entire generics discussion was in fact about Go.
Re: (Score:2)
Generics can definitely be implemented as zero cost abstractions in a statically typed language. Modern Ada compilers do this, for example. (To be fair, Ada is said to have some tricky problems with the combination of strict typing and generics, but nobody said it was easy.)
Re: (Score:2)
Agreed, but provided there're enough basic building blocks to do so. Ada, f.ex., supports operator overloading.
I'm not saying this cannot happen in Go - everything regarding generics on that language is pure speculation at this point. But it won't be easy to make it happen without some performance hit, IMHO.
Re: (Score:2)
Sadly, Go is both relatively inefficient and not all that expressive.
Re: (Score:2)
I humbly disagree. Not like i have ran any scientific benchmarks on this, but from my limited experience Go binaries tend to be blazing fast.
Just found a site comparing different languages solving a number of computing problems. Now, i know these are to be taken with a grain of salt, but their results is that Go runtimes are comparable with C++ [debian.org] and way ahead of Java [debian.org].
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: But what is it used for? (Score:2, Interesting)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: But what is it used for? (Score:4, Informative)
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].
Re: (Score:2)
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
Re: (Score:3)
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.
Re: (Score:2)
"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
Re: (Score:2)
Re: (Score:2)
"Let's not pretend that go has some magic concurrency primitive that is anything other than a normal thread launched by the clone syscall."
\_()_/
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
Go has supported building packages as shared libraries [google.com] for a good while now.
Re: (Score:2)
Good to know, I never found the feature all that critical.
Re: (Score:2)
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++.
Re: (Score:2)
Re: (Score:2)
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.
Re: But what is it used for? (Score:2)
Re: (Score:2)
> 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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Gogs is a GitLab clone written in Go.
It runs on low CPU machines since it's not written in Ruby.
Re: (Score:2)
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?
Re:But what is it used for? (Score:4, Interesting)
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.
Go is a very very nice language to work on (Score:2, Insightful)
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.
Rather meaningless single value metrics (Score:3)
Re: (Score:2)
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.
Syntax (Score:2)
Re:Syntax (Score:4, Interesting)
As somebody who started writing it about 75% of the time at my job starting earlier this year, I found it weird at first because it's pretty different from other popular languages. But once you get used to writing it, it really does become transparent and second nature.
Re:Syntax (Score:5, Funny)
I'm also not too fond of its semantics, and find the libraries somewhat limited. But other than syntax, semantics, and libraries, it looks like a great lanaguage!
Re: (Score:2)
I like Go's syntax. But I'm also someone who has used mainly C for the last 20+ years.
Re: (Score:2)
Anyone else find Go's syntax horrible and avoid the language completely because of it?
I find its syntax gives me flashbacks to Pascal. Terrifying flashbacks.
Re: (Score:2)
I bet half the people who said "C" actually (Score:5, Interesting)
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.
Re: (Score:2)
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.
Re:I bet half the people who said "C" actually (Score:4, Insightful)
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)
Re: (Score:2)
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.
Re: (Score:2)
Also, the language used by the Arduino IDE is C++.
Sorry, no. It's a *subset* of C++.
Re: (Score:2)
You may disagree, but there are plenty of people who disagree with you.
Re: (Score:2)
Hmm. You can do C++ on a
Commodore 64 [youtube.com]
Re:I bet half the people who said "C" actually (Score:5, Informative)
2K ram - check
8k flash - check
STL - yeah sure
Depends on the compiler, of course, but the STL isn't some runtime library, it's a set of templates, which means only bits you use get compiled. Strings and vectors tend to be reasonably lightweight.
Unless of course, you're the guy who says "I'm not going to bounds-check my array access, I only have 2K!" leading to the world's biggest botnet of Internet-enabled toilets.
Re: (Score:3)
2K ram - check
Yep!
8k flash - check
Yep!
STL - yeah sure
Yep!
Or are you claiming you can implement, say, std::priority_queue in a way that uses fewer resources than the STL version. And if yes, prove it because I reckon you can't.
popularity != a good thing (Score:2)
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.
Tiobe's ranking system gets confused easily. (Score:2, Interesting)
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.
How do you measure Google's language popularity? (Score:3)
Re: (Score:2)
is there a rule that all future technology hhas to be named by aspergs and homosexuals?
Yes, because those are the only people who contribute anything of value to technology.
Because you are neither LGBTQIA or on the autism spectrum, your role in technology is to consume it, not create it.
PS - you forgot to mention trans people. they've contributed a great deal to software and the gaming industry in particular.
Re: (Score:2)
LGBTQIA
How many letters are we going to add to this acronym? We only have 26.
Fetishists are left out and they may make it soon. We'll probably have to wait quite a bit for necrophiles, pedophiles and zoophiles to make it.
Re: (Score:2)
How many letters are we going to add to this acronym? We only have 26.
Oh, they'll repeat them. There is no limit. Then holy wars will break out over what the first T stands for. Nukes will fly.
I do find it amusing though that the BDSM crowd has by-and-large rejected the alphabet soup crowd, finding such categories too limiting.
Re: (Score:2)
Obviously you aren't a member of the gay mafia, or you would already have access to the group's LDAP and WHOIS service.
Re: (Score:3)
And, speaking of compiling, the executables are large — even if you use somebody else's code, you must still compile it all into your application...
...by default. Try go build -linkshared.
Re:Another attempt to start anew... (Score:5, Informative)
Rob Pike is hardly a kid.
Go was never about making a beautiful language. It has been about making different compromises than the ones C had to make 45 years ago. All practical languages are a set of compromises.
The lack of shared libraries are an intentional feature of Go. Generally in a cluster environment they cause more problems than they solve. There isn't anything fundamentally special about Go that would prevent it from having dlopen, it just doesn't have it today because the people who are interested in Go aren't interested in dynamic linking.
The executable size issue is slowly improving. There is an open bug to track it, and while the bug is very old, it still gets regular updates. And only the things that are needed are included in the executable, not "everything". If you make a HelloWorld app, then the big bloat in your app will be the garbage collector. But once you go beyond writing extremely trivial programs the size of your executable doesn't increase at a rapid rate. You should settle on a Go program of any significance being about 2MB to 10MB (where you link almost everything), then slowly going up from there. Another way to put it, is that your executable will be about 0.1% to 0.5% of your system RAM, the kernel will demand page it so if there really are unused parts they won't use precious RAM.
Re: (Score:2)
There isn't anything fundamentally special about Go that would prevent it from having dlopen, it just doesn't have it today because the people who are interested in Go aren't interested in dynamic linking.
You know, I just find that kind of attitude very off-putting in a language designer, and it makes me wonder what other important functionality is missing because the project people "aren't interested".
Re: (Score:2)
Re: (Score:2)
They're not making the language for you. They're making it for themselves...
Actually no, they're making it for a captive audience of Google employees who are paid to not complain about it.
Re: (Score:2)
Re: (Score:2)
There are plenty of bloatware kitchen sink languages already. Why replicate what already exists when you are writing a language to solve specific problems.
Every language doesn't have to be a Swiss Army Knife to be useful.
Re: (Score:2)
Rob Pike is hardly a kid.
No, but he is astonishingly arrogant, see for example:
https://commandcenter.blogspot... [blogspot.co.uk]
He even admits to not knowing C++ well yet comes to the conclusion that go is not all that popular among C++ programmers because it's too awesome and anyway C++ programmers totally suck amirite etc etc.
And you know what? Rob Pike will sink into obscurity long before Carl Linnaeus.
Re: (Score:2)
Go seems like another attempt â" undertaken every few years by a fresh crop of bright-but-not-wise kids â" to start a new programming language.
Rob Pike, one of Go's designers, turned me off from the language a few years ago when he posted with incredulity positing why most C++ developers weren't moving over to Go [blogspot.it]. He ends his post concluding that displays a remarkable attitude of "I'm right because everyone who disagrees with me is wrong", deciding that C++ users just don't know what's good for them.
What he doesn't understand is... the existing languages work. And they work pretty well, despite what the rabid fans of the new hot languages will tel
Re: (Score:2)
I think there are some interesting design choices made by Rob Pike and others. Few languages are revolutionary, they are more a set of compromises taken to meet some practical need. If you look at Go as a middle ground between C and Java. But I do agree with your comment that Go is, at least in some ways, a "cautious holding pattern". Because something like Go it is also an insurance policy against further corruption of Java by Oracle. If Java starts to leave a sour taste in people's mouths, we might see Go
Re: (Score:2)
Oh gee, he thought that ONE language was artificially low?! What is the ranking method, btw?
"Go" is a common word in English, unlike "Cobol" or "Fortran" or "PHP". "Java" might be a kind of coffee, but specifically on programming pages, even "Java" is probably much more likely to be programming-language-specific where "Go" might not be. So the problem with measuring references to it should be understandable.
Re: (Score:2)
What a load of baloney.
Yep, taking Tiobe at face value is foolish. Their methodology is shit. Look at job openings, book sales, how busy the forums are, etc. Look at a bunch of stuff. But do not assume that Tiobe's single, brittle method of ranking languages is accurate, especially when it comes to languages that share a common word like "go".