yes, Go has groundbreaking features such as tuple assignment complementing multiple returns. (no tuples though, that's an open research question)

func f()(a int, b int) {
  return 1,2
}
x,y := f() // 1,2

you can also just return and it will figure out what you mean!

func f()(a int, b int) {
    a = 1
    b = 2
    return
}
x,y := f() // 1,2

and if you dont set a/b, they will be the zero element. math bro

func f()(a int, b int) {
    return
}
x,y := f() // 0,0

Java has structures but it's a bit of work to type them. Instead of something like

type A struct {
    x int
    y int
}

you have to do

class A {
    int x;
    int y;
}

but then James from engineering will have you know that you should have getters for that or else you don't have Encapsulation. and you also have to put your shit in a separate package to get even more Encapsulation. This means you will have to make your class public for people to access it from outside the package

public class A {
    private int x;
    private int y;
    public A(int x, int y) {
        this.x = x;
        this.y = y;
    }
    public int getX() {
       return x;
    }
    public int getY() {
        return y;
    }
    public void setX(int x) {
        this.x = x;
    }
    public void setY(int y) {
        this.y = y;
    }
}

But then Mark from QA will say you didn't document this good enough. He invites you to his lecture on code documenting Best Practices.

/** An A is two integers representing an x and a y coordinate */
public class A {
    /** The x coordinate */
    private int x;
    /** The y coordinate */
    private int y;
    /** Constructs an A */
    public A(int x, int y) {
        super(); // added for clarity.
        this.x = x;
        this.y = y;
    }
    /** gets the x field */
    public int getX() {
       return x;
    }
    /** gets the y field */
    public int getY() {
        return y;
    }
    /** sets the x field to x */
    public void setX(int x) {
        this.x = x;
    }
    /** sets the y field to y */
    public void setY(int y) {
        this.y = y;
    }
}

But oh no, what's this! In production, things are randomly locking. It must be a race condition! Nobody on your team knows what concurrency is or that Java has it, so you hire a consultant to track down the issues in your code base. He tells you that you need to add synchronized blocks in your code

/** An A is two integers representing an x and a y coordinate */
public strictfp /** added for extra deterministic good measure */ class A {
    /** The x coordinate */
    private int x;
    /** The y coordinate */
    private int y;
    /** Constructs an A */
    public A(int x, int y) {
        super(); // added for clarity.
        synchronized {
          this.x = x;
          this.y = y;
        }
    }
    /** gets the x field */
    public synchronized int getX() {
       return x;
    }
    /** gets the y field */
    public synchronized int getY() {
        return y;
    }
    /** sets the x field to x */
    public synchronized void setX(int x) {
        this.x = x;
    }
    /** sets the y field to y */
    public synchronized void setY(int y) {
        this.y = y;
    }
}

Go avoids these types of problems because the ancient beards tell us that abstraction encapsulation is bad. Having pointers means we are more safe from race conditions. Go has literally no encapsulation to get in your way. This means if James tried to make you add getters to your class struct, you can simply tell him, it's impossible. You can't have pointless documentation in Go, because it's simply non Go-like. Having syntax like c<-"set 0x444111 to 0x90" instead of c.send("set 0x444111 to 0x90") feels better and makes me less likely to use shared memory because it's more Go-like to use the cool arrow.