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

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%)."

Comments

But what is it used for?

[Anonymous Coward]

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?

[Lisandro]

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?

[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 are hostile towards the idea), it has a weak stdlib (well, compared to python or rust anyway) and the syntax is kinda weird.

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.

But if you need lots of concurrency, and can live with the limitations, go is ok.

Re:But what is it used for?

[0100010001010011]

Gogs is a GitLab clone written in Go.

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

Re:But what is it used for?

[Tough Love]

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: But what is it used for?

[Tough Love]

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:But what is it used for?

[OrangeTide]

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.

Re:But what is it used for?

[Tough Love]

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?

[OrangeTide]

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 some tedious C-like software in the interim. Having faith that Go will eventually be very good makes it a bit more of a religion than a language.

Re: But what is it used for?

[OrangeTide]

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: But what is it used for?

[Lisandro]

Go has supported building packages as shared libraries for a good while now.

Re: But what is it used for?

[OrangeTide]

Good to know, I never found the feature all that critical.

Re: But what is it used for?

[Dutch Gun]

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:But what is it used for?

[Tough Love]

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 financial transaction platform means something different to you than it does to me. As a rule of thumb, Java sucks 50-100% more CPU than C++ for anything more sophisticated than a toy benchmark, and that is ignoring the JIT overhead, which is brutal especially on startup or any as-yet-unexecuted code. Which, by Murphy's law you can expect to dim the lights at the most inconvenient (read: expensive) moment. Then there are the GC latency spikes, which by themselves are enough to disqualify Java for serious work in this area. Then there is the thread synchronization overhead, the memory footprint, the rambling bulky libraries, the crappy-beyond-belief "native" API, and other pain points that are too tiresome to list.

Now, i'll admit that C++ is usually much better suited for the task, but "lack of memory management" is normally not an issue for that application - or for most ones, i'd add.

Right. Unavoidable memory management is the issue, not lack of it.

Re:But what is it used for?

[lgw]

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 such things?

Re: But what is it used for?

[lgw]

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?

[Tablizer]

but Go is useful if you need massive concurrency.

Big co's may need that, but millions of companies don't need mass concurrency, and may rely on databases and web servers to get decent medium concurrency.

We don't need a B-52, just an F-16, and don't want to support a B-52.

That being said, because Oracle and MS cannot be trusted, the industry wants a strong-typed OSS language that more or less resembles Java and C-sharp. Google is welcome to try.

Re: But what is it used for?

[Chalnoth]

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.

Re: But what is it used for?

[Chalnoth]

Go had a very different concurrency system than the one supported by Java. Go's concurrency is largely built on the concept of message passing.

Re: But what is it used for?

[dottrap]

> 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 advantage of multiple cores/processors.

The built in design for coroutines makes it easier to do concurrency easier than other native languages which only have threads, and coroutines are much lighter weight than threads. (Please note, concurrency is not the same as parallelism. The Go literature tries very hard to remind people of this computer science fundamental.)

Re: But what is it used for?

[dottrap]

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. Coroutines can be very effective here.

Re: But what is it used for?

[phantomfive]

Go doesn't have inheritance, so it's not at all like Java and C-sharp.

Re:But what is it used for?

[dottrap]

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: But what is it used for?

[Lisandro]

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:But what is it used for?

[ooloorie]

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 be his forte.

Re: But what is it used for?

[ooloorie]

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.

Re:But what is it used for?

[ooloorie]

The lack of classes (a blessing) and generics (a curse) means that the language is very performant, at the cost of expressiveness.

Sadly, Go is both relatively inefficient and not all that expressive.

Re:But what is it used for?

[UnknownSoldier]

> 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:But what is it used for?

[Tough Love]

> 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 tool chain, and use the standard libraries except where there is a compelling reason to do otherwise. If there are bottlenecks in the standard tool chain then attack them. But don't mind me, sorry if it makes sense. I understand how NIH is so much more fun.

Re:But what is it used for?

[Tough Love]

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: But what is it used for?

[Tough Love]

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:But what is it used for?

[K. S. Kyosuke]

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-off in many languages: you do get a standardized, widely used system, but also a fixed-function, very limited one. Go doesn't offer you any but its build system (and even the language, in part - specifically, the module import syntax) apparently allows you to roll out your own. Seeing as this is something that Google does very often, one ought not to be surprised by this. This might be great for experimentation with ideas before anything gets set in stone, which Go's creators are wary of doing prematurely, so it might have been intentional. At this moment, Go seems to be the R5RS of the Algol family.

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).

There's no way to avoid memory management in any language, save perhaps for the likes of HAL/S. Are you programming the next Shuttle? ;)

Face it, Go is a bland language with really only one thing going for it: promoted by Google ... 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.

Actually, I like to see it as a modern Oberon derivative that accomplishes 80% of what you might want to do with C at 20% the cognitive cost. Clearly people are interested in such a tool. I don't think I fully understand your "2 year diploma programmers" remark but I'd like to note that Java is sufficiently more complex than Go that as a general purpose problem solving tool, if you want to cram as much study matter into two years, adding Java into the mix adds - not removes - a problem.

Regarding C++, it would be interesting to see how much of this "highest performance code" is actually a mixture of assembly/intrinsics and code transformations. The only thing that Go has currently missing or not provided in any form whatsoever is intrinsics (unless you count the assembly functions option, which are of little help in many cases). "General" code in Go doesn't seem to face any more performance hurdles than general C++ code, beyond the level of optimizations in the existing compiler (which used to be a simple adaptation of the Plan 9 C compiler, but changed recently to allow for some more massive changes in the future). In fact, probably fewer of them - I believe that Go's pointers are restricted by default (without the unsafe module, they'd be 100% restricted). But perhaps this has been sidestepped in C++ by the use of references. I'm really not a C++ person, so you probably know better.

Re:But what is it used for?

[K. S. Kyosuke]

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:But what is it used for?

[Lisandro]

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: But what is it used for?

[K. S. Kyosuke]

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

Re: But what is it used for?

[Tough Love]

goroutines are not threads

What is this nonsense? A goroutine is a lightweight thread of execution.

light-weight processes (goroutines)

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, and Go doesn't have a monopoly on it.

Maybe somebody meant to say "goroutines are not processes". True. Processes have separate address spaces.

Re: But what is it used for?

[K. S. Kyosuke]

Go was devised to simplify writing network servers. If your concurrency part has already been offloaded into the web server (and the database), you may not need Go for writing your code. If, on the other hand, you're the unlucky bloke tasked with writing the web server in the first place...

Re:But what is it used for?

[Tough Love]

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:But what is it used for?

[K. S. Kyosuke]

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++.

Re: But what is it used for?

[K. S. Kyosuke]

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 this yourself but then everyone would have to use the same library to cooperate (for example, the one you've linked). Many languages provide an implementation of this for your convenience.

The point of the remark you were responding to seems to have been that while "zillion" of OS-native threads can have "unpredictable overhead" (because you have no control over it, and it needs to work on many systems and even versions of systems), the user-space implementation has predictable overhead because you know exactly how it works. So maybe you should have read "goroutines are not threads" as "goroutines are not OS-native threads, and therefore don't have unpredictable performance"?

Re:But what is it used for?

[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 they can just chuck decades of work into the garbage bin everytime they hire a new Rob Pike.

Re: But what is it used for?

[Lisandro]

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: "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.

Re:But what is it used for?

[Tough Love]

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:But what is it used for?

[Tough Love]

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:But what is it used for?

[Lisandro]

Not quite, no. The entire generics discussion was in fact about Go.

Re:But what is it used for?

[Tough Love]

...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:But what is it used for?

[Lisandro]

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++ and way ahead of Java.

Re: But what is it used for?

[Tough Love]

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 which used to be the threading scheme of choice on Linux until the native threading support exceeded it in scalability, efficiency and reliability long ago.

Their design hides many of the complexities of thread creation and management."

And calling them "goroutines" hides the inconvenience of calling them what they are: threads with syntactic sugar.

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

Rob Pike may have gottent out of touch with just how efficient and scalable Linux threads really are. Emulating the clone syscall in user space may not necessarily be a win, quite the contrary. Note that the compiler does not need to call the syscall every time a new thread is needed, it can keep a pool, which would most likely be a way better design than unnecessarily emulating native OS threads in userspace.

Just to put things in perspective: to implement threads (aka goroutines) you need a scheduler, there is no way around it. Without even looking at the implementation I can tell you that the Go scheduler is naive and will be prone to undesired behavior compared to the native kernel scheduler.

Re: But what is it used for?

[Lisandro]

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.

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: But what is it used for?

[K. S. Kyosuke]

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:But what is it used for?

[butzwonker]

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:But what is it used for?

[K. S. Kyosuke]

Can you inline callees for non-monomophic call sites? It seems plausible that some kind of switch-like construct could be used for whole program optimization (aside from megamorphic call types). Naturally, given Go's whole-program-build, no-dynamic-loading nature, exactly the same mechanism could be used for Go. (I also understand the concept of a lot of C++ code being based on template instantiations as opposed to object hierarchies. That definitely helps, and it's probably the prime reason for the general performance of C++ code. C++ really seems to be a better-suited language for compile-time generic programming than for Smalltalk/Lisp-style OOP code. It puzzles me why the OOP portion of C++ is propped up so often when it's not actually one of the language's strong parts.)

Re: But what is it used for?

[Anonymous Coward]

They are called "green threads". Lisp systems have used them for el cheapo concurrency for decades. From my own attempts at writing a fast toy VM (which indeed turned out to be very fast) it was extremely difficult to implement them without getting a performance hit for unthreaded applications, and I wonder how Go implements them.

Re:But what is it used for?

[K. S. Kyosuke]

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++ 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:But what is it used for?

[K. S. Kyosuke]

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 know I am!).

Re: But what is it used for?

[butzwonker]

"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 a small number of concurrent tasks. If the Go team was able to avoid these performance penalties, kudos to them, and I'd like to know how they do it.

Re: But what is it used for?

[Lisandro]

"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:But what is it used for?

[Raenex]

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:But what is it used for?

[K. S. Kyosuke]

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 and escape analysis at this point in time), has such performance repercussions that you'd have to reject it anyway. If anything, it's at least largely coherent in time and space, which is good for memory hierarchies and multi-core architectures. Refcounting everywhere isn't. We have yet to see how far Go implementers can take the performance, but the progress in the recent minor versions of Go has been very promising for the server domain at least. They're not trying to cater for everyone's needs anyway, so if you're not writing servers, maybe C++ is the right tool for you? Take note of your own footnote here.

Re:But what is it used for?

[Lisandro]

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:But what is it used for?

[Lisandro]

sync.Mutex?

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?

[K. S. Kyosuke]

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.

Re: But what is it used for?

[serviscope_minor]

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 it, but why not use a language that helps, rather than one you have to fight against?

Re:But what is it used for?

[serviscope_minor]

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:But what is it used for?

[Anonymous Coward]

Have you seen modern OSes? New release of some Linux distro, please wait several DAYS while we recompile everything on some 64 core monster with 1TiB of memory and all SSDs to create an image. Same difference.

Re:But what is it used for?

[DrXym]

It's safer and easier to use than C or C++ and it produces compiled executables.

Re:But what is it used for?

[DrXym]

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++.

Yes and then you suffer all the problems that go with developing in C++ - cross platform issues, arcane build systems, differences in compilers, dangerous language idioms, higher risk of problems like dangling pointers, memory leaks etc. And naturally you'll probably have to link to a bunch of 3rd party libs (and wrangle all their arcane build systems) because useful real-world stuff like networking, crypto, compression and similar functionality is left out of standard libs.

Unless speed is absolutely critical some applications might prefer to trade raw performance for safer more concise code.

And if you did need speed then these days there are alternatives to C++ too - Rust for example prevents all kinds of programming errors that C++ wouldn't even bat an eyelid at. And it would do it without compromising on runtime performance.

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.

Go can be compiled into a standalone executable. You don't need a VM or runtime to go with the binary. It occupies a middle ground between C++ (fast and dangerous) and Java (reliable but high runtime overhead). It's certainly not the fastest language in the world but tools like Docker, InfluxDB and Prometheus are written in Go and are cross platform and very reliable.

Re:But what is it used for?

[luis_a_espinal]

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

I hate how easily programmers jump on a bandwagon.

Platform, systems and tool development. It's a really nice language that feels very high level and yet allows you to build a binary. It has its quirks and it is not perfect, but it seems to blend the best of native compilation with what we expect on rich, high level languages with garbage collectors.

I know of a few companies exploring (or using) Go to facilitate development of PaaS and IaaS solutions. I am not sure, however, if I would use it for application development as done in Java or C# however.

Re:But what is it used for?

[DrXym]

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 the traits they implement. The compiler gives meaningful errors too instead of an incoherent wall of screed that C++ outputs when some heavily nested inline code breaks using the type it was expanding to use.

I expect Go could do something similar except of course using interfaces instead of traits as the gatekeeper.

Re:But what is it used for?

[luis_a_espinal]

> 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 tool chain, and use the standard libraries except where there is a compelling reason to do otherwise. If there are bottlenecks in the standard tool chain then attack them. But don't mind me, sorry if it makes sense. I understand how NIH is so much more fun.

Everything you mentioned was already covered by Google's C++ style guidelines for years.

Re:But what is it used for?

[luis_a_espinal]

Have you seen modern OSes? New release of some Linux distro, please wait several DAYS while we recompile everything on some 64 core monster with 1TiB of memory and all SSDs to create an image. Same difference.

I was thinking the same thing. I have worked in large C and C++ (no templates, and limited inheritance) code bases for telecom. Millions of LOCs. We tried everything (unity builds, precompiled headers, etc) and still, compiling was a day-long effort.

This is no different from extremely large code bases. The project I work on, it's a day-long effort to build and release everything.

It's not sloppy project setup. Large code bases simply a lot of time and hardware resources to build and release.

And for a long time we have simply assumed this is just a suck we have to deal with... which was fine until general code bases started to explode in size (about 15-20 years ago).

Go attempts to solve that problem explicitly. Time will tell if the trade-offs (whatever they are) are compensated by the added value of speeding up build/release times on very large code bases.

Re: But what is it used for?

[Tough Love]

thanks for editing this out: "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."

Re: But what is it used for?

[Tough Love]

Go implements a M:N scheduler which is anything but 'naive'. https://morsmachine.dk/go-sche...

You are right, M:N is stupidly complex. And hard to get nice behaviour out of. The naive part is thinking that it's needed, at least on Linux.

Re: But what is it used for?

[Tough Love]

At least we all now understand that "goroutines" are just threads, with marketing. Right?

Re:But what is it used for?

[ooloorie]

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]

That's the same site I was looking at actually. Note that there are two kinds of results there: those where Go and C++ are comparable, and those where Go is several times slower than C++. It's the latter that tell you that there are significant bottlenecks in Go somewhere, and given that the language is 10 years old and they still show up, they can't be all that easy to eliminate. An "efficient language" shouldn't have any significant bottlenecks.

Re:But what is it used for?

[Raenex]

Yes, I know it has locks. So does Java. The "threads and locks" model (goroutines are essentially threads, no need to argue with me, I've seen you do it elsewhere), where the programmer has to figure out what to properly lock, is prone to bugs.

This is the same kind of mess when it comes to pointers, memory management, and C -- exactly the kind of mess Go and languages like Java left behind because it was such a mess. Go missed an opportunity to do something truly useful here.

Re:But what is it used for?

[TeknoHog]

There's this programmable cryptocurrency called Ethereum you may have heard of. It has multiple official implementations, including C++ and Python, but the recommended one is written in Go.

Re:But what is it used for?

[Lisandro]

Agreed. Keep in mind though Go is very reliant on the concept of channels and messages so you're not really expected to rely on concurrent access but it is, in the end, unavoidable on some situations.

Re:But what is it used for?

[Megol]

What is you alternative?
Reference counting? That's GC and commonly the slowest type of GC.
Having the compiler track allocations? Regions are also a type of GC.
Ownership types? I would still call that GC as things are tracked etc.
Doing it manually? It doesn't scale, it hard to do, fails often (catastrophically) and for any type of non-trivial task will add some kind of GC.

Re:But what is it used for?

[erapert]

Why are you using C instead of C++14 with Boost in the first place?

Re: But what is it used for?

[Tough Love]

The message I'm getting here is that there's a Go cult, and I'm being "messaged" by Go cultists.

Re: But what is it used for?

[Tough Love]

OK, I'll give you that if it's true. Has it been demonstrated? BTW, what's with the anon coward posts? If it's just because you don't normally post here then please bear in mind it's a bit like wearing nose glasses at a cocktail party.

Re: But what is it used for?

[Tough Love]

Now that I think of it, Linux may well be able to handle 1,000,000 threads natively. There isn't any actual limit, except memory for stacks.

Re: But what is it used for?

[lemire]

Go has some inlining, but it is fairly primitive compared to gcc. Even Java does better. Inlining is a very important part of an optimizing compiler... There are design reasons why Go might never match C with respect to function inlining. Bounds checking is still expensive in Go compare to Java... to say nothing of C. That might get quite a bit better over time as there is no reason for Go to do poorly in this respect. And if your code needs to call a C or C++ library (like, say, a video driver), Go makes you pay a high price. This might get a bit better, but only to a point. Go will never be as fast as C. Whether this matters is another story.

Re:But what is it used for?

[Tough Love]

Everything you mentioned was already covered by Google's C++ style guidelines for years.

But they still do insane things with templates anyway, and most probably flagrantly ignore the other good practices above and basically everything else in the style book, except possibly the whitespace rules. Don't ask me how I know, I just know.

Re:But what is it used for?

[Tough Love]

...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.

So instead of making a sensible investment in extending C++ with concurrency support it was decided to create an entire new ecosystem. Given a sufficient quantity of energy drinks and powerpoint slides, I can see how that made sense to someone in control of more budget than they knew what to do with.

Re:But what is it used for?

[K. S. Kyosuke]

Given the scale of their code, they probably deemed it the better option for them. Their choice... It also shields them from the vagaries of the C++ standardization folks, which must be nice for them in any case.

Re: But what is it used for?

[K. S. Kyosuke]

Pascal also has memory bounds checking and yet even old Delphi used to be pretty snappy. Why do you assume that Go can't approach C in performance to an arbitrary degree? As far as I know, the language was designed to have no obvious constructs with large hidden costs whatsoever. What design reasons prevent efficient inlining in your opinion?

Regarding C interoperability, yes, it has its limits at the moment. It's not a panacea. Whatever can be written in Go integrates already at the compiler level much better than C.

Re: But what is it used for?

[K. S. Kyosuke]

at least on Linux.

Here's the point I was trying to make elsewhere in the thread. On Linux. So you want a portable language perform well only on a selected platform? That's very likely the whole reason why they went for the scheme they went for!

Re: But what is it used for?

[K. S. Kyosuke]

Regarding passing types into other pieces of code, perhaps higher-order modules could be a language-nonintrusive solution.

Re: But what is it used for?

[K. S. Kyosuke]

No, I'm being dead serious. What you seem to be describing is interoperability of C++ with C++, which is of course very good. But it's also not interesting because it's taken for granted. It's not interoperability between two different compiled languages, such as Go and C++, or Lisp and C++. However, at least lower-level languages like C (NOT C++) have a decently standardized way of how to interoperate with the resulting code artifacts. C++ doesn't have it since the implementation of many features is unspecified in the standard - even just translation of type names ("mangling") is compiler specific. Going the through the "parse the interface definitions" route (the non-binary one - even required for some things, such as things involving templated types) is vastly more difficult as well because you end up with half a C++ compiler. So, in the case of those games, you still need to hook up any "external" code (in a different language) with greater rather than lesser involvement of the extant C++ compiler. (Those other languages are usually not so crazy as to expose C++ interfaces themselves, though - or at least not expose them as the only option.)

Re: But what is it used for?

[K. S. Kyosuke]

Also, those "languages [calling] functions directly out of a library that was compiled from C++" would still face the same problem - the need to get somehow at definitions and implementations of things for which binary objects are insufficient, such as anything residing in header files - regardless of what the language was written in. If I rewrite a Lisp implementation from Lisp into C++, even if the resulting program is still capable of compiling Lisp code, it still can't interface with new bits of C++ (for the reasons states) without the involvement of C++ tools. On the other hand, it can generally interact with C code (without a C compiler) either way, using various FFIs.

Re: But what is it used for?

[K. S. Kyosuke]

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

Well, it's conceptually almost identical with Oberon (with some extra sugar) which definitely is a systems programming language. I mean, if writing an operating system in it is a sufficient condition to qualify for that designation...

Re:But what is it used for?

[Tough Love]

Given the scale of their code, they probably deemed it the better option for them.

Given the scale of their code, it's a safe bet that the vast majority of it will stay exactly as it is.

Re:But what is it used for?

[Tough Love]

...It also shields them from the vagaries of the C++ standardization folks, which must be nice for them in any case.

Non-argument. If you don't like new features in C++ then don't use them. Your existing code will continue to work just fine. Personally, some of the recent additions are godsends. For example, have you ever tried to extend an STL container with a functor? Just disgusting. Lambdas (and std::function) are vastly superior.

Go is a very very nice language to work on

[Lisandro]

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

[chrism238]

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... where Go performs even better - except for jobs.

Re:Rather meaningless single value metrics

[ooloorie]

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

[MikeJones8766]

Anyone else find Go's syntax horrible and avoid the language completely because of it?

Re:Syntax

[doktor-hladnjak]

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

[ooloorie]

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:Syntax

[OrangeTide]

I like Go's syntax. But I'm also someone who has used mainly C for the last 20+ years.

Re:Syntax

[lgw]

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:Syntax

[K. S. Kyosuke]

That's because Oberon is one of Go's daddies. ;) Enjoy your flashbacks!

Re:Syntax

[erapert]

Their fascist insistence on using spaces for indentation guarantees I will never write anything with it.
If they fix that problem then I will give it a second look.

(also, I'm not alone on this. tabs are correct)

Re:Syntax

[doktor-hladnjak]

Actually, it uses tabs. But with go fmt, who cares?

Re:Syntax

[erapert]

go fmt replaces tabs with spaces does it not? Regardless, if go fmt is forcing everyone's code into a single style then that's fascist too, isn't it?

Why not just have a syntax and linter that doesn't require the formatting to be just-so in order to check for issues? Isn't it sloppy and fragile to require some weird syntax + formatting combo in order to reason about the source code?

Re:Docker and KUBERNEATO

[OrangeTide]

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:Another attempt to start anew...

[Lisandro]

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:Just a middle of the road language

[OrangeTide]

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 Google using Go more internally. Right now I think they're letting Rob Pike play with the language to figure out what to change about it before really committing to it in a big way.

There are already some fantastic programming languages that few bother using in production. The ML-family being perhaps the biggest productivity booster and more revolutionary than the usual C, C++, Java stuff that we typically find in the wild.

I bet half the people who said "C" actually

[melted]

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:I bet half the people who said "C" actually

[MouseTheLuckyDog]

Hmm. You can do C++ on a
Commodore 64

Re:I bet half the people who said "C" actually

[lgw]

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:I bet half the people who said "C" actually

[ShooterNeo]

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

[phantomfive]

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

You may disagree, but there are plenty of people who disagree with you.

Re:I bet half the people who said "C" actually

[BESTouff]

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:I bet half the people who said "C" actually

[serviscope_minor]

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.

Re:I bet half the people who said "C" actually

[AmiMoJo]

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:I bet half the people who said "C" actually

[goose-incarnated]

Also, the language used by the Arduino IDE is C++.

Sorry, no. It's a *subset* of C++.

Re:I bet half the people who said "C" actually

[Shane_Optima]

I bet half the people who said "C" actually meant C++. There's really no reason to use C...

Meh. Objective-C is a strict superset of C, not an "almost exact" superset. (You could cut and paste any snippet of C code into an Objective-C program and be guaranteed that it will function properly.) Furthermore, its message passing style objects (similar to Ruby's or Smalltalk's implemention of objects) are more powerful than C++'s objects in that they can parse or ignore the "message" (arguments) as they please.

It's a bit of a pity that Objective-C development is largely dominated by Apple (the result of Steve Jobs bringing his enthusiasm for NeXTSTEP with him when he rejoined), but it's entirely possible to write Objective-C applications for other platforms.

C++'s advantages largely emanate from its popularity--it's popular because it's popular, i.e. there are a bunch of self-sustaining advantages that come with popularity. In the hands of an expert, it's certainly not a bad language and when used correctly it can be considerably more powerful than C while remaining just as fast but taken as a whole, disregarding the advantages its momentum has given it... it's not a great language, and it never was.

I could go even further and argue that the noun-centric syntax favored by many OO languages (including many that use Smalltalk-style OO) is obnoxious and unnecessarily cumbersome, but that's a rant for another day.

Re:I bet half the people who said "C" actually

[NickFortune]

Yeah, but a lot of C++ types get really arsey with you if you try and use C++ as "a better C". If I wanted to write in C, I'd probably just write in C

Re:I bet half the people who said "C" actually

[serviscope_minor]

Another issue for embedded system is that C++ doesn't like type punning and other useful but potentially dangerous functions

It's got very similar rules to C. Type punning via char is certainly allowed: you wouldn't be able to implement memcpy without it, for example. Certain other types are explicitly allowed too.

Other types are deferred to the compiler vendor: neither standard can cuarantee what punning a float with a uint32 looks like, because neither standard mandates any particular format for floats.

These days the compiler understands bitmasking and bitshifting well enough that it will optimize a lot of it away and end up using assembly.

Also, goto makes C++ programmers cry.

It's never made me cry.

Re:I bet half the people who said "C" actually

[serviscope_minor]

Sorry, no. It's a *subset* of C++.

It's complete non-hosted C++, with templates, lambdas, namespaces, interitance, constexpr, r-value references, auto, and so on. The C++ standard notes that non-hosted platforms are not required to provide the standard library.

It has all the language features, however.

Re:I bet half the people who said "C" actually

[serviscope_minor]

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

To me, that sounds like you avoid C++ because you don't have a proper mechanism for doing code reviews. Out of interest, do you check to see if your C programmers are committing utter junk to the repository?

Re:I bet half the people who said "C" actually

[goose-incarnated]

Sorry, no. It's a *subset* of C++.

It's complete non-hosted C++, with templates, lambdas, namespaces, interitance, constexpr, r-value references, auto, and so on. The C++ standard notes that non-hosted platforms are not required to provide the standard library.

IIRC, a freestanding implementation still has to provide 'new', 'delete' and exceptions, none of which are capable within the avr-gcc + atmega328 that the arduino uses (last I checked, anyway).

Without exceptions you'd be awfully stupid to use constructors/destructors (can't return error values!), which means your composite objects will have to be written using functions to create and destroy them.

For all practical purposes, you would not be able to use classes because creation/destruction would occur without the user knowing about it. You'll run into a similar issue when you try to do polymorphism without exceptions.

So, yeah, it's a pretty significant portion of C++ that can't be used.

Re:I bet half the people who said "C" actually

[AmiMoJo]

To be fair, some C programmers wail in despair when they see a goto, myself included. It's more about where the code came from... I know some people who abuse goto and hate maintaining their code.

First thing I do with a new project is add -fno-strict-aliasing.

Re:I bet half the people who said "C" actually

[serviscope_minor]

IIRC, a freestanding implementation still has to provide 'new', 'delete' and exceptions, none of which are capable within the avr-gcc + atmega328 that the arduino uses (last I checked, anyway).

With exceptions: yes. I thought I read somewhere that had been done. Apparently not.

With new, that's only sort of true. The compiler provides new and delete as operators, but you'll get a link error since there's no runtime for them. You can of course few trivial functions along the lines of:

void* operator new(size_t s) noexcept
{
        return nullptr;
}

which fits the letter of the standard. The type of free store management you want on an AVR is almost certainly domain specific anyway.

The compiler also certainly supports placement new.

Without exceptions you'd be awfully stupid to use constructors/destructors (can't return error values!)

Depends on what you mean by "awfully stupid". It's very rare that throwing from a destructor is a good idea. There's also no harm in using constructors which have no error condition. There's not much problem with failing to acquire resources: all resources on such small devices are entirely statically determined.

For all practical purposes, you would not be able to use classes because creation/destruction would occur without the user knowing about it.

I don't see why that's a problem. Anyway, if you want a well-reasoned example, then there's this talk from the recent C++ conference:

https://www.youtube.com/watch?...

The guy writes a simple Pong for his Commodore 64 using C++17, and keeps rather close track of the asm code being generated. He uses classes, constructors, destructors, lambdas, templates and compile-time computation.

Re:I bet half the people who said "C" actually

[serviscope_minor]

First thing I do with a new project is add -fno-strict-aliasing.

Why?

Re:I bet half the people who said "C" actually

[T.E.D.]

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.

This. Little-known fact: You can actually have flat out SYNTAX ERRORS in a template, and nobody ever know until the day some poor bastard actually tries to *use* that particular implementation of that template. Otherwise (VC++ at least) will just make sure the curly-braces match, and then goes on its merry way.

Re:I bet half the people who said "C" actually

[T.E.D.]

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++.

C++ does indeed have a nasty propensity to feature bloat. However, this cure is as bad as the disease. C is a horrible language, and the only thing that gives C++ some small modicum of safety and appropriateness for large-scale programming is the stuff it added. If you don't like that stuff about C++, you should probably just be using a better language instead, like Ada or (if appropriate for the domain) Java.

Re:I bet half the people who said "C" actually

[lgw]

Terrifying in theory, but in practice anything without a unit test is broken anyhow, so it's not really so bad, The error messages on the other hand ...

Re:I bet half the people who said "C" actually

[melted]

As a side note, STL does not bounds check your array accesses (at least in optimized build) unless you use ->at() method. Square brackets operator is fully equivalent to that on a plain array and has the same speed. So fuzz your systems and use Address Sanitizer.

Re:I bet half the people who said "C" actually

[AmiMoJo]

Because I always end up type punning in short order.

Actually a lot of the libraries I wrote and the library code supplied by Atmel (ASF) requires it too.

Re:I bet half the people who said "C" actually

[serviscope_minor]

I mean, what do you use type punning for?

Re:I bet half the people who said "C" actually

[T.E.D.]

Terrifying in theory, but in practice anything without a unit test is broken anyhow, so it's not really so bad,

I'd kind of agree with this, except it actually happened to me in practice, and I can assure you that the thought that our unit tests were broken too (so it was actually twice-broken) was no consolation at the time. Particularly since I was at a customer site on another continent 7 time-zones away from anyone who could (twice) fix it for me...

The error messages on the other hand ...

OMG yes. At least up until C++11 *, "error novels" from nested templates was the single worst problem with the language. There are several Boost features I refuse to use to this day, after spending more than a week trying to get simple example programs to instantiate. If there's a compiler out there smart enough with its error reporting to make 3+ nested templates usable, it isn't any of the ones I've used.

* - I say "until C++11" because I haven't had a chance to fully grok the sheer horror of all the new 11 and beyond features yet. In particular, large nested inline lambdas seem to hold great promise in perhaps dethroning the embedded template error novel.

Re:I bet half the people who said "C" actually

[lgw]

Stroustrup had some good advice in one of his books on taming the error messages (basically, force instantiation of a method who's name was a clear error message). But that's obviously a hacky work-around to a language failing.

I'm eager to play with the new (ish) "concepts" (basically, interface definitions for templates) just because they seem like they should fix the template error mess once and for all.

You may be right about lambdas, but at least here doing something non-trivial in an unnamed function (and thus getting no useful logging or error messages) isn't a failing unique to C++.

Re:I bet half the people who said "C" actually

[goose-incarnated]

IIRC, a freestanding implementation still has to provide 'new', 'delete' and exceptions, none of which are capable within the avr-gcc + atmega328 that the arduino uses (last I checked, anyway).

With exceptions: yes. I thought I read somewhere that had been done. Apparently not.

With new, that's only sort of true. The compiler provides new and delete as operators, but you'll get a link error since there's no runtime for them. You can of course few trivial functions along the lines of:

void* operator new(size_t s) noexcept { return nullptr; }

which fits the letter of the standard.

I doubt it - the standard specifies the behaviour of new, The type of free store management you want on an AVR is almost certainly domain specific anyway.

The compiler also certainly supports placement new.

Without exceptions you'd be awfully stupid to use constructors/destructors (can't return error values!)

Depends on what you mean by "awfully stupid". It's very rare that throwing from a destructor is a good idea.

It's very common to throw from a constructor. In fact, that's the only way to signal an error in the constructor.

There's also no harm in using constructors which have no error condition. There's not much problem with failing to acquire resources: all resources on such small devices are entirely statically determined.

Memory, certainly. Nothing else, though. In embedded devices memory is statically allocated, but there are multiple *other* resources which can fail. Putting the initialisation in the constructor of a class while not being able to catch exceptions mean that the caller has no way to tell if a device is ready.

For all practical purposes, you would not be able to use classes because creation/destruction would occur without the user knowing about it.

I don't see why that's a problem.

It' a problem because double-initialisation (or double de-initialisation) of attached hardware almost always results in errors. An initialisation that occurs more than once is an error. Any initialisation needs to return error or success. Lacking exceptions, you can't put anything important in a constructor or a destructor.

So, sure, you can use classes, if you restrict yourself to classes with no exceptions, which means not using anything that relies on exceptions to signal errors. So, yeah, C++ works fine in embedded if you don't use constructors, destructors, overloaded operators, object assignment, object-as-parameters in function calls... probably a few other things too.

IOW, as long as you use a *subset* of C++.

Anyway, if you want a well-reasoned example, then there's this talk from the recent C++ conference:

https://www.youtube.com/watch?...

The guy writes a simple Pong for his Commodore 64 using C++17, and keeps rather close track of the asm code being generated. He uses classes, constructors, destructors, lambdas, templates and compile-time computation.

Very unimpressing indeed. The C64 had a ton of impressive software - a spreadsheet, first-person-view mazes, platformers... and yet using C++ he could only fit a pong clone into it? This example is a case *against* C++, not for it. FWIW, I wrote a pong clone for the C64 when I was 10, and I recall taking a single weekend to do it, using a fraction of the available ram. Why not compare the C++ pong with the existing pong binaries for the C64?

Re:I bet half the people who said "C" actually

[AmiMoJo]

One common example is comms code. On microcontrollers you want to statically allocate everything if possible, so you have an RX buffer that gets bytes from say a UART. The bytes need to be interpreted so while you can do things like massive unions it's usually easier to just type pun the hell out of it.

Re:I bet half the people who said "C" actually

[serviscope_minor]

char and unsigned char are exceptions to the strict aliasing rules. You're allowed to alias any POD data with either of those.

Also, incidentally, the following bits of code all yield almost identical assembler:

bool foo(unsigned char* a, unsigned short b)
{
        unsigned short c;
        memcpy(&c, a, 2);
        return c < b;
}

bool foo1(unsigned char* a, unsigned short b)
{
        int c = a[0] | (a[1]<< 8);
        return c < b;
}

bool foo2(unsigned char* a, unsigned short b)
{
        unsigned short *c = (unsigned short*)a;
        return *c < b;
}

The only differences are trivial (the order of operands to cmp and so setb vs seta on x86).

Personally, I tend to use a small family of functions like get16, get32 which get 16 and 32 bit values at the given pointer, which internally use code like the above. I tend to use the endian-agnostic shift-and-or style.

The trouble with enabling -fno-strict-aliasing is you lose a whole bunch of potential optimizations. Of course if your vendor requires it, then you don't have much choice.

Re:I bet half the people who said "C" actually

[AmiMoJo]

On AVR8 -fno-strict-aliasing makes little, if any difference because, well, it's an 8 bit RISC CPU so there is very little scope for that kind of thing.

I always use int8_t/uint16_t/etc too, because on microcontrollers things like int and short do vary in size a lot. On AVR8 they are both 16 bits, but on AVR32 and ARM they are the more common 32/16 bits respectively.

My colleague found an interesting silicon bug today. An 8 bit PIC uses paged memory with 256 byte banks. Turns out if you write the bank register while on page 15 under certain circumstances it ends up with a different value. Looked like a compiler issue at first, it was only once we single stepped through the machine code that it became clear.

Re:I bet half the people who said "C" actually

[serviscope_minor]

On AVR8 -fno-strict-aliasing makes little, if any difference because, well, it's an 8 bit RISC CPU so there is very little scope for that kind of thing.

Depends on what you do, but yeah probably true.

I always use int8_t/uint16_t/etc too, because on microcontrollers things like int and short do vary in size a lot. On AVR8 they are both 16 bits, but on AVR32 and ARM they are the more common 32/16 bits respectively.

Yes good point, it's generally good practice. That was me being lazy, though I think technically it's correct since int is guaranteed 16 bits or longer which is sufficient for that piece of code.

My colleague found an interesting silicon bug today. An 8 bit PIC uses paged memory with 256 byte banks. Turns out if you write the bank register while on page 15 under certain circumstances it ends up with a different value. Looked like a compiler issue at first, it was only once we single stepped through the machine code that it became clear.

Holy crap!

Wait, the bank register? That means you end up on the wrong page? Or does it mean that reading back the bank register gives the wrong page, but the access is on the right one.

Either way it's a really nasty bug.

I don't think I've ever used a PIC with that many banks. I've used the 16F877 years ago which IIRC has 4, and more recently some 12F675s which only have 2 banks.

Re:I bet half the people who said "C" actually

[david_thornley]

To be specific, it doesn't have to bounds check your array accesses. It can if it decides to.

Stroustrup suggested considering a MyVector template that exchanges the operator[]() and .at() functions for safety.

Re:I bet half the people who said "C" actually

[AmiMoJo]

It was one of the PIC18 series I think. I don't have all the details to hand but writes were going to the wrong page and then by chance the compiler reset the bank register before reading the bytes back out again. We could see the data on the wire, in the UART FIFO... And then by the time it hit the break point it was gone.

Re:I bet half the people who said "C" actually

[david_thornley]

C++ is perfectly usable as a better C. What generally annoys us is when people think that's all C++ is, or refer to "C/C++" as if they were very similar languages, or criticize C++ on the basis of pre-standard implementations or ignorance (criticizing it for having a difficult learning curve is fine; unlike criticizing it because you don't know it - although that's been at least 75% of language flame wars for as long as I've been in the internet).

Re:I bet half the people who said "C" actually

[serviscope_minor]

Out of interest did you ever find which bank it was writing into, and if it was consistent and repeatable? Also, the million dollar question: did Microchip respond?

Re:I bet half the people who said "C" actually

[AmiMoJo]

We could see which bank it was writing to, but I forget now. It was one bit out, a high order bit.

Years ago we contacted Microchip about these things, but all that ever happened was an errata and an apology so these days we rarely bother. I usually post Atmel bugs on AVR Freaks though.

Re:I bet half the people who said "C" actually

[serviscope_minor]

We could see which bank it was writing to, but I forget now. It was one bit out, a high order bit.

How fun, for certain values of fun.

Years ago we contacted Microchip about these things, but all that ever happened was an errata and an apology so these days we rarely bother. I usually post Atmel bugs on AVR Freaks though.

I guess there's not a vast amount they can do, at least until they respin the next version of the hardware. At least an errate might make it easier for the next guy :)

I did contact TI with an error in one of their datasheet application notes. They never acknowledged it and simply deleted that bit from the next revision of the datasheet even though the fix was trivial (they'd mistakenly drawn one wire connected to -VE instead of ground). I was a bit miffed they didn't even bother with an apology or thankyou.

Re:I bet half the people who said "C" actually

[AmiMoJo]

Are least microchip are friendly. They tend not to fix things, just note them in the errata, because any change could break someone's product. They are very conservative like that, and often it's not with doing a rev B model.

Re:I bet half the people who said "C" actually

[NickFortune]

I never said it wasn't usable as a better C - quite the opposite in fact. It's just that any time you try and use it that way, some people will get on your case because they automatically assume that you're using that way out of ignorance. Which isn't always the case.

Re:I bet half the people who said "C" actually

[serviscope_minor]

Are least microchip are friendly.

Beats TI. I've also had great customer service from Linear about datasheet errors, ones that actually matter. They got an engineer in the loop really fast. And in relation to another question, sent me an internal presentation with some circuits on in addition to the application notes.

They tend not to fix things, just note them in the errata, because any change could break someone's product. They are very conservative like that, and often it's not with doing a rev B model.

I can understand that point of view. It's actually a massive pain in the arse for certified things like medical devices. If the revision number of the chip changes, you have to re-certify your device. Also, I can see why they don't want people's devices to suddenly break.

Re:I bet half the people who said "C" actually

[AmiMoJo]

We have that issue with modem firmware versions. You order a particular version but half the time you get a different one, with different bugs and it messes up your approvals.

Re:Another attempt to start anew...

[OrangeTide]

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:Docker and KUBERNEATO

[OrangeTide]

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:Docker and KUBERNEATO

[GuB-42]

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:Another attempt to start anew...

[PhrostyMcByte]

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. 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 tell you. Their language might do some specific thing better, but it's really only a little bit better, certainly not enough to switch to it. Most coders have at least a few different go-to languages to cover a wide breadth of problems, and adding an extra language just doesn't add any value.

Re:Another attempt to start anew...

[Tough Love]

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:Docker and KUBERNEATO

[lgw]

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:Another attempt to start anew...

[larsl]

GET OFF MY LAWN, KEN THOMPSON.

https://en.wikipedia.org/wiki/Go_(programming_language)

popularity != a good thing

[Gravis Zero]

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.

[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.
   

Re:Tiobe's ranking system gets confused easily.

[Big Hairy Ian]

Mod parent up!

Re:hogwash

[K. S. Kyosuke]

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:Another attempt to start anew...

[K. S. Kyosuke]

They're not making the language for you. They're making it for themselves, and as a courtesy, they offered it to you if you find it convenient (it doesn't cost them anything), and it you don't like how things are, you can feel free to implement things that you need but they don't.

How do you measure Google's language popularity?

[m.alessandrini]

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

Re:Another attempt to start anew...

[serviscope_minor]

Rob Pike is hardly a kid.

No, but he is astonishingly arrogant, see for example:

https://commandcenter.blogspot...

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:Another attempt to start anew...

[Tough Love]

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:hogwash

[Raenex]

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".

Re:Another attempt to start anew...

[K. S. Kyosuke]

You could say exactly the same thing about their extant code base of C++ services. Google employees are paid to not complain about those either.

Re:Another attempt to start anew...

[AmiMoJo]

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:Another attempt to start anew...

[Viol8]

There are some fundamental things a language needs to be able to do to be seen as a serious replacement to C or C++ which is what Go is aiming for. And one of those things is being able to dynamically load shared object files. This is not up for debate.

Re:Another attempt to start anew...

[AmiMoJo]

What makes you think the goal is to replace C/C++? They are are trying to replace it for certain uses, not as a generic do-all language.

Re:Go's relationship with Docker?

[Jamie Lokier]

It's because Docker is written in Go, and it's one of the most high profile Go projects.

http://www.slideshare.net/jpet...

Re:Another attempt to start anew...

[mi]

The lack of shared libraries are an intentional feature of Go.

I know, it is intentional. I just think, it is a flaw, rather than a "feature".

Generally in a cluster environment they cause more problems than they solve.

Not true at all. Apache is regularly used with shared modules — though it is possible to compile modules in, nobody really does that in practice, and some functionality is only available from vendors in a form of precompiled shared library.

Java, Perl, Python, TCL, PHP all make use of run-time loadable shared libraries — solving problems, which Go can not solve without fully recompiling one's application every time.

There isn't anything fundamentally special about Go that ...

Stop it right there. Simply, there is not anything fundamentally special about Go. Period.

There is an open bug to track it, and while the bug is very old, it still gets regular updates.

Well, that's a relief...

If you make a HelloWorld app, then the big bloat in your app will be the garbage collector.

Why can't that boilerplate, that's included into every Go-built executable, live in some kind of libgo.so, so that multiple Go-apps on the same system can share the bloat?

You should settle on a Go program of any significance being about 2MB to 10MB

Why TF should I "settle"? If I have 3 programs, that all need to parse JSON, for example, why must each one of them include the entire JSON-parsing functionality in its own executable, instead of sharing? And then, when whatever 3rd-party that maintains the JSON-parsing code releases a critical update, I have to recompile all of these executables — instead of simply replacing one library... Are you telling me, this is, somehow an advantage?

Yes, modern machines have so much RAM and other resources, a developer and a sysadmin can get away placing their own convenience over performance. Puppet and Sensu, for example, both come with their own version of Ruby bundled — few people are bothered by the fact, that the two always-running daemons, both implemented in Ruby, would not — without some work — share the same Ruby-environment.

Similarly, Java-apps are usually shipping with their own JRE included — and it is not uncommon to find multiple instances of, say, Tomcat on the same machine running under different Java-versions — a waste of tens of megabytes of RAM.

But, at least, a competent DevOps department can take measures to avoid such waste. You can convince a Java and a Ruby app, it is Ok to run under JRE or Ruby of your choice. Go makes that flat out impossible, because everything is thrown into one executable... For your convenience — don't you worry your pretty little head.

Which takes me right back to my usual rant... Per Moore's law, our computers today are 1024-times more powerful than they were 15 years ago. Do you think, your user-experience, however you choose to quantify it, has improved 1000 times? I certainly don't... Today's desktop-environments and browsers are better than they were then, but not by a factor greater than 5. The rest of the stupendous hardware advances were "eaten" by the sloppy developers (and sysadmins/operators) instead of being passed on to users.

Re:Another attempt to start anew...

[amiga3D]

I saw what you did! You called him an asshole!

Codologist? [Re:Another attempt to start anew...]

[Tablizer]

There are room for specialists in programming languages in terms of their compromises and what feature combos organizations need and don't need. Sure, there are technical "compiler experts", but the human and staffing side are also key, and under-studied.

Let's face it, programming is mostly a dead-end career (for good or bad), as stats show, meaning programmers have to absorb languages and applications coded in them quickly, and then they move on to project management, QA, sales, outsource contract management, or something else eventually.

If you master something others find esoteric, it can cause staffing headaches for the org. In my experience orgs really hate that. Thus, the language has to more or less cater to the lowest common denominator.

Most of the staff-level problems are dealing with screwy frameworks and API's anyhow; the language itself is kind of a secondary concern.

Searching for Go?

[aoism]

I've done a few projects in Go. I'm not a huge fan, but I think it has its place, and would much rather write a microservice in Go than in some travesty like NodeJS. What bugs me about the way they ranked is is search engine queries. Anyone who has tried searching for anything with 'go' in the query will find a lot of useless results returned. Google itself takes extra steps to ensure their language is returned in these queries on google, but in many other engines it's ambiguous as to what you mean when you type 'go to beginning of loop'. Are you looking for a rewind, or are you looking for loops in go? If they limited this to 'GoLang', I'd feel much better, but I can't find out how they ranked it, and am afraid they are including questionable results in their indexing.

Arduino uses C++

[melted]

Your point is invalid.

Re:Codologist? [Re:Another attempt to start anew..

[Tablizer]

Grammar correction: "There is room for specialists..."

Modnays.

Meant to respond to a guy two posts above

[melted]

Sorry.

Re:Another attempt to start anew...

[OrangeTide]

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".

There are only so many hours in a day. People are contributing their own things to the language and libraries, but I'd say that the core set of people were in the camp of static linking.

You'll find some level of personal preference in pretty much any new language project. It's inescapable.

Re:Another attempt to start anew...

[OrangeTide]

I admit to not knowing C++ well either, I've only used it for a decade, that's hardly enough time to become familiar with C++. I generally hand off C++ projects to my coworkers who have invested far more of their time in learning and tracking C++ than I have.

Rob Pike has some experiences with programming languages that I find valuable, so for me I am willing to take a look at what he has to say on the topic in the hope there might be some gems.

Re:Another attempt to start anew...

[OrangeTide]

Not true at all. Apache is regularly used with shared modules — though it is possible to compile modules in, nobody really does that in practice, and some functionality is only available from vendors in a form of precompiled shared library.

I'm not saying it's not possible, only that it's undesirable. It's undesirable to wrestle with ABI and version hell when you have to distribute your software across 1000 nodes of a cluster. It's certainly not the biggest difficulty in clustering, but why take on something that doesn't offer value and usually reduced performance and reliability in the field?

Re:Another attempt to start anew...

[TodPunk]

I think it's mostly all the hype and articles claiming "Go is a C/C++ replacement." We could give them a pass and assume they mean "Go is a C/C++ replacement in some narrow Google-like scenarios" but all too many discussions couch it as ALSO a replacement for Python or Java. We could also try to be nice and state that the project maintainers are not trying to say this "replace C/C++" angle is valid, except Rob Pike says things like "although we expected to C++ programmers to see Go as an alternative..." and such, which isn't a great PR statement if you're trying to say it's not supposed to replace C++.

Yes, I'm aware they're not equivalent. No, social dynamics and public relations don't care, and if we expect them to we're idealists or idiots or both. Thus, to the greater populous, Rob Pike was quite literally trying to replace C++ and if he wants a different perspective to the greater populous he needs to change his tune. (full disclosure, my one quote is from 2012, though others exist that are more recent if one cares to get pedantic about this).

See also: this very article and the commentary about it here.

Re:Another attempt to start anew...

[david_thornley]

More specifically, paid not to complain about the Google C++ style guide, which makes sense only for restricting C++ code to be safe for newbies. There's LOTS of languages that are better than Google C++ (including, of course, C++).