TicSo

Нет, нельзя. Модули в Rust оперируют функциями/типами/трейтами, но не отдельными кусками кода.
Ты можешь вынести функции f1 и f2 в отдельные файлы:

main.rs

mod m01;
mod m02;
mod m03;

fn main() {
    m01::f1();
    m02::f2();
    let (i, p) = m03::f3();
    println!("i = {:?}", i);
    println!("p = {:?}", p);
}

m01.rs

pub fn f1() {
 let num: u8 = 12;
 println!("num = {:?}", num);
}

m03.rs

pub fn f2() {
 let s: String = "abc".to_string();
 println!("s = {:?}", s);
}

В случае m03 ты можешь попробовать сделать функцию, которая будет возвращать значения переменных i и p:

pub fn f3() -> (u8, String) {
  let i: u8 = 88;
  let p: String = "xyz".to_string();
  (i, p)
}

PS: Я уже было хотел предложить макрос вида:

macro_rules! f4 {
  () => {
    let i: u8 = 88;
    let p: String = "xyz".to_string();
  }
}

Но он работать не будет, ибо гигиена.

Но можно сделать так:

macro_rules! f4 {
  ($a: ident, $b: ident) => {
    let $a: u8 = 88;
    let $b: String = "xyz".to_string();
  }
}

fn main() {
    f4!(i, p);
    println!("{} {}", i, p);
}

PPS: ну и ещё есть макрос include!, который буквально решает твою задачу - вставить кусок кода из файла, но его я не советую использовать.

На GO, "православный" стек, это стандартный пакет net/http + какой нибудь внешний роутер, например chi, либо вообще не http/rest, а gRPC (если мы говорим об API).
Для БД чистый SQL, максимум какой нибудь маппер на структуру, типа sqlx(можно ещё использовать sql builder, но в IDE Goland хорошая поддержка чистого sql).

ORM очень не советую, есть конечно gorm(генерирует запросы не эффективно, N+1 при связях), для мелких проектов хватит, но вот со сложными запросами любая ORM не справляется.
Я категорически против ORM, так как за всё время моей работы в вебе, в любом проекте, самым слабым звеном всегда была ORM(долбит кучей запросов БД, когда на чистом sql это 1-2 запроса), либо программист, вместо того, чтобы написать запрос вида "SELECT SUM(amount) FROM book WHERE author = 'Petya'", достаёт все записи и суммирует это в коде(делает работу за БД + тратит ресурсы БД на чтение данных с диска и передачу их по сети).

Не нужно использовать фреймворки, это не даст опыта написания на go(как и в большинстве языков).
Go используют, где производительности других решений не достаточно, или нужна многопоточность, что фреймворки так себе обеспечивают.
Шаблоны в go практически не использую, пишу фронт на vuejs и обращаюсь к go api.
Есть генераторы документаций, но я тут не посоветую, их нужно тестировать отдельно, у каждого есть свои плюсы и минусы, сам использую другое решение(опишу в конце).

Самое главное, побыстрее понять, что на go нужно писать как на go, а не так как привыкли в других языках, потому-что, в нём нет привычных классов, строгая типизация, процесс живёт долго и могут быть race condition(гонка состояний) при многопотоке(веб сервер многопоточный), поэтому о подходах из php советую поскорее забыть.

В своих проектах(в проде), использую go только как сервис предоставляющий апи. Недавно начал использовать grpc-gateway(так как использую gRPC, но так же необходимо делать API доступное через web), проект позволяет описать всё что необходимо в proto файлах (см. gRPC), сгенерировать модели и обёртки под большенство языков + документацию в OpenAPI 2.0. Это не фреймворк, это обёртка над стандартным net/http, которая сразу валидирует и маппит данные на структуру.

Коротко:
Для новичка, советую забыть про фреймворки(они не помогут в изучении) и ORM(не эффективно).

Использовать для веб сервера:
net/http - встроен в го
chi(проще) или gorilla/mux - роутер

Для взаимодействия с БД:
sqlx - обёртка над стандартным пакетом sql, но позволяет сразу считывать данные в структуру, без ручного сканирования.

Для работы с полями ввода есть набор событий:
1. focus - пользователь поставил фокус на поле ввода.
2. blur - пользователь убрал фокус с элемента вода.
3. input - пользователь как-то что-то ввел. Это лучше, чем keyup, ибо не надо проверки keyCode, второе потому что пользователь может в поле вставить текст, что тогда будет с Вашим keyUp? Событие input срабатывает каждый раз, как пользователь сделал изменение в поле ввода.
4. change - пользователь ввел данные и убрал фокус с поля ввода, то есть это input + blur. Событие происходит не так часто, как input, но и не заставляет проверять value на изменение, как это придется делать при blur.
5. submit - срабатывает на всей форме, при попытке отправить данные, в данной задаче скорее не интересное событие.

Для живого поиска логично использовать input, по которому надо отправить текущее value через ajax на сервер и далее ответ куда-то распечатать. Вопрос в другом, ведь событие срабатывает довольно часто, и кто-то печатает так быстро, что и запрос-ответ не успеет, поэтому логично сделать тут debounce с задержкой в приблизительно 300мс, чтобы отправка/получение сработало когда пользователь притормозил в наборе текста или вообще прекратил ввод.