beduin01

Vue.observable позволяет создавать объекты, не привязанные к конкретному компоненту, изменения в которых будут вызывать перерисовку всех зависимых елементов.

Грубо говоря, это более низкий уровень абстракции. Когда вы создаёте обект в секции data где-то там, внутри Vue используется Vue.observable. Просто сейчас эта функция стала доступной глобально

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

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

UPD
Приведу немного аргументации и очевидных вещей для тех, кто не понимает почему ответ именно такой. На самом деле все очень просто: в IT индустрии все развивается и меняется очень, очень-очень быстро. И как следствие возникает проблема устаревания знаний и умений. Вот например 15-20 лет назад изучение языка программирования под названием "Дельфи" и популярной тогда его среды разработки для дестктопных приложений вполне имело смысл и было популярным явлением, т.к. оно тогда довольно широко использовалось, или например Perl для создания сайтов. А где оно сейчас? Почему сегодня сайты пишутся на джаваскрипте? А как на счет десктопных приложений? А ведь те же десять лет назад попробуй скажи такое — как бы область деятельности не пришлось менять. И вот такое происходит просто с языками программирования за довольно короткое время. А основа любого CMS, фреймворка и иже с ними — это как раз таки язык программирования. И вот за время жизни языка программирования в нём случаются новые стандарты, изменения и прочее, а популярное ПО на нём переписываются десятки и сотни раз. Т.е., изменчивость продуктов какого либо языка зависит как от самого языка так и от его популярности. И чем они выше — тем чаще что-то меняется. Из всего этого вытекает очень логичный вывод: в долгосрочной перспективе выгоднее те знания, которые не устареют как можно дольше. И вот тут как раз таки знания разработки ПО и языков программирования, построения архитектура, алгоритмы и прочее имеют наибольший срок устаревания. А уж сколько тысяч лет математике можно и не вспоминать. А она, кстати именно благодаря стремительному развитию IT тоже развивается очень быстрыми темпами. Так вот, при наличии вот таких фундаментальных знаний можно легко и быстро осваивать любые новые фреймворки, CMS, языки программирования и прочее. А уж при наличии подробных мануалов, гугла, форумов и прочего большинство задач сводится тупо к вбиванию "как сделать YYY в ZZZ" в строке поиска (я вот например никак не могу понять ход мыслей людей, которые задают вопросы на форумах и прочих ресусах, ответ на которые выдается в первых же строчках гугла, складывается впечатление, что они вообще первый раз в интернете и про гугл не знают вообще ничего).
Если есть желание именно в изучении CMS — ставим себе задачу и решаем её используя разные CMS, далее выбираем наиболее понравившуюся и пользуемся пока не надоест или не устареет. А после — повторить.

Немного перефразирую сам вопрос и соседний популярный ответ:
— Каким инструментом учиться пользоваться начинающему строителю?
— Учись использовать молоток и гвозди, леса полно, доски везде используются.
Вот только строительство — это не одни только доски, в которые забиваются гвозди, а еще архитектура, сопромат и иже с ним, экстерьер, интерьер, отопление, освещение, канализация, вентиляция и еще куча всего. Аналогично и во всех остальных областях, в том числе и web разработке.

Отдайте деньги и ждите. Не далее чем через 3 месяца клиент попросится обратно - берите двойную сумму.

На работе.

Первым делом ищу готовое решение в репозитории. Если готового решения нет, то пишу код для рабочего проекта. Этот код не идёт в опен соурс. Потом дома пишу либу и выкладываю на гитхаб (и npm). Если либа получилась удачной, то со временем убираю код из рабочего проекта и заменяю его либой.

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

На мой взгляд, в резюме не должно быть указано з/п, вообще.
В плане уровня з/п... Любая, за которую сможете себя продать. А о наглости и самоуверенности тут вообще не стоит думать.

БП - ноунейм какой-то на 500 ватт.

Поздравляю, вы выиграли в лотерею!

Тогда давайте еще круче: зачем соблюдать ПДД если можно ездить без них и дать волю случаю.
ПДД нужны для того чтобы поведение машин на дороге было более упорядоченным и предсказуемым, точно также тут машина должна соблюдать ПДД (сохраняем порядок и предсказуемость), а потом уже пытаться минимизировать ущерб (все также не нарушая ПДД).
Напомню что нарушение ПДД приводит к непредсказуемости что часто ведет к увеличению ущерба.