![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
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)
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)
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 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)
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
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)
What is Google's motivation to support a systems programming language? -- Abdull ( talk) 18:13, 30 January 2011 (UTC)
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)
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)
"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)
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.
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:
rune
type represents a Unicode code pointint16
to an int32
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
nil
until allocated with make()
string
is an immutable UTF-8 stringmap[keytypevaltype
is a hash table
make()
before usestruct
s have syntactical differences from C
Point{x: 3, y: 2}
type LockableInt struct { x int; sync.Mutex; }
chan type
is a type-safe channel; see Concurrency
make(chan type)
is necessarymake(chan type, 100)
<-chan int
is receive-onlytype
keyword can assign a name to any type: type Token []byte
func (t Token) IsNum() bool
interface
values point to other types; see Interfaces50.1.48.10 ( talk) 07:59, 13 October 2013 (UTC)
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:
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)
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)
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)
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:
There is a T101 in your kitchen ( talk) 10:09, 23 December 2013 (UTC)
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.:
If there are sources, would consider some other categories of complaint I hear:
I would *not* like to:
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)
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)
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)
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:
There should jsut be a complete, unbiased list of language features instead of "go is better than c".
This is really just advertising.
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.
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.
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".
Please also quote criticism and not just opinions that celebrate go.
195.212.29.185 ( talk) 09:54, 2 January 2014 (UTC)
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)
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)
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-nuts Hawtpeppers ( talk) 06:48, 10 September 2015 (UTC)
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)
@ 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)
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)
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 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:
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
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)
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)
194.100.12.194 ( talk) 12:38, 7 March 2017 (UTC)
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)
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:
Toolset features:
Standard and third-party libraries:
Community tools:
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.
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.
Possible external links:
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. [2] [3] [4]
Metaquanta ( talk) 08:49, 4 November 2018 (UTC)
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 [5]) is a statically typed, compiled programming language designed at Google [6] by Robert Griesemer, Rob Pike, and Ken Thompson. [7] Go is syntactically similar to C, but with memory safety, garbage collection, structural typing, [8] and CSP-style concurrency. [9]
There are two major implementations:
- Google's self-hosting [10] compiler toolchain targeting multiple operating systems, mobile devices, [11] and WebAssembly. [12]
- gccgo, a GCC frontend. [13] [14]
A third compiler, GopherJS, [15] compiles Go to JavaScript for front-end web development.
Thoughts? -- Elephanthunter ( talk) 16:31, 24 April 2019 (UTC)
References
It's the story of how improvements to the Go runtime between Go 1.4 and Go 1.6 gave us a 20x improvement in garbage collection (GC) pause time, of how we've gotten another 10x improvement in Go 1.6's pauses, and of how sharing our experience with the Go runtime team helped them give us an additional 10x speedup in Go 1.7 while obsoleting our manual tuning.
{{
cite web}}
: Cite has empty unknown parameter: |dead-url=
(
help)
structural_typing
was invoked but never defined (see the
help page).The compiler and runtime are now implemented in Go and assembler, without C.
Ada, Go and Objective-C++ are not default languages
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)
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)
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)
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)
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)
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)
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)
Firbase 2409:4051:20E:2973:51BB:BCB4:9A87:D81F ( talk) 06:54, 6 May 2022 (UTC)
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:
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)
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)
[...] 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
i tried adding it but im a noob! Go (disambiguation) needs to exist, google comes here first for daft reasons.
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)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
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)
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)
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 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)
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
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)
What is Google's motivation to support a systems programming language? -- Abdull ( talk) 18:13, 30 January 2011 (UTC)
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)
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)
"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)
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.
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:
rune
type represents a Unicode code pointint16
to an int32
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
nil
until allocated with make()
string
is an immutable UTF-8 stringmap[keytypevaltype
is a hash table
make()
before usestruct
s have syntactical differences from C
Point{x: 3, y: 2}
type LockableInt struct { x int; sync.Mutex; }
chan type
is a type-safe channel; see Concurrency
make(chan type)
is necessarymake(chan type, 100)
<-chan int
is receive-onlytype
keyword can assign a name to any type: type Token []byte
func (t Token) IsNum() bool
interface
values point to other types; see Interfaces50.1.48.10 ( talk) 07:59, 13 October 2013 (UTC)
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:
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)
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)
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)
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:
There is a T101 in your kitchen ( talk) 10:09, 23 December 2013 (UTC)
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.:
If there are sources, would consider some other categories of complaint I hear:
I would *not* like to:
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)
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)
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)
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:
There should jsut be a complete, unbiased list of language features instead of "go is better than c".
This is really just advertising.
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.
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.
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".
Please also quote criticism and not just opinions that celebrate go.
195.212.29.185 ( talk) 09:54, 2 January 2014 (UTC)
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)
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)
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-nuts Hawtpeppers ( talk) 06:48, 10 September 2015 (UTC)
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)
@ 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)
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)
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 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:
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
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)
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)
194.100.12.194 ( talk) 12:38, 7 March 2017 (UTC)
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)
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:
Toolset features:
Standard and third-party libraries:
Community tools:
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.
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.
Possible external links:
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. [2] [3] [4]
Metaquanta ( talk) 08:49, 4 November 2018 (UTC)
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 [5]) is a statically typed, compiled programming language designed at Google [6] by Robert Griesemer, Rob Pike, and Ken Thompson. [7] Go is syntactically similar to C, but with memory safety, garbage collection, structural typing, [8] and CSP-style concurrency. [9]
There are two major implementations:
- Google's self-hosting [10] compiler toolchain targeting multiple operating systems, mobile devices, [11] and WebAssembly. [12]
- gccgo, a GCC frontend. [13] [14]
A third compiler, GopherJS, [15] compiles Go to JavaScript for front-end web development.
Thoughts? -- Elephanthunter ( talk) 16:31, 24 April 2019 (UTC)
References
It's the story of how improvements to the Go runtime between Go 1.4 and Go 1.6 gave us a 20x improvement in garbage collection (GC) pause time, of how we've gotten another 10x improvement in Go 1.6's pauses, and of how sharing our experience with the Go runtime team helped them give us an additional 10x speedup in Go 1.7 while obsoleting our manual tuning.
{{
cite web}}
: Cite has empty unknown parameter: |dead-url=
(
help)
structural_typing
was invoked but never defined (see the
help page).The compiler and runtime are now implemented in Go and assembler, without C.
Ada, Go and Objective-C++ are not default languages
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)
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)
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)
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)
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)
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)
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)
Firbase 2409:4051:20E:2973:51BB:BCB4:9A87:D81F ( talk) 06:54, 6 May 2022 (UTC)
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:
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)
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)
[...] 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
i tried adding it but im a noob! Go (disambiguation) needs to exist, google comes here first for daft reasons.
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)