Знаете, у меня сейчас небольшой спор был с товарищем (это который исполнял роль "ученика" в видео по Ruby). На мой взгляд, подход "идеально или никак" - это зло.

Уже и не сосчитать, сколько раз мне приходилось делать нечто, что изначально идеальным не было даже близко. Да хотя бы первый урок для одного-единственного слушателя, который ошибся датой и приехал на несколько дней раньше, чем начался курс. Как давно это было... Потом вторая лекция, уже для большой группы, где приходилось орать на всю аудиторию, особенно, когда готовились к лабораторным и начинали гудеть серверы. Да мало ли, что ещё было.

Помнится ещё такой случай, который произошёл ещё чуть ли не до эпохи исторического материализма. Учился я в 11 классе и мне предложили съездить на олимпиаду по литературе. Вообще, странно, так как на многих был, а вот на такой - впервые, хотя к тому моменту какие-то паршивые рассказы я пописывал, а один даже вышел в малоизвестном журнале. Ну, в общем, согласился, но сказал честно, что у меня времени будет мало, так как вечером нужно спешить в институт, там вовсю идёт подготовка к экзаменам.

Прихожу, говорят: выбирайте, о чём будете писать. Ну, дескать, по прозе или по стихотворению. Все выбрали прозу, а я подумал - там ведь наверняка длинный рассказ, который ещё и читать придётся. Да ну его, этот рассказ. Выбрал стихотворение, а оно и впрямь короткое. 😂 Дальше было просто - нужно написать свои мысли про прочитанному, причём, как ни странно безо всяких "что хотел сказать автор". Просто развёрнутое сочинение. Дело-то, в целом, нехитрое, только время сильно поджимало, так что я просто как мог написал начисто, безо всяких перепроверок, и сдал это дело, после чего откланялся самым первым.

Проходит месяц, после чего мне сообщают - а у тебя первое место, но только грамоту мы тебе не дадим, так как она потерялась. Чудеса в решете, ведь я в жизни первых мест нигде не занимал. Были какие-то медальки за вторые-третьи места, а тут первое, единственный раз в жизни, и то награду зажилили 😂 Но забавно то, что, по большому счёту, я просто выполнил некую литературную подёнщину, написав рассказ на заданную тему, но всем почему-то понравилось. Был ли он идеальным? Да нет конечно. Но в моменте надо было просто взять и сделать.

Та же ситуация и с приложениями, которые мы пишем. Да, это будет неидеальная версия. Да, будет кривая и косая, ещё и с багами. Но это нормально, ведь версия-то первая. Или вторая или даже десятая. Вспомните Windows circa 98.

Впрочем, это не значит, что нужно ко всему относится спустя рукава, конечно. Грубо говоря, к некоторым лекциям, которые всё равно выходят неидеальными, иногда приходится готовить материала страниц на 15 печатного текста. Стараться нужно, но не стоит зарубаться на том, чтобы это было лучшим делом, которое вы сделаете в жизни. Хочется верить, что такое дело ещё впереди у всех нас.

https://www.youtube.com/watch?v=scTVLy_T9jI

Вторая часть про ECC!

Так вот, мы установили, что с точками на кривой можно выполнять математические операции и это, на самом деле, принципиально важный момент, связанный с получением открытого ключа. В частности, две точки можно складывать и результатом будет другая точка на кривой. Как именно сложение происходит визуально, можно также увидеть вот на этом сервисе https://www.desmos.com/calculator/ialhd71we3 В частности, на нём вы увидите две точки - оранжевую и синюю, - через которые проведена прямая. Третья точка чёрного цвета, где эта прямая пересекает кривую, и есть результат сложения (только заметьте, что эта точка инвертирована относительно оси X и финальный результат оказывается по другую сторону).

Какие там используются формулы для сложения точек, вы можете посмотреть в умных книжках, но нас это не сильно интересует. Важно то, что этот подход мы можем использовать для получения открытого ключа. Алгоритм выглядит так:

- На кривой задаётся изначальная точка G, которая называется генераторной. Про неё ещё потом скажу пару слов в третьей части. Важно то, что для конкретного алгоритма эта точка известна абсолютно всем: к примеру, для secp256k1 её координаты равны 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798. Вы можете спросить, а почему тут только одна координата, но про это будет позднее. Пока просто поверьте, что это координаты точки по двум осям, только в сжатом виде.

- Мы можем сложить эту точку саму с собой - как ни странно, это тоже допустимо. В результате мы получим новую точку A, которую можно записать простым выражением A = G + G. Ну, а коль скоро у нас есть сложение, то и умножение мы тоже можем сделать, то есть A = 2 * G. Кстати, на мой скромный взгляд, во многих руководствах вот этому моменту вообще не уделяется внимания. Часто пишут в духе "возьмём две точки, проведём прямую, получим третью". Но, пардон, изначально-то генераторная точка одна - откуда тогда взялась ещё и вторая?

- Затем мы можем посчитать точку B путём сложения G с уже посчитанной точкой A. B = G + A = G + 2 * G = 3 * G.

- Guess what: мы можем продолжать эту операцию сколько угодно раз. Проделайте эти вычисления самостоятельно вот на этом калькуляторе https://andrea.corbellini.name/ecc/interactive/modk-add.html введя параметры a = 0, b = 7, p = 17 (маленькое поле для простоты, но помните, что в реальной жизни оно гигантское). Затем просто задайте координаты для обеих точек в (15, 13) (в калькуляторе эти точки названы P и Q, но суть не меняется) и вы увидите, что результатом сложения выступит точка (2, 10). Потом можете повторить сложение (15, 13) и (2, 10), и так далее.

Вспоминается старый анекдот: куда мы попадём, если будем долго бурить землю на экваторе? Видимо, в сумасшедший дом. Тут можно задать тот же вопрос: где мы окажемся, если будем повторять это умножение и, самое главное, нафига вообще это нужно?

- Ответ на первый вопрос очень простой: в конце концов мы окажемся в какой-то точке на кривой, обозначенной P, у которой также есть координаты x и y, причём выражены они тоже целыми числами.

- Ответ на второй вопрос тоже не сильно сложный: координаты финальной точки P будут выступать открытым ключом. Да, это два числа, но мы можем просто слепить их воедино. К примеру, для Ethereum каждая координата имеет размерность 256 бит, значит две координаты дают размерность 512 бит - это и есть размер открытого ключа в несжатом виде.

Ладно, а где тогда закрытый ключ? А закрытый ключ, дорогие друзья, - это то число, на которое мы умножаем G. Скажем, в примере выше у нас получилось, что B = 3 * G, значит закрытый ключ k равен 3. Естественно, это очень простой пример, а в реальности же закрытые ключи лежат в диапазоне от 1 до 2 ** 256 - 1, то есть опять же числа нереально здоровые. Закрытый ключ можно получить хотя бы из мнемонической фразы, которая пропущена через тот же keccak256 - так как алгоритм гарантирует, что выходное шестнадцатиричное число будет меньше, чем 2 ** 256, то нас это прекрасным образом устраивает (хотя схемы могут быть сложнее).

А главная замута здесь вот в чём. Посчитать открытый ключ по формуле P = k * G - это достаточно простая и быстрая операция, которая выполняется за время log2(k). Но вот сделать обратную операцию и узнать закрытый ключ по известному открытому k = P / G - это задача на данный момент практически невыполнимая, если используются достаточно большие числа. Эта проблема называется Elliptic Curve Discrete Logarithm Problem (ECDLP); эффективного решения она не имеет, что гарантирует надёжность алгоритма. Опять же, говоря простым языком, даже если мы знаем начальную и финальную точку на кривой, мы в душе не знаем, сколько потребовалось "прыжков" для того, чтобы в этой финальной точке оказаться.

Пока всё, а в третьей части разберём ещё несколько важных моментов.

И ещё пару любопытных тем по ECC.

Все точки на эллиптической кривой можно разделить на так называемые циклические подгруппы. В разных вариантах кривой может быть разное количество подгрупп, а называется это число h ко-фактор (cofactor). Например, для secp256k1 кофактор равен 1, то есть все точки лежат в одной подгруппе. Также, общее количество вообще всех точек во всех подгруппах называется порядок кривой n. Для уже известной нам кривой secp256k1 значение n равно (внимание) FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - это в виде hex. То есть вот столько там есть возможных точек и, соответственно, ключей.

Почему важны все эти кофакторы? Потому что генераторная точка G может сгенерировать любую другую точку в рамках своей подгруппы, если сделать достаточно большое количество "прыжков" (то есть умножений). Частным случаем является умножение на 0 - там получается бесконечность и такая точка нам, конечно, не подходит. Таким образом, для кривой secp256k1 мы можем попасть в каждую другую точку из генераторной. Собственно, G выбрана умными людьми специально, чтобы из неё можно было попасть в наибольшее количество других точек. Именно поэтому следует использовать уже готовые и протестированные кривые, а не придумывать собственную.

И последний момент, связанный со сжатием координат (x, y) для наших открытых ключей. Дело в том, что у кривой Вейерштрасса есть другое любопытное свойство: на каждую координату там приходится максимум две точки, что проиллюстрировано на этом рисунке https://60896510-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LhlOQMrG9bRiqWpegM0%2Fuploads%2Fgit-blob-88e7096ea7710831737bc083a128836c03c6da9b%2Felliptic-curve-over-f17-points-per-y-coordinate.png?alt=media

Больше того, там выходит, что если есть две точки с одинаковыми координатами по оси X, то по для одной точки по Y будет чётная координата, а для другой - нечётная. Неплохо, да? Это значит, что для каждой точки мы можем оставить только её координату по X, а Y выразить как чёт-нечёт, то есть занять фактически лишь один бит. Таким образом, мы можем сжать 512-битную пару (x, y) до 257 бит.

"Расжать" координату по Y можно по формулам y1 = mod_sqrt(x ** 3 + ax + b, p) и y2 = p - mod_sqrt(x ** 3 + ax + b, p), где mod_sqrt - это квадратный корень с операцией модуля (он считается по алгоритму Тонелли-Шенкса, но это не столь важно https://en.wikipedia.org/wiki/Tonelli%E2%80%93Shanks_algorithm). Получив две координаты по Y мы просто выбираем либо чётную, либо нечётную. Хитро, правда?

Ну, и подведём итог. Для того, чтобы посчитать открытый ключ с помощью ECC нам требуется:

- Выбрать кривую, например, secp256k1. Выбранная кривая влияет на параметры a и b, у неё есть известная генераторная точка, а также известный порядок и кофактор.

- Каким-то образом создать закрытый ключ k (выбрать случайное число, использовать мнемоническую фразу или как-то ещё).

- Умножить G на k и получить финальные координаты точки P, открытого ключа.

В Ethereum, кстати, потом происходит интересная штука, так как открытый ключ хэшируется, а последние 20 байт (160 бит) этого хэша становятся адресом аккаунта, которому этот публичный ключ соответствует. Так как хэш представляет собой числа hex, то и адрес тоже является шестнадцатиричным числом. А это значит, что мы можем превратить его в обычное число, если вдруг такая необходимость есть uint256(uint160(some_addr)). В других системах может быть такое, что сам публичный ключ и выступает адресом.

В этом уроке по Elixir мы продолжаем говорить об OTP! В этот раз обсудим, что такое supervisors и как использовать их для мониторинга процессов. Также мы создадим своё приложение OTP и узнаем, как создавать консольные приложения с помощью enoscript. https://www.youtube.com/watch?v=sZKcghMkN80

А, вот ещё забавную штуку вспомнил. В метро Стокгольма кое-где висела вот такая вот реклама - дескать, приглашаем на работу (пардон, поверх в редакторе телефона нарисовал индексы для простоты и забыл стереть).

Эта задачка написана на чём-то вроде python, но забавно, что даже если решить её правильно, то сайт всё равно говорит "ответ неверный". Я просто пока ехал решил в уме, потом проверил, расстроился, стал решать ещё раз - ответ тот же. Плюнул, вбил это дело в интерпретатор онлайн вечером, а ответ всё равно тот же 😂 Короче, я бы ещё подумал, приходить ли в такую компанию 😃

Иногда при настройке автотестов через GH Actions может потребоваться указать несколько разных наборов библиотек - ну, к примеру, отдельно тестировать с Rails 6 и 7. Это вполне возможно - достаточно создать несколько файлов Gemfile и указать пути к ним

        gemfile:
          - Gemfile
          - gemfiles/Gemfile-rails-6-1
          - gemfiles/Gemfile-rails-6-0

А затем указать:

env:
  BUNDLE_GEMFILE: ${{ matrix.gemfile }}

В файле boot.rb в приложении Ror должна быть строка вида

ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../../Gemfile', __dir__)

Полный пример конфигурации тут https://github.com/bodrovis/lokalise_rails/blob/master/.github/workflows/ci.yml

Tokei - классный инструмент, который показывает статистику проекта (на каком языке сколько строк кода, в частности). Очень быстро работает, запускается одной командой https://github.com/XAMPPRocky/tokei

Distress has found a dwelling place in me...

Сегодня просто музыка

https://www.youtube.com/watch?v=2FgE6brE4dw&list=OLAK5uy_n_dHSdj-FDDjrUP3VWzo6cbxIA1lXomw0&index=4

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

Случайность - это вообще весьма важная штука в криптографии. Например, в том же RSA некоторые параметры при генерации ключевой пары выбираются случайно. Или, к примеру, в ECC мы можем задать количество "прыжков" до финальной точки случайным образом. Но дело в том, что нельзя сказать компьютеру "загадай какое-нибудь число", в отличие от людей, которые могут легко выдать нечто в указанном диапазоне (хотя и там наверняка есть какой-то алгоритм).

Так вот, процесс создания случайных, точнее псевдослучайных, чисел в компьютере - это довольно любопытная тема. Самый простой пример генератора случайных чисел (RNG) - это линейный конгруэнтный генератор, который выражается формулой f(x) = a * x + c (mod m). Казалось бы, звучит сложно, но по факту алгоритм следующий:

- Берём изначальное "сообщение", которое может быть числом, словом, строкой. Это сообщение называется seed.

- Хэшируем его по заданному алгоритму, хотя бы с помощью keccak256. Получаем на выходе число в диапазоне до 2 ** 256 - 1 (ну, или в другом, зависит от алгоритма). Это и будет нашим первым случайным числом.

- Проблема, однако, в том, что это число лежит в очень большом диапазоне, а нам, к примеру, нужно получить число от 0 до 10. Ну, это не беда - мы можем просто использовать остаток от деления на 10, то есть нормировать изначальное число.

- Дальше, если нам нужно ещё одно случайное число, мы просто увеличиваем seed на единицу и опять хэшируем - у нас получится другое число, которое также можно нормировать.

- Эту операцию можно повторять сколько угодно раз. Естественно, процесс может быть сложнее, чем просто увеличение на 1, но суть остаётся прежней.

Из всего этого можно сделать очень простой вывод: если кто-то знает изначальный seed, то этот некто сумеет предсказать последующие случайные числа, то есть восстановить последовательность, что, в ряде случаев, может привести к очень серьёзным проблемам. Ну, грубо говоря, хакер может понять, какое случайное число использовалось при создании закрытого ключа и просто его взломать.

Поэтому чрезвычайно важно, чтобы в таких случаях использовались безопасные случайные числа (CSPRNG, то есть криптографически надёжные). Для таких чисел seed выбирается с помощью отслеживания множества происходящих в системе событий, которые сложно предсказать и восстановить. К примеру, сетевая активность, движения мышкой, ввод с клавиатуры - в таком духе. Все эти события вносят так называемую энтропию, то есть размытие, которая сильно затрудняет попытку как-то воссоздать seed.

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

Впрочем, далеко не всегда это нужно - если вы просто хотите вытащить случайный элемент из массива в учебной программе, то вам подойдут обычные генераторы случайных чисел в духе rand() в Ruby.

Случайные числа можно использовать для создания потоковых шифров, а пример такого шифра можно посмотреть в видео-уроке (в общем, он несложный). https://youtu.be/q9PWljGSpKY

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

Мы будем и слышать, и видеть того, кого нет с нами, и останется для нас только одна тоска - тоска о касании.

Забавно, а ведь Тэффи написала это ещё до революции в России, то есть до эпохи исторического материализма. Аппарат изобрели, но он всё ещё не умеет передавать касания, увы...

Впрочем, про это был очень любопытный роман у Лема про "дистантников", когда можно было удалённо управлять неким телом. Естественно, всякие хитрые личности с помощью этого стали устраивать амурные приключения, и многие задались вопросом - а считается ли это изменой, ведь тело-то не твоё? Особо продвинутые даже работали через два прокси, то есть залезали в ещё одного дистантника 😂 Это из романа Pokoj na Ziemi (Мир на Земле), очень рекомендую 🚀

У меня тут небольшой "юбилей" - 13 миллионов закачек, если считать все созданные гемы (ну, то есть Ruby, другие языки тут не считаю). https://rubygems.org/profiles/bodrovis

Что хочу сказать по этому поводу - не стоит бояться публиковать свои творения для мира. Пусть даже ваше решение поможет паре человек, это всё равно классно. Да, оно может быть неидеально, но, в конце концов, найдутся люди, которые помогут довести его до ума. Ну, главное укажите правильную лицензию (MIT в простом случае), чтобы к вам не имели претензий 😂

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

- Так вот, пожалуй, лучший этап был увенчан довольно забавной лекцией по Ruby ещё в каких-то мохнатых годах, когда Rails были в тренде. Это, помнится, была лекция на четвёртом курсе ещё до момента, когда кафедру слили с другой и кто-то на этом, думается мне, неплохо попилил денег, а "неудобного" заведующего, которого не желал следовать генеральной линии, аккуратно убрали.

Тогда я просто-таки летал по аудитории, размахивал руками, приводил какие-то невероятные аналогии, объясняя некую тему (уже не помню, что там точно было). После занятий студенты выходили какие-то непривычно тихие, только один проговорил "да, классная лекция". 😂 (за всю мою практику такое было буквально пару раз, не больше) Когда я вернулся домой, у меня реально пошла кровь из носа - этого не бывало уже лет пять к тому моменту. Большую часть вечера я пролежал, смотря "Один дома" (дело было под рождество как раз).

- А вот точка "снизу постучали" нарисовалась спустя года четыре, когда очередной четвёртый курс сдавал экзамен, это был профильный предмет, что-то про программирование и интернет-технологии. Каждому списывающему я по обыкновению ставил "минус балл" сразу, однако в конце экзамена на меня конкретно "наехали", заявив, что мы вообще-вообще не списывали и всё отлично ответили 😂

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

Хотя, пожалуй, самый финиш был в следующем семестре, когда кто-то поинтересовался у меня "чё такой галимый интерфейс" у консольного приложения. И это я вообще не шучу - вот тогда действительно захотелось поставить во всей этой истории жирную точку. 😜

https://www.youtube.com/watch?v=bUU7b-g5Dlk

Небольшой тизер - в ближайшее время проведём стрим по Ruby, поговорим о практическом использовании и посмотрим на примере относительно большой проект, который я вот только недавно переписал с нуля. Будет про организацию кода, тесты (с webmock), метапрограммирование - в таком духе. Вот как раз только сделал merge для pr 😂

Раз идея со стримом всем зашла, чему я действительно очень рад, давайте встретимся завтра вечером в 20:30 UTC+3. Правда вышло забавно, тк я думал, что сегодня среда, и в четверг можно подготовиться, а выходит, что четверг-то сегодня 😂😂 Но это не беда, уже успел большинство приготовлений сделать https://youtube.com/live/tpQJmG101Gw?feature=share

Итак, вторая часть обещанного стрима состоится завтра. В этот раз мы посмотрим проект поменьше и обсудим, как создать удобную конфигурацию для пользователя, как работать с архивами, потоками, как создавать свои задачи rake и не только. https://youtube.com/live/4VssXSv6gQQ?feature=share

Лучший комментарий на стриме - почему докладчик в шляпе? Даже не придумал сразу, что ответить. 😄

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

Берегите себя https://www.youtube.com/watch?v=DxkeOkaVRLo

Итак, официально - в следующий четверг в 20:30 UTC+3 говорим о диффузионных моделях в современном ИИ 🤖 https://youtube.com/live/pvAdpfZZjNU?feature=share

Знаете, когда у меня спросят, почему мне не нравится экосистема JS, я отвечу просто. Потому, что для обычного форматирования кода TS в проекте ESM нужно добавить себе в package.json вот это вот

    "@typenoscript-eslint/eslint-plugin": "^6.0.0",
    "@typenoscript-eslint/parser": "^6.0.0",
    "eslint": "^8.33.0",
    "eslint-config-prettier": "^8.0.0",
    "eslint-import-resolver-typenoscript": "^3.5.1",
    "eslint-plugin-import": "^2.26.0",
    "eslint-plugin-node": "^11.1.0",
    "eslint-plugin-prettier": "^5.0.0",

После чего создать отдельный файл с вот этим вот

module.exports = {
  root: true,
  parser: "@typenoscript-eslint/parser",
  parserOptions: {
    tsconfigRootDir: __dirname,
    project: ["./tsconfig.eslint.json"],
    ecmaVersion: 2022,
  },
  plugins: ["@typenoscript-eslint", "node", "prettier"],
  extends: [
    "eslint:recommended",
    "plugin:@typenoscript-eslint/recommended",
    "plugin:node/recommended",
    "plugin:import/recommended",
    "plugin:import/typenoscript",
    "plugin:@typenoscript-eslint/recommended-requiring-type-checking",
    "prettier",
  ],
  rules: {
    "prettier/prettier": "error",
    "@typenoscript-eslint/consistent-type-assertions": [
      "warn",
      {
        assertionStyle: "angle-bracket",
      },
    ],
    "@typenoscript-eslint/no-explicit-any": "off",
    "node/file-extension-in-import": [
      "error",
      "always",
      { tryExtensions: [".js", ".json", ".node"] },
    ],
    "node/no-missing-import": "off",
    "node/no-unpublished-import": ["off"],
    "import/no-unresolved": "error",
    "import/no-named-as-default": "off",
    "@typenoscript-eslint/no-unsafe-assignment": "off",
    "@typenoscript-eslint/no-unsafe-member-access": "off",
    "@typenoscript-eslint/no-unsafe-call": "off",
    "@typenoscript-eslint/no-unsafe-argument": "off",
    "@typenoscript-eslint/no-unsafe-return": "off",
    "@typenoscript-eslint/unbound-method": "off",
  },
  settings: {
    "import/parsers": {
      "@typenoscript-eslint/parser": [".ts", ".tsx"],
    },
    "import/resolver": {
      typenoscript: {
        alwaysTryTypes: true,
        typenoscript: true,
        node: true,
      },
    },
  },
};

Кроме того, нужно сделать отдельный tsconfig специально для ESLint. А если у одной из этих библиотек выйдет новая большая версия, то всё вообще перестанет работать, пока другие не добавят совместимость.

В языках типа Elixir или Rust задача форматирования кода решается одной встроенной командой. Dixi.

Ну, и дополнение к посту выше. В общем-то, я не хочу, чтобы это выглядело, как "наброс" (как выразился один из читателей). Я вообще-то за набросами никогда не был замечен.

Это вполне осознанная оценка, основанная на достаточно большом опыте. Впервые с JS я столкнулся ещё до того, как нам рассказали, что такое AJAX, после чего появился мега-костыль из криптонита под названием jQuery (между прочим, он используется на очень многих сайтах до сих пор). По нему тогда реально издавали целые книги, причём довольно толстые.

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

Это не говоря о всяких решениях типа grunt, webpack и прочих, которых тоже существует изрядно. Потом грянул TS, который должен был решить все проблемы, а затем новая история - CommonJS vs ESM. Да, их можно подружить, только зачастую все плюют и бросают это дело.

Да много чего ещё можно рассказать... Но, честно говоря, я не хочу тут устраивать поле боя. Если вам нравится этот язык, то используйте на здоровье. Но мне он не импонировал никогда, и теперь ситуация не изменилась. Честно говоря, если бы мне сказали, что писать можно только на JS, то я бы послал к чёртовой матери всю разработку и переквалифицировался бы в управдомы.

А помните, раньше нужно было просто показать, как поменять местами значения двух переменных без использования третьей? И всё - уже король. https://www.youtube.com/watch?v=KJoPIgg17U4