SEOD

Rust лучше С/С++ во многих (наверное, почти всех) аспектах. Но в сравнении с С++ и тем более Си он слишком молод. Непопулярность языка ещё обуславливается тем, что рынок полностью забит Си и плюсами — миллионы строк кода и библиотек уже написаны на С/С++. Кто их будет переписывать?

Так же, не было никакой значимой маркетинговой кампании по популяризации Rust. Я случайно услышал об этом языке на Moscow Python Conf++, до этого я думал, что когда говорят про Rust, имеют ввиду игру.

Плюс, Rust — язык очень нишевый, как и С/С++. И эта ниша — системное или околосистемное программирование. Операционные системы, драйвера, высокопроизводительные системы, игровые (и любые другие) движки, embed — вот удел раста. И в этих сферах не принято, как, например, в JS'е менять фреймворки и версии языка раз в неделю. Сообщество там крайне консервативное.

К тому же, у Rust очень высокий порог входа. Вот прям очень. Если в контексте C++ постоянно шутят про книги "выучить С++ за 24 часа", то в контексте Rust можно шутить над книгами "выучить Rust за неделю". У их прекрасной парадигмы zero-cost abstractions на самом деле есть cost — сложность понимания. За отсутствие сборщика мусора и необходимости чистить за собой память придётся заплатить многими часами войны с компилятором, а именно — с borrow checker'ом. И это только одна сложность

Когда начинаешь понимать Rust, всё идёт прям отлично. Но до этого момента придётся пройти ад и Израиль, который С/С++'еры не хотят проходить. Потому что они уже его прошли, когда учили С/С++ и там было намного хуже.

Я бы очень хотел, чтобы Rust заменил С/С++, он объективно лучше. Но вряд ли это произойдёт в ближайшие лет 10

Какие задачи решают на 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 нет.

Деньги просто приходят на Ваш личный счёт, а в приложении для самозанятых указываете их как доход от иностранной фирмы. Название можно указать как "Upwork Inc." и наименование услуг тоже на ваше усмотрение. В этом плане все проще, чем у ИП.

По скорости запросов информации. Скорость работы схемы "мозг - руки" довольно ограниченная - человек не тычет в первую же ссылку - он читает, анализирует и уже потом куда-то переходит, ситуаций, когда человек тыкает в первую ссылку сразу же практически не бывает.
По общим прокси - если Вы используете список прокси с тырнета - почему и владелец сайта не может его скачать и забанить?

Вариантов много. Из простого:

• по User-Agent
  
• по IP адресу через отслеживание количества запросов с одного адреса
  
• по используемым публичным прокси (многие такие сервисы явно сообщают, о себе кто они)
  
• и т.д.
  

Из сложного:

• отслеживают перемещение мыши
  
• ведут аналитику на о типичных поведениях пользователя и ищуют анамалии
  

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

Вот такой блок должен был получиться?

в tmux/screen можно шарить сессию между пользователями
смотри в гугле: tmux pair programming

первый юзер:
tmux -S /tmp/shared new -s shared
ставь или права 777 на файл сессии chmod 777 /tmp/shared или в одну группу добавляй пользователей или тупо под 1 аккаунтом заходите
второй:
tmux -S /tmp/shared attach -t shared

Функция все же несколько иная по типу действия и как следствие применимости, нежели чем for. Основное и самое главное отличие, это новый-независимый контекст работы с элементом массива при каждом проходе(функция обратного вызова), с моментальным сбором результатов в новый массив. Да, в for все это тоже можно организовать, но кода потребуется несколько больше, а тут получается очень кратко. И еще, при переборе массива, не нужно указывать индекс элемента массива, как это делается в for. В общем map действительно хорош, но применять его понятное дело надо там - где это уместно.

Также в условиях решения одинаковой задачи(простого перебора массива):
+ Быстрое написание кода
+ Код более читабелен, в том числе теми кто будет потом работать с вашим творением

export enum SelectSize {
  medium = "medium",
  large = "large",
}

// создай тип
type PositionProps = {
  bottom: string;
  left: string;
  right: string;
  top: string;
};

// или интерфейс
interface PositionProps {
  bottom: string;
  left: string;
  right: string;
  top: string;
};

export const selectSizeValues: { [key in SelectSize]: PositionProps } = {
  [SelectSize.medium]: {
    bottom: "8px",
    left: "16px",
    right: "56px",
    top: "24px",
  },
  [SelectSize.large]: {
    bottom: "8px",
    left: "24px",
    right: "64px",
    top: "32px",
  },
};