Go is a general-purpose language designed with systems programming in mind. It is strongly typed and garbage-collected and has explicit support for concurrent programming. Programs are constructed from packages, whose properties allow efficient management of dependencies
There are boolean constants, rune constants, integer constants, floating-point constants, complex constants, and string constants. Rune, integer, floating-point, and complex constants are collectively called numeric constants.
Go developers generally only rely on encapsulation when it's necessary, such as when field data needs to be validated by setter methods. In Go, if you don't see a need to encapsulate a field, it's generally okay to export it and allow direct access to it.
Q: I've seen other languages where the name of every getter method started with "Get", as in GetName, GetCity, etc. Can I do that in Go?
A: The Go language will allow you to do that, but you shouldn't. The Go community has decided on a convention of leaving the Get prefix off of getter method names. Including it would only lead to confusion for your fellow developers! Go still uses a Set prefix for setter methods, just like many other languages, because it's needed to distinguish setter method names from getter method names for the same field
Q: Many other languages don't allow access to encapsulated values outside of the class where they're defined. Is it safe for Go to allow other code in the same package to access unexported fields?
A: Generally, all the code in a package is the work of a single developer (or group of developers). Generally all the code in a package has a similar purpose, as well. The authors of code within the same package are most likely to need access to unexported data, and they're also likely to only use that data in valid ways. So, yes, sharing unexported data with the rest of the package is generally safe. Code outside the package is likely to be written by other developers, but that's okay because the unexported fields are hidden from them, so they can't accidentally change their values to something invalid
#github.com/misostack/calendar/event.go
package calendar
// Event : defined an event such as birthday, anniversary
type Event struct {
Title string
Date Date
}
# github.com/misostack/calendar/date.go
package calendar
// Date type defined a date in year
type Date struct {
year int
month int
day int
}In Go, an interface is defined as a set of methods that certain values are expected to have. You can think of an interface as a set of actions you need a type to be able to perform
Many other languages would require us to explicitly say that MyType satisfies MyInterface. But in Go, this happens automatically. If a type has all the methods declared in an interface, then it can be used anywhere that interface is required, with no further declarations needed.
A concrete type specifies not only what its values can do (what methods you can call on them), but also what they are: they specify the underlying type that holds the value's data.
When you have a value of a concrete type assigned to a variable with an interface type, a type assertion lets you get the concrete type back. It's kind of like a type conversion. Its syntax even looks like a cross between a method call and a type conversion. After an interface value, you type a dot, and a pair of parentheses with the original type. (Or rather, what you're asserting the value's original type is.)
func tryOut(d Player, song string) {
d.Play(song)
d.Stop()
recorder, ok := d.(TapeRecorder)
if ok {
recorder.Recording()
} else {
fmt.Printf("%v was not a TapeRecorder.\n", d.Title())
}
}type Stringer interface {
String() string
}
type error interface {
Error() string
}type AnyThing interface {
}The empty interface doesn't require any methods to satisfy it, and so it's satisfied by all types




