[{"data":1,"prerenderedAt":160},["ShallowReactive",2],{"$fBBQ5ulyG5jVWbIBJe3r8F-kTKQKf1scMJiu0B6qzX5k":3,"$f7AVZHmPutZ23_8XKkLbDtEszKCuiY3yPjIDp9eRXGag":5,"$fSWtn-HdxXChyNlXlCUZklsxwM2HoajOQqMUe3Fwfiog":7,"$f3GrXncKgBkLWXugU5zeeYhHQAWOmmp2Qe_blk1z4meM":136},{"data":4},[],{"data":6},[],{"data":8,"meta":132},[9],{"id":10,"documentId":11,"title":12,"seo_title":13,"summary":14,"seo_description":15,"slug":16,"published_date":17,"body":18,"content":19,"createdAt":53,"updatedAt":54,"publishedAt":55,"blogauthor":56,"cover":78,"categories":121},347,"lpkly83282obll49h6bg6idb","Java против Go в 2026: бенчмарк через шесть лет показал другую картину","Java против Go в 2026: бенчмарк микросервисов","Авторы повторили тест Go против Java через шесть лет. При малой нагрузке результаты равны, при высокой Java с Leyden AOT обгоняет Go почти вдвое.","Повтор бенчмарка 2020 года: Go 1.26, JDK 26 и Leyden AOT на Helidon SE. При 192 воркерах Go даёт около 59 тыс. rps, Java с Leyden — около 99 тыс.","java-protiv-go-v-2026-benchmark-cherez-shest-let-pokazal-druguyu","2026-06-25","Шесть лет назад я и Питер Наги задали вопрос, который был достаточно простым, чтобы быть забавным, и достаточно занудным, чтобы быть полезным: [могут ли микросервисы на Java быть такими же быстрыми, как микросервисы на Go](https:\u002F\u002Fmedium.com\u002Fhelidon\u002Fcan-java-microservices-be-as-fast-as-go-5ceb9a45d673)? Речь не шла о войне языков — такие споры обычно субъективны, а хуже того, отбивают желание разбираться дальше. Практический вопрос был куда у́же: если взять небольшой HTTP-сервис, аккуратно реализовать его на Go и на Java и запустить на одном железе, окажутся ли результаты в одном диапазоне производительности?\n\nВ 2020 году ответ был «да» — для небольшой нагрузки. Тогда я заметил закономерность, которую хотел проверить снова: Java становилась интереснее по мере роста нагрузки и мощности машины. Поэтому вопрос 2026 года не «проиграл ли Go?» и не «решила ли Java все свои проблемы?». Вопрос звучит иначе: для этого сервиса, на этой машине, с текущими рантаймами — что происходит при росте нагрузки и уровня конкурентности?\n\nРепозиторий с материалами к статье: [markxnelson\u002Fgo-java-go-2026](https:\u002F\u002Fgithub.com\u002Fmarkxnelson\u002Fgo-java-go-2026). В нём код сервисов, скрипты бенчмарков, исходные результаты, сводные таблицы и скрипт построения графиков.\n\n\u003Ch3 id=\"ishodnye-usloviya\">Исходные условия\u003C\u002Fh3>\n\nДля этого прогона использовались:\n\n- Go 1.26.3\n- Oracle JDK 26.0.1\n- Helidon SE 4.4.1\n- Linux на x86_64\n- Intel Xeon W-11855M, 6 ядер \u002F 12 потоков\n- 128 ГиБ RAM\n\nGo-сервис использует стандартный `net\u002Fhttp`-сервер из стандартной библиотеки. Без фреймворка, без middleware-стека.\n\nJava-сервис использует Helidon SE WebServer. Helidon 4 обрабатывает запросы через virtual threads, и health-эндпоинт подтвердил, что обработка запросов действительно шла на virtual threads.\n\nДля Java-стороны измерялись два варианта рантайма:\n\n- Oracle JDK JVM\n- Oracle JDK с AOT-кэшем Leyden\n\nЭтого достаточно для данного прогона. Это удерживает статью в фокусе вопроса, который я на самом деле измерял: компактный Go-сервис против компактного Java-сервиса, оба работают последовательно на одной локальной машине.\n\n> Если вдруг решите повторить эксперимент из статьи, то удобнее всего это сделать в OpenIDE. В [OpenIDE](https:\u002F\u002Fopenide.ru\u002F) реализована первоклассная поддержка Java, Go и других самых популярных языков программирования. А поддержка Docker и 300+ плагинов в [маркетплейсе](https:\u002F\u002Fmarketplace.openide.ru\u002F) доступны абсолютно бесплатно.\n\n![]({{strapiUrl}}\u002Fuploads\u002F76d30ffb4795d00f34a6ddce023a7d73_85af3a2dbd.webp)\n\n\u003Ch3 id=\"servis\">Сервис\u003C\u002Fh3>\n\nОба сервиса экспоузят одинаковые эндпоинты:\n\n```\nGET \u002Fhealth  \nGET \u002Fready  \nGET \u002Fapi\u002Fstrings\u002F{value}  \nGET \u002Fapi\u002Fgenerated\u002F{size}\n```\n\nЭндпоинт `strings` полезен для простых функциональных проверок. Эндпоинт `generated` — тот, который использовался в матрице бенчмарка.\n\nЭто различие важно.\n\nВ одном из ранних прогонов я тестировал 2 КБ входных данных, передавая 2-килобайтную строку прямо в URL-пути. Это в основном показало, как каждый роутер обрабатывает странный path-параметр. Возможно, интересно, но не то, что я хотел измерить. В финальном полном прогоне используется `\u002Fapi\u002Fgenerated\u002F{size}`, поэтому URL остаётся коротким, а нужный размер входных данных генерируется внутри обработчика.\n\nКаждый запрос выполняет одинаковый небольшой объём работы:\n\n- перевод входных данных в верхний регистр\n- перевод входных данных в нижний регистр\n- разворот строки\n- вычисление CRC32-хэша\n- повторение дополнительной CRC-работы согласно `WORK_FACTOR`\n- возврат JSON с результатом и метаданными рантайма\n\nДля бенчмарка `WORK_FACTOR=10`. Логирование запросов было отключено.\n\nЭто всё ещё небольшой синтетический сервис. Не корзина покупок, не антифрод-система и не платёжный API. У него нет базы данных, TLS, очереди, парсера JSON на входе и внешних зависимостей. Это сделано намеренно: цель — сделать горячий путь достаточно маленьким, чтобы было видно поведение рантайма и сервера.\n\n\u003Ch3 id=\"konfiguracziya-benchmarka\">Конфигурация бенчмарка\u003C\u002Fh3>\n\n> Позвольте мне в этой статье использовать термин «бенчмарк» немного вольно.\n\nРаннер бенчмарка запускает один сервис, прогоняет полную матрицу, останавливает его, затем запускает следующий сервис. Go и Java не работают одновременно, поэтому они не конкурируют друг с другом за CPU или память.\n\nВ прогоне использовались следующие параметры:\n\n```bash\npayload sizes:      7, 128, 2048, 8192 bytes  \nconcurrency levels: 1, 6, 12, 24, 48, 96, 192  \nrepeats per cell:   2  \nwarmup per cell:    2 seconds  \nmeasurement window: 5 seconds  \nwork factor:        10\n```\n\nНастройки рантайма были заданы явно:\n\n```bash\nGo:  \n  GOMAXPROCS=12  \n  GOMEMLIMIT=off  \n\nJava JVM variants:  \n  -XX:ActiveProcessorCount=12  \n  -XX:MaxRAMPercentage=75  \n\nWith Leyden:  \n  -XX:+UnlockDiagnosticVMOptions  \n  -XX:-AOTRecordTraining  \n  -XX:-AOTReplayTraining\n```\n\nОбъединённый набор результатов, использованный в статье, лежит здесь:\n\n```\nresults\u002Fsequential_generated_leyden_feedback_full_20260608_0700432\u002F\n```\n\nВ нём — исходная сводная таблица по ячейкам, таблица пиковой пропускной способности, сводная таблица для графиков и таблица конфигурации рантайма.\n\n\u003Ch3 id=\"malenkaya-nastrojka-kotoraya-izmenila-rezultat-java\">Маленькая настройка, которая изменила результат Java\u003C\u002Fh3>\n\nПеред основным прогоном бенчмарка я наткнулся на странный результат.\n\nСервис на Helidon выглядел нормально для маленьких ответов, но при более крупных сгенерированных ответах появлялся подозрительный нижний предел задержки около 44–48 мс — когда Go-драйвер нагрузки повторно использовал персистентные HTTP\u002F1.1-соединения. Обычный запрос через `curl` после прогрева такого поведения не показывал. Это было больше похоже на поведение пакетов, чем на проблему в коде приложения.\n\nРешение было таким:\n\n```java\nWebServer server = WebServer.builder()  \n        .port(port)  \n        .connectionOptions(socket -> socket.tcpNoDelay(true))  \n        .routing(routing -> routing  \n                .get(\"\u002Fhealth\", (req, res) -> health(res))  \n                .get(\"\u002Fready\", (req, res) -> ready(res))  \n                .get(\"\u002Fapi\u002Fstrings\u002F{value}\", (req, res) -> strings(req, res, logRequests, workFactor))  \n                .get(\"\u002Fapi\u002Fgenerated\u002F{size}\", (req, res) -> generated(req, res, logRequests, workFactor)))  \n        .build()  \n        .start();\n```\n\nПосле включения `tcpNoDelay(true)` кейс с 2 КБ и персистентным соединением перешёл из категории «явно сломанный бенчмарк» в категорию «нормальный сервер». Именно поэтому такие тесты стоит прогонять перед тем, как писать статью: одна пропущенная настройка способна превратиться в уверенный, но неверный вывод.\n\nОба сервиса также явно выставляли `Content-Length` для JSON-ответов известного размера.\n\n\u003Ch3 id=\"chto-poluchilos\">Что получилось\u003C\u002Fh3>\n\nКороткая версия: для этого сервиса, на этой машине, Java не была просто «не хуже Go». Как только тест выходил за пределы самого маленького случая, реализация на Java часто масштабировалась лучше.\n\nВ прогоне раннер использовал 10-секундный прогрев сервиса после его запуска, плюс 10-секундный прогрев перед каждой измеряемой ячейкой. Также прогонялся Leyden-replay с диагностическими опциями, отключающими запись и replay-тренировку во время измерения.\n\nНа самом маленьком сгенерированном payload все три варианта были в одном диапазоне при низкой конкурентности. С одним воркером и payload в 7 байт Go достиг около 3 200 запросов в секунду. Обычный Oracle JDK — около 2 722 запросов в секунду, а Leyden AOT — около 3 561.\n\nИменно такой результат люди обычно запоминают из старых споров Java против Go: Go стартует быстро, код компактный, и при низкой конкурентности всё выглядит прекрасно.\n\nНо картина менялась с ростом конкурентности.\n\nПри 192 одновременных воркерах и том же payload в 7 байт Go достиг около 59 173 запросов в секунду. Обычный Oracle JDK — около 74 044. Leyden AOT — около 99 099.\n\nНа 128 байтах Java-варианты вышли вперёд при более высокой конкурентности. При 192 воркерах Go достиг около 40 928 запросов в секунду, обычный Oracle JDK — около 62 433, Leyden AOT — около 91 124.\n\nНа 2 КБ разрыв стал больше. Пик Go — около 16 971 запроса в секунду. Пик обычного Oracle JDK — около 39 532, Leyden AOT — около 41 604.\n\nНа 8 КБ оба варианта Java заметно опережали Go в этом локальном прогоне. Пик Go — около 6 815 запросов в секунду. Пик обычного Oracle JDK — около 15 025, Leyden AOT — около 15 493.\n\nТаблица пиковой пропускной способности из этого прогона выглядит так:\u003Cbr>\n\n![]({{strapiUrl}}\u002Fuploads\u002F4b0ee8ad8c235c3952db4a96ef1eaac8_e54a3497f3.webp)\n\nДанные с высокой конкурентностью, на которых строится основной вывод статьи:\n\n![]({{strapiUrl}}\u002Fuploads\u002Ff99b023cf16430b661c2f577c9c7f5d8_b5c683b521.webp)\n\n![]({{strapiUrl}}\u002Fuploads\u002Ff20c6049f5848f8c274e1a4eec1d248e_dd65c6e2a7.webp)\n\n![]({{strapiUrl}}\u002Fuploads\u002F1258f66138c8ab933a00fefec0754e18_7e7004483a.webp)\n\n![]({{strapiUrl}}\u002Fuploads\u002F4672ed278212114de42e30933d5469fa_18be7a1f6c.webp)\n\nЭто и есть интересная версия истории: кривая.\n\nДля самого маленького кейса сервисы находятся в одном диапазоне при низкой конкурентности, но Leyden AOT отрывается на высоком конце конкурентности. По мере роста сгенерированного payload преимущество Java проявляется раньше и сильнее.\n\nЭто не значит «Java быстрее Go». Это значит, что данная реализация на Java, на этом JDK, с обработкой запросов через virtual threads в Helidon и правильной настройкой сокета, масштабировалась лучше, чем данная реализация на Go в этой конкретной локальной среде.\n\nВ этом предложении много существительных. И все они нужны.\n\n\u003Ch3 id=\"chto-dal-leyden-aot\">Что дал Leyden AOT\u003C\u002Fh3>\n\nLeyden AOT не просто ускорил каждую конфигурацию запуска — но с отключёнными опциями replay-тренировки во время измерения он существенно изменил итоговый результат.\n\nУ него была лучшая пиковая пропускная способность для каждого payload в этом прогоне. На 7 байтах пик Leyden составил около 99 099 запросов в секунду при конкурентности 192, с p95 около 6,0 мс и p99 около 9,1 мс. На 128 байтах пик — около 91 124. На 2 КБ — около 41 604. На 8 КБ — около 15 493.\n\nЭто не значит, что Leyden выигрывал постоянно. Leyden AOT показал наивысшую пропускную способность в 20 из 28 вариантах payload\u002Fконкурентность, а обычный Oracle JDK JVM выиграл оставшиеся 8. Go не выиграл ни в одной из комбинаций в финальной матрице, хотя держался близко на самых маленьких кейсах с низкой конкурентностью. Общая картина пиковой пропускной способности сместилась: Leyden AOT оказался вариантом рантайма с наивысшим пиком для каждого payload в этой матрице.\n\nЭто не разочаровывает — это полезно. Leyden AOT не магический переключатель «сделать результаты бенчмарка лучше». Он меняет поведение запуска, прогрева и рантайма так, что это нужно измерять применительно к конкретной нагрузке, которая вас интересует.\n\nЧестный итог для этой статьи такой:\n\n> Leyden AOT оказался сильнейшим в разрезе пиковой пропускной способности после того, как прогон измерения аккуратнее отделил прогрев и отключил запись\u002Freplay-тренировку Leyden во время replay. Запуск и footprint всё ещё заслуживают отдельного рассмотрения.\n\n\u003Ch3 id=\"chto-znachat-eti-rezultaty\">Что значат эти результаты\u003C\u002Fh3>\n\nСтарый простой аргумент звучал так: Go — очевидный выбор для маленьких сетевых сервисов, потому что Java слишком тяжёлая.\n\nЭтот аргумент разбивается о результаты данной статьи.\n\nGo остаётся прекрасным выбором для маленьких сервисов. Реализация компактна. Тулчейн прост. Стандартный HTTP-сервер вполне способен. История с деплоем единым бинарником всё ещё очень привлекательна.\n\nСовременная Java тоже отлично подходит для маленьких сервисов, и у неё совсем другой набор сильных сторон. У JVM зрелый оптимизатор, богатые инструменты наблюдаемости, отличная инженерия GC и теперь массовая модель virtual threads, которая делает блокирующий серверный код заметно дешевле, чем раньше.\n\nHelidon SE удерживает Java-сторону достаточно компактной, чтобы это сравнение не превращалось в «минимальный Go против огромного Java-фреймворка». Это компактный Java-сервис на компактном Java-сервере.\n\nЭто не значит, что я взял бы эти цифры и сделал на их основе общекорпоративную языковую политику. Пожалуйста, не делайте так. Именно так статьи с бенчмарками превращаются в офисный фольклор, а офисный фольклор — это место, куда нюансы уходят на тихую пенсию.\n\nПрактический вывод из этой статьи такой:\n\n> Язык имеет значение, но рантайм, фреймворк, форма железа, прогрев, логирование, настройки сокета, упаковка и дизайн измерения часто значат больше, чем наши лозунги.\n\n\u003Ch3 id=\"chto-ya-izmeril-by-dalshe\">Что я измерил бы дальше\u003C\u002Fh3>\n\nПропускная способность — лишь часть истории.\n\nСледующий проход должен добавить:\n\n- время запуска\n- использование RSS и heap\n- утилизацию CPU\n- GC-логи\n- Java Flight Recorder\n- async-profiler\n- более длинные прогоны\n- больше повторов на ячейку\n- изолированный хост для генератора нагрузки\n- лимиты контейнера\n- TLS\n- логирование запросов включённым и выключенным\n- Spring Boot\n- хотя бы одну настоящую зависимость, например вызов базы данных\n\nЯ бы также оставил урок с `tcpNoDelay` в чек-листе бенчмарка. Это не эффектно, но и быть неправым на 40 миллисекунд — тоже не эффектно.\n\n\u003Ch3 id=\"kak-povtorit-etot-progon\">Как повторить этот прогон\u003C\u002Fh3>\n\nСобрать Java-сервис:\n\n```bash\ncd helidon-service  \nJAVA_HOME=\u002Fhome\u002Fmark\u002Fjdk-26.0.1 \\  \nPATH=\u002Fhome\u002Fmark\u002Fjdk-26.0.1\u002Fbin:\u002Fhome\u002Fmark\u002Fapache-maven-3.9.12\u002Fbin:$PATH \\  \nmvn -B -DskipTests package\n```\n\nЗапустить последовательную матрицу:\n\n```bash\nRESULTS_DIR=\u002Fhome\u002Fmark\u002Fredstack\u002Fgo-java-go-2026\u002Fresults\u002Fsequential_generated_$(date +%Y%m%d_%H%M%S) \\  \nGO_PORT=25081 \\  \nJAVA_PORT=25082 \\  \nCONCURRENCY_LEVELS=\"1 6 12 24 48 96 192\" \\  \nPAYLOAD_SIZES=\"7 128 2048 8192\" \\  \nREPEATS=2 \\  \nDURATION=5s \\  \nWARMUP_DURATION=2s \\  \nJAVA_VARIANTS=\"oracle-jdk-jvm oracle-jdk-leyden-aot\" \\  \nWORK_FACTOR=10 \\  \nENDPOINT_MODE=generated \\  \nscripts\u002Frun-sequential-matrix.sh\n```\n\nРаннер автоматически записывает исходные и сводные таблицы.\n\n\u003Ch3 id=\"v-chyom-ya-vsyo-eshhyo-uveren\">В чём я всё ещё уверен\u003C\u002Fh3>\n\nОригинальная статья не закрыла этот вопрос навсегда. Она и не должна была.\n\nПроизводительность — это не только свойство языка.\n\nЭто также свойство:\n\n- формы железа\n- версии рантайма\n- выбора фреймворка\n- прогрева\n- логирования\n- сериализации\n- настроек сокета\n- лимитов контейнера\n- поведения GC\n- дизайна драйвера нагрузки\n- продолжительности измерения\n- «шумных соседей»\n- частей сервиса, которые не входят в ваш бенчмарк\n\nЭто было верно в 2020-м и остаётся верным в 2026-м.\n\nТак могут ли микросервисы на Java быть такими же быстрыми, как на Go?\n\nДля этого сервиса, на этой машине, с этими версиями — да. И по мере роста payload и конкурентности реализация на Java часто оказывалась быстрее.\n\nПолезный следующий вопрос «с какой формой рантайма вы хотите оперировать, наблюдать, тюнить, деплоить и жить в продакшене?». Он даёт вам что измерить, что улучшить и, в удачный день, что-то, в чём стоит поменять мнение.\n\n![]({{strapiUrl}}\u002Fuploads\u002Fc56b26087a188121b23a62999c07d439_b386c8935c.webp)\n\nУже сейчас [OpenIDE](https:\u002F\u002Fopenide.ru\u002F) позволяет разрабатывать проекты на Java, Spring, Python, Go, PHP, JavaScript и TypeScript! А поддержка Docker и 300+ плагинов доступны абсолютно бесплатно в [маркетплейсе](https:\u002F\u002Fmarketplace.openide.ru\u002F). Пробуйте российскую IDE в деле и подписывайтесь на нас в [Telegram](https:\u002F\u002Ft.me\u002Fopenide_official) или [Max](https:\u002F\u002Fmax.ru\u002Fopenide), чтобы не пропустить свежие обновления и полезные материалы.\n\n---\n\n_Впервые опубликовано на [Хабре](https:\u002F\u002Fhabr.com\u002Fru\u002Fcompanies\u002Fhaulmont\u002Farticles\u002F1051930\u002F)._\n",[20],{"title":21,"links":22},"Содержание",[23,26,29,32,35,38,41,44,47,50],{"label":24,"href":25},"Исходные условия","#ishodnye-usloviya",{"label":27,"href":28},"Сервис","#servis",{"label":30,"href":31},"Конфигурация бенчмарка","#konfiguracziya-benchmarka",{"label":33,"href":34},"Маленькая настройка, которая изменила результат Java","#malenkaya-nastrojka-kotoraya-izmenila-rezultat-java",{"label":36,"href":37},"Что получилось","#chto-poluchilos",{"label":39,"href":40},"Что дал Leyden AOT","#chto-dal-leyden-aot",{"label":42,"href":43},"Что значат эти результаты","#chto-znachat-eti-rezultaty",{"label":45,"href":46},"Что я измерил бы дальше","#chto-ya-izmeril-by-dalshe",{"label":48,"href":49},"Как повторить этот прогон","#kak-povtorit-etot-progon",{"label":51,"href":52},"В чём я всё ещё уверен","#v-chyom-ya-vsyo-eshhyo-uveren","2026-11-12T11:25:23.140Z","2026-11-13T11:49:18.604Z","2026-11-13T11:49:18.667Z",{"id":57,"documentId":58,"firstname":59,"lastname":60,"createdAt":61,"updatedAt":62,"publishedAt":63,"slug":64,"photo":65},40,"yuewij1jc3qoxmkvsh2mpeny","Георгий","Власов","2026-02-17T11:40:25.168Z","2026-11-13T11:49:25.324Z","2026-11-13T11:49:25.371Z","georgij-vlasov",{"id":66,"documentId":67,"name":68,"alternativeText":69,"caption":69,"width":70,"height":70,"formats":69,"hash":71,"ext":72,"mime":73,"size":74,"url":75,"previewUrl":69,"provider":76,"provider_metadata":69,"createdAt":77,"updatedAt":77,"publishedAt":77,"focalPoint":69},1359,"jt1gpp4kqcyzwuwfhzj1c1vc","Gosha_ab88bd0ec5.webp",null,96,"Gosha_ab88bd0ec5_972867885d",".webp","image\u002Fwebp",2.14,"\u002Fuploads\u002FGosha_ab88bd0ec5_972867885d.webp","local","2026-11-13T11:47:15.450Z",{"id":79,"documentId":80,"name":81,"alternativeText":69,"caption":69,"width":82,"height":83,"formats":84,"hash":117,"ext":72,"mime":73,"size":118,"url":119,"previewUrl":69,"provider":76,"provider_metadata":69,"createdAt":120,"updatedAt":120,"publishedAt":120,"focalPoint":69},1211,"ar6x5d1n7nbb3052rp6vg47d","cover-java-protiv-go-v-2026-benchmark-cherez-shest-let-pokazal-druguyu.webp",1672,941,{"thumbnail":85,"large":93,"medium":101,"small":109},{"name":86,"hash":87,"ext":72,"mime":73,"path":69,"width":88,"height":89,"size":90,"sizeInBytes":91,"url":92},"thumbnail_cover-java-protiv-go-v-2026-benchmark-cherez-shest-let-pokazal-druguyu.webp","thumbnail_cover_java_protiv_go_v_2026_benchmark_cherez_shest_let_pokazal_druguyu_58fc57cc86",245,138,4.72,4724,"\u002Fuploads\u002Fthumbnail_cover_java_protiv_go_v_2026_benchmark_cherez_shest_let_pokazal_druguyu_58fc57cc86.webp",{"name":94,"hash":95,"ext":72,"mime":73,"path":69,"width":96,"height":97,"size":98,"sizeInBytes":99,"url":100},"large_cover-java-protiv-go-v-2026-benchmark-cherez-shest-let-pokazal-druguyu.webp","large_cover_java_protiv_go_v_2026_benchmark_cherez_shest_let_pokazal_druguyu_58fc57cc86",1000,563,23.81,23812,"\u002Fuploads\u002Flarge_cover_java_protiv_go_v_2026_benchmark_cherez_shest_let_pokazal_druguyu_58fc57cc86.webp",{"name":102,"hash":103,"ext":72,"mime":73,"path":69,"width":104,"height":105,"size":106,"sizeInBytes":107,"url":108},"medium_cover-java-protiv-go-v-2026-benchmark-cherez-shest-let-pokazal-druguyu.webp","medium_cover_java_protiv_go_v_2026_benchmark_cherez_shest_let_pokazal_druguyu_58fc57cc86",750,422,16.84,16842,"\u002Fuploads\u002Fmedium_cover_java_protiv_go_v_2026_benchmark_cherez_shest_let_pokazal_druguyu_58fc57cc86.webp",{"name":110,"hash":111,"ext":72,"mime":73,"path":69,"width":112,"height":113,"size":114,"sizeInBytes":115,"url":116},"small_cover-java-protiv-go-v-2026-benchmark-cherez-shest-let-pokazal-druguyu.webp","small_cover_java_protiv_go_v_2026_benchmark_cherez_shest_let_pokazal_druguyu_58fc57cc86",500,281,10.43,10434,"\u002Fuploads\u002Fsmall_cover_java_protiv_go_v_2026_benchmark_cherez_shest_let_pokazal_druguyu_58fc57cc86.webp","cover_java_protiv_go_v_2026_benchmark_cherez_shest_let_pokazal_druguyu_58fc57cc86",60.46,"\u002Fuploads\u002Fcover_java_protiv_go_v_2026_benchmark_cherez_shest_let_pokazal_druguyu_58fc57cc86.webp","2026-11-13T11:43:51.330Z",[122],{"id":123,"documentId":124,"title":125,"published":126,"weight":127,"slug":128,"createdAt":129,"updatedAt":130,"publishedAt":131,"color":69},6,"lky7cgb1xah86knhb7cblhsg","Мнения",true,5,"opinions","2026-11-12T11:20:31.505Z","2026-11-12T11:22:44.480Z","2026-11-12T11:22:44.467Z",{"pagination":133},{"page":134,"pageSize":135,"pageCount":134,"total":134},1,25,{"data":137,"meta":156},[138,144,150],{"published_date":139,"id":140,"documentId":141,"title":142,"slug":143},"2026-10-19",343,"rqn2rjpmxlg9cf0v7h7ibddq","Меня заставили использовать OpenSpec","menya-zastavili-ispolzovat-openspec",{"published_date":145,"id":146,"documentId":147,"title":148,"slug":149},"2026-09-29",349,"m4ub2qhs589ts46l90x2sz1y","Режим планирования мёртв","rezhim-planirovaniya-myortv",{"published_date":151,"id":152,"documentId":153,"title":154,"slug":155},"2026-07-03",315,"ha8a4ct3vzhnoeasnbsuwv7a","JetBrains IDE: будущее не за горами","jetbrains-ide-budushhee-ne-za-gorami",{"pagination":157},{"page":134,"pageSize":158,"pageCount":158,"total":159},3,7,1794584600248]