Eugene Usachev

Потому что в Го сигнатура метода в интерфейсе должна совпадать полностью. Таким образом на рантайме они быстро матчатся.

Иначе пришлось бы заглядывать внутрь типа A, а так как это все происходит на рантайме, было бы неоптимально. Возможно для вашей цели больше подойдут дженерики, в их случае происходит мономорфизация и компилятор генерирует отдельный код для каждого варианта дженерика, что работает быстро.

Кстати, не рекомендую называть интерфейсы ISomething, это не принято в Го.

Изучил основы JavaScript, понял что всякие манипуляции DOM мне не нужны, потому что это не используется больше

Где и кем больше не используется?

Думаю такой, может мне надо выучить React?

Но есть почему-то ощущение что React в чистом виде мне не нужен, чтобы пользоваться Next.js.

NextJS: The React Framework for the Web...
А в "грязном" виде React какой?

Я остановился и понял что я занимаюсь какой-то фигней. Что я хватаю отовсюду понемногу знаний, но они не складываются в общую картинку.

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

Все так и есть. Вам необходимо изучать JS в следующем порядке:
1. Vanilla JS.
2. React.
3. Frontend React + NextJS.
4. Fullstack React + NextJS (+NestJS?).

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

А вот здесь интересный момент. Видите ли, исходя из количества вакансий, NodeJS и все ее производные в качестве backend фреймворков - не сильно востребованы, относительно более специализированных backend языков/фреймворков. Если у Вас нет особой страсти к NodeJS, то рекомендую сфокусироваться лишь на frontend (учитывая, Ваш контекст), а затем (если будет возможность) - учить в дополнение к frontend более специализированные backend языки/фреймворки.

Как уже выше сказали - cargo не увидел, что src поменялись и не стал собирать заново.
Определяет он, что файл изменился по дате изменения файла. Если дата изменения файла меньше либо равна дате компиляции, то повторной компиляции не будет.
Чтобы обновить дату изменения файла - достаточно сделать touch main.rs после первой сборки.
В docker появился docker init, который сам делает корректный dockerfile - так что в принципе уже и не нужно руками dockerfile писать.
Генерирует он примерно такое для компиляции (зачем так - описано в комментариях):

ARG RUST_VERSION=1.71.0
ARG APP_NAME=project
FROM rust:${RUST_VERSION}-slim-bullseye AS build
ARG APP_NAME
WORKDIR /app

# Build the application.
# Leverage a cache mount to /usr/local/cargo/registry/
# for downloaded dependencies and a cache mount to /app/target/ for
# compiled dependencies which will speed up subsequent builds.
# Leverage a bind mount to the src directory to avoid having to copy the
# source code into the container. Once built, copy the executable to an
# output directory before the cache mounted /app/target is unmounted.
RUN --mount=type=bind,source=src,target=src \
    --mount=type=bind,source=Cargo.toml,target=Cargo.toml \
    --mount=type=bind,source=Cargo.lock,target=Cargo.lock \
    --mount=type=cache,target=/app/target/ \
    --mount=type=cache,target=/usr/local/cargo/registry/ \
    <<EOF
set -e
cargo build --locked --release
cp ./target/release/$APP_NAME /bin/server
EOF

Ещё можно попробовать написать так (этим пользовался я раньше):

# FROM, Установка rust и прочих зависимостей
# ...

RUN cargo new /app
COPY app/Cargo.toml /app/

# This step compiles only our dependencies and saves them in a layer. This is the most impactful time savings
# Note the use of --mount=type=cache. On subsequent runs, we'll have the crates already downloaded
WORKDIR /app
RUN --mount=type=cache,target=/usr/local/cargo/registry cargo build --release

COPY ./app /app

# touch нужен, чтобы изменить дату изменения файла
RUN --mount=type=cache,target=/usr/local/cargo/registry \
  set -e; \
  touch /app/src/main.rs; \
  cargo build --release;

Оба варианта позволяют активно использовать фичи кэширования в Docker, чтобы не выкачивать все зависимости и не перекомпилировать их при каждой сборке образа.

Абсолютно так же как и остальными Node.JS, Go и другими языками в современном мире пакуется в контейнер и деплоится в прод. Есть несколько готовых вариантов, но все они будут придерживаться docker и docker compose:

- ручное: Клонируем репозиторий, билдим на этом сервере docker compose build && docker compose up -d.
- ручное: Локально билдим докер образ и пушим в регистр докера, на самой машине так же docker compose pull && docker compose up -d но уже только с получением образа из регистра докера в docker compose.
- полу-автоматически: Пишем .sh скрипт который на git хуки или руками будет делать действия что и в одном из предыдущих вариантов, но без Workflow.
- автоматически: Используем GitLab/Github Workflow или любой другой, на каждый релиз/коммит/PR запускаем Workflow с билдом, дальше пушит полученный контейнер в регистр, затем последним этапом будет подключение по SSH к серверу и применения условного

cd /path/to && docker compose pull && docker compose up -d

Я привёл самые простые варианты. Ещё есть варианты с k8s, ansible и другими вещами, но это не ваш случай судя по всему.

1. async-await используй
2. Используй какую-нибудь orm-ку (EF core, Dapper, linq2db). Многие из них как правило явно запрещают параллельные запросы в рамках одной транзакции.

Но вроде чисто в теории sqlite разрешает конкурентное чтение (но не запись)

ну, раз никто не ответил, чуток лекции от меня

во-первых как сказал ув. Василий Банников -тестировать надо только IO диска
вот это вот детский сад, так нельзя

Сначала я прогнал тест на Windows... я и не стал проверять на Windows неделю назад (работал в Docker).

условия должны быть неизменны

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

• вот тут товарищи тоже задаются года с 2018
  
• а вот и кое-какой продукт
  

да, это про IO а не файлы, но - с твоей задачей где-то рядом, если вообще не то что надо , но там много вопросов - ответов, которые расширят твое понимание - например, разное поведение в разных ОС

в третьих, есть такая штука как кеш диска (а еще есть кеш у харварного рейда, но не всегда), да так что в этой вашей команде DD
dd if=/tmp/test.img of=/dev/null bs=1M count=1024
есть спец опция для отклбчения кеша, иначе получается космик цифры

в четвертых - есть проблема храннеия мелких файлов и вообще файловой системы, тут приведу только два-три слова: самопис ( там почитаешь про суть проблемы), пром1 пром2

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

если все же "а зачем" осталось актуальным - я бы делал так:
1) прогнал прогу для дисков из пример выше
2) посмотрел бы вдумчиво это видео (увы, не про Rust, но докладчик знает толк в извращениях (с)), в том числе и ввиду твоих проблем с генерацией в памяти

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

Вы пытаетесь сравнить тёплое с мягким.

rest - архитектурный подход.
Axios - библиотека для отправки http запросов.
Babel - транспайлер.
Webpack - сборщик/бандлер.

Каким боком тут сервер и питон я не понял, тк всё перечисленное работает в браузере.

Ты забыл третий вариант, самый быстрый и наиболее предпочтительный если общее количество опций не велико (сотни, например у mysql лимит 1024 колонок максимум) - каждая опция это своя колонка, пустое (null) значение будет значить отсутствие опции у записи.

Недостаток подхода - если у объекта может быть несколько опций с одним именем, то такой подход не работает (но судя по всему это не твой случай).

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

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

p.s. если говорить про твои варианты:
* для 1 используй json сериализацию (опция=значение) в mysql для работы с такими данными есть соответствующие методы
* для 2 постарайся вместо текстовых наименований опций использовать числовые идентификаторы, заведя соответствующий классификатор либо в базе в отдельной таблице либо в виде констант в коде.

p.p.s. Ну и еще вариант, если тип значений опций - boolean (либо ограничен небольшим количеством значений, например цвет светофора 4 - выключен, красный, желтый, зеленый) то так же заводи для этих значений числовой эквивалент. В этом случае у тебя появляется еще бонус, упаковывать битовые значения (где количество вариантов 2^x и x это количество бит) и хранить в целочисленном поле сразу несколько (правда не все базы позволяют индексировать операции с битами).

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

Какую конкретно? Ту, которую лучше знаешь, если не можешь назвать конкретную причину, почему лучше изучить другую и взять другую. Например вот я беру postgres по-умолчанию, но вот у меня проект, который требует минимального жора ресурсов и наиболее простой инфраструктуры - тогда беру sqlite.
Или наоборот - я понимаю, что у меня какие-то специфичные требования по консистентности и доступности, система у меня будет распределённая, а запросы у меня будут исключительно key-value, да и желательно ещё иметь возможность подписки на изменения каких-то ключей - тогда беру etcd.

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

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