В целом - да. Я просто привел как еще один пример попытки приблизить JavaScript к native. Имел ввиду, что похоже это именно тренд. Чем дальше - тем чаще у ЖСа прорывы по перформансу в текущих средних размерах проектов.
Суть асм.жс - урезаный ЖС, через урезаную гибкость и работу с типами (сделать более С-подобным; Го-подобным, так как есть CG) - и тогда сильно уменьшается объем инфраструктурной логики, что делает его сильно ближе к нативному С по производительности.
По вашей логике я бы тогда не узнал про NVim вообще. Сидел бы в других IDE и редакторах. И решал бы все свои вопросы в их рамка. И никогда не гуглил бы то, о чем и не представляю.
А так периодический случайный поиск и апдейт по технологиям иногда приносит неожиданные результаты.
Но подчеркну, что согласен с вами - в тупую гоняться за всеми тренд плагинами глупо. Будет сильно больше вреда.
Идут процессы о которых мы все знаем и видим; и скорее всего дальше будут идти; и долго и много. Нравится нам это или нет. Но они идут.
А дальше мы можем об этом всем узнавать только мнения сторонних наблюдателей + псевдо-инсайды или слухи. И этого предостаточно в отношении РуТьюба. Каждая новость обрастает слухами и уже давно сложно найти хоть что-то интересное и подтвержденное.
А можем - какую то часть получать непосредственно от людей изнутри. Как к этой инфе относиться - сообщество решит само. Но получить еще один (новый и оригинальный) канал информации об этом процессе - мне кажется нормальная тема.
П.С. Плюс эта статья - чисто техническая. А экспертизы открытой по этой теме не много. И делалось это все обычными трудягами ИТшниками. Так что тут тоже вполне себе.
А позже в диалоге с комьюнити, глядишь, может и прольется немного свет на детали не-технических решений по РуТьюбу, которые всех интересуют. Но для этого нужен инфо канал. А это способ его наладить.
Автор 1 раз в статье и один раз (минимум) в комментах написал JvmBrains.
При этом статья в хабе Java, но про Джаву ни слова (C# & TS), кроме дописывания до кучи в списке других языков пару раз.
При этом какие то статьи по Джаве еще есть.
При этом сравнивает JetBrains и другие IDE для Джавы не сравнивая мега разницу в возможностях...
Выше пишет, что Нода "уж куда производительнее Java".
Складывается впечатление, что автор не сильно знает Джаву. Просто дописал до кучи.
П.С. По самой статье: все что из нее нужно вынести - не нужно быть адептами никаких сект и слепо верить догмам. Нужно выбирать из всех возможностей и парадигм что есть. Выбирать комфортную вам и вашей команде под задачу и ресурсы. И быть гибкими в своем выборе.
Автор явно старается и ищет упорно и активно свой идеал. И он молодец в этом поиске. Видно, что много читает и интересуется. В общем путь идет достойно. Тут вопросов нет.
Но в статье же призывает сменить одну секту на другую как он. Что мне кажется ошибочным. И со временем мне кажется, что он прийдет к тому, что нет идеала ни где, а есть куча мнений как решать задачи. И инструментов. И нужно уметь выбирать. И это он научится на своем пути.
Благодарю за то, что не стали со старту хоронить Джаву и хейтить ДжаваСкрипт (как сейчас модно) и попытались провести адекватную аналитику популярности языков. Интересно.
Выскажу свое мнение по феномену Делфи и Бейсику на ТИОБЕ:
Статистики (и слезы) СтекОверфлоу и т.д. показывает, что из-за развития ИИ люди стали меньше искать ответы в интеренете на свои вопросы по кодингу, а больше спрашивать у ИИ. Т.е. стали меньше гуглить. И вроде бы как существенно меньше. Это наверное можно считать фактом.
В тоже самое время можно предположить, что на вопросы к ИИ перешло больше прогеров там, где их язык более новый, легкий, молодежный или хайповый (Раст - мало пробовали, но много хотели). И меньше там, где язык старый/консервативный/хардкорный/тяжелый/...
Или если кратко: студент питонист в первый же день стал использовать ИИ для кодинга и популяризовать, а бывалый мега опытный делфист сразу сказал, что не будет делать этого никогда, но он при этом все так же гуглит.
Так и произошел перекос статистики по некоторым "непопулярным" языкам - их доля подросла. Это гипотеза.
Никогда не слышал, что бы проблема была в этом. Вносится много всего хорошего и нового. И если где-то что-то выходит долго, то это не из-за "незнания С", а из-за обратной совместимости и прочих стратегических инициатив. Писать код в данном случае не самое сложное.
C#, JavaScript, Python, ... - они все не сами на себе написаны. И нет у них с этим проблем. И при этом новые модные фичи присутствуют. Но в ЖаваСрипте куча мусора, а в двух других обратная совместимость далека от уровня Джавы. Вот и причина, почему в Джаве фичи появляются позже.
Брайан об этом всем говорил очень много раз. Все в интернете есть.
@semenovsemenov подскажите, а в источнике в задаче про 9 точек был красный квадрат вокруг них? Или это вы добавили?
Спрашиваю, потому что это была сильная подсказка для меня: поскольку не увидел ничего про него в условии, сразу понял что подразумевается выход за рамки. Вот и хочу понять, была ли такая задумка у автора...
Полностью согласен с комментом. Тестирование проведено не полно и не прозрачно. Но даже в его камках есть явные косяки: - В графике "Средний бал на рубль" у вас Таймвеб впереди всех, и чем короче полоса (и это вообще не ТаймВеб) - тем больше переподписывают (шаред проще говоря). Но в выводах вы гасите Таймвеб. Вы ж противоположные выводы делаете тому, что у вас в графиках. Как так? - Как вы определяете шаред сервера (переподписки по вашему)? Вы этого не описали, но вы якобы за прозрачность. У клауд-ру и яндекса (особенно на однопоточном тесте) явно ж не хотите видеть, что нагрузка на разных серверах перманентно разная и ресурсы отличаются. Но в выводах этого ж нет.
В общем мне кажется нужно вам пересмотреть выводы, описать методику тестирования и инструменты, проанализировать еще раз все, подписать оси графиков и описать методики подсчета, не плодить новые термины и сущности, доработать полноту тестирования (ваши показатели - это капля в море из всех что интересуют).
Не учитывать винт, ИО, сеть, объем и скорость инета, стабильность и интеграции - это профанация, а не тест. Вы возьмите и напишите полезное предложение, которое бы использовало только РАМ и ЦПУ. Что это должно быть?
Плюс очень хороший комментарий выше. Прислушайтесь. Он дело говорит.
И не стоит критиковать обвинять других совсем не разобравшись в теме (так это выглядит).
П.С. Прошу прощения если грубо, но вы тоже как бы навалили на ребят не разобравшись.
Чтобы приобрести блокировку, мы применяем метод test_and_set() к std::memory_order_acquire. Так создаётся барьер памяти, гарантирующий, что все предыдущие операции записи будут видны потоку до тех пор, пока он не приобретёт блокировку. Затем мы применяем метод clear() к std::memory_order_release, чтобы высвободить блокировку, и тем самым выставляем барьер памяти, гарантирующий, что после снятия блокировки все последующие операции записи будут видны другим потокам.
Это не верно понято или переведено. Все +/- наоборот. Если кратко: все, что сделано до релиз-лок в одном потоке, будет видно после эквайр-лок в другом потоке. В вашем переводе - наоборот.
Барьер сохранения: Барьер сохранения (также называемый барьер записи) — это барьер памяти, гарантирующий, что все операции сохранения в память до достижения барьера будут видимы другим потокам. Барьеры сохранения не позволяют процессору переупорядочивать операции сохранения в память. В противном случае операция записи в одном потоке могла бы сработать до операции чтения в другом потоке.
Барьер загрузки: барьер загрузки (также называемый барьер чтения) — это барьер памяти, гарантирующий, что все операции загрузки в память после барьера будут видны актуальному потоку. Барьеры загрузки не позволяют процессору переупорядочивать операции загрузки в память. В противном случае операция чтения могла бы быть выполнена до операции записи в другом потоке.
Примерно та же проблема. Только тут и в оригинале запутано написано.
У вас в результатах 29% - женский пол. Это скорее всего говорит о перекосе в вашей статистике и подрывает надежность. Цыфра сильно большая. Возможно вторым таким маячком является то, что практически весь экспертный совет женский.
Поэтому довольно большие сомнения по поводу фразы:
Наша выборка из 1 208 верифицированных анкет обеспечила надёжность (то есть доверительную вероятность) результатов на уровне 99%.
В противном случае, если Беларусь нашла ключик к тому, как обеспечить занятость девушек в ИТ до каждого третьего - эта информация стоит больше всех таких отчетов вместе взятых.
В целом - да. Я просто привел как еще один пример попытки приблизить JavaScript к native. Имел ввиду, что похоже это именно тренд. Чем дальше - тем чаще у ЖСа прорывы по перформансу в текущих средних размерах проектов.
Суть асм.жс - урезаный ЖС, через урезаную гибкость и работу с типами (сделать более С-подобным; Го-подобным, так как есть CG) - и тогда сильно уменьшается объем инфраструктурной логики, что делает его сильно ближе к нативному С по производительности.
И вот такое еще есть от авторов самого JavaScript (но это не точно) - asm.js
Я не пробовал, но вроде как имеет довольно хорошую поддержку в браузерах уже и в WebAssembly.
Ютуб Primeagen:
https://www.youtube.com/@ThePrimeTimeagen/videos
https://www.youtube.com/@ThePrimeagen
https://www.youtube.com/@TheVimeagen
Один из саппортеров НВима - TJ DeVries
И вот неплохое: https://www.youtube.com/@joseanmartinez/videos
Так же когда чего-то нужно нового, начинаю подбирать еще на (это наш парень): https://github.com/echasnovski/mini.nvim
По вашей логике я бы тогда не узнал про NVim вообще. Сидел бы в других IDE и редакторах. И решал бы все свои вопросы в их рамка. И никогда не гуглил бы то, о чем и не представляю.
А так периодический случайный поиск и апдейт по технологиям иногда приносит неожиданные результаты.
Но подчеркну, что согласен с вами - в тупую гоняться за всеми тренд плагинами глупо. Будет сильно больше вреда.
Я начинал настрочку с этого конфига. Плюсы:
его делает и продвигает один из авторов НеоВима
конфиг в одном файле
конфиг хорошо документирован
конфиг легко устанавливается
конфиг легко дальше расширяется
сразу получаем хорошо выглядящий НВим
Полностью согласен. И это не только к программированию.
Если человек сам не копает и не пробует, а ждет магии/курсов/провидения/... - это не приведет к успеху. Значит скорее всего ему самому не интересно.
П.С. Но это не отменяет курсов/уроков/тренингов/.... Они могут быть помощью, где нужно.
Почему? Смотрите:
Идут процессы о которых мы все знаем и видим; и скорее всего дальше будут идти; и долго и много. Нравится нам это или нет. Но они идут.
А дальше мы можем об этом всем узнавать только мнения сторонних наблюдателей + псевдо-инсайды или слухи. И этого предостаточно в отношении РуТьюба. Каждая новость обрастает слухами и уже давно сложно найти хоть что-то интересное и подтвержденное.
А можем - какую то часть получать непосредственно от людей изнутри. Как к этой инфе относиться - сообщество решит само. Но получить еще один (новый и оригинальный) канал информации об этом процессе - мне кажется нормальная тема.
П.С. Плюс эта статья - чисто техническая. А экспертизы открытой по этой теме не много. И делалось это все обычными трудягами ИТшниками. Так что тут тоже вполне себе.
А позже в диалоге с комьюнити, глядишь, может и прольется немного свет на детали не-технических решений по РуТьюбу, которые всех интересуют. Но для этого нужен инфо канал. А это способ его наладить.
Хорошая интересная статья. Но таких нужно больше. Если вы сами не будете рассказывать историю про себя, ее расскажут другие.
Нужно больше технических статей. Работы еще много и нужно делать. Работать с аудиторией в проф. среде.
Слушать ИТ сообщество в отношении вас и рефлексировать. Это все важно и на долго.
П.С. Возможно имеет смысл рассмотреть выкладывание каких то своих внутренних продуктов на ОпенСорс (которые на самые стратегические, но удачные)?
Вам удачи!
@Erwinmal у вас в тексте "Джоэл Шац" превращается со временем в "Джоэл Кац"...
А за статью спасибо! Интересно.
Автор 1 раз в статье и один раз (минимум) в комментах написал JvmBrains.
При этом статья в хабе Java, но про Джаву ни слова (C# & TS), кроме дописывания до кучи в списке других языков пару раз.
При этом какие то статьи по Джаве еще есть.
При этом сравнивает JetBrains и другие IDE для Джавы не сравнивая мега разницу в возможностях...
Выше пишет, что Нода "уж куда производительнее Java".
Складывается впечатление, что автор не сильно знает Джаву. Просто дописал до кучи.
П.С. По самой статье: все что из нее нужно вынести - не нужно быть адептами никаких сект и слепо верить догмам. Нужно выбирать из всех возможностей и парадигм что есть. Выбирать комфортную вам и вашей команде под задачу и ресурсы. И быть гибкими в своем выборе.
Автор явно старается и ищет упорно и активно свой идеал. И он молодец в этом поиске. Видно, что много читает и интересуется. В общем путь идет достойно. Тут вопросов нет.
Но в статье же призывает сменить одну секту на другую как он. Что мне кажется ошибочным. И со временем мне кажется, что он прийдет к тому, что нет идеала ни где, а есть куча мнений как решать задачи. И инструментов. И нужно уметь выбирать. И это он научится на своем пути.
Благодарю за статью.
Можете пояснить по бенчмаркам: что в колонках? Например первая строка - 1 итерация и 45.5 секунд - это что?
Благодарю за то, что не стали со старту хоронить Джаву и хейтить ДжаваСкрипт (как сейчас модно) и попытались провести адекватную аналитику популярности языков. Интересно.
Выскажу свое мнение по феномену Делфи и Бейсику на ТИОБЕ:
Статистики (и слезы) СтекОверфлоу и т.д. показывает, что из-за развития ИИ люди стали меньше искать ответы в интеренете на свои вопросы по кодингу, а больше спрашивать у ИИ. Т.е. стали меньше гуглить. И вроде бы как существенно меньше. Это наверное можно считать фактом.
В тоже самое время можно предположить, что на вопросы к ИИ перешло больше прогеров там, где их язык более новый, легкий, молодежный или хайповый (Раст - мало пробовали, но много хотели). И меньше там, где язык старый/консервативный/хардкорный/тяжелый/...
Или если кратко: студент питонист в первый же день стал использовать ИИ для кодинга и популяризовать, а бывалый мега опытный делфист сразу сказал, что не будет делать этого никогда, но он при этом все так же гуглит.
Так и произошел перекос статистики по некоторым "непопулярным" языкам - их доля подросла. Это гипотеза.
Не соглашусь.
Java написана на C.
Никогда не слышал, что бы проблема была в этом. Вносится много всего хорошего и нового. И если где-то что-то выходит долго, то это не из-за "незнания С", а из-за обратной совместимости и прочих стратегических инициатив. Писать код в данном случае не самое сложное.
C#, JavaScript, Python, ... - они все не сами на себе написаны. И нет у них с этим проблем. И при этом новые модные фичи присутствуют. Но в ЖаваСрипте куча мусора, а в двух других обратная совместимость далека от уровня Джавы. Вот и причина, почему в Джаве фичи появляются позже.
Брайан об этом всем говорил очень много раз. Все в интернете есть.
@semenovsemenov подскажите, а в источнике в задаче про 9 точек был красный квадрат вокруг них? Или это вы добавили?
Спрашиваю, потому что это была сильная подсказка для меня: поскольку не увидел ничего про него в условии, сразу понял что подразумевается выход за рамки. Вот и хочу понять, была ли такая задумка у автора...
За задачи благодарю.
И статистики по промпт-инженерам очень не хватает.
Благодарю за интересный и актуальный материал. Вот только кажись опечатка:
"т.п" скорее всего опечатка или не понятное сокращение.
Полностью согласен с комментом. Тестирование проведено не полно и не прозрачно. Но даже в его камках есть явные косяки:
- В графике "Средний бал на рубль" у вас Таймвеб впереди всех, и чем короче полоса (и это вообще не ТаймВеб) - тем больше переподписывают (шаред проще говоря). Но в выводах вы гасите Таймвеб. Вы ж противоположные выводы делаете тому, что у вас в графиках. Как так?
- Как вы определяете шаред сервера (переподписки по вашему)? Вы этого не описали, но вы якобы за прозрачность. У клауд-ру и яндекса (особенно на однопоточном тесте) явно ж не хотите видеть, что нагрузка на разных серверах перманентно разная и ресурсы отличаются. Но в выводах этого ж нет.
В общем мне кажется нужно вам пересмотреть выводы, описать методику тестирования и инструменты, проанализировать еще раз все, подписать оси графиков и описать методики подсчета, не плодить новые термины и сущности, доработать полноту тестирования (ваши показатели - это капля в море из всех что интересуют).
Не учитывать винт, ИО, сеть, объем и скорость инета, стабильность и интеграции - это профанация, а не тест. Вы возьмите и напишите полезное предложение, которое бы использовало только РАМ и ЦПУ. Что это должно быть?
Плюс очень хороший комментарий выше. Прислушайтесь. Он дело говорит.
И не стоит критиковать обвинять других совсем не разобравшись в теме (так это выглядит).
П.С. Прошу прощения если грубо, но вы тоже как бы навалили на ребят не разобравшись.
В статье есть путаница с барьерами:
Это не верно понято или переведено. Все +/- наоборот. Если кратко: все, что сделано до релиз-лок в одном потоке, будет видно после эквайр-лок в другом потоке. В вашем переводе - наоборот.
Примерно та же проблема. Только тут и в оригинале запутано написано.
Совет автору статьи на будущее:
пишите прямо в статье в конце краткую расшифровку TIOBE как они считают этот рейтинг (они дают полное описание на сайте).
И я бы добавлял именно текстом, а не ссылкой.
Так как по комментариям видно, что многие не знают как он считается и получается путаница и ложные выводы.
У вас в результатах 29% - женский пол. Это скорее всего говорит о перекосе в вашей статистике и подрывает надежность. Цыфра сильно большая. Возможно вторым таким маячком является то, что практически весь экспертный совет женский.
Поэтому довольно большие сомнения по поводу фразы:
В противном случае, если Беларусь нашла ключик к тому, как обеспечить занятость девушек в ИТ до каждого третьего - эта информация стоит больше всех таких отчетов вместе взятых.