Talk:Go (programming language)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computer science (Rated C-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
 
WikiProject Free Software / Software / Computing  (Rated C-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Free Software, a collaborative effort to improve the coverage of free software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software (marked as Low-importance).
Taskforce icon
This article is supported by WikiProject Computing (marked as Low-importance).
 
WikiProject Plan 9 (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Plan 9, a collaborative effort to improve the coverage of Plan 9 from Bell Labs on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
 

Naming Controversy[edit]

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[edit]

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!"?[edit]

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)

CSP references[edit]

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[edit]

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)

"It has been reported that many have called for..."[edit]

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)

Google has not commented ... doesnt this require a reference?[edit]

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

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[edit]

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[edit]

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?[edit]

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)

Memory safety[edit]

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.[1] --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.[2] There's some denial about this in the Go community. "Effective Go"[3] 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.[4] --John Nagle (talk) 20:05, 9 October 2013 (UTC)

Building on previous work related to the Inferno operating system?[edit]

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[edit]

"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. (mbork3!) 16:36, 13 June 2013 (UTC)

Features, examples, other references[edit]

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 [5] and [6]

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

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) 

Shelved section on Go's types; improving Syntax section[edit]

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[edit]

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[1]
  • 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[edit]

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[edit]

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)

Tendentious language[edit]

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)

"Notable users"[edit]

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)

Notable downsides and criticism![edit]

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:

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)