Михаил Р.

Сейчас редко нанимают чистых растаманов, тк язык молодой.
Обычно нанимают тех, кто переходит с других, более традиционных языков.
Так что тебе сначала надо стать мидлом/сеньором в C++/Java/C#/C а потом дотянуть знания раста, чтобы уметь на нём решать задачи, аналогичные тем, которые ты решаешь с основным языком.

Ну и соответствующий коммерческий опыт ~5 лет.
Учитывай ещё и специфику Rust-проектов: это что-то новое, что требует безопасности и эффективности, где нельзя/нежелательно/невозможно использовать "Традиционные" языки.
Так что и уровень ответственности и требуемых знаний будет выше, чем на аналогичную, например Java-позицию.

Как Вы передаёте файлы на сервер?

Просто подключаем удаленную папку /var/www/html как локальную через sshfs и просто в обячном проводнике (любой: Nemo, Nautilus, МС...) копируем папку с данными как локальную... не надо никаких клиентов, никаких заморочек с настройками и все вот это
https://losst.ru/podklyuchenie-i-nastrojka-sshfs-v...

Из обсуждения https://github.com/golang/go/issues/50182 видно что проблема с производительностью generics не новая.
При запуске бенчмарков с флагами получается ожидаемое мной ± равное время выполнения ф-ций:
go test -bench=. -count=2 -gcflags=all=-d=unified

BenchmarkNativeFunc-4            2029149               600.5 ns/op
BenchmarkNativeFunc-4            2018277               591.7 ns/op
BenchmarkNativeMethod-4          1962086               592.0 ns/op
BenchmarkNativeMethod-4          2024234               603.9 ns/op
BenchmarkGenericFunc-4           1985313               573.4 ns/op
BenchmarkGenericFunc-4           2053454               585.1 ns/op
BenchmarkGenericMethod-4         2067790               591.3 ns/op
BenchmarkGenericMethod-4         2054346               612.2 ns/op

что форсирует применение при компиляции stenciling (трафарет по отдельным типам) вместо словарного подхода реализации дженериков (текущая реализация).
Остаётся ждать оптимизаций в обновлениях языка

чтобы картинка подстраивалась под размеры данного блока

Если это фон: background-size
Если img, то object-fit

Как правильно вставлять большие изображения на страницу?

Уменьшить до нужного размера. Понятно, что при адаптиве картинки все равно не будут равны размерам блока, но постараться использовать разумные размеры.
И соответственно, для ретины и разных размеров вьюпорта, либо тег picture для контентных либо media для фоновых.

<div class="parent" style="--p_inherit:30px; padding-right: 30px">
  <div class="parent__child pl_inherit pr_inherit">123</div>
</div>

.parent {
  padding-left: var(--p_inherit);
}
.pl_inherit {
  padding-left: var(--p_inherit);
}

Ну только кастомное свойство нужно нормально назвать.

Либо дочернему так прямо и писать padding-left: inherit;. Но это, конечно, зависит от того, как вы планируете дальше обращаться с этой переменной.

В документации os/exec даже есть пример под ваш случай: https://pkg.go.dev/os/exec#example-CommandContext

Мне кажется вы с ног на голову... Может быть так?

type Admin struct {
  Permissions map[string]interface{}
  User
}
type Subscriber struct {
  Online        bool
  Status        string
  SubscriptedTo []int
  User
}
type User struct {
  ID    int
  Login string
}

Эта разметка абсолютно правильная в двух случаях:
1) Ваши `close` и `card` действительно нигде не переиспользуются;
2) Объём стилей блока `some-class` остаётся адекватным для восприятия.

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

Возьмём разметку посложнее (не надо в ней искать какого-то смысла, просто от фонаря что-то набрал для иллюстрации):

<div class="block">
  <!-- Header -->
  <div class="block__header">
    <h2 class="block__title">Title</h2>
    <div class="block__actions">
      <button type="button" class="block__action block__action--edit">
        <span class="block__action-icon"></span>
      </button>
    </div>
  </div>
  <!-- Content -->
  <div class="block__content">
    <p>...</p>
  </div>
  <!-- Footer -->
  <div class="block__footer">
    <div class="block__about">
      <div class="block__author"></div>
      <div class="block__date"></div>
    </div>
    <div class="block__awards">
      <div class="block__award">
        <div class="block__award-inner"></div>
        <div class="block__award-tooltip">
          <div class="block__award-tooltip-content"></div>
          <button type="button" class="block__award-tooltip-close"></button>
        </div>
      </div>
    </div>
  </div>
</div>

Положим, что весь контент этого блока уникальный и никак не переиспользуется.
Объём стилей `block` при такой структуре неизбежно станет некомфортным для восприятия, строк на 200-300.

В таком случае хорошо создать внутренний блок (или несколько) просто для того, чтобы размазать сложность.
`block-header`, `block-footer` или даже `block-footer-award`.

Самое главное здесь организовать файловую структуру / конфигурационный файл / чем вы там ещё собираете таким образом, чтобы было очевидно, что `block-footer` - это не самостоятельный блок, а внутренний блок `block`, нужный только для упрощения восприятия, и он не может / не должен использоваться в отрыве от него (в этом случае у него не должно быть в названии общего префикса с `block`, чтобы не создавать путаницу)

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

Вики по GOPATH.
GOPATH подход устарел и с 1.16 версии по умолчанию используются модули.

Если вам так нужен проект в GOPATH, то можно отключить модули:
GO111MODULE=off go get github.com/go-chi/chi/v2

В режиме модулей зависимости сохраняются в кэше.
Их можно перенести в проект командой go mod vendor, и зависимости перенесутся в папку vendor рядом с файлом go.mod.

При сборке проекта зависимости автоматически скачиваются в кэш.

В подобных случаях лучше переустановить ОС к чертям, имхо.

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

Для начала немного контекста - 2 важных примечания:
1) Описанная задача решается на любом упомянутом стеке, + еще десяток возможных вариантов (Java/Spring, питон, нода, дотнет, голанг и т.д.).
2) Быстродействие системы зависит от ее самой медленной части, и в 95% случаев самая медленная часть - БД, просто в силу специфики работы: много данных со сложными связями, выборки с сортировкой и фильтрацией из большого массива и вот это все, в то время как язык бэкенда в основном выполняет достаточно простые манипуляции с уже готовыми наборами данных (за редчайшими исключениями, которых в вашем кейсе нет, или они не описаны в вопросе).

В вашем случае:
- база можно сказать совсем небольшая, до 1 миллиона записей условный мускуль ворочает весьма шустро, если железо соответствует.
- задача сбора метрик достаточно тривиальная, особого ума в сохранении действий пользователя не надо, бОльшая часть работы - вывод в красивые графики и написание быстрых запросов с хитрыми выборками/агрегациями, немного пошаманить с формулами, возможно делать какие-то сводные выборки с денормализованными результатами для отчетов и прочие мелочи. Работа не сложная, но нудная, и ее много.

Насчет стоимости и условий:

полный самопис 150к+ (я это не тяну) или же сайт на Laravel +MySQL а дальше варьируется.

полный самопис - либо маркетинг, либо идиотизм, писать на голом языке не будет ни одна нормальная студия, в принципе в данном случае либо используется фреймворк и заказчику преподносится как "сделано вручную программистами девственниками под светом серебряной луны", либо разработчики идиоты, мнящие себя круче всех (нет). В первом случае это то же что и "сайт на Laravel +MySQL" (норма и стандарт для среднего уровня студий), во втором - развод на мани на пустом месте и попытка продать г**но в обертке "иксклюзивнасти".

По цене - на сегодняшний день, если я не ошибаюсь, 150к деревянных это +- 1000уе. Цена приемлемая за нормальную работу, если найдете дешевле "на Laravel" - думаю будет вообще ок. Опять же, цены штука такая, кто-то за копейки сделает хорошо, кто-то за дорого каку сляпает. Влияет так же регион, понятно что в Мск цена будет серьезно больше чем в условном Челябинске...

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

UPD:

проект планируется на 100 к+ посетителей в месяц...
предупреждают что если аудитория достигнет условных 100 тысяч в месяц Лара начнет потихонечку задыхаться от нагрузки,

ок, пусть будет 200к для наглядности.
В среднем, если это маркетплейс, то постоянных посетителей будет не много, думаю около 10%, так что ими можно пренебречь. Условно - 200к / 30 дней = 6600 в сутки, при активных 10-12 часах посещения это ~600 в час. Пусть на 1 посетителя будет 5 запросов страниц, это 600*5=3000 в час = 50 в минуту или менее 1 запроса в секунду.
Даже если умножить это на 30 (допустим такая пиковая нагрузка), 30rps вообще "ниачем". Не знаю кто там вам считал то это проблема, любое современное железо среднего уровня вытягивает без напряга.