Вышло очередное обновление индекса языков программирование TIOBE. Меня прикалывает, как создатели TIOBE продолжают срать себе в штаны, делая вид, что все в порядке👌

"У нас Ada обогнал PHP и Kotlin, а Visual Basic будет попизже Golang. Perl попал в 10ку, а Ruby, даже в 20ке не видно. Typescript мы поместили на 35е место. Вас что-то смущает?.. Нам поебать!" - так прокомментировал свежие данные рейтинга глава TIOBE Вротстислав Хуепутолов.

Ну а если серьезно, когда видишь в одном рейтинге matlab и php, то сразу же вопрос возникает, а для кого это составляется вообще? в чем польза?

The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system.

Я считаю, что индекс можно использовать для проверки того, на сколько челики в TIOBE ебнулись в своих метриках, который нахер никому кроме них самих не нужны. Тупее было бы только составить рейтинг по количеству букв в названии языка. Хотя нет, даже это имело бы больше смысла😡

Единственное, что могло бы оправдать этот рейтинг из жопы, это если бы TIOBE просто бабок занесли. Но мы об этом никогда не узнаем.

У нас наоборот

Че-то в последнее время тяжеловато идет написание постов. Много работы и уходящее лето, когда надо успеть чуток почиллить, - делают свое дело!

Контент план есть, тем много. Темы появляются быстрее, чем успевается о них писать. Но я тот еще писака, поэтому на написание одного поста у меня уходит от 2х часов 😔 Сами понимаете, как с такими таймингами тяжело вписаться в текущую жизнь.

Тем не менее, будем надеяться, что с приходом осени все стабилизируется. На улице будет нечего делать, и придется заниматься эскопизмом в канале 😊

Но чтобы перерывы в постах о программировании не были такими уж длинными, я воспользуюсь читерной рубрикой "подписчики набрасывают на вентилятор".

Мне тут скинули старую, но презабавнейшую статью What is {} + {} in JavaScript?. В статье автор задается вопросом, а что будет при выполнении следующих операций в js

[]+{}
[]+[]
{}+[]
{}+{}

Спойлер: будут приколы.

Для []+{} ответ '[object Object]'. []+[] - это ''. И наконец, два моих "любимых": {} + [] дает 0, а {} + {} вернет NaN.

Для "любимых" объяснение такое, что первый {} js интерпретирует как пустой блок кода 🤡, а дальше уже приводит второй аргумент к числу в соответствии с действием унарного оператора +. Ну не красота ли! Об остальных можно прочесть в статье.

Может показаться, что всем результатам есть логичное объяснение. И в статье это объяснение дается. Но по факту, это просто торчащие уши плохого дизайна js, с которым приходится мириться и по сей день, используя костыли в виде ts. Запоминать такое поведение категорически противопоказанно для сохранения рассудка! 👆

А если на собеседованиях вас спрашивают про подобные особенности, то можете смело проваливать это интервью, потому что тех. лид долбаеб, и делать в такой компании нечего. Ну либо можете зазубрить кучу таких кейсов и задоминировать! Но будьте осторожны, ведь тогда можно самому ебнуться наглухо и стать вонючим душнилой🤓 Смотрите сами короче

Лайфхацк для любимых подпищеков♥️

Кто-то решил покреативить со шрифтами, а я минуту стоял и не мог понять, что тут написано🥲

Прикол. У меня прям сейчас таск по обновлению пакетов. Обновляю-обновляю, и вдруг перестает все собираться. И ошибка такая интересная

npm error 404 Not Found - GET https://registry.npmjs.org/debug/-/debug-4.4.2.tgz - Not found

Захожу на гитхаб, а тут issue час назад была создана Version 4.4.2 published to npm is compromised.

С одной стороны, как бы круто что в npm так быстро сработали. С другой стороны, че то я себя не очень безопасно щас почувствовал, даже несмотря на то, что этой версии уже нет в npm. Какое-то время эта херабора запускалась у меня локально, пусть и в контейнере.

Вообщем в мире js все как всегда 😔

А я отвечу постом на комментарий выше про то, что это касается не только js.

Да, безусловно, такое может произойти в любой экосистеме, не только в js. Везде есть уязвимости!

Но js отличает то, что здесь какое-то неадекватное количество peer dependencies. Авторы пакетов на каждый чих используют другой сторонний пакет. Мемный пакет is-odd все еще с нами, и у него ебейшее количество скачиваний в неделю. А истории про то, что папка node_modules занимает гигабайты - это вообще-то норма, а не исключение.

Именно потому что в папке node_modules лежат миллиарды пакетов, вероятность получить уязвимость кратно возрастает!

У меня 3 экосистемы на поддержке: js, php и python. И раз в полгода мне надо обновлять пакеты для аудита. И я хочу сказать, что если у вас более менее серьезный проект, то довести количество уязвимостей до 0 в js нереально. Мне ни разу не удавалось это даже для внутренних простеньких проектов. В то же время для php и python отсутствие уязвимостей - это скорее норма.

Конкретно в случае с пакетом debug это зависимость express

+-- debug@4.4.1
`-- express@5.1.0
  +-- body-parser@2.2.0
  | `-- debug@4.4.1 deduped
  +-- debug@4.4.1 deduped
  +-- finalhandler@2.1.0
  | `-- debug@4.4.1 deduped
  +-- router@2.2.0
  | `-- debug@4.4.1 deduped
  `-- send@1.2.0
    `-- debug@4.4.1 deduped

А самое смешное то, что я вот откатил этот злоебучий пакет до предыдущей версии, а в нем 7 критических уязвимостей 🤡

Поэтому нет, я не соглашусь, что оно везде все так. В js количество уже перетекло в качество. Точнее в его отсутствие.

Я уже 5 лет плотничком работаю с Doctrine ORM. Работа у меня разнообразная. Пишем мы и новый код, с новыми таблицами в бд. Но также имеется большая легаси база говна данных, на которую мы старательно натягиваем Doctrine. Короче, всякое повидал за эти годы, в том числе даже поконтрибьютил в саму Doctrine.

Несмотря на то, что в целом впечатления от Doctrine благостное (по сравнению с тем же Eloquent хех), эта ORM может вставить палки в колеса. Как и любой инструмент. Об этом я написал свой очередной лонгрид Как Doctrine ORM ломает вашу архитектуру.

Я постарался рассказать об основных принципах работы этой ORM так, чтоб было понятно даже тем, кто никогда не работал с Doctrine. А по скольку Doctrine - это классический пример Data Mapper, все эти принципы могут быть применены к другим Data Mapper ORM, например Hibernate и SQLAlchemy.

А от тех, кто тоже успел поработать с Doctrine, жду накидывания на меня какашек о том, что я просто все неправильно понял 😘

Говорят, чем больше у тебя пхп-слоников, тем хуже пишешь на голэнг) сегодня у меня +1🥳

Все еще работаем над llm-based FastAPI сервисом. Создал сам себе issue: нужна возможность периодически выполнять какие-то задачи, в народе именуемых cronjobами. Поскольку fastapi - это современный веб фреймворк тупо роутер запросов, такой функционал нам не завезли из коробки. Но задача довольно классическая, проблем быть не должно.

Кроме того, бох девопс дал нам кубернетис с его встроенными CronJobs. Поэтому изечно можем раз в минуту дергать какой-то сервис по ендпоинту /run-cron. Нам лишь нужно
* хранить и отслеживать статус джоб
* парсить cronexpr и решать, какие джобы щас запустить
* определять, если джоба зависла и сбрасывать статус
Это такой bare minimum, который бы меня устроил.

Гугл и ллмки выдали мне решение: билиотека apscheduler. Куча звезд на гитхабе, делает все то, что описано выше и даже больше. Короче, царский подгодон.

Начал интегрироваться и вместо cronjobов сделал blowjobы. Потому что этот apscheduler сам себе экзекутор задач. Он ни в какую не хотел привязываться к внешнему тригеру, потому что он сам знает, когда ему запускать задачи. А мне зачем экзекутор джобов в каждом поде приложения??

Потратив целый день на попытки скрестить жопу с ужом питоном, я понял, что за этот день я бы уже написал свое решение. Единственное, что мне нужно, это либа для парсинга cronexpr. Ну уж с этим то проблем быть не должно? Не должно ведь, python?

Самая популярная либа для парсинга cron экспрешнов называется croniter. И она официально не поддерживается с конца 2024 года 🤡 На стэковерфлоу в связи с этим советуют воспользоваться новой либой cron-converter, у которой невероятные 46 звезд на гитхабе (кстати, поставил 47ю) 🤩 Ну тут особо выбора нет, ибо писать парсер с нуля - это задача для пет проектов.

И вот получается, что в 2к25 я все еще занимаюсь тем, что было сделано во многих фреймворках и цмсках в нулевые. Странно это как-то... Может я неправильно это готовлю.

Кто-то может подумать, что я тут опять накидываю на питон. На самом деле уже 4 года в проде на Symfony также крутится собственное решение с кронджобами, которое делает все тоже самое. Ибо Scheduler компонент завезли только в версии 6.3. И я его даже не пробовал 😔 Но хотя бы в пхп у либы dragonmantank/cron-expression, которая парсит cron expression, 4.7к звезд, а у питоновсокого croniter 485 🤷 вообще нет уверенности, что кому-то это надо.

Поделитесь, как сами решаете проблему с кроном? сразу ставите celery? запускаете отдельный сервис с тем же кодом, но чисто повыполнять таски? или целиком на кубовых джобах живете?

Итак, настал момент истины. На сколько же php быстрее golang?

И нет, я не ошибся. Дмитрий Кириллов в своем шикарном докладе показал, что php с jit может быть быстрее Си (базового). Это на столько меня вдохновило, что я решил поиграться с этим сам. Пришлось даже виртуалочку для этого арендовать.

Я использовал ту же самую задачу о рюкзаке из доклада. Вот код на golang.

package main

import "fmt"

const w = 700
const h = 700
const l = 700
const target = 1500

func main() {
 ans := 0
 for i := 0; i < w; i++ {
  for j := 0; j < h; j++ {
   for k := 0; k < l; k++ {
    vol := (i + 3) * (j + 4) * (k + 5)
    if vol == target {
     ans += 2
    }
   }
  }
 }
 fmt.Println(ans)
}

Код на пхп взял прям отсюда.

Итак, вот, что нам выдал perf для 10 запусков golang(1.25.2)

0.353181 +- 0.000158 seconds

А вот для php(8.4.13)

0.2895 +- 0.0119 seconds

Таким образом, мы видим, что php реально очень быстр, когда дело касается CPU-bound задач. Ну и конечно, когда вы поприседали с ним, чтоб убрать все ненужные опкоды. Мы получили, что пхп быстрее почти на 20%.

Изначально я тестировал этот код на версии php 8.3. И там результат был таков

0.33962 +- 0.00224

Что конечно все еще быстрее голэнг, но не так впечатляюще. То есть разрабы php действительно хорошо поработали над jit в 8.4!👍

А еще я поставил nodejs и python, раз уж пошла такая пляска. И я вынужден признать, что ребята, которые пилят V8, рил настоящие гении. Для ноды результат получился

0.32645 +- 0.00288

Что медленее php8.4, но быстрее и 8.3 и golang. Но при этом, в отличии от php, мне не нужно было делать ничего специального. Я просто написал

const calc = (w, h, l, target) => {
    let ans = 0;
    for (let i = 0; i < w; i++) {
        for (let j = 0; j < h; j++) {
            for (let k = 0; k < l; k++) {
                const vol = (i + 3) * (j + 4) * (k + 5);
                if (vol === target) {
                    ans += 2;
                }
            }
        }
    }
    return ans;
};

console.log(calc(700, 700, 700, 1500));

и оно уже быстрее голэнг!

Что касается питона (3.12), то тут все выглядит как-то так 😂

25.958 +- 0.235 seconds

Лан, нет смысла сравнивать язык с jit и без jit. Понятно, что это будет избиение младенца.

Поэтому я решил отключить jit в php. Более того, я решил использовать версию кода на пхп без всяких извращений с проверками на out of bound conditions. Таким образом, код стал выглядеть, как обычный код на пыхе. Итого имеем

4.9320 +- 0.0439 seconds

То есть питон более, чем в 5 раз медленее пхп.

А что в итоге? Понятно, что это все синтетика. Понятно, что, когда мы начнем писать бизнес логику, начнем вызывать методы у объектов, начнем массивами всячески оперировать, то картина будет немного другой. Конечно статически типизированный и компилируемый голэнг все таки в другой лиге играет. Особенно в плане потребления памяти.

Но если вдруг перед вами стоит задача, где надо тупо дробить числа, а у вас пхп - не бегите переписывать этот кусок на голэнг, шоб было побыстрее! Лучше вместо создания нового микросервиса посмотрите доклад Дмитрия, охуейте, а затем примените новые знания на практике 👆

P.S. Мечтаю стать Дмитрием, когда вырасту

В догонку к предыдущему посту. Поставил еще bun, pypy (python реализация с jit) и ruby!

Ну что могу сказать. Bun очень удивил! 🤩

0.22418 +- 0.00369 seconds

У ноды, напомню, было 0.32645. Так что это наш новый чемпион!

Окей, я подумал, что может рил влияние запуска самой ноды на столько велико. Ведь я мерию perfом, а он измеряет выполнение команды. Добавил в сам скрипт временные метки. И нихрена подобного. У bun это в среднем около 0.20 секунд. У ноды 0.30 секунд. То есть, и там, и там на запуск и всякое остальное тратится +/- одно и тоже время.

Так шо bun рил топ! 👍

А что там с pypy? А наконец-то все как у людей

0.346620 +- 0.000672

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

Ну и чисто по фану, запустил Ruby (3.2.3).

20.0148 +- 0.0176 seconds

Чуток быстрее питона -- уже хорошо. Ожидаемо.

Рубисты сорри. Я вообще не рубист. Я пытался поставить yjit и у меня он не собрался чет с первого раза. А по скольку "собрать из исходников" -- единственый варик у них в доке, то пошли они нахуй я забил.

Кароче, первый вывод. Если у вас jit, то че то вычислять числами будет плюс-минус одинаково везде. Но только если это не bun. Bun -- мое почтение! 🫡 А если у вас не jit, то пхп вам напихает за обе щеки (привет python и ruby).

Второй вывод: первый вывод -- это вывод из жопы. Не надо воспринимать его серьезно. Мы тут чуток в циклах числа посчитали. Это мягко говоря не все вычислительные задачи. Так шо похер. Все чисто for fun.

И последнее. У пхп с jit просто отвратительный разброс по таймингам

0.2980 seconds
0.2284 seconds
0.3182 seconds
0.2904 seconds
0.2707 seconds
0.3137 seconds
0.2628 seconds
0.2971 seconds
0.2144 seconds
0.2786 seconds

от Bun до nodejs. Нигде больше такого нет, у всех все стабильно с точностью до 2го знака.

You use Mojo. I use Bython. We are not the same.

Любой пхпшник знает, что топовая IDE это джетбрейнсовский phpstorm. Сорри любители Vim с LSP, но это горькая правда🥲 И недавнее исследование от джетбрейнс 🤡 это подтверждает. Кстати, ставьте лоис, если хотите обзор на возможности сторонней lsp (phpactor) для пхп. Или не ставьте. Как хотите, кароч, я все равно сделаю.

Но сегодняшний пост не о восхвалении пхпшторма, а скорее наоборот. Ядром любой IDE я считаю вот эту часть, связанную с lsp и статическим анализом кода. Все остальное - это просто приятные присрачки, без которых жить сложно, но можно. Без стат анализа же ide превращается в обычный блокнот.

Проблема в том, что я уже несколько раз натыкался на баги, связанные с некорректным анализом кода. И тут вы мне скажете "да ты охуел! у всех есть баги!" Но прикол в том, что эти баги не вчера зарепортили люди. И создается впечатление, что никто их не торопится фиксить. Например, как вам вот такой баг из 2023 года. Если вкратце, то в этом коде

$a = ['a'];
$b = ['b'];
$c = [...$a, ...$b];

шторм будет считать, что у $c тип string[][], хотя должно быть string[]. Это в дальнейшнем приводит к false-positive ошибке в редакторе, что очень бесит. И вот в конце 2025го я вынужден использовать array_merge при работе со списками😡

Поэтому я решил проверить свое ощущение и узнать, а как вообще у джетбрейнс обстоит дело с фиксом багов, которые им пользователи приносят. Благо, что у них вполне себе открытые release notes и трекер. В youtrack надо поставить фильтр Subsystem: PHP Inspections, чтоб получить тикеты связанные с анализом пхп. Вот для 2023 года (178 штук), а вот для 2022 (286 штук).

Чекнул релиз ноуты за 2025 год. На момент написания поста, актуальная версия 2025.2.4. Получилось, что в этом году они не исправили ни одной проблемы из 2023 года, исправили 1 тикет из 2021 и 1 тикет из 2022. Это было все в одном релизе 2025.2. И это довольно печально😢

Конечно я не продакт в джетбрейнс, и не мне приоритеты выставлять, чем занять разрабов завтра. Но как минимум мне кажется странным, что почти все тикеты имеют приоритет Normal (процентов 90), либо Nice to have. И только два (тикета, а не процента) имеют приоритет Major. Но, сука, и их никто не торопится фиксить 🤡

Мне странно видеть у всех багов пользователей приоритет Normal. Баги же разные бывают. Некоторые чисто косметические и на них можно забить, а некоторые куда серьезнее. Например, вот этот тикет влияет на возможности рефакторинга. Люди в комментах бампают его, но как-то всем насрать. Проприетарная безысходность...

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

Вот такая осенняя грустняшка сегодня😰

Литералли мой гитхаб

Сегодня жители Санкт-Петербурга могли видеть ярко красное зарево. Это полыхала моя срака после попыток стать pro python девелопером😡

В чем суть. Потребовалось разработать новый сервис. К сожалению его специфика вновь заставила использовать python вместо любимого пхп 😢

Очень часто можно услышать мнение что стандартный пакетный менеджер pip - говно из жопы. Типа он медленный, всратый, не позволяет разделять зависимости на группы, нет лок файла и прочее. Короче говоря, устаревший инструмент. И это не безосновательно.

И вот комьюнити напряглось и родило новый пакетный менеджер uv, который blazingly fast (написан на rust 😍), в котором куча всяких фич, который за тебя готовит виртуальные енвайронменты и прочее. Короче, слышал про него только хорошее.

Подумал, что говорят про него достаточно долго и много, поэтому можно его попробовать затащить в прод. Покурил доку. Вроде бы все выглядит как нормальный пакетный менеджер. Есть pyproject.toml файл, в котором описываются зависимости с требованиями к их версиями, аналог composer.json и package.json. Есть uv.lock, в котором прям точные версии пакетов описываются. Есть команды для установки, удаления, обновления пакетов. Короче, все как мы любим, и все работает реально быстро. Так что же тогда могло так сильно поджарить жепу?

Давайте вспомним, как мы готовим наши проекты для прода. Обычно одним из этапов билда является команда вроде yarn install --frozen-lockfile --production, которая ставит все зависимости из лок файла без development. И вот аналогом такой команды в uv является команда uv sync --frozen --no-dev. Это команда создает venv со всеми зависимостями из лок файла, кроме дев зависимостей.

А дальше вопрос, как запускать наше приложение? Дла этого используется команда uv run. Она сама активирует текущий venv со всеми зависимостями и запустит ваш скрипт. Так, например, рекомендуют запускать uvicorn в докере.

И вот разработчики решили, что будет АХУЕННО крутой идеей при запуске uv run
* проверять, что лок файл соответствует toml, и если нет то обновлять его
* проверять, что venv соответствует лок файлу, и если нет то обновлять venv

Блять, я готов ставить свое сгоревшее очко на то, что когда вы запускаете uv run app.py вы не ожидаете, что у вас че-то будет меняться в лок файле или в venv. Ибо это команда для ЗАПУСКА. Окей, мы поставили все прод зависимости с помощью uv sync --frozen --no-dev, затем выполнили uv run на старте контейнера, и у нас подтянулись все дев зависимости🤡збс! и чтоб этого не случилось, нужно добавлять флаг --no-sync.

И такое "ожидаемое" не только меня сбивает с толку. Считаю, что делать такое было мега тупой идеей. Ибо ни в одном другом пакетном менеджере я не припомню такого поведения. Сук, ты выдай лучше ошибку! Че ты бесиш то! 😡

А так в целом конечно blazingly fast и очень круто 👍

Ну давайте, питонисты, напихайте мне в комментах, что я неправ и команда запуска - отличное место, чтоб обновить venv 😢