DevMan

Какие задачи решают на Rust

любые. Rust - язык общего назначения, применимый к большинству возможных задач. Rust достаточно высокоуровневый для написания на нем прикладного ПО и компилируется в достаточно эффективный машинный код, для применения в ядрах ОС, драйверах или embedded разработке. Так же Rust на сегодня имеет самый маленький размер при компиляции в wasm, что критично для использования в web. Я честно не знаю такой сферы, к которой бы не подошел Rust.
Единственной проблемой в применимости Rust я вижу недостаточную его распиаренность в РФ, что часто бывает самым важным критерием для "манагеров" и прочих людей принимающих решения о используемом стеке.

а какие на Golang

Golang тоже язык общего назначения, но имеющий ряд ограничений:
- Крайне тяжелый рантайм не дает возможность использовать его в wasm, embedded или компонентах ядра.
- Необходимость в сборке мусора опять таки ограничивает разработку для embedded или компонентов ядра.
- Отказ от llvm в качестве бэкенда компилятора ограничивает число целевых платформ.

Можно один заменить другим?

Rust спокойно заменяет Golang в любой возможной на последнем задаче, наоборот же иногда имеем ряд ограничений.

Вместо P.S.:
Golang скорее всего окажется более быстрым для прототипирования и быстрого старта. Однако отсутствие полиморфизма в любом виде (утиная типизация не в счет) и ограниченность одной парадигмой структурного программирования делает этот язык крайне дорогим в поддержке. Так же этому (и быстрому прототипированию и дорогой поддержке кода) способствует лютая ненависть создателей языка к принципу DRY.
Rust имеет такую редкую сегодня строгую типизацию, одним из нюансов которой являются концепции владения и заимствования (которые позволяют делать автоматическое управление памятью в compile time), что порождает с одной стороны высокий порог входа в технологию (что сглаживается человекопонятным выводом компилятора, если входящие умеют читать, что еще более редко встречается сегодня, чем строгая типизация), но так же удешевляет поддержку продукта длительное время. Так же надо понимать, что Rust не спасет от кривых рученок быдлокодеров (разве что они не смогут его освоить), так как при большом желании можно сделать и утечки памяти и дедлоки и гонки данных (хотя в Golang это все сделать на порядок проще).
Ну и надо не забывать, что много где присутствует hype-driven-development и Golang распиарен, а Rust нет.

Сколько времени - зависит конкретно от вас. Какими навыками приходится овладевать зависит от конкретного работодателя. Единственно правильного ответа быть просто не может. Разве что читайте книжки по сетям.

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

Практически - ни то ни другое.
Нужно получить результат запроса в массив, с помощью mysqli_fetch_all(), и этот массив передать в другую функцию для дальнейшей обработки. Вывода например.

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

Должен например модуль формирования html знать что-то про базу данных? Не должен. Его должны интересовать сами данные, а не средства работы с ними.

Ну и разумеется, код для работы с БД не должен смешиваться с кодом вывода в браузер. Это аксиома.

Если у элемента нет уникального идентификатора, то надо подобрать относительный идентификатор (составной), нп. div1 > div2 > div3[0] ( образно, в xpath оно иначе записывается)

А зачем вообще трекать время? Уложился в дедлайн - молодец. Не уложился - разбор полётов. Хронически не укладывается - понижение грейда или увольнение.

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

<div blabla>
<?php foreahch(): ?>
    <div blah>
<?php    if(): ?>
        <table>
<?php        foreach(): ?>
            <tr>

Получилось в теории ровно но на практике еще более уродливо.
А потом стал пользоваться шаблонизаторами и забыл про все эти куличики в песчнице

Мне это напомнило историю, когда некий докладчик сравнил поиск в Яндексе и прямое указание сайта в адресной строке. Типа, когда он пишет адрес сайта, то сразу переходит на него, и якобы поиск не включается. Однако даже при прямом указании адреса сайта всё равно включается поиск: вы ввели адрес сайта, но это не точный путь к серверу, где хранятся данные. Пока идёт запрос к данным, и пока они идут обратно, включаются несколько поисков на разных этапах.

Так же и здесь. По сути системе нужно достать некое значение из памяти. Массивы изначально заточены под машинную организацию памяти: по порядку. Логично предположить, что если вам нужно N-e значение, то оно быстрее достанется из памяти, так как оно N-e в самой памяти, начиная от некой ячейки (грубо говоря). Более сложные ассоциативные массивы (или объекты) организованы в памяти более сложно (извиняюсь за тавтологию). Ассоциативный массив - это, как минимум, два обычных массива. Соответственно, выполняя поиск по нему, работают уже минимум два поиска.

это всегда перебор всего массива каждый раз.

Если ключи уникальны, а в обычных javascript массивах это так, то вряд ли поиск продолжается после нахождения нужного элемента.

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

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

array_splice