Why Go design not to mark as error when assign a variable to whatever interface that has same signature

I'm just start learning Go, most of my background came from Java, Ruby.

I just wonder that, from my example, why Go language designer intentionally design to not specify an interface type when implement an interface. So that if someone accidentally try to assign an object to an interface that match a signature but doesn't intend to implement that interface, that would lead to be a bug and cannot be catch at a compile time.

You can try at this: https://play.golang.org/p/1N0kg7m4eE

package main

import "fmt"

type MathExpression interface {
	calculate() float64
}

type AreaCalculator interface {
	calculate() float64
}

type Square struct {
	width, height float64
}

//This implementation intend to implement AreaCalculator interface
func (s Square) calculate() float64 {
	return s.width * s.height
}

func main() {
    //Suppose that a developer got this object from 
    //somewhere without a knowledge that object is a Square struct
	mysteryStruct := Square{width: 4, height: 3}
	var areaCalculator AreaCalculator = mysteryStruct
	fmt.Println("Area of something:", areaCalculator.calculate())
	
	var mathExpression MathExpression = mysteryStruct
	fmt.Println("This should not work:", mathExpression.calculate())
}

One advantage of "implicitly satisfied" interfaces (ones where types don't need to explicitly declare that they implement them) is that interfaces can be created after the fact. You can see several types that have a method in common, perhaps in different packages, and decide to write a function that can accept any of them by calling for a new interface that specifies that method.

Also, Go's approach to interfaces lets you write an abstraction of the behavior of a type in an existing package, without modifying the original package. The first example that comes to my mind is the File interface in the net/http package:

type File interface {
	io.Closer
	io.Reader
	io.Seeker
	Readdir(count int) ([]os.FileInfo, error)
	Stat() (os.FileInfo, error)
}

It represents a file that can by served by an http.FileServer. Normally it is an os.File, but it could be anything that fulfills the interface. For example, I think someone has made an implementation that serves files out of a zip archive.

Since the net/http package is defined in the standard library, it might have been possible to explicitly declare that os.File implements http.File—but it would have made the os package depend on the net/http package. This is a circular dependency, because net/http depends on os.

In an inheritance-based language, someone who was trying to do this would probably just give up on using an interface, and make http.FileServer require that all files be subclasses of os.File. But this would be a pain, because they wouldn't need any of the implementation of an os.File; they would just be inheriting from it to satisfy the type system.

The example in the OP works because of a poorly-chosen method name. It is not at all clear what a Square's calculate method should return. Its area? Its perimeter? Its diagonal? If the method were named CalculateArea, which would be the idiomatic name for the single method in an interface named AreaCalculator, it would not be possible to confuse an AreaCalculator and a MathExpression.

One benefit of this approach is inversion of dependencies. In typical languages with static type systems, you have source level dependency from implementation to interface. Which means you can't deploy them separately. With implicit interfaces you have no source level dependency and implementation module can be deployed/developed/build without module containing interface. This gives you flexibility usually reserved for dynamic type systems.

Go uses implicit interfaces, it means that type implements interface if it has all functions required by interface. Note that you don't have to declare in code that type implements interface (as in Java).

Such language design have good and bad consequences:

• type can implement interface by accident (this happened in your example). Actually it happens very rarely so IMO it is not a big problem.
• without interface declaration in code you don't know which interfaces your type implements. This problem can be solved by using good IDEs.
• you can easily create adapters and similar design patterns
• you can easily create mocks
• more readable code (type declaration is very simple in go)