Иван Кулаков

Junior разработчиком после выполнения пары проектов в отвратительном качестве не стать.

в моей голове junior - это тот, кто пишет круды и что-то там допиливает в проектах

Этот тот которому дают простое задание и говорят, как делать и он делает, так как ему сказали.

Я могу сделать какой-нибудь обычный crud с sql, но, видимо этого не достаточно.

У Вас не обычный CRUD, а тот который никогда делать не надо. Следует узнать о шаблозаторах Twig и Smarty. Попробовать сделать свою простую шаблонизацию на PHP, что бы отделять верстку о логики.

Также у меня есть пару книг популярных по этому языку и там тоже нечего взять полезного.

Я думаю, если бы Вы прочитали PHP 7 Котерова, может быть не задавали бы такого вопроса. Можете начать с PHP 7, и обязательно выполнять задания, которые там даны в конце каждой главы. Если хочется быстрее понять PHP можете пройти интенсив. (бонус, что будет опытный наставник и работа с системой контроля версий).

После того, как будет понимание о языке PHP и его возможностях, следует посмотреть на работу с SQL, создать несколько баз данных руками, попробовать JOIN из нескольких таблиц, написать простой CRUD каталог по архитектуре MVС, что бы понять, как реализуется роутинг.

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

Изучать тему Linux и как работать в консоли, настройка LAMP и LEMP окружения.

Желательно посмотреть на Docker и Vagrant, запустить их у себя на машине и установить внутри какой нибудь обычный WordPress.

Попробовать работу с PHP фреймворками, сделать несколько простых проектов.

Изучать лучшие практики работы PHP правильный путь

P.S. и постоянно учиться чему то новому...

В таких случаях лучше передавать структуру как параметр.
Пример

type User struct {
    Name string
    Email string
    // все нужные поля далее
}

func CreateUser(r.Context(), user)

Не нужен, в Go есть полноценный веб сервер.

Nginx есть смысл использовать в случае если есть необходимость обслуживать больше одного домена на одном и том же IP:Port, ну и для раздачи статики (изображений, CSS, Javascript и т.д.)

Еще есть смысл использовать Nginx когда у вас большая нагрузка и ваш сервис на Go работает на нескольких серверах - Nginx'ом можно балансировать нагрузку между этими серверами.

Более четырёх лет пишу на Go, лично для меня поддерживать проекты на других языках сложнее ))
До Go много лет писал на Perl/PHP/Python/Java/C/Ruby on rails/JavaScript и "крутил" еще не мало чего.
Сейчас пишу только на Go и Python.

Основная сложность в Go - это то, что если вы начинаете писать "криво" - то писать так очень трудно :))
Подход к реализации в Go достаточно непривычный для тех, кто приходит из скриптовых языков.
Например запрет циклических импортов - это самое первое, что "взрывает" мозг :)
Нужно время чтобы адаптироваться после скриптовых языков.

Про обработку ошибок - это да, это, пожалуй, единственное что мне не нравится в Go.
Для себя я решил эту проблему за 1-2 часа :) и больше меня это не беспокоит.

По ООП - в Go оно есть, лично мне оно нравится намного больше, чем ООП в других языках ))
Всё, что реально нужно - всё есть, но при этом ничего лишнего нет.
Интерфейсы - просто прекрасны :)) Каналы, горутины - это просто "счастье" :))

А если объективно - то я бы не стал говорить о сложности поддержки проекта применимо к какому то конкретному языку.

Как правило сложность поддержки возникает там, где нормальная архитектура не заложена в проект.
Т.е. проект как могла так и писала куча людей плюс, как обычно, сделать нужно было побыстрее )), от этого никто вообще не думал об архитектуре и получилось то, что получилось :))
Про покрытие тестами и документацию мы вообще не говорим )))

А когда в таком проекте нужно что-то доработать или исправить ошибку, то почти всегда очень не просто найти то место, где нужно править, и после правок в одном месте, как правило, что-то ломается в другом :)

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

Так мы приходим к тому, что если опыта нет - тогда проект поддерживать будет достаточно тяжело не взирая на язык и т.д.

Хочется добавить, что как бы не писали про Go, что он простой и т.д. - он явно сложнее Python/PHP и т.д.
Это еще один повод сказать, что поддерживать код на Go сложно ))

Также стоит учитывать, что проекты которые пишут на Go зачастую сложнее, чем проекты для которых выберут скриптовый язык. Go выбирают когда планируются большие нагрузки, параллельная обработка чего-либо и т.д., а это, в свою очередь, дополнительно усложняет проект.

Абсолютно любой VPS-хостинг, тысячи их.
Если надо разместить не сервер, а функцию, то Яндекс-облако и AWS это умеют.
Так же подойдет любой сервис, размещающий докер-контейнеры.

"Чтобы сервер запускался сразу при включении системы" вам не нужно выполнять go run main.go. go run -- это тестовые компиляция и запуск при эскизировании. Вам нужно сделать нормальный бинарник вашего сервера go build -o myserver main.go или go install. Полученный бинарник при включении системы можно запускать стандартными средствами -- юнитом systemd, записью cron или, самое простое, поместив команду в profile
myserver &

Не сразу заметил, вы забыли сказать серверу использовать ваш mux

var serv = &http.Server {
        Addr:         "127.0.0.1:600",
        ReadTimeout:  15 * time.Second,
        WriteTimeout: 15 * time.Second,
        Handler: mux, // <---- здесь
    }

Кстати, не стоит делать так:

func allRout(w http.ResponseWriter, r *http.Request) {
    http.FileServer(http.Dir("F:/Projects/www/domen.com/")).ServeHTTP(w, r)
}

Вы по сути при каждом запросе создаете файловый сервер и после запроса он удаляется сборщиком мусора. Нужно один раз его создать (вызвать http.FileServer(...)), а потом в хендлере вызывать ServeHTTP уже у готового сервера.

Для подобного тестового кода можно использовать ab (Apache HTTP server benchmarking tool)

Например так
ab -n 10000 -c 1000 http://localhost:8080/

Где:
-n это количество запросов, которое нужно сделать
-с это количество одновременных запросов

Запустил у себя на одном из серверов, результат вот такой

Server Software:
Server Hostname:        localhost
Server Port:            8080

Document Path:          /
Document Length:        5 bytes

Concurrency Level:      1000
Time taken for tests:   0.509 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      1210000 bytes
HTML transferred:       50000 bytes
Requests per second:    19627.39 [#/sec] (mean)
Time per request:       50.949 [ms] (mean)
Time per request:       0.051 [ms] (mean, across all concurrent requests)
Transfer rate:          2319.25 [Kbytes/sec] received

Т.е. при 1000 одновременных запросов сервер сможет обрабатывать в среднем 19627 запросов в секунду

Но важно понимать, что в реальном проекте у вас будет не один endpoint, и что каждый endpoint, в зависимости от того, что он будет делать - будет показывать разный RPS.

Например если сейчас вы добавите еще один endpoint и будете делать запросы в базу для формирования ответа - RPS будет значительно меньше.

http не поддерживает скачивание папок.
Поэтому простой ответ - никак. Более сложный

Вариант 1
Пройтись по всем папкам, получить список всех файлов и скачивать каждый отдельно.

Вариант 2
На стороне сервера создать архив со всеми файлами и папками и скачать его

Вариант 3
Настроить не web сервер, а что-то другое, ftp/ssh/nfs/samba и воспользоваться клиентом, который умеет работать со структурой директорий (filezilla, rsync, FAR с ftp/ssh плагинами, проводник)

certbot renew --force-renewal --cert-name domain.tld

Какой именно cert-name у него, смотреть в папке /etc/letsencrypt/live/ на имя

Скорее всего, ничего особенного не будет. Перезапустите, и заработает.

Есть какие-то встроенные в СУБД механизмы, позволяющие избежать последствий?

Конечно. Транзакции и REDO LOG

func isPasswordValid(password string) bool {
  if len(password) < 8 || len(password) > 128 {
    return false
  }
  return true
}

pprof Вам в помощь. Потому использование указателей не всегда оправдано и зависит от конкретной ситуации.

нужно ли стараться по максимуму работать именно через указатели

Нет

Первое, что нужно здесь понять, то что лоадер работает в compile-time, а Ваш js код где require - в run-time.
Лоадер получает на вход исходный текст файла (или текст выданный предыдущим лоадером) и выдает свой текст на выход. Последний лоадер (в цепочке лоадеров webpack он стоит первым) должен выдавать валидный js.
Ваш лоадер конечно может сгенерировать в выходном файле функцию, но на процесс компиляции она уже повлиять особо не сможет.

Воспользуйтесь сервисом: https://www.remove.bg/ на хайрезе, результат должен быть ещё лучше.

1. Не мыслите таблицами - ничего хорошего не выйдет
2. Хранить можно также в NoSQL, что даже лучше. Например, redis.

Потому что переменная input объявлена, но не используется.
Внутри for вы используете оператор := который объявляет локальные переменные input и error. А та, которую вы объявили выше тут не используется.

https://golangdocs.com/short-variable-declaration-...