Иван Кулаков

подключить ПК к прокси

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

в зависимости от операционной системы, способы настройки прокси - разные, и часто бывает не доступны обычным приложениям (т.е. либо нужны повышенные привилегии и разрешены только ручной настройкой, например на android)

Еще в windows есть путаница, есть настройки прокси сервера для metro приложений (для win10-ой версии и выше) они в стандартных настройках а есть старый конфиг в панели управления - свойства браузера (этой настройкой пользуется браузер chromium и его производные) - и они разные и настройка одной не влияет на приложения, использующие другую. Ну и конечно программы успешно эти настройки игнорируют, например firefox имеет свой конфиг (а в том же android настройки прокси скрыта и ее можно менять только сторонним расширением)

В linux общая прокси настраивается через переменные окружения PROXY но их очень редко кто использует.

А еще есть разные типы прокси серверов (http/https/socks) и их настройка и принципиальная возможность так же будет зависеть от приложения.

Так вот отвечая на сам вопрос, выбор языка программирования тут ничего не поменяет, так как настройка прокси это операция по настройке ОС (конфигурационные файлы или реестр или вызов специальной системной функции), но:
В windows/linux полагаю будет проще работать с системными настройками напрямую в c++, а вот java обычно прячет все привязанное к ОС и так или иначе чтобы вылезти из ее песочницы приходится использовать jni на c++/c (либо ее используют библиотеки для выполнения этой же задачи) а вот в android базовый язык - java, и системные вызовы подготовлены именно для программ на этом языке

Что значит стопорится? зачем гадать, расставь по больше вывода в свои логи отладочной информации (когда принял запрос, обработал, отправил транзакцию, когда получил ответ от базы и т.п.) с таймингами и смотри что и где происходит в проблемный момент

Что за пиз...ц с сериализацией картинок в base64 потом это все в json, а в базе хранить php-щным serialize?

http post прекрасно справляется с отправкой файлов, там своя сериализация, никто не мешает миксить в запросе get и post данные

Не храните картинки в базе данных, никак, ни блобом ни сериализацией, кто придумал этот маразм, в каком бредовом туториале это прочитали и каждый второй это реализует?

Файлы храни в файлах на диске, а в базу записывай путь или имя файла (либо сам файл по идентификатору называй), раз в сто лет на обслуживании базы сравнивай наличие файлов на диске и записей в базе и удаляй висяки (образуются если во время обработки произошла ошибка, например скрипт умер, файл записали а транзакция в базе откатилась)

p.s. в php во всех репозитариях есть красивый сериализатор igbinary, если что он в каком то смысле даже быстрее старого serialize и точно компактнее, его потихоньку в стандарт пропихивают, например можно использовать его для хранения сессий

Заверните весь код в input.cpp в namespace input {}
namespace добавляет к символам в объектом файле имя namespace, но т.к. у вас определения в input.cpp не включены в namespace, то в объектном файле эти символа будут без добавления имени namespace, поэтому и undefined reference.

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 плагинами, проводник)