Interviews: Ask Alan Donovan and Brian Kernighan About Programming and Go

Alan Donovan is a member of Google’s Go team in New York and holds computer science degrees from Cambridge and MIT. Since 2005, he has worked at Google on infrastructure projects and was the co-designer of its proprietary build system, Blaze. Brian Kernighan is a professor in the Computer Science Department at Princeton University. He was a member of technical staff in the Computing Science Research Center at Bell Labs, where he worked on languages and tools for Unix. He is the co-author of several books, including The C Programming Language, and The Practice of Programming. Recently, the pair have co-authored a soon to be released book titled The Go Programming Language. Alan and Brian have agreed to give us some of their time to answer any questions you may have about the upcoming book, Go, and programming in general. Ask as many questions as you'd like, but please keep them to one per post.

Comments

OpenGL and LockOSThread

[Anonymous Coward]

Hi, I've stopped using Go when I saw the hacky stuff I need to do to get libraries like OpenGL to behave correctly. (see https://github.com/golang/go/wiki/LockOSThread) Are there any plans to fix this?

Re:OpenGL and LockOSThread

[genocitizen]

Not sure there is anything to fix there... Have you given a look recently to https://github.com/go-gl ? The main issue here is that you need a specific goroutine to "sit" on a specific thread and process your OpenGL flow; it's already covered with some hacks, AFAIK.

Re:OpenGL and LockOSThread

[OrangeTide]

Yes, OpenGL is a big hack. Why is this Go's problem?

Re:OpenGL and LockOSThread

[genocitizen]

AC was referring to the fact you need to run all OpenGL code from same thread. Go's goroutines are not guaranteed to run on same thread (unless you do some black magic sorcerery).

Re:OpenGL and LockOSThread

[bzipitidoo]

Why even use OpenGL directly? It's been called the assembly language of graphics. It has no brains when it comes to sorting polygons by visibility, it just dumbly draws everything in the list your program builds for it, whether visible or not. It's up to your source code to employ a little algorithmic cleverness to prune the list. But even if you do, you soon find that unless the pruning is very good, performance is still unsatisfying. To make the pruning excellent requires implementation of some fairly complicated algorithms.

I'd much rather use a library such as OpenSceneGraph or OGRE.

Re:OpenGL and LockOSThread

[Anonymous Coward]

>it's already covered with some hacks

Probably why OP mentioned he stopped using it because of all the hacky stuff.

Re:OpenGL and LockOSThread

[Austerity Empowers]

Because, quite often, you don't want to use a library. I like Ogre, but I do a lot of OpenGL stuff too, it's just convenient when you have simple scenes. This is more common than it may seem, I have several tools I support for my team (or have supported in the past) that are just very simple OpenGL calls.

Re:OpenGL and LockOSThread

[Anonymous Coward]

Instead of linking your app to OpenGL you can instead create a separate process that will do that and communicate to it through a socket. You know, like X11 does. This way you are not putting driver guts in your process space like Win 3.1 used to do. See http://msharov.github.io/gleri... for an example.

Re:OpenGL and LockOSThread

[luis_a_espinal]

AC was referring to the fact you need to run all OpenGL code from same thread. Go's goroutines are not guaranteed to run on same thread (unless you do some black magic sorcerery).

A deficiency that's not Go's problem to solve IMO.

Re:OpenGL and LockOSThread

[NostalgiaForInfinity]

Yes, OpenGL is a big hack. Why is this Go's problem?

The world is full of "big hacks" and shitty software, so languages that can't deal well with such systems aren't going to cut it. In different words, it's Go's problem because users aren't going to use Go if they can't get their work done in it.

Re:OpenGL and LockOSThread

[NostalgiaForInfinity]

A deficiency that's not Go's problem to solve IMO.

So you're saying that people should adopt Go only once all the major deficiencies in other common software systems have been addressed? That's going to be when hell freezes over.

(In addition, there are reasons for why OpenGL is the way it is; it's not a deficiency, it's a tradeoff.)

Re:OpenGL and LockOSThread

[guruevi]

You have obviously no idea how the lower-level architectures of your computer operate.

On some platforms (eg. Intel), a single processor will have access to only a portion of the busses (eg. the PCIe bus and the memory). So anything that has access to specific hardware (say a GPU or a specific memory area) has to run on a specific processor (and that is done at a higher level by keeping it in the same thread). Sure you can go about it by doing an (automatic) memcpy every time you need to switch physical processor but that makes things more complicated and uses resources unnecessarily, especially if you cannot guarantee which processor your language will be using next.

There are certain things you can not abstract away in a lower-level programming language. If you as a programmer want to avoid 'seeing' that, you use Python (and even then, certain low level things are simpler implemented in C).

Re:OpenGL and LockOSThread

[OrangeTide]

Maybe switch to Vulkan.

Re:OpenGL and LockOSThread

[OrangeTide]

Heh, I'm an engineer at a graphics card company and part of architectural team there. So perhaps you have me confused with someone else and took my comment in a completely different context than I intended.

I have a love hate relationship with OpenGL, my accusation that OpenGL is a hack is perhaps a tad hyperbolic. I see a lot of the warts having to work with the driver details for a living (system sw team), but it is interesting to work on and does feed my family.

Re:OpenGL and LockOSThread

[Anonymous Coward]

Does Go have a from future import feature?

According to wikipedia Vulkans initial release is: Late 2015 (expected).

Re:OpenGL and LockOSThread

[Anonymous Coward]

Wow how embarrassing for you. I'd probably have said nothing except for you obviously have no idea how to engage with remarks you disagree with without expressing contempt.

Re:OpenGL and LockOSThread

[Anonymous Coward]

guruevi wasn't talking to you; he's addressing the direct parent of his post, which is this claim by luis_a_espinal:

A deficiency that's not Go's problem to solve IMO.

In context, luis_a_espinal is making the dubious claim that Go doesn't need to support APIs which are not thread-safe, such as OpenGL.

Re:OpenGL and LockOSThread

[luis_a_espinal]

A deficiency that's not Go's problem to solve IMO.

So you're saying that people should adopt Go only once all the major deficiencies in other common software systems have been addressed? That's going to be when hell freezes over.

(In addition, there are reasons for why OpenGL is the way it is; it's not a deficiency, it's a tradeoff.)

I didn't say that, but I'm not here to work over your deficiencies in reading comprehension. Therefore, I will let you assume I answered your question in the affirmative.

Re:OpenGL and LockOSThread

[Anonymous Coward]

I didn't say that,

Obviously, you have trouble not only with the basics of real-world software engineering, but also such elementary concepts like "rhetorical questions" and "sarcasm".

Re:OpenGL and LockOSThread

[luis_a_espinal]

guruevi wasn't talking to you; he's addressing the direct parent of his post, which is this claim by luis_a_espinal:

A deficiency that's not Go's problem to solve IMO.

In context, luis_a_espinal is making the dubious claim that Go doesn't need to support APIs which are not thread-safe, such as OpenGL.

It is not necessarily a dubious claim. We could take it as an architectural decision from Go. C computing model and semantics have no notion of non-nullable pointers. Or Java computing model has no notion of direct addressing. There is nothing peculiar then that Go's computing model does not provide out-of-the-box support for non-thread-safe code.

And whether non-thread-safety is required by low-level computing, that is irrelevant to the definition of a deficiency. Non-thread-safety is a deficiency, even if it is also a useful trade-off when programming at the low-level. All trade-offs, however useful they might be, involve deficiencies. If they didn't, then they would not be trade-offs, but perfect solutions.

Re:OpenGL and LockOSThread

[luis_a_espinal]

You have obviously no idea how the lower-level architectures of your computer operate.

On some platforms (eg. Intel), a single processor will have access to only a portion of the busses (eg. the PCIe bus and the memory). So anything that has access to specific hardware (say a GPU or a specific memory area) has to run on a specific processor (and that is done at a higher level by keeping it in the same thread). Sure you can go about it by doing an (automatic) memcpy every time you need to switch physical processor but that makes things more complicated and uses resources unnecessarily, especially if you cannot guarantee which processor your language will be using next.

There are certain things you can not abstract away in a lower-level programming language. If you as a programmer want to avoid 'seeing' that, you use Python (and even then, certain low level things are simpler implemented in C).

I actually do know how low-level architectures operate. The limitations that you describe imposes OpenGL to operates with a certain trade-off (lack of thread-safety), which incurs in a deficiency. A trade-off will always incur in a deficiency, however useful a trade-off is. If it weren't, then it wouldn't be a trade-off, but a perfect solution, like, I dunno, a unicorn that farts confetti while carrying cute bunnies into the sunset or something.

From Go's POV, its current computing model won't support non-thread-safe code (maybe never). That is also a trade-off (and thus a deficiency), but that it is model. And on that model, then it doesn't have to support OpenGL model.

It just fucking doesn't. That is not what it is for (just like Java computing model will never support direct pointers to memory.)

So what do you do in such situations when you want to integrate such disparate computing models? One word: shims. You create a shim. Let OpenGL run in its own real, and have the higher-level client side (in this case Go) communicate with it through that shim.

A hack? Fuck yeah, but welcome to the real world. You want to glue two different computing models together, guess what, you need a shim. I've actually have to do such things when having to integrated managed code (Java or .NET) with raw, native code or drivers.

Welcome to the world of trade-offs. Computing model A does not have to support computing model B just because the A-B shim is a PITA to develop.

Re:OpenGL and LockOSThread

[Anonymous Coward]

Being an engineer at a graphics card company and obviously having no idea how computer architecture works are not mutually exclusive. Just ask AMD.

Wisdom of naming it "Go"

[ZeroPly]

There's already a game called Go, which has about a gazillion articles on how to program it. Couldn't you come up with a name that would be less ambiguous? Now, when you see a user group for "Go programming", you have no clue which one it is.

Re:Wisdom of naming it "Go"

[JoshuaZ]

I agree. I saw the headline and thought I was going to see an interesting article about Go and computers, maybe something explaining in detail how Monte Carlo methods have made Go programs much more successful than the older brute force used to be. But nope. Maybe someone should write a program in Go to play Go for maximum confusion.

Re:Wisdom of naming it "Go"

[eldavojohn]

There's already a game called Go, which has about a gazillion articles on how to program it. Couldn't you come up with a name that would be less ambiguous? Now, when you see a user group for "Go programming", you have no clue which one it is.

In conversation, I refer to it as golang. You are right on your point about potential for confusion but I don't think your example is apt anymore. Googling for programming go appears to yield only results about golang. Also, it is not without tangential benefits like being able to call Go developers "gophers."

I think when I first started programming Groovy long ago I stumbled upon a website promising that software development was groovy ... that's no longer the case when I google for groovy programming resources.

In short the success of your language is a big enough concern than the name of your language is negligible (with the exception of negative words). The search results will follow.

Re:Wisdom of naming it "Go"

[Anonymous Coward]

So to add to your sibling post from JoshuaZ to "write a program in Go to play Go for maximum confusion," a go (lang) developer (gopher) should write a gopher client.

Re:Wisdom of naming it "Go"

[McGruber]

Couldn't you come up with a name that would be less ambiguous?

Forth was already taken.

Re:Wisdom of naming it "Go"

[OrangeTide]

why couldn't the name have been a SHA-256 hash of the initial specification document or a UUID. So instead of "Go" we could all say "one two three echo four five six seven dash echo eight nine bravo dash one two delta three dash alfa four five six dash four two six six five five four four zero zero zero zero". Then it wouldn't be ambiguous and unlikely to have search collisions if you search as "123e4567-e89b-12d3-a456-426655440000"

Re:Wisdom of naming it "Go"

[fnj]

Go and Rust are both stupidly named. Try googling "go" or "rust". It's hopeless.

Re:Wisdom of naming it "Go"

[MountainLogic]

This is a common problem for products in English. You can overload a name with something common such as Go, C or Forth and have name collision or make up something new such as GoLang and have to educate people.

Re:Wisdom of naming it "Go"

[BadDreamer]

The problem is for us who want to read about programming Go, the strategy game, and don't care in the least about some new, fancy programming language.

Re:Wisdom of naming it "Go"

[Anonymous Coward]

Exactly. If I search for "C" only three of the top ten results are about the programming language.

Re:Wisdom of naming it "Go"

[Anonymous Coward]

here's a google "hack": if you google "rust" (don't type the quotes) you come up with results on the game. If you google "rust -game" you'll find that all but one of the results on the front page are about the language. I suggest you look into search operators, they'll make looking for things a whole lot easier.

Re:Wisdom of naming it "Go"

[rastos1]

I guess you run IPv6 only and without any DNS, right?

Re:Wisdom of naming it "Go"

[behrooz0az]

You may call that program Goto

Re:Wisdom of naming it "Go"

[Anonymous Coward]

"Go strategy game"

"Go language"

"Go english word"

"Go eff yourself"

You could just do that.

Re:Wisdom of naming it "Go"

[OrangeTide]

And open myself up to DNS hijacking? Some of us care about security.

Re:Wisdom of naming it "Go"

[Chalnoth]

That's why "golang" is frequently used to explicitly refer to the language.

Re:Wisdom of naming it "Go"

[Anonymous Coward]

My preferences would be "Go-go Dancer" or "Go Go Power Ranger"

Why the hell would anyone use Go?

[xxxJonBoyxxx]

Why the hell would anyone use Go?

(Serious question, since our editors didn't tell us why Go was created, what Go's intended purpose was and whether or not anyone is actually using Go.)

Re:Why the hell would anyone use Go?

[eldavojohn]

Why the hell would anyone use Go?

(Serious question, since our editors didn't tell us why Go was created, what Go's intended purpose was and whether or not anyone is actually using Go.)

As a software developer here that likes to fiddle with all languages, the second paragraph from Wikipedia seems to answer your question nicely: "It is a statically typed language with syntax loosely derived from that of C, adding garbage collection, type safety, some structural typing capabilities,[2] additional built-in types such as variable-length arrays and key-value maps, and a large standard library."

So from the first few words someone might know C and desire garbage collection to be handled for them? Golang might be a better selection for them than Java.

Personally for me, the built-in primitives for concurrency make it a great language for tinkering in realms of software design that were once onerous to me. But that's only one of a few of the language's goals.

Maybe a better set of questions would be for an elevator pitch on why someone should use golang? Or perhaps if they have dropped some goals of golang for others as development went forward?

Re:Why the hell would anyone use Go?

[Anonymous Coward]

Your condescending attitude is quite possibly less constructive than the terse post you are criticizing. I think many, if not most, visitors here will feel that Go looks more like a solution in search of a problem. The other reply that took a constructive approach (rather than your pedantic whining) offers some nice improvements but the question is still valid.

Re:Why the hell would anyone use Go?

[xxxJonBoyxxx]

>> Hi! It looks like you're swearing...

Clippy is that you? Were YOU written in Go?

Re:Why the hell would anyone use Go?

[Assmasher]

This.

We use it in very specific places because it works well there (some of our services junctions points) and has excellent concurrency primitives. This lets us overlook the drawbacks that would arise by using it as a general purpose language. I suspect that we use it in the fashion that Google initially intended to use it (they use it much more pervasively now I believe.)

Re:Why the hell would anyone use Go?

[KGIII]

Keep bringing up Clippy and, I'm telling you, I'm going to write Clippy for the terminal and get it included in the Linux Base. Don't make me do it. I have gifs and enough source code to copy. I'll make it work with *every* prompt...

$ ls -lah >> foo.txt

(Clippy) Hi! It looks like you're trying to generate a list, would you like some help with that?

There are enough examples so that even *I* can write that. Pfft... Gimme a little and I can package it as a .deb and get it up on launchpad. I then tie it in to systemd and it'll get included by default. Hmm...

$ journalctl

(Clippy) Hi! You're looking for binary error logs? Would you like some help with that?

Clippy touched me in bad places.

Re:Why the hell would anyone use Go?

[Anonymous Coward]

1) You run a company wanting to hire the cheapest code monkeys you can get. Go is simple, not to help you program, it is simple to help your boss find the next replacement. It was conceived at a time most silicon valley companies collaborated to keep developer salaries artificially low.

2) You recently awoke in a hospital, 23 years after some unspecified accident. Go is the language just for you, none of these newfangled languages or features, Go is purely inspired by Modula, Oberon and K&R C the keystones of modern day programming. Start using it now and feel like you haven't missed anything in the last two decades.

C vs Go

[claude.j.greengrass8]

How does 'The Go Programming Language' compare to 'The C Programming Language'?

Re:C vs Go

[Anonymous Coward]

How does 'The Go Programming Language' compare to 'The C Programming Language'?

Well, it's about twice as verbose, but it has a vowel, so that might be considered a plus.

Re:C vs Go

[fyngyrz]

'go' is clearly exactly twice as difficult and complex to write as is 'c' - and there you have it.

Re:C vs Go

[Anonymous Coward]

It does have the edge over c++.

Re:C vs Go

[bobbied]

How does 'The Go Programming Language' compare to 'The C Programming Language'?

About as well as Java compares with "C" and in almost exactly the same ways.

Re:C vs Go

[Anonymous Coward]

Binary files cc and go differ.

Re:C vs Go

[KGIII]

Yes, but that means it's on par with C#.

Re:C vs Go

[psmears]

How does 'The Go Programming Language' compare to 'The C Programming Language'?

About as well as Java compares with "C" and in almost exactly the same ways.

That's doing Go a massive disservice; Go differs from Java in very significant ways. To name but a few:

• Go's source code is much less verbose (due to deliberate decisions on the part of the designers)
• Go produces (by default) native static executables, so no need to bring a JVM before you can run your code
• Go compiles to native machine code (not bytecode), so there is no JIT warm-up penalty
• Go's concurrency model is much more sophisticated than Java's - making it much easier to write concurrent programs that behave correctly

In fact, apart from having garbage collection, Java and Go are really not that similar (within the realm of somewhat-compiled imperative languages).

Re:C vs Go

[bobbied]

Being less verbose isn't necessarily a good thing. All it really does is abstract away behind keywords and syntax the complex things that are really going on. Where it's not a bad thing when done well, it does make the language harder to learn and use well. My favorite example is C++ constructors/destructors and variables going in and out of scope in the middle of a statement sometimes, if you don't understand why all this happens, why the compiler hid this activity, you can get yourself into serious trouble and not know why. So Abstraction isn't always a good thing.

Yea, the source is smaller and it goes directly into native a executable, but it still carries similar overhead of the garbage collection and all the stuff they hide from the programmer by abstraction, just like Java. Did they do a better job? Perhaps...

More sophisticated concurrency model? Perhaps, I'd say it's more abstracted away so you may not have to worry about it, usually, but that must means it's going to be harder if your problem doesn't fit well in their concurrency model. (Need we discuss Open GL?)

But where "go" and "Java" differ, they are extremely similar looking when you compare them to "C". Which is my point. I'm not dissing Go or Java, nor am I saying they are exactly the same, only that they are, from the prospective of "C" programmers, pretty similar.

Re:C vs Go

[psmears]

Being less verbose isn't necessarily a good thing.

Definitely agree - sometimes being explicit is better. But this is definitely an area where Java and Go take very different approaches.

More sophisticated concurrency model? Perhaps, I'd say it's more abstracted away so you may not have to worry about it, usually, but that must means it's going to be harder if your problem doesn't fit well in their concurrency model. (Need we discuss Open GL?)

Actually the OpenGL thing is solved fairly easily - but in general this is a valid observation; my point is that Java's approach (with explicit threads, synchronisation etc) is much closer to C's than Go's is.

But where "go" and "Java" differ, they are extremely similar looking when you compare them to "C".

And my point is that's clearly not true - apart from garbage collection, the two languages have relatively little in common; they may both do more abstraction than C, but what they choose to abstract, and how they implement it, is very different.

Why was package versioning left out?

[genocitizen]

Why was package versioning left out? And are you guys still fond of this decision? As I use Go more and more I see this to be the weak spot; software has been around for many decades, and we all know that it is continuous evolution. Go's import system does not allow specifying or hinting a version, nor does the `go get` command (although it supports major VCSes), and that's how hacks like gopkg.in have been conceived. And it's not like package managers for other languages haven't already solved in a more or less elegant way the problem already...

Re:Why was package versioning left out?

[TopSpin]

I'd be a Go programmer today except for this. Every major programming platform in use today has a module system to manage dependencies except Go. Go gives you "go get" to haul gobs of source into your tree, after which you get to build and maintain the mess.

The Go folks cop-out and say this problem is one "for the community." Well, it has been six years and "the community" is still schlepping around, making messes with "go get" and inventing bad workarounds for the projects.

Got a plan for this? You should.

Re:Why was package versioning left out?

[genocitizen]

I've seen people not updating 'master' of their git repository because of this...utterly ridiculous. It makes new releases difficult to adopt and becomes soon detrimental to change in general. The package managers which have been developed (Godep, gb, glide) are not of the quality you would expect to professionally use Go...I've found issues with all of them (I know they're in high flux, but still).

Re:Why was package versioning left out?

[TopSpin]

One of Google's core Go developers addressed this "master" problem at a golang conference some time ago. He said Go developers are expected to keep master clean. Maybe that works inside Google, where employees must adopt the policies of their employer. For the rest of the world this has been a terrible policy; whatever time one is supposed to have saved with simple abstractions and fast compilers is utterly pissed away herding dependencies and fixing breakage due to changing masters.

Builds must be easily reproducible, and that requires enumerated, versioned dependencies. The fact that this appears to be lost on The Powers That Be behind Go is astonishing. I seriously studied Go; read the book end to end and drank all the necessary kool-aid. Then I tried to use it for something. Two weeks after starting to work on toy projects to evaluate the language I walked away. The experience of trying to wade through the mess that accrues when trying to leverage libraries still makes me nauseous. I can't imagine trying to explain / apologize for Go dependency management to a peer. Complete non-starter.

Re:Why was package versioning left out?

[ewhac]

Because package versioning is not a language issue. It's a build issue, and should be part of your build system.

"But go get ... reaches out and..." Stop. go get isn't part of the Go langauge; it's the default Go build environment. And yes, it lacks many features you'd want in a so-called "professional" build system (whatever that means this week).

I get the impression that Go was perhaps intended to be used with repo, a tool principally used for managing the Android project, but also used elsewhere inside Google to manage large numbers of independent Git repositories. With repo, you establish a common branch or tag name across all the repositories that comprise your project, then "repo sync" to them. Poof! Build and version management. (Sorta.)

Re:Why was package versioning left out?

[genocitizen]

Totally agree with you. It doesn't change a thing the fact one of the core developers said that: keeping clean 'master' is not a solution to everything. What if I want to use version 2? Or version 2.1? Utter anachronistic nonsense...

Re:Why was package versioning left out?

[genocitizen]

Then the default Go build environment is insufficient even for a toy project; does that describe better the issue at hand? Nonetheless it predates the success of the language. I've used repo a bit, nice tool; but still: don't release a half-assed build environment because in your company you use a different tool. Sometimes it's better to not release a feature at all, instead of one that is incomplete/insufficient.

Re:Why was package versioning left out?

[Assmasher]

This is exactly what people need to accept about Golang if they're going to embrace it.

Google was happy to share it, but their desires for Go are primarily aligned with Google's needs - not the community's. It's not personal, it's business.

BTW, enjoy the debugging... ;)

Re:Why was package versioning left out?

[ewhac]

What if I want to use version 2? Or version 2.1?

cd $GOPATH/src/myrepository/myproject
git checkout release-2.0
go build .

Geez...

Re:Why was package versioning left out?

[NostalgiaForInfinity]

Because package versioning is not a language issue. It's a build issue, and should be part of your build system.

In many languages, building code is a language issue. The fact that Go takes a fairly old-fashioned view of batch compilers and separate build systems is just a choice it makes, not a fundamental part of nature. Furthermore, language issue or not, the question simply becomes why are the commonly used build systems for Go so poor.

Re:Why was package versioning left out?

[Serious Callers Only]

Got a plan for this? You should.

As a matter of fact they do. Go 1.5 Vendoring experiment

Re:Why was package versioning left out?

[Chalnoth]

Pretty sure the main build system they were thinking of when designing Go is Google's internal build system, the open source version of which is Bazel. This is just a build system, though, and doesn't manage repositories. It also seems like it would be highly non-trivial to make use of a significant number of libraries (as you'd probably have to create your own BUILD files for each one). Versioning would be no problem, but the initial setup would be.

Re:Why was package versioning left out?

[genocitizen]

By your ecstatic example I can see you never managed more than 1 or two package dependencies in your Go programming experience

Re:Why was package versioning left out?

[genocitizen]

Ah, funny you mention this! It's still as broken as a "default build environment", since there is no version management there. The whole vendor experiment seems a shy attempt at covering up the GOPATH "feature"

Re:Why was package versioning left out?

[Anonymous Coward]

Why reinvent the wheel for every fscking language in the world and fuck things up in the process? Almost any of the language-specific package managers repeated the mistakes done by Linux distros and CPAN ages ago.

Use your OS package manager for managing packages. It doesn't matter one bit what language they're written in.

Error Handling in Go

[JPyObjC Dude]

Go language differs from many other languages in how it handles Errors. Can you summarize the benefits and drawbacks to the Go language error handling approach when compared to Java for large scale applications.

Re:Error Handling in Go

[Anonymous Coward]

Dave Cheney's a pretty big Go developer and wrote up his thoughts. Read the previous post as well. http://dave.cheney.net/2015/01/26/errors-and-exceptions-redux

Re:Error Handling in Go

[snadrus]

What's your thought on syntactic sugar:

result, err = StdLibFunc()
if err != nil {
      return err
}
FunctionTwo(result)

===to===

FunctionTwo( StdLibFunc() || return error )

Languages' expressiveness is often compared in lines-of-code because the higher percentage of a program on your screen at once, the bigger picture you have easily. This is how inner functions often operate. Defers handles clean-up. Here error represents unexpected outcomes which usually must bubble up the stack.

Have we sunk this low?

[Anonymous Coward]

Do we really need to introduce Brian Kernighan? Has the quality of the slashdot readership really dropped this low, or am I just an angry old fart who thinks that all the kids should know who my antiquated heroes were?

Re:Have we sunk this low?

[genocitizen]

Ah! Thought the same :)

Re:Have we sunk this low?

[trevc]

I though this was funny "He is the co-author of several books, including The C Programming Language, Second Edition" Like somebody else co-wrote the first edition?

Re:Have we sunk this low?

[Jack9]

I didn't know who he is and I wont remember tomorrow. Introducing any of these people (badly) is rather pointless. If they were properly linked instead of calling someone a professor and ostensibly leaving out the important bits, there would be no issue. Instead we have an editorial fail. @ slashdot, it's business as usual.

Re:Have we sunk this low?

[Anonymous Coward]

They do that so the reader is aware that the second edition is the latest version.

Re:Have we sunk this low?

[trevc]

Go away please

Why an un-googlable name?

[bigsexyjoe]

Seeing as how it was created after the Internet was big, and one is constantly searching the Internet about the programming language one using, wouldn't you want a distinct name so search results are what the programmer wants? "Go" is the 35th most common word in the English language. When you search for "go" you get entries about games, movies, etc. Google, coincidentally gives the best results if the programming language is what you are searching for, but even Google gives you results for all sorts of things. The programming language isn't even a dominant result on other search engines.

Obviously, if you use a search engine to find things about "JavaScript" or "Erlang" you get what you want. I can't imagine going through the trouble of creating a programming language and then failing to give it a distinctive name.

Re:Why an un-googlable name?

[Anonymous Coward]

Seeing as how it was created after the Internet was big, and one is constantly searching the Internet about the programming language one using, wouldn't you want a distinct name so search results are what the programmer wants? "Go" is the 35th most common word in the English language.

Try searching for "golang".

Re:Why an un-googlable name?

[genocitizen]

Most people search for it as 'golang', but yeah - I get what you mean. Good question.

Re:Why an un-googlable name?

[__aaclcg7560]

Python brings up all kinds of interesting snake videos on YouTube.

Re:Why an un-googlable name?

[BadDreamer]

It was already hard enough to locate new and interesting developments in programming Go, the strategy game. Now it's practically impossible.

But then, who cares about people working on solving some of the most cutting edge AI problems encountered in board gaming.

Re:Why an un-googlable name?

[TeknoHog]

I didn't expect a hovercraft full of motherfucking snakes!

Re:Why an un-googlable name?

[Jeremi]

But then, who cares about people working on solving some of the most cutting edge AI problems encountered in board gaming.

If they can't figure out how to work around a name collision on a search engine, they must not be very good AI programmers.

Re:Why an un-googlable name?

[BadDreamer]

The AI programmers are the ones writing the articles. Those searching for them are generally students and interested amateurs. And you are right, they are usually not very good AI programmers, and now they won't become very good AI programmers either.

Re:Why an un-googlable name?

[Chalnoth]

Also, as Google now understands context for queries, simply using a phrase such as "go language" provides good results.

Usage

[behrooz0az]

For what scenarios and projects do You recommend it and for which you recommend against using Go?

Re:Usage

[packman]

Do:
- cli tools
- server software, especially stuff offering webservices. Has a mature http(s) server in the stdlib, and there are surprisingly mature libraries with DNS server, SSH server/client, ... functionality are out there and being used in a lot of projects.

Don't: GUI stuff, the libraries just aren't there.

Questionable: Web stuff. Ok if you have a static frontend which talks to webservices implemented in Go. Using Go stricly to serve dynamic pages is possible, but I wouldn't recommend it.

Why can't you mark a class with an interface?

[bigsexyjoe]

I can understand the convenience of not needing to mark a class as an implementer of an interface. But on the other hand, it would be nice if you at least had the option of marking a class as an implementer of an interface, so your IDE could tell you your class is not complete.

Re:Why can't you mark a class with an interface?

[Fwipp]

I usually use the following method: https://play.golang.org/p/iF_d... - Attempting to run this will give a compile error. Once you implement MyType.Foo(); it will compile and run successfully.

The only added part is line 10.

Gos potential

[Qbertino]

What serious long-term real-world potential do you see for Go?

How do you see the potential of Go replacing existing open source webstacks such as Apache and PHP, Python or Ruby? Was Go built with a technology update of existing approaches in mind? How feasible is it in your opinion to try and replace the existing complex stacks with pure Go runtimes?

Re:Gos potential

[packman]

I think the long-term real-world potential is already showing in the "devops" world, with a lot of new interesting and cool projects being written in Go:

- Docker
- Consul, packer, otto, terraform, ... (and pretty much everything else Hashicorp wrote after Vagrant)
- Heka
- InfluxDB
- etcd
- kubernetes
- ...

I don't think Go will replace webstacks, it's more suitable for backends (with webservices) imho

Official Go IDE?

[Qbertino]

Is there an official cross-plattform Go IDE in the works? Experience shows that adoption is accelerated by offering a solid toolkit that is easy to pick up and get started with - such as the formidable Android Studio IDE Google offers to developers. Are there any plans similar to this for Go?

I would like to see it take the place of C++ in the development of performant end-user applications with GUIs - are there any officially sanctioned projects that aim to provide a serious GUI toolkit and stack based on Go?

Re:Official Go IDE?

[JamesRing]

There's an excellent IntelliJ plugin under active development: https://github.com/go-lang-plu... Check it out!

Re:Official Go IDE?

[motorsabbath]

Check out LiteIDE.

Re:Official Go IDE?

[motorsabbath]

Sorry, was late last night. LiteIDE is a go-centric ide with lots of great hooks for that language. I run it on Linux, OSX and Win10.

https://code.google.com/p/liteide/

Name of the programming language

[Qbertino]

A large hindrance for seaching information on Go is its name. Many people have pointed this out already.

What plans does the Go project team have in terms of naming conventions to make future searching for information on Go easyer? Is there an alternative term that you recommend using when searching Google for Go related information - perhaps something like the term "go-lang" or so?

What plans does the Go core team have to mitigate this problem? What approach to searching for Go stuff do you recommend right now?

Re:Name of the programming language

[Anonymous Coward]

Well.. Go is better than Come....At least if you are interested in search engines giving you results related to a programming language...

Re:Name of the programming language

[Serious Callers Only]

One of the creators of forking unix are offering to take questions, and multiple people are asking about the branding. Slashdot, 2015. PS Consider the C and C++ programming languages.

Re:Name of the programming language

[packman]

When you're new to go, one of the first things you learn is searching for "golang" instead of "go" :)

Inheritance vs. Composition

[Anonymous Coward]

What was the main motivator with the decision to leave inheritance out of the Go? Code complexity argument goes both ways here, assuming keeping up with the Liskovs.

Re:Inheritance vs. Composition

[Anonymous Coward]

Embedding

I worry about autonomous language activities

[fyngyrz]

adding garbage collection

Well, if all of computer language history is any guide, that's going to present an asynchronous performance issue.

I'm a C programmer by choice. I require that the program does what I told it to, when I told it to. Anything else is malbehavior. Data structures are not garbage unless and until I say they are. So, if go follows the example of every other garbage-collected language I've run into thus far, I'd need to disable garbage collection (and most likely anything else that is running off by itself to do things I didn't ask for within the context of what I write.) I'm perfectly satisfied with local variables that are cleaned off with one CPU instruction on procedure exit; that's as automatic a "cleanup" as I care to indulge in.

Also, threading's not all that difficult. I use it all the time in C. I really don't see the big deal, but I'm willing to listen / read why it might be.

So that would be my question: As a C programmer with a deep collection of working, very fast algorithms in my areas of specialization, and a regular, nearly constant need to get as close to the metal as I can get, why would I want to transition to go? Just as an aside, being able to call C from go... go would have to offer something very significant indeed for that to fly. I can already call C from C.

Re:I worry about autonomous language activities

[bobbied]

Go is obviously not for what you do. Neither is Java or C# for that matter..

I would put Go's useful problem space to be nearly exactly the same as Java and C#, with one notable difference, Go is not controlled by Oracle or Microsoft. I'm not sure how that matters, but it's something.

Re:I worry about autonomous language activities

[Anonymous Coward]

It is certainly possible to improve on C - but adding garbage collection is not the way to go. Freeing up memory is no harder than allocating it in the first place. Occationally, one needs full control of latency. (Audio mixers, etc.) So, no library/language that steps in and does "some" GC at that time. The nice thing about C is that the language don't jump in and steal time. The OS may do so, but that is when you use an OS with some level of real-time capability.

Having to use a different language when latency-constrained is irritating - better to find a language that works and use that all the time.

Re:I worry about autonomous language activities

[Anonymous Coward]

Go is not controlled by Oracle or Microsoft. I'm not sure how that matters, but it's something.

It's controlled by Google. <eyeroll>That's SO much better.</eyeroll>

Re:I worry about autonomous language activities

[fyngyrz]

Go is obviously not for what you do.

That was my impression.

I'm still interested to hear what kind of answer might issue forth from Kernighan and/or Donovan.

A follow up question is, when I'm not constrained by high performance, I have been using Python 2-series. Does go offer something worthy of the effort to move to it there?

Re:I worry about autonomous language activities

[Dutch Gun]

C has a lot going for it. It's simple, portable, ubiquitous. The language lets you do whatever you want with minimal fuss or overhead. Its generated assembly code is fast and efficient. Because it's the system language of choice for operating systems, nearly every other language can interop with C to some degree. C++ is largely backwards compatible with it. If you want a library to be portable with just about everything else, you write it in C. Great.. awesome so far.

That being said, C requires that the programmer write code perfectly, or else you've got a potential security disaster. It's not theoretically impossible, but as we've seen from history, in a large body of complex code, it's nearly impossible. There are virtually no built-in mechanisms for the compiler to help the programmer catch obvious programming errors. As such, it seems like a rather terrible language to use for any sort of internet-facing API, where the code will be subjected to intense attacks. And that pretty much describes most of Google, doesn't it? So it's not too surprising Google would be looking for a safer C-like alternative.

C is a fine language for what it is, but I don't understand people that seem to pick a single language, then infer that it's the end-all and be-all for every programming task on the planet. You CAN write secure, threaded code in C. Then again, you CAN build an entire house with nothing but hand tools. No carpenter doesn't have a basic hammer in their toolbox, but I'd imagine very few would purposefully eschew the use of a nail gun when appropriate.

Re:I worry about autonomous language activities

[bobbied]

Ah, well that question doesn't have a clear answer from the information given.

Python is a scripting language, Go, not so much. I think Python would have a bit lower footprint in terms of disk space used and memory consumed so it might be a bit faster in a resource constrained environment where a C programmer might find themselves, but for most applications you'd write in Python I doubt there is much of a noticeable difference if you wrote it in Go.

Go is basically useful in the same kinds of use cases where Java might be, user interfaces on varying platforms. The question of which one might be better boils down to which one is easier to get working on your platform. I suspect that it will be much easier to build Python for most platforms than Go, but I've not built either myself.

Re:I worry about autonomous language activities

[fyngyrz]

That being said, C requires that the programmer write code perfectly, or else you've got a potential security disaster.

You do realize that not every program is relevant to a network, yes? Or to a system that is exposed to a risk of compromise? Or even running on a system that is connected to a network?

You should also realize that there is absolutely nothing about c that requires the programmer to stick with its zero-terminated string model, or the standard string processing routines, or anything along those lines.

Finally, there's nothing about any language that, if you are exposed to potential compromise WRT the task at hand, relieves the programmer of the responsibility of treating every interaction with the outside world such that the only data that can get in, is the data in the format and of the length you intended to process.

The most important thing about security in programming isn't which language you are using. It is how well you are using it, which is to say, how good you are at, you know, programming.

Re:I worry about autonomous language activities

[luis_a_espinal]

Go is obviously not for what you do.

That was my impression.

I'm still interested to hear what kind of answer might issue forth from Kernighan and/or Donovan.

A follow up question is, when I'm not constrained by high performance, I have been using Python 2-series. Does go offer something worthy of the effort to move to it there?

Speed and static typing. I do Python for a living (along Java and C/C++), and I dream of using a statically typed language that does some of the Python/Ruby syntatic magic. Go might be one way to do just that (read "might be", not necessarily "is" or "will be").

Re: I worry about autonomous language activities

[Anonymous Coward]

You do realize that not every program is relevant to a network, yes?

Don't say that to Apple, or Google, or....

Re:I worry about autonomous language activities

[Anonymous Coward]

Just use OCaml then, Go is nowhere near in speed and easy of use.

Re:I worry about autonomous language activities

[radish]

If your program runs on a machine which is connected to a network then it's an attack vector, even if it doesn't directly offer network services. Look at the huge number of vulnerabilities in things like file viewers or graphics rendering libraries.

Sure, if you're writing an application which you know will only ever be run on airgapped machines with no removable storage then maybe you can not worry about security. Those applications are few and far between.

Re:I worry about autonomous language activities

[radish]

If Java is controlled by Oracle then Go is controlled by Google. Neither worries me particularly.

I don't personally see much of a need for Go in my world (high throughput web services), but I know some of the ops folks in my company like it for the stuff they do - and anything which gets more C out of the stack gets my vote :)

Re:I worry about autonomous language activities

[radish]

Why aren't you writing in assembler? Actually scrub that - how's your microcode? What always amuses me about the bare metal brigade is that they're often not actually that close to the metal.

Different levels of abstraction work for different tasks, and it's always a trade off. Security vs Reliability vs Performance vs Resource Usage vs Developer Time vs Maintainability vs ... you get the picture. Anyone who tells me their tool of choice is appropriate for all tasks is telling me they have a very restricted view of the world. I write mainly in Scala these days but there are plenty of things I wouldn't try to use it for, and I sure as hell wouldn't write my services in C!

Re:I worry about autonomous language activities

[bobbied]

Java is LICENSED by Oracle who doesn't give out the source code... Go is BSD licensed and has source code so you can build your own copy.

Check with Oracle about the terms they use if you want to distribute their Java Virtual Machine in a commercial product. I can assure you it involves you providing them with cash before they will let you even distribute Java, unmodified, as part of your product. I know this from experience. I'll warn you, Java from Oracle does NOT come cheap if you wish to distribute it. Sure they will let you and your customer download it for free, but they want their cut if you download and distribute Java to a customer.

With Go, there will be no such restriction. You can build and distribute Go to your hearts content w/o paying anybody even if you charge for it. You can embed Go in a project, modify it and sell it without having to give up your source code (as I read the license) as long as you leave the BSD license alone.

Re:I worry about autonomous language activities

[Anonymous Coward]

I require that the program does what I told it to, when I told it to.

Once you're a little more experienced, you'll realize that (1) good malloc/free implementations don't free stuff exactly when you ask them to, (2) that you have pretty much the same level of control in GC languages and in malloc/free languages, and (3) that good garbage collector implementations actually have better guarantees and are more predictable than malloc/free.

Also, threading's not all that difficult. I use it all the time in C. I really don't see the big deal, but I'm willing to listen / read why it might be.

You probably solve fairly simple problems in your mom's basement. Building large and complex parallel systems with hundreds of programmers is something entirely different.

Re:I worry about autonomous language activities

[alreaud]

If-then-else compiles into about 6 bytes (approximately) of machine code. Nothing beats it, to my knowledge, of getting tight close to the metal, other than microcode, which we'all in the real world can't usually access (not since the days of bit-slice anyhow). So what would be the purpose of any language that can't fit the metal as tightly as C or C++ (I'm a rusty C++ aficionado)?

Re:I worry about autonomous language activities

[snadrus]

These statements come from experiences in other languages with obnoxious GCs. This is a performance-focussed language with great multiprocess primitives. The GC causes far less latency.
https://talks.golang.org/2015/...
Pauses average 1ms and will be halved again next release to 1/2000 of a second which is plenty workable for games & audio mixers
Further, intelligently-written code can massively reduce GC frequency.

A certain high-throughput web service I've built runs GC roughly once per hour (yet services 1000s of concurrent requests). And this is without any serious effort at tuning. This is because (unlike Java, Python, and JS) GC is avoided if possible for stack space (whenever provably-safe) which is freed when it leaves scope. The proving algorithms are improving too.

Re:I worry about autonomous language activities

[psmears]

Check with Oracle about the terms they use if you want to distribute their Java Virtual Machine in a commercial product. I can assure you it involves you providing them with cash before they will let you even distribute Java, unmodified, as part of your product. I know this from experience. I'll warn you, Java from Oracle does NOT come cheap if you wish to distribute it. Sure they will let you and your customer download it for free, but they want their cut if you download and distribute Java to a customer.

OK, I checked with Oracle, and they said this:

Can I distribute Java with my software?
Yes, you can provide Java with your software provided you abide by the terms and conditions of Java binary code license.

Go is great, and there are definitely advantages to Go's BSD licensing model, but this is not one of them :)

Re:I worry about autonomous language activities

[Anonymous Coward]

Java is LICENSED by Oracle who doesn't give out the source code...

The reference implementation is OpenJDK which is GPL with appropriate exceptions to allow its use as a runtime without infecting commercial projects.

Check with Oracle about the terms they use if you want to distribute their Java Virtual Machine in a commercial product.

The FAQ for the ORACLE JRE seems to boil down to: Yes you can, no money needed as long as the JVM is distributed as part of a product and not by itself.

You can embed Go in a project, modify it and sell it without having to give up your source code (as I read the license) as long as you leave the BSD license alone.

Modifying the JVM is the only limitation imposed and that really does not affect most projects.

Re:I worry about autonomous language activities

[packman]

> I think Python would have a bit lower footprint in terms of disk space used and memory consumed so it might be a bit faster in a resource constrained environment where a C programmer might find themselves, but for most applications you'd write in Python I doubt there is much of a noticeable difference if you wrote it in Go.

A Python runtime + all scripts and used modules would consume a lot more diskspace than a Go application. Go might produce pretty big binaries, but on my system, the python2.7 binary is already 3.2mb and the python3 3.9mb. Start adding modules and tools like pip you need to deploy stuff - and this grows quickly.

Go's upside here is that the binaries produced are completely static, without any external dependencies (including libc, libpthread, ...), so it is super-easy to deploy.

Also Python faster than Go? Sorry, but on most systems with a default CPython install, a Go produced binary will run circles around it, especially if it comes to concurrent programs where the gil still is a major bottleneck. Pypy might come close, or even pass Go in certain benchmarks for a limited set of features, but I highly doubt that would show in real-world scenario's.

I've used both languages, and Python is getting a lot of heat from Go, which I understand. The latter is a lot easier to deploy, has a massive stdlib with stuff you care about, and while sometimes more verbose and limited, is actually a pretty nice language to code in once you get used to some annoyances. Most of my "quick & dirty" scripts are still Python, but once it becomes something more, it's usually written in Go which offers a built-in testing and benchmark framework.

Re:I worry about autonomous language activities

[fyngyrz]

Those applications are few and far between.

No, they are not. You're just unaware of them. Networks are known to be threat vectors. For many applications, there's no particular benefit to being networked, and considering the risks, it is not uncommon at all to forego the option. We're not talking about your desktop here. We're talking about industrial controllers and the like, of which there are many.

In any case, you are carefully ignoring the fact that I addressed the need for care in a networked environment.

Re:I worry about autonomous language activities

[bobbied]

You need to read the "Binary Code License Agreement" because that's where the terms are set. So YEA, you can distribute it, but if you distribute the "commercial features" (and my product does) you need a separate license. They charge for that license.

Re:I worry about autonomous language activities

[bobbied]

Again, this is a "use case" question and I said at the start that we didn't have enough information.

If you are just cooking up some small script thing on the fly and python is already built and on your system, python wins. But if you are looking to deploy something in an embedded system with limited resources, getting a already compiled Go program onboard might be better. You will need to "cross compile" that Go program to make it run, but once you have that, it will be smaller than the whole python distribution. How many Go programs you have might be a consideration though. Each of those native executables carry a lot of extra stuff, where the python scripts are just small text files.

On the size question... Python is sizeable, but it includes everything to compile and run from source code. The Go executable does not. I'm just guessing here, but I think if you consider the Go build environment to get you from source to a running program, the comparison might not be so uneven.

But all this begs the "how are you using this" question. We don't know and either tool may be the preferred choice depending on the specific application.

Re:I worry about autonomous language activities

[luis_a_espinal]

Just use OCaml then, Go is nowhere near in speed and easy of use.

Yes, but it is not as ubiquitous, whereas Go already has a substantial number of job openings. I'm not doing this just for the sake of academic enlightenment (if I were, I'd be more inclined to go to Haskell.)

Re:I worry about autonomous language activities

[radish]

I'm well aware of industrial controllers. I'm also aware that many of them are networked in one way or another, be it ethernet or something else, and most have some mechanism for introducing code or data (floppy disk, USB, whatever). It's not like one of the biggest malware incidents in recent years was targeted towards PLCs or anything.

Re:I worry about autonomous language activities

[Anonymous Coward]

Then don't use the Oracle binaries? Use OpenJDK. It is licensed under GPL (with classpath exceptions) and has none of the Oracle binary restrictions. It was open-sourced by Sun and Oracle can't take that back. In fact, Oracle even made OpenJDK the reference implementation of Java starting with JDK 7.

Writing in Go might be the better idea nonetheless.

Why should I use Go?

[aaaaaaargh!]

For someone like me who likes garbage collection, multiple dispatch, and extreme abstraction capabilities in high level languages like Common Lisp, and safety, compile-time error detection, readability, and speed in low level languages like Ada or Haskell, what are the benefits of using Go in comparison to these two different types of languages? What new useful features does Go bring?

Re:Why should I use Go?

[OrangeTide]

The main feature in Go is channels and the light weight threads you can use with them (goroutines). Go is for writing a certain style of concurrent program, and it does not intend to rival Common Lisp in language features. (I'd take ML over Lisp, I think the type inference in ML is a pleasure to use compared to Lisp)

Re:Why should I use Go?

[Anonymous Coward]

The main feature in Go is channels and the light weight threads you can use with them (goroutines).

Of course, they also exist in C++ implementations (and are being standardized) and many other languages, and they are generally much more expressive than in Go.

Re:Why should I use Go?

[OrangeTide]

Perhaps, but I haven't met a C++ implementation that can survive creating as many threads of execution (contexts?) as I can make in Erlang or even Go.

Android

[Anonymous Coward]

Is there a plan for creating complete Android apps with Go?

tEoPS

[M. D. Nahas]

There many books on "how to program" but few on "how to program well". Brian, your book "The Elements of Programming Style" is a wonderful and a classic, but my students have a hard time reading the examples (Fortran 66 and PL/I).

Is there any hope for an update?
Is there any similar modern-language book that you recommend?

Michael Nahas (son of Joe Nahas)

P.S. I totally stole as much as I could from you when writing my tutorial for the language Coq. Sorry/Thanks!

Re:tEoPS

[Anonymous Coward]

I'll post this as AC. If your dad is who I think he is, I know some phreakers who are probably still pissed at him.

Re:tEoPS

[Serious Callers Only]

Here's a book by Brian which might interest you: The Go Programming Language

Re:tEoPS

[M. D. Nahas]

Gee, thanks, I never thought to read the post! Or any of the comments by Go aficionados and promoters.

The topic is not only "Go" but "Programming" too.

The Elements of Programming Style is widely regarded as a classic. However, it's examples are dated and I don't know of another book like it. But I'm pretty sure "The Go Programming Language" is not a replacement.

Re:tEoPS

[Serious Callers Only]

It's not a general programming book, but it's actually similar in style - working through lots of small examples to learn about programming (programming Go in this case). In true slashdot tradition, I didn't read the post, just the headline ;)

Any plans for Visual Go?

[Anonymous Coward]

with a good form builder?

micro Go?

[Anonymous Coward]

I develop embedded system applications using Go. The Python folks are working on a "micro python" to be a striped down system for embedded applications. What is the chance that there will be a "micro Go" in the near future?

Why Go exists

[Anonymous Coward]

Go exists because most programmers these days just write text pumps. We pump text from the database to the browser. We pump text from the browser to the database. We pump text. We pump text over "APIs". That's it. Programmers don't really need to know how the machinery works for pumping text to and fro. Nobody will be writing OS kernels in Go or device drivers in Go. That is not what it is for.

On the PR and ego inflation front, I would certainly suspect that Go is named from (Go-ogle) and was created because as a big tech (media) company, they didn't want to be left out and not have their own language -- Objective C / Swift (Apple), Java (Oracle), C# (Microsoft). In order to be one of the cool kids, Google had to create something so they did and with their $$ and "community" of paid influencers, they will evangelize it whether its actually necessary or not. Yet another text pump language.

Happy pumping!

Why is Go snobby?

[Anonymous Coward]

I quit developing in Go after my first two experiences were terrible.

First, I tried parsing an internal CA certificate, and it failed because Go didn't like the encoding. I submitted a bug with a fix, since every other SSL package and language (OpenSSL, Java, Python, PHP, Perl, Ruby) all work, and the response to my fix was literally "No thanks." That ruled out me doing anything with a network stack at work with Go.

Second, I tried parsing a date, only to find that instead of using the POSIX sequences, Go decided to use Monday Jan 2, 3:04:05, 2006 as a spec-by-example, which can't be made to work for my case. I proposed at least allowing POSIX time representations on the mailing list, only to be told that Go is quite happy with what they have and "more esoteric formats will have to be parsed by hand."

Overall my interactions with Go maintainers has been awful - it seems like if it isn't their idea, they won't hear it. Why is that?

Re:Why is Go snobby?

[Anonymous Coward]

golang is working as an excellent filter to keep out the riff-raff.

Have you considered using Java?

C's current place in the world

[MountainLogic]

As the legend has it, C was created to support operating system development. As time has gone by C++ has slipped into OS development on larger platforms. It seems that much of the current core use of mother C is centering on embedded processors (all the way down to 8 bit micros with 256 bytes of RAM) and drivers in larger systems. For current use what design choices in C do you see as wise and what would you change given the current usage of C.
PS: Thanks you for co-authoring the most wonderful, perfect, clear and concise technology document ever.

Do you hate go fanboys as much as I do?

[slashdice]

Come on, be honest!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Manual hacking around is not adequate

[Anonymous Coward]

If you expect that kind of procedure to be done manually for each dependency when you build the dependent package then you don't understand package management systems and modern automated build procedures.

Hint: the version dependencies have to be expressed using a defined syntax and in one place only in the dependent package, and thereafter when building it, all the dependencies in their required versions need to be obtained and built automatically. What's more, multiple versions of packages need to coexist, because it is very common that two packages which depend on a third require different versions of it, and allowing only a single version in the tree would create a build conflict.

Manual hacking around to compensate for the absence of proper package management just doesn't cut it, except possibly for basement dwellers. Life is too short for everyone else.

Re:Manual hacking around is not adequate

[KGIII]

This may tie in with the bigger question but, as someone who wrote many (probably several times more than needed) lines of code, thankfully for internal use only, and done a very bad job of it - needing specific versions seems like something that I would have done. To try to state this more eloquently:

Why do we, in this day and age, still need to rely on specific version dependencies?

Be gentle, I was never very good and I've not done much programming in 15 years. When I do it's usually something small, unimportant, and something I just needed for whatever silly reason I had at the time. It's still not good. It's still far too verbose. I'm pretty much the master of spaghetti code - you should see some of my Perl.

Anyhow, it seems like we should be, somehow, past this. That thing should either be static, to some extent, or consistent as versions change. I'm surely not using the correct terminology but, to give an example, calls to an API shouldn't change and the results should be the same even if new features are added. The code should not need to change if the dependency is v. 3.4 or 5.9 so long as I'm still trying to get the same result from that code. Should it? I guess I can see requiring v. 3.4 or greater in some instances (like a new feature was added at that point). But needing specific versions seems, well, like something I'd do. I'm pretty sure that's a bad thing.

Sorry, but I've pondered this while reading /. or SO questions before. I'm thinking about picking C back up or poking at Rust. I'd considered Go but I already need to brush up on my C. I'm not sure that I'd need it for anything I intend to do. I got to work with some great programmers - and learned a lot (not enough) but they'd probably chide me for needing a specific version number as a dependency. They were pretty brutal. Yes, they did tear down and rewrite all of my work. I think they actively plotted my demise on more than one occasion but I kept them well paid, stocked in toys, and gave them all the caffeine they desired.

Re:Manual hacking around is not adequate

[guruevi]

Because people are bad at writing interfaces. POSIX is an example of a really good interface, how it is implemented on your platform doesn't matter, you use the POSIX library in C, Python etc, it works the same.

In the ideal world, your code would use the interfaces (public functions) and they would be there forever and operate the same regardless of the future versions. In the real world however, things change in libraries from version to version, even bug fix releases may break your code because it got rid of 'unnecessary' functions.

Why: because people are bad at interfaces (API's, whatever you call them) and want to make everything as clean and optimal as possible or don't want to maintain old crud "nobody uses". They also make new API's to do the same as old API's but today the fashion is camelcase and tomorrow it is something else. Mostly these days, libraries aren't just libraries anymore, they are entire programs with web servers etc built-in.

Re:Manual hacking around is not adequate

[KGIII]

Thanks. It seems that they've grown quite a bit. It also sounds like something I'd do - which is probably a bad idea. ;-) I think I'll read a few books on C and find a new (VIM probably) way to code. That'll keep me amused for a little while. There really should be standards with these things - at least I'd think so but I am not a real programmer or anything.

If you were US Secretary of Education...

[theodp]

How and when would you introduce kids to programming?

Should Go replace Java?

[Martinjnh]

Should Go replace Java as development platform/language for android?

Re:Should Go replace Java?

[QuantumReality]

It would be very good choice. No need to fight with oracle on java. I really like Go and using it as backend language and language in which i could write apps on Android would be something that would make Go VERY POPULAR language.

Re:Donovan duck!

[KGIII]

I'm not sure that that should be at -1. I mean, come on now. We have guests. That means we have certain standards to uphold. One of those standards is letting them see the true /. and, as such, we should probably have the app guy, the cow guy, and APK.

This is where we fling poop and screech like howler monkeys. It's what we do. We shouldn't get out the fancy China, we're just going to break it when they leave.

Go objects

[StealthyRoid]

I'm curious as to the design decisions that led to the way that Go objects are implemented, which feel and seem to operate like C structs w/ function pointers. Yes, all objects are essentially structs with function pointers, but most languages provide a good deal of syntactic and functional candy on top of them to make them more useful. With Go objects, you get sortof-inheritance, sortof-polymorphism, and sortof-encapsulation, which requires re-thinking a lot of design patterns that people learn working with languages like C++, Java, and even PHP. That's not necessarily a bad thing, I can see arguments for forcing people to get out of their comfortable patterns, I'd just like to know why.

Re:Go objects

[Anonymous Coward]

What in the holy fuck are you talking about?

It has full inheritance (embedding), full polymorphism (interfaces https://youtu.be/QHnLmvDxGTY?t=2914 (~1 minute long)), and... I don't even know what to tell you about the encapsulation comment, that's easily the dumbest thing I've heard yet this month. It has block scoping, as well as private and public variables/methods/functions/structs.

No currency type?

[Anonymous Coward]

Why is there no native and correct way to deal with money? No language since cobol has properly dealt with currency leaving coders to write or use broken libraries.

Re: No currency type?

[Anonymous Coward]

Delphi has a currency type

Does the lineage include C++?

[JerseyTom]

In the preface there is a chart of "The Origins of Go" which includes many languages such as C, Modula-2, CSP, and so on. However C++ is missing from the chart. Oversight or intentional?

Can Go add better static analysis?

[JerseyTom]

The "Rust" programming language boasts the ability to perform more static analysis (finding errors at compile time) than Go. Could Go add better static analysis?

Runtime

[Anonymous Coward]

Any response to articles like this talking about how the runtime is crap?

http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/

Re:Runtime

[Serious Callers Only]

Sure, here's one from Russ Cox: https://news.ycombinator.com/i... Ultimately, those criticisms are not very interesting, because as a Go programmer these are tools you use as an end-user, not something which dictates how you program, and can and will be improved behind the scenes.

Runtime

[El Rey]

Any response to articles like this talking about how the runtime is crap?

http://dtrace.org/blogs/wesolo...

Safe Performance

[snadrus]

Reimplementing the Gnu+Linux toolchain in GoLang could provide safety that decades of eyes on C could not (thinking about the recent BASH bugs & OpenSSL overruns).

Even a small portion would add security to Android. Performance is close & 1.5's library loading should keep executables light.

Is there interest in rebuilding Linux's base userland?

Compiler hack guide

[snadrus]

Could the GoLang team produce a walkthrough on enhancing the compiler?
Even something as simple as making the code more idiomatic (since it was translated) could garner huge increases in contributions.
A guide to the structure would also be helpful.

No "Autotools" or CMake configuration layer

[IBitOBear]

The very first thing I tried to compile under Go's build scheme failed because of headers I don't have for a sub-service I don't need.

It was the "cups connector" for Google cloud print and it wanted libavahi.h even though I don't want or need any of that local network auto configuration stuff.

If the build system can't do what "configure" (autotools) does, or CMake, or CPAN, or any of the other portability systems, then it's not really portable is it.

Go? It went right to bit-bucket for now.

advice for "newbies"?

[ThorGod]

What would your advice be to people looking for work as a programmer? Either straight out of college with a CS degree, not a CS degree (but a degree), or someone transitioning to it from something else.

The future of Go

[Serious Callers Only]

Now that Go has been in the wild for some time, which parts of the language would you change, and which bits have been an unexpected success?

Are there any plans for Golang version 2, and what might that include?

Go in frontend vs. JavaScript

[Martinjnh]

What do you think about GopherJS or similar projects?

Re:Donovan duck!

[Anonymous Coward]

We have guests. That means we have certain standards to uphold. One of those standards is letting them see the true /. and, as such, we should probably have the app guy, the cow guy, and APK.

This is where we fling poop and screech like howler monkeys. It's what we do. We shouldn't get out the fancy China, we're just going to break it when they leave.

"China" should not be capitalized when referring to dinnerware.

The pedantic guy is part of the true /. as well.

Re:Donovan duck!

[KGIII]

Now I know about china. And knowing is half the battle.

Dynamic Modules

[MrHim]

dlopen(3) and its friends allows a C developer to dynamically link to symbols at runtime, the ClassLoader.forName() method allows a Java developer to dynamically load classes at runtime, and other languages have similar constructs. Runtime linking is an extremely useful feature for implementing a module system so in-house developers or 3rd parties can create new implementations of well-defined interfaces; Apache HTTPD is a good example of how to use this effectively. Runtime linking has a number of benefits, not the least of which is security: a user (at runtime) can disable large chunks of code to limit the attack surface.

The May 2015 The State Of Go talk addressed this feature in the execmodes document, specifically:

• Go code as a shared library plugin with a Go style API
• Go code that uses a shared library plugin

It states that neither of these are to be available in 1.5 and indeed they do not appear to be. What's your take on runtime linking? Do you consider it a priority and do you think it'll be available in the next release?

Summerfield's book

[motorsabbath]

Gentlemen,

I've really enjoyed Mark Summerfield's book (http://www.qtrac.eu/gobook.html). I keep it with me. I am seriously considering purchasing yours as well.

Should I?

Thanks.

Inline error handling

[stub667]

Go has eschewed error handling at the end of a scope using exceptions in favor of placing the error handling after nearly every statement. Do you accept the criticism that having all of the the error handling interleaved with the main program flow can negatively affect readability and comprehension? If the problem exists, are there techniques developers should be using to avoid it? Are there plans to replace the 'if err != nil { ... }' boiler plate after each statement with syntactic sugar?

Motivation for writing the book

[jameshwang]

I was curious out of all the Golang books that currently exists, how does this book, "The Go Programming Language," differ from the rest and fit into the landscape of Golang? I've read some of the other books like "Go Programming Blueprints" and "Go in Action." Specifically with "Go in Action," the table of contents seems similar to your book.

I guess what was your motivation to write this book and how will it be different from all the rest? Brian, are you hoping this book becomes what "The C Programming Language" became but for Golang?

On writing (to Kernighan)

[menzinger]

What is your approach for writing such short, clear and concise books? What is your writing process?

Board Game of Go

[RockDoctor]

Do you (either) play Go? To what strength?

Why a Go book?

[yokimbo]

Brian has cemented himself in computer science legend with The C Programming Language. What things made you decide to write The Go Programming Language? And why now?