Talk:Go (programming language)/Archive 1

Archive 1

Naming Controversy

User at 66.50.136.44 - please open a discussion on 'weasel words', rather than just anonymously tagging thus BarryNorton (talk) 06:39, 12 November 2009 (UTC)

Citations

This article needs improvement by relegating golang.org references to footnotes and citation of reliable third party sources in references BarryNorton (talk) 08:40, 13 November 2009 (UTC)

It absolutely amazes me how much time people are willing to put into discussions and tags, and how little into actually improving the article. It took less than half a day to fill a page of discussion when I marked the article for deletion, and less than half a day for people to play with my tags and inform me about proper policy, but will anyone actually improve this article (despite yesterday claiming that reliable third party sources were numerous)? The Wikicrats are really ruining this site BarryNorton (talk) 14:41, 13 November 2009 (UTC)

I think you have a legitimate point here. It’s easy to put on a tag or to share one’s opinion, especially when there’s a heated debate. It’s hard to find good references and what not. And, for the record, these days I generally don’t add information to Wiki articles unless I can back it up. Samboy (talk) 16:25, 13 November 2009 (UTC)

Special treatment of "Go!"?

I was wondering why "Go!" appears in the hatnote while Go (game) and other much more notable "Go" don't? Also, in general, notable topics don't link in the hatnote to obscure ones. For instance, John Lennon doesn't link to John Lennon (captain) and Bill Clinton doesn't link to William Henry Clinton - instead they both link to a general disambiguation page. Likewise, I would suggest changing the hatnote to redirect to Go (disambiguation). I haven't done it myself as it might be a sensible topic given the recent heated AfD, so I'd like to know what others think first. Laurent (talk) 11:30, 14 November 2009 (UTC)

• The title of the article is 'Go (programming language)' - I'm sure that if there was a 'John Lennon (captain)' and a 'Jon Lennon (captain)' the hatnote would make that clear. BarryNorton (talk) 13:05, 14 November 2009 (UTC)

Seems reasonable to me - I think "Go" (the programming language) is probably more likely to be confused with "Go!" (the other programming language), than "Go" the board game, or anything else called "Go" that isn't a programming language. Letdorf (talk) 12:21, 16 November 2009 (UTC).

Per WP:NAMB, pages with disambiguated names should not have hatnotes about pages which they share an undisambiguated name with. A logical exception can be made for pages which use the same disambiguator in their names, as in the case of Go!. --Cybercobra (talk) 12:33, 16 November 2009 (UTC)

Google has not commented ... doesnt this require a reference?

The text reads: As of 16 November 2009, Google has not commented on the issue, although they let InformationWeek know that they were aware of it. Not sure how someone knows that without having read ALL media EVERYWHERE ... but if some reputable source did that research, or if Google stated that they have not commented, that statement itself should be cited —Preceding unsigned comment added by 68.199.243.237 (talk) 05:50, 26 November 2009 (UTC)

'The developer of a little known language called Go!... ' - is undocumented, unreliable, biased.

I have removed the previous reference to Go! being a little known language because (1)no citations are provided to establish whether or not Go! is a little known language, (2) I reckon whether Go! is a little known language or not is of no academic value and (3) It is reasonable to doubt whether Go! is a little known language at present given the exposure that the Go! language has recently received as a side effect of the naming dispute. It appears to me that there is a consistent bias in the way Go and Go! are presented to readers of Wikipedia. The Go! language is quoted under the Go article in the context of the naming dispute. This forms a separate section rejected at the end of the Go! article. In contrast, the Go language is quoted at the beginning of the Go! article, and this may suggest that Go! is only notable because of the naming dispute. In this context I hope others will find it reasonable that I remove undocumented, untrusted references to Go! being a little known language. 114.243.188.106 (talk) 13:15, 14 December 2009 (UTC)Tea

Go! is definitely not very much used or widespread language.--90.191.108.171 (talk) 10:41, 22 December 2009 (UTC)

Go! has a theoretical interest however many users, while Go seems to be another mudwrestling Yaupl (u = unnecessary) between wanna-be-biggest Corps. ... said: Rursus (^mbork³) 13:58, 7 January 2010 (UTC)

When my university professor asked the class (some 40 engineering students) how many had heard about LISP, I was about the only one holding up my hand. I guess you could say that LISP is not very much used either. BTW I had hear about GO! too. How do you measure how widespread it is? And finally, google should really change the name of the language, because it's hell to search for "go" resources on the web. I should know because I've been struggling to find baduk resources for the last year :) 188.126.207.212 (talk) 23:34, 9 August 2010 (UTC)

Symbol Visibility

There was previously an erroneous statement about how go uses capitalization to define symbol visibility versus C++ which uses 'public'. 'public' has nothing to do with visibility. I just removed the comment but maybe something about static vs extern in C++ should be mentioned. There's also the independent issue of visibility in dynamic shared objects which can be controlled with compiler specific extensions, linker scripts, etc. I'm not sure how go handles this (perhaps it supports gcc's visibility attribute?). Egmetcalfe (talk) 05:21, 21 October 2010 (UTC)

Google's motivation

What is Google's motivation to support a systems programming language? --Abdull (talk) 18:13, 30 January 2011 (UTC)

http://golang.org/doc/go_faq.html#Origins ; Google does systems programming, they think Go can make it easier. --Cybercobra (talk) 21:20, 30 January 2011 (UTC)

What's Special About Go?

I don't think this question is covered well, even though many people who visit this article will be wondering about it. At least, that was the case for me. --Danielx (talk) 10:03, 17 February 2011 (UTC)

Well, in case you are still wondering, what makes it special is that it is designed to offer a modern alternative in areas that until now have been the exclusive domain of C. Like C, it is a very small, lightweight language and first and foremost designed for efficiency, but unlike C, it is strongly typed, garbage collected, treats functions as first class objects (thus facilitating a functional programming style), offers a lightweight and efficient concurrency model etc. It also deliberately lacks some features that make programming in C a complex, difficult task, like pointer arithmetics. —Preceding unsigned comment added by 91.119.1.177 (talk) 18:20, 10 April 2011 (UTC)

Building on previous work related to the Inferno operating system?

The initial design of Go was started in September 2007 by Robert Griesemer, Rob Pike, and Ken Thompson,[2] building on previous work related to the Inferno operating system.[6]

[6] http://golang.org/src/cmd/goyacc/goyacc.go

That the language's parser is derived from Inferno's parser isn't fundamental to the Go language itself. I have removed this claim and its citation. 70.225.166.42 (talk) 00:32, 7 August 2011 (UTC)

Trademark

"While McCabe has not trademarked the name"

I never understand why people use "trademark" as a verb. Merely using a name is sufficient to claim it as being a trademark. There's all kinds of legal considerations about whether a trademark is valid and whether or not someone else's use violates it, but there's no specific process required to "trademark" something, unless you're talking about a "registered trademark". In which case, you should probably use "register" as the verb.

I was feeling pedantic... — Preceding unsigned comment added by 86.128.42.150 (talk) 22:34, 19 December 2011 (UTC)

I never understand why people use "trademark" as a verb.

It seems that comes natural to English speakers, anyways it is legal within the English language system, unlike most other languages. Rursus dixit. (^mbork³!) 16:36, 13 June 2013 (UTC)

Shelved section on Go's types; improving Syntax section

Shelved because I don't think it communicates anything particularly big about Go the whole. Could say the same for the syntax section (which isn't entirely syntax either) which probably means the laundry list needs to be edited down to what actually matters to somebody looking at the language from afar.

Built-in types

Go shares a number of core types with C: integers and floats of various sizes; arrays; and pointers. Among the differences in the types shared with C:

• Go's rune type represents a Unicode code point
• Conversions between number types differ:
  • There are no implicit conversions: the code must request conversion from an int16 to an int32
  • Numeric constants in source code can be assigned to any type
• Pointer semantics and syntax differ
  • There is no pointer arithmetic, and arrays and pointers are different types
  • Most pointer dereferences are explicit: p.Method not p->Method

Like many other languages, Go extends C with object-orientation and additional core types. Some important points about Go's added types:

• []type is a slice
  • Slices have a length and, to track allocated space, a capacity
  • Slices can represent any portion of an array, even starting in the middle
  • Slices are nil until allocated with make()
  • Slices are references to mutable data
• string is an immutable UTF-8 string
• map[keytype]valtype is a hash table
  • Like slices, maps are references and must be allocated with make() before use
• structs have syntactical differences from C
  • Construction by name is allowed: Point{x: 3, y: 2}
  • A struct can embed another, taking on its data and methods: type LockableInt struct { x int; sync.Mutex; }
• chan type is a type-safe channel; see Concurrency
  • Like slices and maps, make(chan type) is necessary
  • Channels optionally have a buffer: make(chan type, 100)
  • Channel direction can be specified: <-chan int is receive-only
• Any type can have a name and methods and thus act as an object:
  • Methods on types are common but not the only option.
  • The type keyword can assign a name to any type: type Token []byte
  • The name becomes a distinct type, not an alias
  • Methods are functions with a 'receiver': func (t Token) IsNum() bool
• interface values point to other types; see Interfaces

50.1.48.10 (talk) 07:59, 13 October 2013 (UTC)

Improving Syntax section

So, I'm trying to figure out how you communicate the overall feel of Go syntax -- and more precisely I really mean everything in the core lang but interfaces and concurrency because they're already covered -- without tiring/overwhelming folks. Key things seem to be:

• Lots of shortcuts, especially compared to C. Type inference/short declarations, no semicolons, adding some literal syntaxes where C's sort of missing them, ranged for loops.
• Added built-in types: maps, slices, strings with some Unicode support baked into the runtime. Mention interfaces and channels but leave the details for their sections.
• Some of the structural quirks like type embedding instead of inheritance and names/methods for any type and that named types are not aliases.

And maybe separately, conventions, like go get-friendly package paths and go fmt for formatting. I'd like to keep it to things that actually substantially affect how folks program and are different from many other languages and aren't hit elsewhere in the article, rather than necessarily all the things that are different or visible. Hrm.

24.7.67.251 (talk) 23:25, 29 October 2013 (UTC)

quotes

There's a section with quotes from shortly after Go's release--most of those are less vital than they once were, maybe. (Eckel's might be an exception because he's a reputable expert on C++, and his statement is strong enough that it probably represents one extreme of opinion.) If revamped, I'd like it to include some of the thoughtful criticisms of/complaints about Go in the critics' words (it's like Java, lacks expressivity/safety/genericity/etc. vs. other languages, etc.), and I'd like the positive statements to be more specific than "it's great!": to have some bearing on the language philosophy or how Go is used (e.g., that it's attracted people from dynamic languages).

Similarly, I'm not sure if the initial naming dispute is still as relevant as it was back before Go-no-exclamation-pt decided to keep its name--I think the disambiguation tag says all that needs to be said in this article. I also don't know if we need whole section on the (awesome) mascot (which is already in the infobox, too!) unless it was rolled into, like, a Community section--there's a lot else such a section could talk about, I think.

24.7.67.251 (talk) 00:06, 20 November 2013 (UTC)

OK, thinking about two other sections, roughly 'community' and 'discussion'.

Community [and bit of history and philosophy]: where it's discussed [golang-nuts, reddit, news.yc], resources [godoc, gobyexample, tour, effective go, talks.golang], 'gophers' and the golang gopher. its history in plan 9. the origin story as the developers told it (three folks, different approaches, some things fell into place quickly but had to get unanimity for things to go in). its dev team.

Discussion: common high-level dings are 1) it's just java/c# (since both are compiled but garbage-collected and otherwise softened vs. C), 2) relatively simple type system (no map, no generics, no hedley-miller or kinds), 3) does badly on some benchmark or other. the responses. fans commonly say it's easy to get into, easy to understand what programs do, they dig concurrency, good stand-in for scripting langs, good stdlib, runs fast and fast to build in in practice--or whatever fans actually can be found saying where i can cite it.

70.36.134.151 (talk) 06:53, 8 December 2013 (UTC)

CSP references

The underlying principles of CSP are based on creating formalisms for safe concurrency.

Go not only ignores these formalisms, it also ignores the last 30 years of research into safe concurrent programming.

The references to CSP are little short of defamatory in light of this. —Preceding unsigned comment added by 86.3.139.124 (talk) 13:16, 14 November 2009 (UTC)

I can't agree with this at all. Process algebra is about formalising models for interaction and concurrency, and the mechanisms for channel-based communication and non-deterministic choice are certainly a feature of limbo (and occam undeniably) inspired by CSP. Unfortunately when people cherry-pick from an area they might ignore many of the concerns of the associated community, as happens again and again in programming language design (ask anyone who works in type theory), but "defamatory" seems way too strong for acknowledging the inspiration. BarryNorton (talk) 13:27, 14 November 2009 (UTC)

... that said, your actual edits to the article seem more than reasonable BarryNorton (talk) 13:28, 14 November 2009 (UTC)

The arguable historical marginalization of those developing and interested in CSP-derived languages - and the insistence by large corporate entities over the past 20 years that "concurrency is hard" - is likely to stir up considerable dissatisfaction with those claiming influence unless they also address related concerns. On another note, this article is woefully devoid of real discussion or information, can anyone from Google perhaps contribute a bit more information? JonathanMayUK (talk) 12:14, 16 November 2009 (UTC)

I'm afraid working for Google would be no substitute for reliable sources. See also WP:COI and WP:OR. Letdorf (talk) 13:04, 16 November 2009 (UTC).

Be that as it may, I can't see anyone else being motivated to contribute substantially to this article. Anyway, I wasn't suggesting someone simply spews commercial drivel all over the article, I was suggesting that someone from Google might have the right incentive to put some properly researched and well-referenced content here.JonathanMayUK (talk) 08:56, 4 December 2009 (UTC)

Inter-process communication semantics

Maybe one should add a table comparing the semantics of inter-process communication of Golang and possibly [Erlang_(programming_language) Erlang] and [Occam_(programming_language) Occam].

See also: A Tale of Two Concurrency Models: Comparing the Go and Erlang Programming Languages

Here's some kick-off:

• CSP: Assumes that event read and write are fully synchronous and instantaneous (which would translate to "blocking" in any implementation; blocking is considered harmful to responsive applications)
• Go
  • Processes ('goroutines') exchange 'messages' through typed and named 'channels'; operations are called 'send' and 'receive'
  • Syntax unlike CSP; semantics are somewhat those of CSP
  • Only weak guarantees regarding ordering or delivery of messages
  • Message exchange limited to same Go process
  • Blocking and non-blocking send-to-channel (send blocks if the channel is 'unbuffered' or the channel's buffer is full)
  • Blocking and non-blocking receive-from-channel (Go by Example: Non-Blocking Channel Operations)
  • Messages cannot be read from channel out of order (i.e. no examination of the message queue of a channel)
• Erlang
  • Processes exchange 'messages' asynchronously via untyped 'mailboxes'; addressing is done by PID; this is an actor model with one untyped message queue per process
  • Syntax like CSP; semantics those of early versions of CSP
  • No guarantees regarding order or delivery of messages
  • Message exchange can be in-process or between Erlang VMs possibly running on remote machines
  • Events can be read from the message queue out-of-order (using matching)
• Occam
  • Processes exchange 'events' through untyped and named 'channels'; operations are called 'send' and 'receive'
  • Syntax like CSP; semantics like CSP
  • Blocking send and receive
  • Message exchange limited to same Occam process (or the same Transputer-carrying board?)
  • Messages cannot be read from channel out of order

There is a T101 in your kitchen (talk) 10:09, 23 December 2013 (UTC)

Notable downsides and criticism!

Gopher bradfitz summarizes a lot of complaints I tend to hear:

http://talks.golang.org/2014/gocon-tokyo.slide#50

It could also be nice to cover, to the extent that it's possible neutrally, with citations, etc.:

• Concrete examples, e.g., zlib slowdown vs. C, GC benchmark comparison vs. Java
• Holes in the ecosystem, e.g., semi rarely used for interactive client apps of any sort
• Some verboseness (you copy some code around, you check if err == nil a lot)
• Nod to how Gophers respond to these things (e.g., verboseness is explicitness, life w/GC, generics workarounds)
• Some of it's not changing, for better or worse; language authors consider it a feature

If there are sources, would consider some other categories of complaint I hear:

• The simplicity of the type system (besides lack of generics)--e.g., no Hedley-Miller type system or Rust-style linear types or const/immutable types or...
• "It's Java" since both are garbage-collected, imperative, etc.
• any complaints from folks who have actually written a lot of Go

I would *not* like to:

• Use Programming Language Shootout benchmarks uncritically (the shootout operators themselves don't like that)
• Rehash wider arguments there's no clear consensus on (e.g. is static typing good? are semicolons?)
• Note everything anyone thinks/has blogged/etc. about Go, particularly if it's of the form "I don't think that feature will work well" and the hypothesis has not been tested

Most language pages don't appear to talk about negatives much, and they shouldn't get too much weight or they make a complicated topic impenetrable. (The design description can't become a point-by-point design debate.) But it seems like it could be a substantially more useful page with a well-done section on limitations/downsides. If some eager editor wants to beat me to the punch that would be fantastic. 50.0.142.100 (talk) 09:28, 18 June 2014 (UTC)

---

Moar sources:

• various content about GC speed and workarounds (http://blog.cloudflare.com/recycling-memory-buffers-in-go, https://code.google.com/p/go/issues/detail?id=4720; the GC-focused benchmark at http://benchmarksgame.alioth.debian.org/u32/performance.php?test=binarytrees; what else?).
• vitess presentation (talks pros/cons, e.g., that C++ wins on performance and Python on expressiveness in small programs, and talks about their generics workaround and various micro-complaints): https://github.com/youtube/vitess/blob/master/doc/Vitess2014.pdf?raw=true
• post about porting a large Google project (mentions some gripelets with interfaces and losing the transparency of explicit types): http://matt-welsh.blogspot.com/2013/08/rewriting-large-production-system-in-go.html

I'm picking on these sources because they've deployed large chunks of battle-tested code and know better than I possibly could what hurts in practice, but that obviously limits to people within the Go world and excludes some "we didn't consider Go because..." (we're building a client app, or need tiny binaries, or...). Also does not cover coulda-done-betters (memory management, safety, or concurrency features that other languages have, or expressiveness) or some fuzzier opinions, though I'm less sure how appropriate it is to talk about them (this is about Go, not about the design space of all possible langauges).

There are a lot of opinions written up out there, some quite thoughtful (Tim Bray's might be noteworthy just because Tim Bray (gripes: no REPL, un-googleable name, no map function): 1, 2). But I strongly lean that it's more useful and interesting to write up the objectively true limitations than tell anyone what they should think. — Preceding unsigned comment added by 50.0.142.100 (talk) 07:23, 20 June 2014 (UTC)

The problem is that this inherently subjective. Most of the links cited are personal websites or blog posts. "Criticism" sections on Wikipedia are generally discouraged because they tend to be inherently biased and have little to do with any objective criteria (and there is no objective criteria for these things in the computing field). Huihermit (talk) 09:13, 20 June 2014 (UTC)

There are some facts about Go that come up in a lot of the opinion posts and aren't in the article (code generation vs. C compilers, GC pauses), and some statements that are made by enough people including Go team members that the fact that a lot of people feel they're tradeoffs might be notable (lack of generics, you trade off some conciseness for explicitness, good but not perfect performance).

It may be that what there is to write about is something like limitations or tradeoffs or downsides. FWIW, writing this as a Go user who's not at all down on the language; it just feels like we've written a lot about "the designers sought XYZ benefits" without "with ABC tradeoffs" where there are clear statements to make about them.

I do think inclusion of negatives ought to be limited (I don't want to go over things where there isn't wide agreement about what constitutes a tradeoff, and I don't care that Go doesn't have some other language's pet feature; that's about that language or feature, not about Go). But I think there's room for addition/improvement on what's there now.98.232.94.231 (talk) 04:07, 23 June 2014 (UTC)

If there are notable criticisms or compromises in reliable sources, then they can just be incorporated into the normal body of the article. There is no need to have a separate "bad things about X" section (commonly called "Criticism"), which is generally discouraged in Wikipedia articles. Huihermit (talk) 03:26, 25 June 2014 (UTC)

---

So, to address an advert tag, I added a list of common critiques to the "language design" section, sticking critiques that are mostly about missing features next to the list of missing features.

I don't think this was the most useful way it could be done. For one thing, I went for popular and strongly-critical posts, without particularly trying to emphasize sources that showed expertise (e.g., they'd written a system in it, so they could talk about their practical stumbling blocks, not just opinions) or walked around the tradeoffs. Also, the integration is poor; I'd like it to be clear how the positives and negatives are related (e.g., paraphrasing, Tim Bray doesn't find Go syntax as expressive as Ruby, but finds it easier to follow what the machine will do to execute his code). Rewriting citing frank posts from sources with substantial Go experience is potentially a way towards addressing both of the problems. — Preceding unsigned comment added by 98.207.62.11 (talk) 09:15, 19 April 2015 (UTC)

No interface inheritance?

Go does not have interface inheritance, but one interface type can embed another; then the embedding interface requires all of the methods required by the embedded interface.

I fail to see how this is not interface inheritance, or at least subtyping (it's surely not called inheritance). When an interface is embedded in another interface, the embedding one is substitutable for the embedded one:

package main

type Super interface {
	Method1()
}

type Sub interface {
	Super // Or declare Method1() for implicit subtyping.
	Method2()
}

func main() {
	var x Sub
	var _ Super = x
}

The given source, the language spec, doesn't care to say whether this is interface inheritance or not. QVVERTYVS (hm?) 14:23, 13 May 2015 (UTC)

Tendentious language

Large parts of the article seem to be written in tendentious language, trying to point out the (arguably) "nice" features and silently omitting the deficiencies of go. Reading the article I get the impression that go is defined by comparison to c and other languages and not as a language on its own - which adds to the impression that the article is about poining out that go is "better" than other languages.

Examples:

• "It is a statically-typed language with syntax loosely derived from that of C, adding automatic memory management, type safety, some dynamic-typing capabilities, additional built-in types such as variable-length arrays and key-value maps, and a large standard library."

There should jsut be a complete, unbiased list of language features instead of "go is better than c".

• "Go is defined by ... Fast compilation times"

This is really just advertising.

• "Go is recognizably in the tradition of C, but makes many changes aimed at conciseness, simplicity, and safety."

That's just a subjective opinion. If there is a comprehensible list of design goals, then just add it to the article, possibly including information how the language features are related to the design goals.

• "Go's syntax includes changes from C aimed at keeping code concise and readable."

Ditto. There are also some language "features" that make go code arguably less readable:

- The fact that the case of a symbol's first letter defines whether the symbol is exported or not which is not obvious at all to a casual reader.

- This system is really just compatible with camel case symbols (there is much discussion about the readability of camel case).

- The syntax often enforces placement of curly braces on the same line as the language construct to which it belongs.

- It is difficult to break long function declarations into multiple, readable lines because newlines cannot be placed after closing braces.

- The possibility to declare variables implicitly using the ":=" operator has the downside that the reader or even programmer may have no idea of what type a variable actually is.

- Automatic type conversion of pointers to values with the "." operator ("p.x" versus "(*p).x")

- The fact that most semicola are optional.

• "Go deliberately omits certain features common in other languages ... After initially omitting exceptions, the language added the panic/recover mechanism, but it is only meant for rare circumstances."

If go implements a panic-recover-mechanism, just state that and maybe explain is or link to a page where it's explained. There's no need to state that "the author" thinks what "it's meant for", or to subtly suggest that "the author" thinks that expressions must be not so good because they have been "deliberately omitted".

• "Go's initial release led to much discussion."

Please also quote criticism and not just opinions that celebrate go.

195.212.29.185 (talk) 09:54, 2 January 2014 (UTC)

I agree to some degree with your observations; in particular, the comparisons with C seem out of place for a language that is supposed to compete with Java and C++. The "Language design" section is also a bit of a mess, discussing details of the type system twice, first in comparison with C, then in comparison (somewhat implicitly) with class-based languages. QVVERTYVS (hm?) 15:10, 13 May 2015 (UTC)

"self-published source" tags on criticisms

They're right, though I referenced those blog posts there to say these are frequent criticisms, not that the criticisms are correct or made by authorities (one is a high-school student, I think). I actually find the text of the posts themselves grating, but they do seem to represent what some folks think (just going by their reception on some programmer-news sites, etc.), each complaint has multiple sources, and and after toning down the clickbait-y phrasing of the posts, they do substantively highlight Go limitations and points for comparison with other languages.

Anyhow. If someone has a great source that summarizes criticism out there, which I guess is what we'd need to remove the tag, I'm interested.

Ironically, I added that list to respond to a complaint that the first section was too advertisement-y (and because I already thought limitations and comparisons with other languages were a worthwhile topic). But I know, I know, "balance" is not the goal, etc. — Preceding unsigned comment added by 24.7.64.61 (talk) 19:06, 19 May 2015 (UTC)

Offsetting advertorial content by the opinions of random bloggers is not the way to an encyclopedic overview and goes against Wikipedia policy. Indeed, a source that summarizes the criticisms would be great; until we have that, I suggest we just trim the complaints away and do the same with the praise. I've already added some references to academic works (some by Google people, some by complete outsiders) that compares Go with other competing technology, and I've tried to tone down the language description to become more factual. QVVERTYVS (hm?) 19:28, 19 May 2015 (UTC)

Aaaah, this is going right into the deep end. Possibly useful sources:

• Thoughts of a Rustacean Learning Go, Manish Goregaokar. The author has contributions accepted to another large programming-language project (Rust), which is the nearest thing I can think of for a non-academic to "work in the relevant field...published by reliable third-party publications", and others reviewed the post before Polyglot Weekly posted it ([2], [3]). (I'm guessing PW is too small and new to itself be a reliable source to Wikipedia, which is why I'm talking about Goregaokar.)
• Pain points appear in a a Go team member's complaints I linked to in an earlier talk section, and
• There's a conference talk about an internal Google system.

There's Matt Welsh's post on rewriting one of Google's C++ systems in Go, but it's on his blog and not sure how one establishes expertise there. I'm also not clear on how much, if at all, WP assigns reliability to non-academic industry sources generally (conference talks, etc.).

 

> Offsetting advertorial content by the opinions of random bloggers is not the way

For what it's worth, that wasn't my thought process; I thought of both the design goals and limitations as legit topics deserving the space they got.

Like, in the language design summary I thought I'd successfully stuck to talking language goals and that was a reasonable thing to do (see, say, C++'s "Philosophy" section), but I had also figured limitations needed attention (I wrote "Notable downsides..." higher up on this page before the advert tag). So I took some claims I'd seen widely discussed across mailing lists/discussion sites/blogs/etc. and had some kernel of technical truth (like, "Go has GC") and wrote them up. (Like I said above, not super proud of the cites, but that was why I added the text they're supporting.)

That's not to wave off criticism of the resulting text and cites, only to defend my thought process as a little less naïve than one might think.

It seems sad to give up on discussing anything but the authors' goals and spec, but hard to check the necessary citation boxes when dipping into broader discussion when the language is still new and the community relatively small, and most of the discussion outside docs and such is informal. I don't have unlimited hours in the day or complete command of WP guidelines, so not sure what to do. Do edit at will. — Preceding unsigned comment added by 24.7.64.61 (talk • contribs)

Industry sources are fine, especially for a language designed for industrial use. Journalistic sources like The Register are also a good source of analysis and somewhat better thought-through opinion. Preferably, sources should be under some form of editorial control.

(Requiring academic sources only is pretty much impossible for such a conservative language :) QVVERTYVS (hm?) 20:49, 20 May 2015 (UTC)

"It has been reported that many have called for..."

These are classic weasel words, and the only citation is a link to Google's issue tracker. There are comments in issue 9 calling for Google to adopt a new name, but there are over 800 comments there already, and it's not much of a source for the claim. Everyone's talking about "big controversies" and "widespread support" of changing the name... are there any sources besides the issue 9 comments and a few blogs reporting them? Merc64 (talk) 15:15, 14 November 2009 (UTC)

Except that the InformationWeek link, which has moved backs, was the quoted source for these reports. It these are 'weasel words', then the entire broadsheet press in the UK are weasels. This is simply how you relay such third party reports without supporting them. BarryNorton (talk) 08:49, 15 November 2009 (UTC)

The wording is much better now. The InformationWeek link only mentioned the comments on the tracker issue, and the vague wording made it sound like issue 9 was just one of many examples. Merc64 (talk) 15:11, 16 November 2009 (UTC)

I'd like to note that google has edited the issue tracker and has removed the issue. Russ Cox was the author that commented 'unfortunate' and closed the issue.Hawtpeppers (talk) 06:48, 10 September 2015 (UTC)

There was also some discussion regarding the naming dispute on https://groups.google.com/forum/#!forum/golang-nutsHawtpeppers (talk) 06:48, 10 September 2015 (UTC)

Embedding as inheritance

Not only did this edit introduce syntax errors (foo: int is not valid Go), but the assertion that "a function taking a pointer to A will accept a pointer to B" is incorrect:

package main

type Base struct{}

type Derived struct {
    Base
}

func f(*Base) {
}

func main() {
    f(&Derived{})
}

produces

./test.go:13: cannot use Derived literal (type *Derived) as type *Base in argument to f

It's also not "a version of inheritance in languages like C++". Embedding is somewhat similar to non-virtual inheritance in C++, which is pretty much a C++-only feature (maybe D has it, I'm not sure) and it doesn't have "a syntax that does not hide the memory layout and pointer adjustments involved". Where are the explicit pointer adjustments? QVVERTYVS (hm?) 07:07, 15 September 2015 (UTC) QVVERTYVS (hm?) 07:07, 15 September 2015 (UTC)

Dynamic typing?

@TvojaStara: after re-reading The Laws of Reflection and Nominative And Structural Typing I came to the conclusion that you're right. I was extrapolating from the run-time part of interface implementation (the fact that an interface holds a pointer to a type). That's not necessarily dynamic typing. QVVERTYVS (hm?) 20:19, 1 October 2015 (UTC)

If you insist on using the word "dynamic", you can say it is dynamic dispatch. Interface holds not only pointer to the type, but also function pointers to all functions in the interface. This is very similar to a C++ vtable, except that in C++ a vtable is part of every object (that has at least one virtual method), whereas in Go it is part of an interface value. Additional good references on this is http://research.swtch.com/interfaces and possibly https://en.wikipedia.org/wiki/Virtual_method_table to see how it is done in C++.TvojaStara (talk) 21:42, 1 October 2015 (UTC)

I know how this works in C++, and even there I'd call this a limited form of dynamic typing (although the C++ lingo for it is RTTI). QVVERTYVS (hm?) 21:51, 1 October 2015 (UTC)

WP:NPS / History section

The history section is entirely copy/paste of quotations. It needs to be removed and/or be rewritten. The Dissident Aggressor 16:18, 28 October 2015 (UTC)

You're right. I condensed it a bit, but a rewrite is still in order. QVVERTYVS (hm?) 19:47, 28 October 2015 (UTC)

It uses primary-source quotations, but to support a narrow claim (as text stands now, "the authors said they wanted to do X"). Since we're only saying authors said they wanted to do X and it's easy to for any reader to click through and see it's true, it seems to fit within the one use allowed by WP:PRIMARY--"A primary source may only be used on Wikipedia to make straightforward, descriptive statements of facts that can be verified by any educated person with access to the primary source but without further, specialized knowledge."

It doesn't say a ton in terms of timeline, so "Goals" might be a more descriptive heading than "History," but I don't think the text there is un-Wikipedian simply because it cites people's words about what they aimed to do. Compare to the Philosophy section of the C++ page (citing primary source Stroustrup) or the discusson of goals on the Java page (citing Java owner Oracle).

Similarly, I added a bullet saying under "Conventions and code style" that the authors make statements about style/design/philosophy, with links to the authors' statements about style/design/philosophy--it seems within WP:PRIMARY because it's literally just saying this content exists (as other sections say language features exist, and cite pages on the Go site for it), not that it is wise or good or anything. I tried to avoid "editorializing" (which an edit message mentioned in deleting some old text) but if the bullet can be made more neutral, go for it. — Preceding unsigned comment added by 76.103.246.130 (talk) 00:04, 28 November 2015 (UTC)

The problem isn't verifiability, it's undue weight. What the designers want is not quite as important as what they achieved, but that's hard to tell at this point in the hype cycle. This article has the problem that it's already a linkfarm, and it runs the risk of becoming a Google advertorial (if it isn't one already). QVVERTYVS (hm?) 00:15, 28 November 2015 (UTC)

I just read WP:DUE and it seems to be about giving a lot of weight to a fringe sources in a dispute. Here there's no dispute; we're saying the authors had the goals they claimed, not that they met them. I don't know of a credible source that disputes that Go had those design goals. And the authors aren't fringe sources about their own language, and especially about their own goals designing it.

Of course, lots of people think bad stuff about Go; I added some links to criticism a while back we should add more and better. But that doesn't make citing the authors of a language about their goals impermissible under WP policies. That would seem to reduce a page to a summary of the manual then (and you reverted a change for that too!).

I was referring to the first sentence of WP:DUE: we need to "fairly represent all significant viewpoints that have been published by reliable sources". The authors are already cited, but too often using their own websites. Citing their opinion about all kinds of minutiae without independent viewpoints constitutes undue weight, IMO. QVVERTYVS (hm?) 11:54, 28 November 2015 (UTC)

I don't think WP should focus on "what they achieved" over goals if you're saying that. Standards for achievement for languages are subjective and not great topics for WP; ask a bunch of experts about, say Java's security or readability, and you get a lot of answers. Goals, on the other hand, tend to be conveniently written out by the authors, and help you mentally organize the features that follow, and make the jump from how languages differ to why (if you look at the Java and C++ goals/philosophy sections, you get why one has GC and the other doesn't).

If we had a bunch of experts commenting on Go, that would be great. I'd happily cite them all and put their viewpoints side by side. Otherwise, achievements include being widely used, or in notable applications. See, e.g., the section "Suitability for parallel programming", where I've summarized a peer-reviewed study that actually checks Pike's claim that parallelism follows from concurrency.

(Note that the C++ article fails to discuss garbage collection at all, even though it's a topic of frequent debate in that language's community, and the C++11 standard was written with the idea of allowing it in mind.) QVVERTYVS (hm?) 11:54, 28 November 2015 (UTC)

It sounds like you feel Go is hyped out there and there are weak sections of the page. I kind of agree. The Discussion section is weird, and Users tends to accumulate non-notable users adding themselves, and, again, I want better-sourced criticism. But maybe that's getting in the way of you judging pieces of content on their individual merits? You don't have to cut sourced, informative, useful stuff just because it feels positive. Links to the spec or authoritative styleguides in support of related text can be appropriate despite there being too many links in another section of the page.

I also notice you're reverting a big chunk of all the edits that come through. It's possible Go just attracts an unusual percentage of bad edits, but I'd be wary of getting an attitude of ownership that scares off other contributors. It's probably not too hard to find a policy that at first glance seems to apply against an edit, but it might merit slowing down before pulling the trigger on most stuff. — Preceding unsigned comment added by 162.229.60.73 (talk) 05:00, 28 November 2015 (UTC)

Edits to channels section

A recent revert in the goroutines section actually deleted a bunch of content that had been there for months. I think the right text about channels does more than just documents their existence and tags on a couple adjectives; it's at least relevant that there's syntax built around them (which distinguishes Go channels from, e.g., C(++) inter-thread communication libraries, and likens them to some other CSP languages), and despite being a single type they're built for different communication flows (blocking or non-blocking comm, event loops w/select, consuming streams with range/close).

Some version of the old bullets seemed like a reasonable way to achieve those aims, but if you've got a better one, go for it. Showing what the syntax was and linking to the spec was incidental, but seems harmless and not unlike what's done elsewhere.

It looks like reverts are happening pretty aggressively now and I don't have the energy or handy references to everything written about WP policy to deal, so I'm stepping back. — Preceding unsigned comment added by 76.103.246.130 (talk) 00:25, 28 November 2015 (UTC)

I reinstated the point about syntax; I shouldn't have removed that, sorry. I also replaced the echo example with one that actually shows the concurrency features and cites a source. QVVERTYVS (hm?) 12:28, 28 November 2015 (UTC)

"FIFO buffers" seems confusing, and concurrent ordering seems unspecified

I see from edit history that a book called channels FIFO buffers. There's some truth to it, as current behavior is clearly FIFO with a single sender/receiver, and a buffered chan is clearly a buffer. But:

• Ordering under concurrency is, practically speaking, hard to plan around because the memory model makes few promises about execution order of anything and weird anomalies do actually occur. The two times I found that ordering came up the Go authors say "well, it's tricky" and launch into a long discussion--not a "yes, FIFO". Given we're writing for some readers that don't know Go's weak memory model, etc., it seems best to me to somehow try to avoid giving them a false impression they understand what turns out a complicated topic. Maybe explicitly talking weak memory model (or, e.g., randomized scheduling) is the way.
• The spec is unclear (folks have wanted to clarify it), so I'm not 100% sure the book is describing an inherent trait of the language that can be relied on in future versions. (You can reduce coordination overhead by weakening FIFO promises, sometimes.)
• It's weird to call unbuffered chans buffers, even if you can ultimately justify it.

For more about ordering, here's an old thread with some of the Go team answering "are channels FIFO?" and a recent one about tricky race conditions and the gc's implementation there.

What stands out at me from those is

• With one sender and one receiver, FIFO holds.
• When channel ordering under concurrency comes up, the Go team's says something nearer "it's complicated and confusing" than "yep, FIFO." That seems to be because:
  • With multiple senders/receivers, both "first"s in FIFO are tricky to define because of the relaxed memory model. For example, logical order needn't relate to wall time right before/after the send/receive.
  • The implementation allows some surprising anomalies: "it is possible in the gc implementation for channel send or receive operations to jump the queue under various simultaneity conditions" in the first thread, and the discussion of "drive by" goroutines in the second.
• Details of behavior change version to version (bug ends with a changelist for 1.6).
• The spec doesn't say FIFO though folks are interested in clarifying that.

On "buffers", the current text describes all channels, unbuffered or buffered, as "FIFO buffers". But Go distinguishes "unbuffered" and "buffered" channels: make(chan int)<-1 (unbuffered) blocks but make(chan int, 1)<-1 doesn't. You could argue make(chan int) is really returning a chan with a zero-item buffer or something, but it's weird enough to have two senses of the word 'buffer' floating around that I don't think it's the best choice of words to introduce the feature. The changelist on that second link also suggests that the buffered/unbuffered channel impls actually differ (i.e., unbuffered channels are not just zero length buffers).

There's something about FIFO to say (Pike says storing values FIFO is "language semantics" on the bug), I just don't want to suggest predictability that isn't, practically speaking, there. 76.103.246.130 (talk) 22:54, 7 February 2016 (UTC)

Actually, the language spec does state it explicitly (since 2013): "Channels act as first-in-first-out queues". So the promise is there, and while "buffer" wasn't a good choice of words, perhaps we should borrow the word "queue" to succinctly describe both buffered and unbuffered channels? It also seems like the different implementations have been merged (see patches linked from the bug report). QVVERTYVS (hm?) 13:49, 8 February 2016 (UTC)

Blah, which I'd seen that in the spec before going down those other rabbit holes. Still strikes me as a weird intro to chans--an unbuffered chan is a weird "queue" (since first write can't complete until matched to a read), and FIFO delivery doesn't prevent weird timing with multiple senders/receivers (thread 1 receives first but then its OS thread immediately gets suspended; thread 2 receives second and gets to keep running, so its message gets fully processed first). Can't say it's inaccurate, and not sure what I'd prefer instead, esp. re: timing stuff. May be inevitable an intro hides a bunch of weirdness when the underlying topic is so weird. — Preceding unsigned comment added by 67.188.193.139 (talk) 06:06, 9 February 2016 (UTC)

Self published sources are ok for enumerated lists of community criticisms

The Wikipedia guidelines state that self published references are "largely" not a good idea. Clearly they are inferior to published sources. But in situations where community discussion is overwhelmingly taking place outside of formal publications, they can be the best available source. The article here is better for the presence of the eight citations to sources of criticism, and the self published tag makes them less readable, so I intend to delete this tag, the purpose of which is to suggest that the use of a self published resource is erroneous. 108.46.195.138 (talk) 12:11, 1 August 2016 (UTC)

Why is the text about 1.8 not visible? If you try to edit the history it is there in the source, but not in the rendered page??

194.100.12.194 (talk) 12:38, 7 March 2017 (UTC)

"open source programming language"?

This strikes me as a silly phrase, especially in the very first sentence of an important article. I know there is a citation to Google using the same phrase. But the language itself is an abstraction. A programming language is not itself a program, and so does not have source code. The language itself is also not "free software", since it's not software. I think what they mean is that the compiler is free and open source, which certainly does mean something. (I asked a similar question at Wikipedia:Reference_desk/Computing#.22open_source_programming_language.22.3F just to be sure I wasn't completely missing the point.) Staecker (talk) 20:12, 24 September 2017 (UTC)

Features, examples, other references

Notes about things that may or may not be worth adding. Could compare with other language articles to see what's been found worth mentioning elsewhere.

Language features:

• Type embedding.
• Multiple and named return values.
• Dependencies: extra imports and circular deps not allowed.
• Built-in UTF-8 strings.
• struct (like C, unlike Java)
• Closures.

Toolset features:

• No-dependency binaries.
• Standard code formatting ('go fmt').
• Remote repository integration ('go get').
• Simple cross-compilation.
• Documentation system (godoc).
• C integration (cgo).

Standard and third-party libraries:

• Standard lib sample: net, crypto, math, syscall, gzip...
  • Seen it described as "what you need for building Web/network servers," which seems fair
• Brief overview of types of third-party libraries
  • Bindings for and direct ports of popular libs (cgzip, protobufs, Snappy, Qt...)
  • Drivers/DB connectors/net protocol implementations
  • Web frameworks
  • Specialized libraries (biogo)
  • Anyway, should go look at [4] and [5]

Community tools:

• Go Playground/Tour
• IDE integration (e.g., LiteIDE, Vim/Emacs packages)
• godoc.org

Widely acknowledged limitations?

Full pros and cons list could get hairy; point is to hit some warts that are objectively provable or widely agreed on, even by designers/boosters of Go.

• perf on microbenchmarks sometimes half that of C
• not the most DRY language; sometimes must repeat yourself
• relatedly, lack of generics or polymorphic functions or other tools for generic algorithms
• relatively new and small (if fanatical) community, lacks ecosys of C(++)/C#/Java

Possible additional examples:

Could just link to gobyexample.net, since too-many or too-long examples may not be the Wikipedia thing to do. In any case, would be great to gesture at ways idiomatic Go looks different from other static languages.

• io.Reader/Writer seem like the canonical example of ifaces
• using channels to parallelize
• covering a bunch of data types (maps, strings, interface{}, channels)

Possible external links:

• Applications using go
  • dl.google.com
  • vitess (Google's MySQL proxy)
  • go read
  • Docker
  • camlistore
• External resources
  • golang-nuts
  • godoc
  • /r/golang?
  • go-wiki
  • Go Tour/gobyexample.net — Preceding unsigned comment added by 65.205.194.42 (talk) 03:09, 27 September 2013 (UTC)

Philosophy:

Would have thought of this as too mushy/un-cite-able for WP, but C++ has a section on it, so Go's article could summarize some of the stuff its authors have written about their approach: type composability vs. type hierarchies, keeping the whole language simple enough you could hold it in your head, pragmatism. Some core parts of that that are laid out by Rob Pike in a blog post.

There are some things other things that it might take more work to find cites for, but do seem to be frequently repeated by Go authors/community members. For example, there's a sense that idiomatic Go does not just consist of a port of the corresponding C/Java/... code: bradfitz, author of a lot of the Go standard library, has said "you just block" in Go instead of using callbacks, folks have different ways of working around the lack of generic static containers/algorithms, and so on.

---

Okay, same author back here. I don't think I can put all of that here or no one will want to read it, and besides, WP isn't the place for much of it. Some distinctive things that may be worth actually digging into are 1) what makes it in some ways more like a scripting lang (type inference, "duck typing" via interfaces, fast compiler, remote package manager), 2) the decision to omit more sophisticated features, for comprehensibility (quotes about "holding the whole language in your head" or "advancing practice rather than theory", and some things left out in the name of that), 3) specific features that are unusual in their implementation details (interfaces, channels, self-contained binaries). We may already have too much about interfaces.

Anyway, folks shouldn't come here to learn Go, but might come to learn what Go is about. So the things that differ from, say, both Java and Python likely merit more words.

From another angle entirely, better external links would be nice so that interested folks can quickly see projects in Go, reference docs, tutorials, etc. — Preceding unsigned comment added by 50.1.48.10 (talk) 20:33, 6 October 2013 (UTC)

 — Preceding unsigned comment added by 50.1.48.10 (talk) 07:06, 24 September 2013 (UTC) 

I removed the following from the criticisms section. Considering the detail of the references, it may belong elsewhere as a feature:

GC has been improved to sub-millisecond GC pause times in later versions.

Metaquanta (talk) 08:49, 4 November 2018 (UTC)

Lede gets into the weeds with details on implementations

The lede as-is has too many details on Go implementations (default Go compiler, GCC, and GopherJS). The links to all the details about the various compilers detracts from the overall summary of what Go itself is. I'd suggest we briefly summarize and link to a section on Go compilers rather than attempting to describe all the details in the lede. For reference, here is the current lede:

Go (also referred to as Golang) is a statically typed, compiled programming language designed at Google by Robert Griesemer, Rob Pike, and Ken Thompson. Go is syntactically similar to C, but with memory safety, garbage collection, structural typing, and CSP-style concurrency.

There are two major implementations:

• Google's self-hosting compiler toolchain targeting multiple operating systems, mobile devices, and WebAssembly.
• gccgo, a GCC frontend.

A third compiler, GopherJS, compiles Go to JavaScript for front-end web development.

Thoughts? --Elephanthunter (talk) 16:31, 24 April 2019 (UTC)

References

"Notable users"

There are several projects in the list of "notable open-source applications" which I am not sure are notable. btcd and GoConvey seem particularly unlikely to me to be notable. Perhaps we should reevaluate the notability of the projects in this list. --Cgtdk (talk) 15:08, 3 April 2014 (UTC)

Towards that I took out the last four items on the list, which didn't appear to either be infrastructure for a notable operation (Bitly nsq, Heroku doozer) or have pages saying lots of people'd used them (like Docker or Juju or others).Twotwotwo (talk) 01:19, 10 June 2014 (UTC)

The list seems outdated - there are probably much more open source projects and companies now. Also, is it worth mentioning that Golang is designed to encourage users to depend on the standard library? Corgifan200 (talk) 02:46, 5 October 2017 (UTC)

I would argue that this list needs to be entirely omitted. It serves no purpose for defining the language other than to advertise for various open-source projects. Axium Cog (talk) 18:36, 25 September 2019 (UTC)

Unicode and runes in Go

This article uses but fails to define the word rune.

A rune is a datatype equivalent to "an int32 containing a Unicode character", meaning a code point. It does not contain the otherwise usual UTF-8 encoding used in Go. If a reference is needed, https://blog.golang.org/strings contains this information. I'm posting this here instead of editing because I'm new to Go and I don't want my changes reverted. David Spector (talk) 01:04, 4 September 2020 (UTC)

It is disingenuous to consider Go a functional language

Go is an imperative, concurrent, and maybe OO programming language but it is not a functional language. I suggest removing functional as one of its paradigms as it is declared in the sidebar now. And I am not even referring to immutability, pureness, etc. -- even loosely speaking, Go is not a functional language.

Even though Go uses the keyword func for declaring reusable snippets of code, these code snippets are procedures, not functions.

In other words, Go's functions are more like C's functions than Haskell, OCaml, or LISP functions. And in the wiki page for C, functional is not listed as one of its paradigms, and correctly so.

Another important aspect of a functional programming languages is function composition. As Go does not have an Either monad like Haskell, or something like Scala's Try type, and instead of exception handling returns error variables from its functions, it makes function composition in some cases impossible and in other cases too complex.

Another feature of loosely functional programming languages is that they let programmers manipulate collections in a declarative manner but Go's arrays, slices, and maps can only be operated on imperatively. Even though some proof-of-concept libraries out there have mimicked functional programming in Go, they are not designed for use in production code.

Python, Java, and JavaScript let you operate on collections declaratively, compose functions, curry functions, etc. so loosely speaking it is acceptable to say they are functional (or hybrid functional) programming languages.

If we call Go functional, then we should call C functional too. If we call C functional, then we should call assembly code functional too.

Anyway, I propose removing "functional" as one of the paradigms that Go falls under. — Preceding unsigned comment added by Behrangsa (talk • contribs) 07:16, 2019 May 3 (UTC)

Yeah, I agree it's mostly imperative. Technically we have books like "Learning Functional Programming in Go", which label Go a functional language [6]. There have been discussions about what constitutes a functional language in the functional programming article if you peruse the archives [7] [8]. Golang gets close to functional programming in some ways: It has first-class functions, higher-order functions, and recursion. But it does seem to fall short. Can we find any reliable sources on the subject? --Elephanthunter (talk) 16:28, 3 May 2019 (UTC)

Agree fully. The Go team seems to be the source of this claim, and I think they possibly don't know about actual functional programming languages, which are not widely used. Go is nothing like them; it is far more like a cross between JavaScript and C++. One of the first and iconic functional programming languages was ML (programming language), released in 1973. It achieved some popularity among academic researchers, but would not likely be used in apps or websites. 01:14, 4 September 2020 (UTC)

Change the license

The "BSD-style" license is very vague and confusing because it's lumping together but they have different clauses. Here is why? Because every BSD license has different clause the original one is GPL-incompatible according to FSF. You should study the BSD license. Let's say the Golang BSD-style license into BSD 3 clause. Remember: BSD license is not divided but rather a versions and you must check the source of the software license. I'm not an FSF member Flankbed (talk) 13:08, 23 January 2021 (UTC)

I changed it to "3-clause BSD". If you ignore the whitespace, https://golang.org/LICENSE is identical to the 3-clause BSD license. —Dexxor (talk) 08:30, 24 January 2021 (UTC)

Memory safety

What I found very interesting about Go is that it is memory safe (unlike C/C++) without being managed (like Java). You can't just write into arbitrary memory, all memory access is checked (all slices have a length). I think this should be mentioned in the article (it's also relevant to the above question of "what's special about go"). 65.113.40.1 (talk) 21:34, 13 June 2011 (UTC)

Is Go memory-safe? There's array bounds checking and garbage collection, which makes sequential programs memory safe. Concurrent programs are iffy. Go's "maps" are not concurrency-safe. You can share references across goroutines, so race conditions are quite possible.[9] --John Nagle (talk) 18:41, 19 January 2013 (UTC)

24.7.67.251 (talk · contribs) wrote in a comment "Go isn't memory-safe when there are data races, though slightly unclear just how unsafe (like, does the whole show segfault?". Yes, it can. There are demo programs and exploit code which exploit timing windows in slice descriptor updates.[10] There's some denial about this in the Go community. "Effective Go"[11] paints an unrealistically rosy picture of the language. In contrast, Google's own AppEngine locks Go programs down to one thread to protect the cloud-based execution environment.[12] --John Nagle (talk) 20:05, 9 October 2013 (UTC)

As of 2020, Go was still not memory safe in concurrent code: https://www.reddit.com/r/golang/comments/erjsks/im_aware_of_race_condition_but_should_i_care/ff4971p/ I believe the introductory section should not claim that the language is "memory safe", or should have some caveat to that claim. 2601:282:8202:A7B0:ECFD:CF90:1142:4486 (talk) 19:35, 6 May 2021 (UTC)

"Google Go" listed at Redirects for discussion

An editor has identified a potential problem with the redirect Google Go and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 January 26#Google Go until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Vitaium (talk) 04:27, 26 January 2022 (UTC)

"Google go" listed at Redirects for discussion

An editor has identified a potential problem with the redirect Google go and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 February 5#Google go until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Vitaium (talk) 13:56, 5 February 2022 (UTC)

Linke

Firbase 2409:4051:20E:2973:51BB:BCB4:9A87:D81F (talk) 06:54, 6 May 2022 (UTC)

@2409:4051:20E:2973:51BB:BCB4:9A87:D81F (talk) 05:54,6 May 2022 (UTC) 2409:4051:20E:2973:51BB:BCB4:9A87:D81F (talk) 06:57, 6 May 2022 (UTC)

Typing: strong vs. weak

Hi @136.26.36.110 - I disagree that Go is weakly typed. Go has type inference, but (aside from a dynamic cast at runtime), the type system is strongly typed. The tweet you provided (https://twitter.com/rob_pike/status/546973312543227904) is about the satisfaction of interfaces, not about the type system in general, although it does point to a stronger type system than duck typing, but a could also be construed as Go also includes type inference which is not the same as weak typing. If you refer to Strong and weak typing#Definitions of "strong" or "weak", neither of the first two criteria for weak - Implicit type conversions & pointer arithmetic - are present in Go. The final criteria for strongly typed - static type checking - is included in Go. Finally, from the official docs:

Go is a general-purpose language designed with systems programming in mind. It is strongly typed and garbage-collected and has explicit support for concurrent programming. Programs are constructed from packages, whose properties allow efficient management of dependencies.

Jonathan Williams (talk) 21:11, 4 October 2022 (UTC)

Applications section

Is this bullet-pointed list useful as anything more than advertising? In my opinion, if this section must be present, it would be more relevant if it discussed a few select examples of applications where the choice to develop them in Go was crucial to their implementation/development time/function/performance, or perhaps something similar to the Uses section of the C article, and not simply a list of applications that happen to be developed in Go. askeuhd (talk) 13:49, 21 February 2023 (UTC)

Plan 9 C

The page mentions Go is inspired by Plan 9's C dialect, but the reference only talks about Plan 9 assembly conventions. Is there even such a thing as a Plan 9 C dialect? MattF (talk) 14:48, 23 June 2022 (UTC)

@Mattf: I believe the dialect being referred to, is what is mentioned on page 9 here. The [Pike95] citation mention in this document should be this. But I agree that a better source more explicitly describing the influence between this Plan 9 C dialect and Go might be beneficial. --askeuhd (talk) 11:40, 8 August 2022 (UTC)

The design section gives the impression that C was the only influence, versus being among the various influences as shown in the influenced by section. Robert Griesemer has publicly stated that he was also influenced by Oberon-2 (which shows in the influenced by section). Refer to- The Evolution of Go from 17:00 on. Maybe there needs to be more elaboration about the design influences.

Wukuendo (talk) 02:07, 16 March 2023 (UTC)

There was specifically support for compiling plan 9 C in the GC compiler, per an old design document https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8. The command was "6c" and worked like the plan9 6c. Artoria2e5 🌉 05:54, 7 May 2023 (UTC)

Go Programming Language Family Tree

[...] But there are other ancestors in Go's family tree [...] Rob Pike and others began to experiment with CSP implementations as actual languages. The first was called Squeak [...] This was followed by Newsqueak, which offered C-like statements and expression syntax and Pascal-like type notation. It was a purely functional language with garbage collection, again aimed at managing keyboard, mouse, and window events. Channels became first-class values, dynamically created and storable in variables. The Plan 9 operating system carried these ideas forward in a language called Alef (programming language), but its omission of garbage collection made concurrency too painful

obligatory Disambiguation page line

i tried adding it but im a noob! Go (disambiguation) needs to exist, google comes here first for daft reasons.

I have added this with the Other uses template. Lightbloom (talk) 20:42, 7 September 2023 (UTC)

TODO

twitter source https://twitter.com/rob_pike/status/546973312543227904 is no longer available and needs to be replaced with an archived version https://web.archive.org/web/20220407025913/https://twitter.com/rob_pike/status/546973312543227904 — Preceding unsigned comment added by 2.206.189.140 (talk) 10:32, 22 August 2023 (UTC)

Someone has done this. However this should be replaced with a secondary source if possible. Lightbloom (talk) 20:46, 7 September 2023 (UTC)