Алексей 〒.

Несмотря на то, что эти инструменты созданы для решения одних и тех же проблем, делают они это по-разному, как под капотом, так и в плане предлагаемых абстракций. Потому нельзя сказать что 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, то может иметь смысл продолжать делать так же, сохраняя единообразие в коде.

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