Алексей 〒.

> "status": "recently",
Читаем доки.

status (str, optional) – User’s Last Seen & Online status. Can be one of the following: “online”, user is online right now. “offline”, user is currently offline. “recently”, user with hidden last seen time who was online between 1 second and 2-3 days ago. “within_week”, user with hidden last seen time who was online between 2-3 and seven days ago. “within_month”, user with hidden last seen time who was online between 6-7 days and a month ago. “long_time_ago”, blocked user or user with hidden last seen time who was online more than a month ago. None, for bots.

Есть смысл скомпилировать CLI приложение и запускать уже бинарник с нужными параметрами, например так

yourprog worker1
yourprog worker2

Можно использовать вот эти библиотеки:
https://github.com/urfave/cli (хороший и простой, советую начать с него)
https://github.com/spf13/cobra (очень мощный, его использует Docker)

Структура проекта у вас также немного изменится, в Go принято делать папочку cmd, типа так:
cmd/
cmd/worker1.go
cmd/worker2.go

Образец есть в каждой из библиотек, что я выше написал.

По структуре проекта на Go уже был вопрос, вот тут хорошо описано Структура проекта на Golang?

Несмотря на то, что эти инструменты созданы для решения одних и тех же проблем, делают они это по-разному, как под капотом, так и в плане предлагаемых абстракций. Потому нельзя сказать что async/await в C# - это "просто обертка над горутинами".

Горутины в Go - это концепция stackful coroutines (под капотом) + CSP (в абстракциях). Каждый раз, когда мы создаём горутину, под неё выделяется отдельный стек вызовов для её собственных нужд. При этом, когда происходит паника, то stack unwinding (размотка стека вызовов) происходит только в пределах этой горутины и не покидает границ её стека. Стек горутины полностью отвязан от стека её создания/вызова, потому горутина не может возвращать результат. Любое общение между горутинами выполняется либо посредством каналов, либо какой-то общей памяти.

async/await в C# (то есть, Task'и) - это концепция stackless coroutines (под капотом) + futures (в абстракциях). Код с async/await'ами компилятор превращает в определенную стэйт-машину с yield point'ами. У них нет отдельного стека, они выполняются в том же стеке что и вызывающий их код. Соотвественно, есть возможность словить exception'ы (аналог panic'и) возникающие внутри асинхронного Task'а прямо в запускающем его коде. Так как выполнение идёт на том же стеке - Task нормально может возвращать результат и мы его можем считать в вызывающем коде без дополнительных примитивов/инструментов.

При этом, если мы запустим Go с GOMAXPROCS=1, то мы получим однопоточный асинхронный код в Go (по умолчанию он многопоточный). Также и в C# мы можем выполнять Task'и как на одном потоке, так и на thread pool, получая аналогичные Go гарантии рантайма.

С точки зрения абстракций/использования - это уже вкусовщина. Кому как больше нравится. У futures лучше дизайн в плане composability (их эргономичнее join'ить и select'ить), но они вынуждают писать везде async и await. У горутин надо постоянно городить чехарду с синхронизацией (попробуйте сделать аналог await для произвольной горутины), но если эту чехарду прятать под капот (как обычно и делают), то код вообще выглядит полностью синхронным и программисты радуются.

Проверяем, что возвращает оператор typeof:

const strings = arr.filter(n => typeof n === 'string');
const numbers = arr.filter(n => typeof n === 'number');
const booleans = arr.filter(n => typeof n === 'boolean');

Или, проверяем, что элемент и результат его преобразования в значение интересующего нас типа совпадают:

const strings = arr.filter(n => n === `${n}`);
const numbers = arr.filter(n => n === +n); // в отличие от typeof, отбрасывает NaN
const booleans = arr.filter(n => n === !!n);

Или, группируем массив по имени типа, а дальше извлекаем чего надо:

const groupedByType = arr.reduce((acc, n) => {
  const type = n == null ? `${n}` : n.constructor.name.toLowerCase();
  (acc[type] = acc[type] || []).push(n);
  return acc;
}, {});

const strings = groupedByType.string;

Rust это не C++. Почему он должен брать термины из C++?

В Java вон тоже ссылки - это указатели в терминологии C++.

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

но которую можно реализовать и с помощью css, и с помощью javascript...
ваше мнение хотел услышать

Мне самому нравится делать все на CSS, но... Если анимация должна быть интерактивной и нужно ее останавливать в процессе, откатывать в изначальное положение и.т.д., или некоторые ее части зависят от данных (в широком смысле - это и движение по сложной траектории, и построение графиков и.т.д.) и их проще рассчитать скриптом, чем подбирать коэффициенты в CSS keyframes, то JS будет лучшим выбором. Если это последовательность мало связанных между собой изменений, то опять же скрипты почти всегда будет проще реализовать. Если речь идет о CSS-анимациях с фильтрами (особенно SVG-фильтрами), то можно влететь в очень сильные проблемы с производительностью на слабом железе. И никакие хаки с GPU тут не помогут - все равно будет тормозить. В такой ситуации может иметь смысл не просто писать на JS, но и подключить WebGL и все делать руками на шейдерах.

В остальных случаях стоит смотреть по ситуации - разные :hover / :focus эффекты обычно легко реализуются на CSS, и, если это так, то зачем что-то придумывать? CSS в последнее время очень даже неплох. Но если, например, в проекте вся анимация делается на JS, то может иметь смысл продолжать делать так же, сохраняя единообразие в коде.