https://golang.org/pkg/encoding/json/#Marshal

В документации всегда все написано, надо просто прочитать)

Да, вот теперь мне стало понятно:

package main

import (
    "fmt"
    "reflect"
)

type Data struct {
    Foo string `json:"foo"`
    Bar int    `json:"bar"`
}

func main() {
    var x Data
    t := reflect.TypeOf(x)
    fmt.Println("json tag of first field:", t.Field(0).Tag.Get("json"))  // foo.
    fmt.Println("json tag of second field:", t.Field(1).Tag.Get("json")) // bar.
}

потому что reflect из stdlib так парсит?

Да, именно для работы Tag.Get нужен такой формат, а сам Tag это обычная строка

Ребят, получается что в го у функции и у переменных метода нет, нужно создавать самому ?

Или например в жс все объекты и прототипирование. В консоли можно это увидеть. А как в го можно увидеть ? или только через документацию ?

вопрос не ясен

?

В Go не всё объекты. В Go типы. Типами могут быть как структуры (аналог объектов), так и примитивы. При этом методы типа, не хранятся в самом объекте, как в JS, а всего лишь являются сахарком над обычными статическими функциями. Список доступных функций правильно смотреть действительно в документации, так как Go - статически типизированный язык, и то, что существует на этапе компиляции, не обязательно существует в рантайме. Если именно в рантайме надо смотреть свойства значения, то есть рефлексия (reflection пакет в std), но её следует применять только когда точно знаешь зачем она тебе и почему.

В го же тоже надо мутить прослойку DAO даже если GORM? Ну если по красоте

«Мутить»)

Лучше смотреть под проект

Ну делать)

Если так проще читается и поддерживается — то да

Ну меня уже пугает то, что для апи у меня все вынесенно удобненько красивенько, а для бд прям в коде DB.Find()...

А могут быть случаи, когда этого делать не стоит? Ну в маленьких 5-ти строчных проектах понятно, а где еще

В чем преимущество Get(c *types.Chat) error перед Get() (types.Chat, error)?

Это разные сигнатуры
Первая - принимает на вход *types.Chat
Вторая - без параметров

Я это понимаю. Я имею ввиду, как подход лучше? Или это тоже надо смотреть в контексте? В жабе какой-нибудь только 2 вариант возможен по понятным причинам (ну давай массивы не брать в счет), а тут есть выбор. Ну мне кажется, что 2 вариант удобнее, ибо в конечном коде будет только одна строчка, а не две (объявление переменной и вызов метода), я что-то упускаю?

Копирование указателя и копирование структуры. Первый способ имеет смысл делать после профилирования приложения.