[V3] Concepts List

[tehsphinx]

Source to compare once this list gets edited: https://github.com/exercism/v3/blob/master/languages/go/reference/README.md

Go

This is a list of concepts of Go. They are categorized into OOP, Functional and General. The Specialties category tries to mention concepts that are somewhat special to Go. A concept can belong to multiple categories.

Specialties

Concepts that are special to Go or have key differences to a vast majority of other languages.

• Channels
• Code Formatting
• Concurrency
• Constants
• context.Context
• Defer
• Empty Interface
• Errors and Error Handling
• Goroutines
• Modules
• Multiple Return Values
• Named Returns
• Nil
• Packages
• Panics
• Pointers
• Readers, Writers, Buffers, Pipes
• Recover
• Reflection
• Select
• Type Switch
• Unsafe
• WaitGroups
• Zero Values

General concepts

• Arithmetic
• Bitwise manipulation
• Boolean logic
• Channels
• Code Formatting
• context.Context
• Comments
• Concurrency
• Conditionals
• CSV Handling
• Debugging
• Defer
• Errors and Error Handling
• Functions
• Globals
• Ignoring (return) values
• Init function
• JSON Handling
• Loops
• Methods
• Modules
• Mutexes
• Packages
• Panics
• Pointers
• Nil
• Random (math/rand vs crypt/rand)
• Readers, Writers, Buffers, Pipes
• Recover
• Reflection
• Regular Expressions
• Scope
• Switch
• Type Switch
• Unsafe
• Variables
• WaitGroups
• Zero Values

Object-oriented Concepts

Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of "interface" in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous-but not identical-to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, even built-in types such as plain, "unboxed" integers. They are not restricted to structs (classes). Is Go an object-oriented language?

• Structs (Classes)
• Method Sets
• Encapsulation
• State
• Mutation
• Composition
• Polymorphism (?)
• Interfaces

Functional Concepts

Go is not a functional language but has a lot of features that enable us to apply functional principles. Functional Go

• Anonymous Functions
• Function Composition
• Higher Order Functions
• Multiple Return Values
• Named Returns
• Nested Functions
• Partial Application
• Pipelines (?)
• Pure Functions
• Recursion
• REPL (some community projects)
• Type Inference

Advanced

• Code generation (go generate)
• plugins
• cgo
• Assembly in Go
• conditional compilation

Patterns

Concurrency

• synchronization for sharing memory (mutex, atomics)
• synchronization via communication (channels)
• data protected by confinement (guard pattern ?)
• for-select loop
• fan-in, fan-out

Types

Types are not really concepts but it might be helpful to have as list of types Go has as some might need an extra introduction. Some are already added as a concept above, e.g. channels, interfaces, etc. as there are special concepts around some of Go's types.

• array (rarely used)
• bool
• channel
• function
• interface
• interface{} (empty interface)
• map
• nil
• Numeric Types (uint types, int types, float types, complex types, byte and rune)
• pointer
• slice
• string
• struct
• time.Duration
• time.Time

Tooling

• go doc / documentation, eg export & package documentation. Machine/human. Inline "why"
• golint
• go vet
• go test / writing tests
• benchmarking / profiling
• gofmt
• golangci-lint

Resources used

• The Go Programming Language Specification
• Effective Go
• Frequently Asked Questions (FAQ)
• Concurrency Patterns

[tehsphinx]

Above is a list of Concepts I have started in the early discussions around v3. This is by no means a finished list!

I would like to use this Issue as a discussion. Everything on this list is to be questioned!

I suggest we edit the list above as we go and then create a PR to update the changes to the repository.

My approach for this list was looking through the 3 links mentioned at the bottom and see what features/concepts Go has. Another approach would be to look at an exercise and break down which concepts are needed to solve it. Yet another approach would be to look at other tracks (e.g. C#, JavaScript) and see what concepts they use and whether that applies to Go. For example we do not have the concept of Strings in here yet where we could teach students about working with strings (e.g. concatenation, manipulation, iteration, etc.). Maybe that even needs multiple concept exercises.

[sebito91]

This is an awesome start @tehsphinx, thanks for pulling this together! I'd like to propose extending this to an Advanced section that may not just be exclusive to go, but would include topics that an advanced go developer might use. To start, I would add the following:

ADVANCED

• code generation (go generate ./...)
• plugins
• cgo

And also, do we think that adding concrete examples of golang projects would be good? A section called Examples or whathaveyou?

[sebito91]

Of course these would be purely OPTIONAL topics ^^

[tehsphinx]

@sebito91 Thanks! I added the Advanced section in the description with the concepts you mentioned.

Also added 2 more that came to mind: Assembly in Go and conditional compilation (plattform specific / build tags)

About optional: We will definitely not start with those 😄 .

[tehsphinx]

I'm also wondering if and how we can maybe bring in Design Patterns. Not necessarily the classical ones (which might also be interesting and worthwhile) but more Go specific patterns that aren't needed or possible in other languages. Since Go is a simple language, some things are harder to do if you don't know about certain patterns.

What do you all think about this?

(of course we will need to focus on the core concepts first...)

[hans-d]

Some thoughts, not sure if they are separate topics or should be part of others:

• documentation (go doc), eg export & package documentation. Machine/human. Inline "why"
• zero values (more likely part of variables)
• golint
• go vet
• tests
• benchmarking / profiling
• mindset / approach (line of sight, keep it simple, multiple returns, ...)

[tehsphinx]

documentation (go doc), eg export & package documentation. Machine/human. Inline "why"
golint
go vet
tests
benchmarking / profiling

I'm generally wondering if we should go into the tooling of Go as well.

I'd say we can open a section on this for now. Anyone interested in adding that section? (if you can't edit the description above, just create the section in a comment and I'll ad it)

[tehsphinx]

zero values (more likely part of variables)

Yes, could be part of a concept exercise teaching e.g. variables.

In my head I'm currently making a distinction between this document listing all the concepts and the list of concept exercises we need to derive from this after. There might be some concepts that need multiple concept exercises and other concept exercises might handle multiple concepts at once.

[tehsphinx]

mindset / approach (line of sight, keep it simple, multiple returns, ...)

I'm not yet sure where to put this. Multiple Returns is in there already... the other things are important but hard to place.

[tehsphinx]

Note: I added time.Time and time.Duration above as I think those are quite fundamental types to get to know. Any other types we should introduce?

[tehsphinx]

Added JSON Handling as that can be quite a stumbling block for people new to Go.

[tehsphinx]

Just added a bunch of concepts:
Switch
Globals
Ignoring (return) values
Init function
Select
Goroutines

[andres-zartab]

What about constants and type aliases?

[tehsphinx]

Added Constants. Not sure about type aliases because of this:

Type aliases are not meant for everyday use. They were introduced to support gradual code repair while moving a type between packages during large-scale refactoring. https://yourbasic.org/golang/type-alias/

Not sure we should teach them specifically. What do you think?

[andres-zartab]

Yeah, probably best to leave them untouched for now.

[DavyJ0nes]

This looks great. I'm wondering if it's worth adding a specific exercise around context.Context as it gets used a lot in web work and can lead to some interesting failures 😄?

[hans-d]

Some other:

• debugging
• source code layout
• compiler, flags, cross architecture

[andres-zartab]

Some that came to mind:

• Recover
• math/rand vs crypt/rand
• Trailing commas at the end of structs/maps allow to have fewer lines affected when PR's add new cases

[tehsphinx]

@hans-d

compiler, flags, cross architecture

I see that in conditional compilation.

source code layout

You mean: how to structure code? package, folders, files, etc?

[tehsphinx]

@andres-zartab

Trailing commas at the end of structs/maps allow to have fewer lines affected when PR's add new cases

An interesting detail we could have in a After.md as a "Did you know?". Not sure we should add it as a concept though.

[tehsphinx]

Very good comments here! Keep them coming! 😁

[andres-zartab]

@andres-zartab

Trailing commas at the end of structs/maps allow to have fewer lines affected when PR's add new cases

An interesting detail we could have in a After.md as a "Did you know?". Not sure we should add it as a concept though.

Yeah, maybe we could introduce it as a DYK when working with maps and structs or something like that.

[andres-zartab]

We could also add:

• Buffers, Readers, Writers
• CSV parsing

[tehsphinx]

CSV Parsing

I added it, although I think that is more a good use case for an exercise rather than a concept. It definitely is borderline...

[tehsphinx]

Started with a Patterns section where we can gather different patterns to teach. I started with some concurrency patterns but this is by no means exhaustive.

[Lewiscowles1986]

Should be noted that pointers, and maps are dealt with in the current concepts stage, so can probably be ticked off the list.

Not sure if I'm telling a dog how to bark here, but if you * [] you can get tick-boxes, and progress can be communicated.

[Lewiscowles1986]

👍 for

• goroutines
• waitgroups
• select
• channels

[junedev]

To give a better overview of what's already implemented etc there is a roadmap document now and a new issue for discussions: #1886