"Static" method design

I'm looking for advice on the best way to clean up the following structure. I know Go doesn't have static methods and it's usually better to encapsulate functionality in a separate package. My struct types reference each other, and so cannot be declared in separate packages because of circular imports.

type Payment struct {
    User *User
}

type User struct {
    Payments *[]Payments
}

func (u *User) Get(id int) *User {
    // Returns the user with the given id 
}

func (p *Payment) Get(id int) *Payment {
    // Returns the payment with the given id 
}

But, if I want to load a user or payment, I'm just throwing away the receiver:

var u *User
user := u.Get(585)

I could namespace the functions themselves, which strikes me as unclean:

func GetUser(id int) *User {
    // Returns the user with the given id 
}

func GetPayment(id int) *Payment {
    // Returns the payment with the given id 
}

I would really like to be able to just call .Get or similar on the struct without writing the name of the struct in the function itself. What's the idiomatic way to do this?

GetUser() and GetPayment() strike me as perfectly clear and idiomatic. I'm not sure what you find unclean about them.

Calling .Get() on a struct to return another struct is the thing that strikes me as very odd, unclear, and unidiomatic.

I think this might be a case of just sticking with the idiom and trusting that you'll get used to it.

Golang does not support constructors.

Use factory functions instead (Effective Go reference). The convention is to use New prefix:

func NewUser(id int) *User {
    // Returns new User instance
}

The difference between constructor and factory function is that factory function is not "attached" to the User struct. It's a normal function that happen to return User while the Java/C++ like constructor is a method that modifies newly created User object in place.

having a Get function is perfectly fine; it's not unidiomatic in any way.

func (u *User) Get(id int) *User doesn't make any sense, though, it should be func (u *User) Get(id int) error. The one thing that you're missing is that you can define a method receiver on a pointer, and then inside of that method, dereference the pointer to overwrite what it points to.

Like this:

// Returns the user with the given id 
func (u *User) Get(id int) error {
    *u = User{ ... } // dereference the pointer and assign something to it
    return nil // or an error here
}

and if there was any problem, return an error. Now you can say

type Getter interface {
    Get(int) error
}

and so any type that defines Get(id)error can be defined. You would then use it like this:

u := new(User)
if err := u.Get(id); err != nil {
    // problem getting user
}
// everything is cool.

Another way to call simulating an static method, despite the fact it isn't, is as follows:

package main
 
import "fmt"
 
type Manager struct {
}

func (m Manager) MyMethod(a float32, b float32) float32 {
	return 0.5 * a * b
}
 
func main() {
	fmt.Println((Manager).MyMethod(Manager{}, 15, 25))
}

But from my point of view, it is less understandable than placing this method in a separate package manageroutside from class Manager

From comments, another alternative would be:

 fmt.Println(Manager{}.MyMethod(15, 25))

Finally with pointers:

package main

import "fmt"

type Manager struct {
}

func (m *Manager) MyMethod(a float32, b float32) float32 {
    return 0.5 * a * b
}

func main() {
    fmt.Println((*Manager).MyMethod(&Manager{}, 15, 25))

    fmt.Println((&Manager{}).MyMethod(15, 25))
}