Category talk:Go

Language versioning and updates

Official public launch was November 10, 2009. As of 2011, substantial changes to the base language are infrequent, but there is a new release with bug fixes and library enhancements every week typically. Releases are assigned no version number other than a date, so the language must certainly still be considered a work in progress. It is likely that some RC task solutions will need to be updated at some point due to language changes. —Sonia 07:50, 17 January 2011 (UTC)

Since you're more knowledgable about the language than I am (much more!) I suggest you curate its solutions; it shouldn't be too much work as yet. You may find the optional version parameter to {{works with}} to be useful; it lets you tag in what specific releases are known to work. –Donal Fellows 09:29, 17 January 2011 (UTC)

Tasks not considered / Omit from Go

I thought it would be worthwhile to record some thoughts about tasks marked omit. (All initial content in this section —Sonia 22:10, 29 April 2011 (UTC). I'll sign additions individually.)

In general, non-solutions

I don't think the following sould be considered legitimate solutions. I think solutions of the following sorts should be removed and the task marked Omit from Go.

• Solutions that essentially implement the task in C or C++ code called through Cgo or Swig, excepting of course, tasks that specifically mention going outside of the language.

• Solutions that use package unsafe to do most of what they do. It might be acceptable to use unsafe for accessing something or converting something, but not wholesale implementation of the task by peek and poke.

• Solutions using subpackages of exp or go. Exp is for experimental and I don't think we'd be doing RC readers any favors by showing solutions based on these packages. The subpackages of go are not experimental, but they are pieces of the implementation of Go. That is, they are components for writing a language, not using one. Unless the task is about implementing a language, again, I don't think we would be doing RC readers any favor by implementing our own flavor of Go just to allow a task solution.

• Solutions that excessively stretch the interpretation of the task. I know, it's usually a total judgement call. I've written several solutions that stretch interpretations pretty far. If you run across something like this and have strong feelings about it, remove the solution, mark the task omit, and then explain your reasoning here. The decision about how much stretching to allow sould be based heavily on the task wording. If the task description is very specific, not much stretching should be allowed. If the task says “do your best to achieve the end result,” then creative interpretations are probably in order.

Add a variable to a class instance at runtime

Go has no dynamic type defintion. All data types are determined and fixed at compile time.

Arena storage pool

Go uses a single arena, created at program load and managed by the Go runtime. Mmap is available as a syscall, but Go offers no support for initializing a raw block of memory like this as a usable heap and no support for working with multiple managed heaps. Its multiple stacks, I believe, are created within this one arena.

Call a function in a shared library

Go programs are statically linked and do not load libraries from external files.

Create an object/Native demonstration

My reading of the task is that it wants you to override default behavior of a [map, in the case of Go] without wrapping it in something with a different syntax. Sure, you could wrap a map in a defined type with a set of methods that do what the task wants, but I think the task is calling for something that looks exactly like map but works differently. Natively, maps are created with make() and used with the indexing syntax. A user type with methods cannot be created with make nor used similarly with indexing syntax.

Define a primitive data type

Similar reasoning to Create an object/Native demonstration. You could wrap an int in a struct, but you'd lose all the syntax and--worse for ints--type compatibility.

Dynamic variable names

No variable names exist at runtime. Even the reflect package doesn't have them. (Field names, but not variable names.)

Exceptions/Catch an exception thrown in a nested call

The specific wording of the task description excludes Go. It specifies that foo call bar, bar call baz, and foo catch U0. The only execption-like mechanism we have is panic/recover. If foo defers a function that uses recover, it can catch a panic, but it cannot continue executing. Deferred means deferred to the end and foo is ending one way or another the first time a panic gets to it.

One totally contrived solution would be to make the second call to bar from within the deferred function. I think most anyone would cry foul at that.

It strikes me as plausibly appropriate you raise this issue in the task page, and suggest that the task be renamed. It sounds like either a better name for the task might be "Recover from a thrown exception", or that the task should perhaps be adjusted to more cleanly reflect a core intent. --Michael Mol 02:26, 30 April 2011 (UTC)