Василий Банников

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

За оборонные не скажу, не знаю. А на промышленных предприятиях все очень просто. В мире контроллеров доминирует только один язык программирования - С!
Что касается роботов и систем промышленной автоматизации, то очень часто используется блочное программирование на одном из языков МЭК/IEC типа 61131, 61499 и тэдэ. Все это интерпретируется в интерпретаторах на стороне контроллера и разрабатывается в каком нибудь SCADA. Интерпретаторы часто пишутся тоже на С, иногда C++ :)
Все встроенные операционные системы и системы реального времени тоже написаны на С, изредка на С++.
А чтобы все работало надежно, желательно, чтобы компания сертифицировалась на CMMI или ISO 11540 или ISO 33001 - https://ru.wikipedia.org/wiki/ISO/IEC_15504
Часто, если системе позволяют ресурсы, разрабатывают на Java или Net. Иногда всякие разновидности паскаля, но это очень очень редко.

Специальных языков типа forth, я вообще не встречал, ибо просто нет специалистов!
Также не разрабатывают на на lisp, ибо та же беда - специалисты!

Все знают С - с ним и колупаются. Даже C++ редко используют!

Главная проблема - конкурентный доступ. SQLite емнип не предполагает расшаренного доступа к файлу БД.
Вторая проблема - устройство системы разграничения доступа - или у клиента будет доступ на запись в файл (тогда он может сделать все, включая удаление файла), или доступ только на чтение.
Третья проблема связана с главной - даже если получится конкурентный доступ, транзакций не будет уж точно, что имхо при многопользовательском режиме критично.

В общем я бы предложил не исключать вариант с сервером БД.

Разнообразные - от очень медленной работы до порчи данных. SQLite не предназначена для конкурентного доступа, используйте полноценную СУБД.

эмм.... нужно искать любую работу.
сможете в РФ? отлично.
сможете за бугром? ещё лучше.

только как одно отменяет другое?
судя по вопросу: вы в раздумиях, вместо, собственно, поиска.
и это - фейл!

Нет.
Ставьте в виде виртуальной машины.
Меньше геморроя будет.

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

А в реальном физическом мире и у сигнала будут скругленные углы (и возможно лишние пики) и всякие паразитные емкости на дорожках и выводах светодиода начнут роль играть. В зависимости от кучи параметров яркость или немножко возрастет, или наоборот. Такие дела.

В любом случае, изменение яркости будет небольшим, и вполне вероятно, что никто не заметит.

Однажды шагнув в асинхронщину, из нее не вылезешь.
В синхронном коде результат Промиса обрабатывается в then
https://habr.com/ru/company/vk/blog/269465/

mainFunc(rightElem).then(result => {
  console.log("mainFunc", result)
});

В отделении милиции сказали, что даже не станут терять времени и сил на такое пустяковое дело.

Дело происходит не в России, я так понимаю? Просто сто лет о таком не слышал.

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

Some((&[""], ""))
или
None

Зависит о того, что вам надо. Почитайте про Option.

А чем плохо? пользоваться не удобно? строковые константы почти одинаковые, отличаются по чуть чуть?
Лично я не вижу в простом нагромождении switch case ничего зазорного, если это простое описание логики если то... многоуровневая логика уже сложнее (если внутри тоже есть условия) такое читать сильно неудобно и легко пропустить ошибку.

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

https://github.com/nodejs/node/tree/master/lib/int...

У неизменяемых объектов есть свои плюсы. Во первых, их легче сравнивать: вместо сравнения всех полей (рекурсивно) сравниваем только две корневые ссылки на объекты. Во вторых, можно расшарить некоторые внутренние структуры данных. Например, строка во многих ЯП (C#, Java, JS) - это неизменяемый объект. И в JS есть оптимизация - когда берем подстроку от строки, то используем тот же буфер данных. В случае изменяемой строки такой фокус бы не прокатил.

Разумеется, плюсы компенсируются минусами. В большом объекте долго делать изменения. Больше нагрузка на память и сборщик мусора. Так же нельзя такой объект передать куда-то и потом поменять - там, куда передали, будет устаревшая версия (это иногда хорошо, иногда плохо).

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