Tyranron

На чистом database/sql:

r, err := db.Query("SELECT 1 FROM items WHERE origin='http://example.com/path' LIMIT 1")
if err != nil {
    // Oops!
}
thisTableReallyHasThatRow := r.Next()
r.Close()

То же самое можно провернуть и на gorm'е с помощью raw sql, или с помощью RecordNotFound() сделать примерно так:

thisTableReallyHasThatRow := !db.Find(&Item{}, "origin = ?", "http://example.com/path").RecordNotFound()

Если файлы лежат в одной директории и оба в package main, то никаких проблемы быть не должно, даже если именуете с маленькой буквы.
Подозрвеаю что проблема в способе запуска программы. Для go run такое не прокатит, он умеет цеплять только одиночные файлы. Нужно скомпилить директорию и должно быть все в порядке.

как лучше обращаться к Go, через Proxy или FastCGI?

И так и так хорошо. Я все же предпочитаю вариант проксировать запросы на Go.

Не могу проверить вообще, так как на рабочей машине Windows.

Это не проблема, поставьте виртуалку и вперед. В конце-концов: личный опыт лучше любых объяснений.

И ещё очень странный вопрос: нужно-ли при таком подходе компилировать Go? Просто где-то видел пример кода, когда обращаются к исходному файлу с расширением .go.

Компилировать нужно, особенно в случае большого приложения.
Да, можно сделать:
go run file.go
Но, во-первых, код все равно компилируется в бинарник и выполняется при таком подходе, просто это происходит в папке с временными файлами и как бы скрыто от Вас.
Во-вторых, этот подход не катит, если в папке с проектом больше файлов нежели file.go (имеется в виду на уровне package main).
В-третьих, это обязует Вас иметь установленный Go соответственной версии на production серверах, когда обычный бинарник этого не требует.
В-четвертых, а как быть в таком случае с демонизацией и zero downtime reloads? Да, можно, но неудобно, учитывая что каждый раз нужно будет перекомпиливать.
Лучше скомпилировать один раз и не заморачиваться.
Команда go run больше подходит для небольших файлов аля скрипт для выполнения одноразовой работы и тому подобное.

Прошу не кидать камнями, я только учусь правильному написанию веб-сайтов на Go.

Учиться - всегда полезно, никто камнями кидать не будет.

Во втором варианте вроде как так. Чтобы объявить тело функции, нужно использовать ключевое слово func и никак иначе, что разумно по своим причинам. Как минимум, Вам не нужно помнить и держать в голове какая сигнатура кроется за каким типом, когда Вы смотрите на тело функции, то есть для каждого тела функции видно явно что оно должно принимать и возвращать. К тому же, дополнительная гибкость (в данном случае: объявление функции через алиасы типов, а не ключевое слово func) - это всегда удар по производительности, в данном случае - вероятное повышении времени компиляции, а для разработчиков языка это один из главных факторов, потому они очень и очень придирчиво относятся ко всем введениям и возможностям компилятора. Вон, от них даже дженериков никак допроситься не могут. Более того, выгода от возможности объявлять тело функции через алиасы типов (type aliases), а не ключевое слово func, крайне сомнительна, Вам так не кажется? К тому же не стоит путать объявление типа и объявление функции. Логично, что всегда сначала должен быть объявлен тип, а потом уже сама функция/переменная/структура, просто синтаксис языка позволяет сократить писанину. А Вы в данной ситуации хотите обойтись только созданием типа. А как тогда будете именовать входные параметры функции при её объявлении, если таковы имеются?

Выгода же абсолютно такая же, как и при других вариантах применения алиасов типов. В первую очередь - это возможность дополнительного контроля типов.
Например: Вы разрабатываете библиотеку (свой package) и Вам нужно, чтобы какая-то функция получала на вход только те функции, которые определены у Вас в библиотеке и никакие другие. Тогда Вы создаете алиас типа на сигнатуру функции и делаете его невидимым для внешних потребителей (объявляете с маленькой буквы).

package mylib

type someFunc func() bool

var (
	Apple someFunc = func() bool {
		return true
	}
	Dog someFunc = func() bool {
		return false
	}
)

func Consume(f someFunc) {
	f()
}

После этого внешний потребитель не сможет вызвать функцию Consume() передав туда какую угодно функцию, а только те функции, которые Вы ему приоткрыли.

package main

import "mylib"

func main() {
	externalFunc := func() bool {
		return true
	}
	
	mylib.Consume(externalFunc) 	// fail
	var extF mylib.someFunc		// fail
	
	mylib.Consume(mylib.Apple)	// success
}

Таким образом, обвязав свою библиотеку дополнительным контролем типов, Вы добились желаемого результата.
Во вторую очередь - это возможность сделать код более читаемым. Например, у Вас где-то есть достаточно громоздкая сигнатура и её нужно использовать во многих местах, чтобы не писать одно и то же много раз, Вы пишете сигнатуру только при объявлении функции и создании алиаса, а потом жонглируете алиасом.