Как всегда, это история о политике, крови, грызне и скудоумных менеджерах.
Мне всегда казалось, что C# сильно лучше нашей Java (только LINQ expressions чего стоит — именно expressions, а не применения типа LINQ-to-objects). А в F# (тоже работает на .NET) есть нормальные провайдеры типов и другая функциональщина. И всё это работает чудесно, а не как Haskell, который несколько лет подряд сегфолтился на Windows, и никто это не чинил.
Но всё портит маниакальная борьба Microsoft с конкурентами и из-за этого отсутствие экосистемы вне продуктов Microsoft. Это отсутствие конкуренции и деградация. Какой дурак захочет связываться с технологией, из-за которой тебя может назавтра кинуть создатель этой технологии? Беда, C# нам тоже не подходит.
На всякий случай, «Embrace, Extend, Extinguish» (EEE, «обнять, расширить, уничтожить») — это не забавная фраза и не инструкция к анальному плагу, а реальная антимонопольная стратегия Microsoft по захвату открытых стандартов. Она описана в судебном деле правительства США против Microsoft, 1998–2001.
С Oracle в общем-то так же. Пример: фреймворк изначально назывался Javaslang, но влетел на разбирательство с Oracle из-за использования слова «Java» в своём названии. Из-за чего авторы визуально перевернули название вверх ногами и получился VAVR. И даже красивый слоган придумали: «vavr — turns java™ upside down». Что не отменяет, что Oracle — контора, которую очень сложно любить.
Но есть нюанс — был один раз в истории особый исторический момент, когда сам Oracle нагнули несколько компаний во главе с IBM, и значительный кусок власти у них забрали. И только благодаря этому ивенту Java всё ещё живая и интересная.
История там довольно простая и поучительная.
Наверное, сейчас уже мало кто помнит, но Java сделала контора Sun Microsystems. И дела у неё в последние годы шли не очень. Чтобы как-то починить эти проблемы, они пытались максимально контролировать свою власть над Java. А какому же программисту понравится, что его любимую игрушку контролируют? Это не понравилось целой индустрии.
Так была создана особая свободная и открытая реализация Java под названием Harmony. Не та, которая сейчас у Huawei, HarmonyOS, а другая :) Официально всё это проходило под эгидой Apache Foundation, но бэкалось силами разработки лидеров — например, IBM.
Важная подробность. Sun придумали хитрую систему, как нагнуть сообщество юридическим образом. Они взяли свою тестовую сюиту TCK (Technology Compatibility Kit) — очень крутую, очень нужную, очень важную технически — на самом деле. Взяли и превратили в оружие. Та штука, которая не проходит тесты из неё, не может называться словом Java. Нельзя написать какую-то опенсорсную реализацию Java и не пройти половину тестов — к тебе сразу же придут юристы.
И всё бы хорошо, ну сделай всё по красоте, пройди тесты, получи свой бейджик. Да вот только TCK — это закрытый коммерческий продукт, который Oracle раздаёт только тем, кому посчитает нужным. То есть, конкурировать можно, но только если Oracle разрешит тебе с ними конкурировать. Такие вот рыночные механизмы, понимаете?
Когда Oracle купили Sun, практику терроризировать всех через TCK они не оставили, а даже расширили и углубили.
Возвращаемся к нашим баранам — Harmony как попытке переизобрести Java. Конечно же, Oracle отказалась предоставить Apache Foundation тестовый комплект TCK, что делало Harmony «не джавой» и приводило к куче юридических последствий.
Тем не менее, двигать вперёд Harmony было вполне можно, хоть и сложно. Это вызвало конфликт: основная опенсорсная организация в мире, Apache, вышла из оракловского JCP (Java Community Process), а компании вроде IBM, Red Hat и других поддержали бойкот Oracle, требуя открытости Java.
К счастью, ещё до покупки компанией Oracle, Sun уже провела некоторую работу по превращению Java в опенсорсный проект. В результате появился проект OpenJDK — это то, что люди сейчас подразумевают, когда говорят слово «Java». Он был уже более открытый и с более нормальными лицензиями (внутри GPL, с нюансами).
Когда Oracle пошла на попятную и дала зелёный свет тотальному опенсорсингу OpenJDK, IBM присоединилась к OpenJDK, а Harmony закрыли.
OpenJDK стал эдаким псевдостандартом: его код стал стандартной (и единственной реально работающей после смерти Excelsior Jet) реализацией Java-как-рантайма, а его опенсорсные процессы стали рельсами для дальнейшей разработки Java-как-проекта.
Немного технических подробностей. Eclipse OpenJ9, Azul Zing/Zulu, Amazon Corretto — всё это живые реализации, но это всё упражнения над форком кода OpenJDK со своими фишками. И все эти организации бегают на очень коротком поводке, любая попытка в индивидуальные суперинновации — нарушение стандарта Java — добро пожаловать к юристам.
Замечание для джавистов: после почившего Excelsior, из всех них самая свободная трактовка идеи — это OpenJ9. Это отдельная реализация JVM, исторически происходящая из IBM J9, компактного рантайма, специально созданного для максимально эффективного исполнения на девайсах пониженной мощности. А самая разумная для повседневного применения, особенно вместе со Spring — это Liberica JDK. Про Либерику — это уже некое моё личное мнение, я не стану спорить, если вы найдёте преимущества у кого-то ещё.
В свете общего охлаждения индустрии к Java как технологии, этого вполне хватило. Почему охлаждение? Ну там как бы другие разработчики технологий на месте не сидели и породили множество других рантаймов. Возможно, не настолько крутых, эффективных и удобных — но там можно было не иметь дела с Oracle, и в наше безумное время это уже само по себе фича!
Процесс опенсорсинга был непростым и неприятным. Основной когда-то фреймворк, Java Enterprise Edition, Oracle зажали на 10 лет. TCK для JavaEE отправился в опенсорс в 2017. И по моим ощущениям, это был какой-то поворотный момент, когда Oracle просто перестали считать Java серьёзным бизнесом и спустили всё на тормозах. Настолько вот антиобщественные у них настроения: или это бизнес, или это сообщество, третьего не дано.
Тем не менее, Oracle кошмарить разработчиков не бросила, просто по-другому. Иск между Google и Oracle по поводу использования Java API в Android длился около 11 лет и закончился победой Google.
Вообще всё существование языка Go — это просто работа над ошибками Google про то, как не иметь дело с Oracle. Изначальный Go — это по сути Java без дженериков версии 1.4 (весна 2003 года) с нормальным компилятором в нативный код (в Java появился в 2018 в составе GraalVM, но по сравнению с Go он пока почти всем проигрывает). Как язык программирования, Go всё ещё хуже Java, хотя они пытаются пройти по её пути — например, добавили дженерики и улучшили сборщик мусора. Тем не менее, вообще никакого Go могло бы и не быть, если бы Oracle зачем-то не начала это безумное судебное разбирательство на 10+ лет длиной.
Да, кто-то может сказать, что на самом деле Go — это боль от компиляции C++ и сложность управления зависимостями в больших кодовых базах, а совсем не Oracle. Я не буду спорить про то, что Go появился бы и без проблем с Java. Я поспорю только с тем, что Go в нашей ветке мультивселенной и Go в той ветке, где Java не было — один и тот же язык.
Казалось бы, добро победило? Не совсем. Упаси тебя бог где-то использовать слово Java без согласования. Половина Oracle — это не программисты, а юристы, и ты, вот лично ты — не Google. Ты не сможешь с ними судиться 10+ лет.
Я очень сильно люблю Java, и значительная часть моей жизни была с ней связана. И вся эта грязь очень сильно портит желание людей иметь с этим дело. Есть какой-то момент, когда крови и грызни собирается настолько много, что отмыться от неё очень сложно.
Тем не менее, сейчас Java занимаются крутые, адекватные люди. И, наверное, она придёт к успеху. Будем надеяться.
А вот с Microsoft этого так никогда и не произошло. Нет никакого общественного объединения или коммерческого фронта Войск Света и Добра, которое бы умудрилось взгреть все их тёмные практики. Впрочем, и C# не то чтобы какая-то жизненно важная штука, чтобы всем этим заниматься. Когда Java только появлялась, она была единственной и поэтому жизненно важной, а C# уже нет.
А приводит это к тому, что экосистема C# — с гулькин нос. У тебя есть несколько крутых фреймворков имени Microsoft, несколько известных опенсорсных проектов... и всё. Нет такого, что как в Java или JS/Node ты сидишь и час выбираешь, какую бы библиотеку из сотен использовать, чтобы сложить два числа.
Rust тоже зашкварился о похожие проблемы. В 2023 году черновик их политики вызвал огромное бурление масс. Например, они запрещали использовать слово «Rust» в названиях crates, библиотек, репозиториев, инструментов для Rust, доменов/поддоменов и софта на Rust без лицензии. Бурление масс было настолько сильным, что заставило Rust Foundation отменить это решение.
Но самое главное, что мы из этой истории узнали: в Rust сидят примерно такие же по майндсету чуваки, как в Oracle. Да, они уже научены горьким опытом Oracle и быстрее реагируют на мнение сообщества. Но в голове-то то же самое. Кто знает, что они придумают в следующий раз?
Для меня пока что островком свободы кажутся ECMAScript, also known as JavaScript (слово «JavaScript» принадлежит Oracle, там же слово «Java»!!!!!, поэтому джаваскрипт джаваскриптом называть нельзя. Я уже говорил, что Oracle — контора, которую очень сложно любить?).
Несмотря на доминирование Google/V8 и Apple/JavaScriptCore в деле высокопроизводительного JS, вся остальная экосистема — это огромная Вавилонская башня из проектов настолько разных и никак между собой не связанных, что ты как будто бы глядишь на мир из глаз Доктора Стренджа. И тем не менее, всё это работает, причём — работает вместе! Внутри одного веб-интерфейса или внутри одного бэкенда! На всё это действительно сложно как-то повлиять корпорациям и внедрить туда свой тоталитарный контроль.
Второй островок свободы — это C++. Тут есть два нюанса.
Первый: C++ разрабатывается большими плохими зубастыми компаниями. Но их МНОГО. И они разрабатывают всё это огромным комитетом, куда входят все. Если одна компания из многих начнёт выпендриваться, то её тут же сгрызут. Это чудесно, рынок в действии.
Второй: сама природа современного C++ эклектична. По сути, почти каждый участник сообщества может делать всё, что угодно, хоть в лес, хоть по дрова. И ему ничего за это не будет ни от каких юристов. Это суперважно: чтобы разработать фичу, нужно быть гениальным инженером — и это возможно. Бороться с Oracle и Microsoft в суде — невозможно. Это огромная разница.
А ещё нет какого-то человека, который бы знал «весь C++» и мог придумать идеально совместимую фичу. После чего объявить себя диктатором, который Знает Как Правильно Нужно. Это задаёт здоровый тон анархизма.
Для меня это самое главное. Не знаю, как вам, а для меня наличие диктатуры, какого-то единого Великого Верховного Магистра, который Знает Как Надо — это настолько ужасно и чудовищно, что перекрывает примерно любые другие плюсы. Подчиняться диктатуре можно только если альтернатива — прозябание или смерть. Диктатура противна всему человеческому, а диктаторов совершенно естественно ненавидят.
И всем был бы хорош C++: и крутых фичей у него намного больше, чем в любом из популярных языков (включая C#). И разработка его ведётся круто и демократично. И работает он быстро. НО СИНТАКСИС — ПОЛНЫЙ КОШМАР. До изобретения Perplexity мы даже не могли нормально загуглить программу на C++ — гугл воспринимал это как мешанину из спецсимволов.
И вот какую мысль хочется вкинуть под конец. Мы вступаем в эпоху, в которой люди перестают писать код на Языках Высокого Уровня. Теперь всё за нас пишут роботы.
Роботу, в целом, всё равно, на чём писать. Языки типа Java и C#, основная фича которых была в том, что писать на них было комфортно и удобно, — должны потерять приоритет и уйти в тень, в тот очень небольшой загончик софта, который всё ещё будут писать люди. Банки, медицина, космонавтика — всё это будет на Java. Везде, где торгуют не столько софтом, сколько рисками и страхом. И там людям придётся продолжать мириться с загонами Oracle.
А вот все остальные в скором времени будут писать программы на обычном английском языке. А потом будет Нейролинк, и языки станут не нужны.
В какой из «языков высокого уровня» превратит нейросеть вашу спецификацию, зависит уже не от удобства этого ЯВУ для использования, а от конкретных технических характеристик: насколько качественный код генерит нейросеть, как рантайм языка управляет ресурсами, насколько быстра компиляция, насколько быстрые итерации разработки в целом.
И может оказаться, что языки будущего — это не Go и не Java, а всеми забытые C++/C. Может быть, даже ассемблер. Может быть, даже перфокарты — не обычные, а квантовые. Хорошая новость: никакой из этих языков вам не нужно будет знать сильнее, чем вы сейчас знаете ассемблер и Си. Разработчикам каких-то очень конкретных специальностей, типа «перформанс-инженер», наверное, нужно будет очень изредка забежать и поправить какой-то сложный случайный баг. Но для всех остальных всё напишет нейросеть, и это чудесно.
Для соблюдения формальной корректности нужно явно сказать, что по состоянию на начало 2026 года утверждение «роботу всё равно, на чём писать» — спорное и скорее неверное. Качество генерации кода сильно зависит от языка (объём тренировочных данных, типизация как костыли для LLM, тулинг для верификации). Например, при написании кода на C у робота точно те же проблемы, что и у человека — он не может уследить за потоком памяти, отчего пишет совершенно неработающую ерунду. Даже Claude Code, даже Grok Super Heavy. Но ситуация быстро меняется по мере того, как корпорации вкладывают триллионы денег в датацентры, позволяющие делать всё более мощный и глубокий анализ.
Всё это заслуживает отдельного разговора, но размывает скоуп статьи. Напишу отдельно.
И самое главное: написание кода через AI на разговорном языке — это настоящая свобода. Разговорный язык не принадлежит какой-то коммерческой компании, которая заставила бы вас говорить только то, что ей нужно. Сделать хорошее техническое решение — сложно, но не продолбать свою свободу может оказаться еще сложнее.
Итого: учитесь писать на английском/русском/китайском и внятно излагать свои мысли. Имейте свои мысли, чтобы было чего излагать. В самое ближайшее время это понадобится.
Комментарии (51)
Dhwtj
01.02.2026 13:24Про упомянутый Rust
Из-за независимости и отсутствия большой команды, финансируемой централизованно, у них тупо нет денег и развитие фич и тулинга идёт крайне медленно. Зрелая асинхроннонность и веб появились там 2.5 года назад (axum 1.x). А IDE all in one (rustrover) хоть какой-то но не полной стабильности только в прошлом году. При том не перестаёт меня удивлять глюками (пошли ложно положительные сообщения об ошибках, хотя проект не менялся, собирается и работает).
Rust open source разработчики постоянно пишут про выгорание. И вообще там всё на бесплатном рабском труде основано.
Всё это начинает утомлять и хороший язык похоже так и не взлетит в корпоративном секторе вместо Java.
olegchir Автор
01.02.2026 13:24Сейчас они начнут разрабатывать Rust с помощью ИИ, и никакие корпоративные вливания им больше будут не нужны :
MountainGoat
01.02.2026 13:24Там большинству просто не нужна асинхронность, приколоченная к вебу, когда есть просто асинхронность, и нахрен не нужна IDE "какой-то не полной стабильности", когда есть VSCode.
Lewigh
01.02.2026 13:24Как язык программирования, Go всё ещё хуже Java
Не очень понимаю что значит как язык хуже? Ну вот к примеру то что Go вышел в 2009 году и в нем уже были горутины, а в Java мире виртуальные потоки появились только в 2023 году (спустя 14 лет), это видимо показатель того что Java лучше как язык?
хотя они пытаются пройти по её пути
По какому ее пути? Добавить дженерики со стиранием типов? Да вроде бы нормальные добавили а не те о которых джава последние 10 лет избавиться не может. По какому ее пути тогда? Сейчас больше похоже на обратное - в Java добавили виртуальные потоки напоминающие горутины, потихоньку отходят от ООП, плюс больше двигаются в сторону AOT. Больше похоже что Java в сторону Go идет.
А приводит это к тому, что экосистема C# — с гулькин нос. У тебя есть несколько крутых фреймворков имени Microsoft, несколько известных опенсорсных проектов... и всё. Нет такого, что как в Java или JS/Node ты сидишь и час выбираешь, какую бы библиотеку из сотен использовать, чтобы сложить два числа.
Дада, знаменитые сотни библиотек по разработке игр, десктопов фронтендов и прочего. Куда там "никчемной" экосистеме C# с Unity, Godot, Avalonia, всякими Blazor и кучей десктопной и прочей обвязкой, куда этому всему до могучей экосистемы Java состоящей по большей части из библиотек на тему Spring и все что с ним связано. Еще было бы не плохо в подтверждение своих слов показать насколько весело в Java обстоят дела с разработкой обычного автономного CLI приложения. Ну так, для иллюстрации как все "хорошо" в Java мире.
Прежде чем поливать говном другие языки и экосистемы, неплохо было бы в них для начала подразобраться, так для галочки хотя бы.
Dhwtj
01.02.2026 13:24Go вышел в 2009 году и в нем уже были горутины
Go это минимальная языковая обертка вокруг их отличного сетевого рантайма, включая горутины
olegchir Автор
01.02.2026 13:24Лёгкие потоки (green threads) появились в Java 1.0 (май 1996 года) и были по умолчанию до Java 1.2 (декабрь 1998 года), где их заменили на native OS-threads. В 1.3 (2000) green threads удалили полностью. Т.е. Go еще не появился, а в джаве от них уже и сделали, и уже отказались ;)
Имхо, это слишком много работы для не очень востребованной в то время технологии. В API тогда было много блокирующих вызовов (например, одинsocket.read()- и вся JVM встаёт), и для поддержки этой штуки нужно было считать легкие потоки официальной линией партии и вкладываться в поддержку.
А там и операционки подтянулись. На Solaris появились качественные LWP, на Linux пришёл NPTL (Native POSIX Thread Library в ядре 2.6), Windows NT изначально имел нормальные треды. Нативные потоки стали достаточно дешёвыми, и их планировщик - заведомо лучше того, что мог сделать планировщик JVM в юзерспейсе.Тут наверное надо порассуждать, почему почему 20 лет не возвращались к этой идее. Вообще, возвращались. Там пол-интернета этими рассуждениями завалено. Но если все уже привыкли кодить в идее "один тред = один OS-тред", зачем ломать то, что уже работает?
В Java есть кейворд
synchronizedи он очень удобный и приятный. Но он деградирует легкие потоки до обычных. А этим словом обмазано всё в любой библиотеке :) Чтобы это починить, нужно либо переписать весь мир наReentrantLock, либо менять семантику мониторов в JVM. Второе начали делать только в Java 24 (JEP 491).Профилировщики, дебаггеры, thread dumps, JMX, APM-инструменты - весь удобный тулинг Джавы, ради которой ее и используют, был построен на предположении, что потоков десятки-сотни, у каждого есть имя, у каждого предсказуемый стек. А миллион странных виртуальных потоков в thread dump - это какой-то шум, который непонятно как читать и отлаживать. Потоки должны иметь владельца и жизненный цикл, и эндпоинты для обсервабили и управления, иначе это всё превращается в черный ящик, в котором ХЗ что происходит.
Кстати, че там как с инструментарием в Go, как там с визуальным отладчиком, чтобы запрофилировать и заморозить горутины и глазами посмотреть, что там с ними происходит? :)))
Насколько я знаю (мне немного приходится иметь дело с Go), Delve - единственный серьёзный дебаггер, и то он сильно ограничен. И не потому что его создатели идиоты, а потому что это ограничение Go. Например, остановить или возобновить одну отдельную горутину в Go невозможно, поэтому любое действие активирует или останавливает все горутины одновременно. Даже если бы грязными ногами забрался в потроха и остановил или запустил нужный тред, это все задедлочится и повиснет вместе с GC. Это фиаско. Разработчики Go так упоролись по консоли, что сдизайнили рантайм, пользователям которого приходится отлаживать приложения, читая принты в логах.Но самое главное - это то, с чего всё началось. Подавляющему большинству Java-приложений реактивщина никогда и не была нужна. И сейчас не нужна. Типичный enterprise-сервис - это CRUD поверх PostgreSQL, 50-200 одновременных запросов, каждый живёт 20-200ms. Tomcat с пулом в 200 потоков справляется с этим без проблем. Потоки дорогие? На типичном сервере с 16GB RAM даже 2000 потоков - это 2GB стеков, и то только если каждому отдать дефолтный мегабайт. Уменьши
-Xssдо 256K - и у тебя 8000 потоков при тех же 2GB. Ты еще пойди найди какое-то приложение, которому этого не хватит.Реактивщина стала массовой не потому что была нужна, а потому что индустрия поверила в ложную идею: либо ты делаешь thread-per-request и не масштабируешься, либо ты юзаешь реактивщину и масштабируешься. А есть и третий вариант - делаешь thread-per-request и масштабируешься, потому что тебе и не нужен миллион потоков. Но это скучно и не порождает докладов на конференциях.
А про Go... ну хорошо, что они есть. Наверное, кому-то пригодятся.
olegchir Автор
01.02.2026 13:24Например, основа StackOverflow - это 9 веб-серверов на IIS в виртуальных машинах, по 64 ГБ RAM каждый, с достаточно низкой нагрузкой на CPU: 5-12%. Еще там есть 1 база Microsoft SQL Server + 1 hot standby, по 1.5TB RAM на сервер. Ну и всякая мелочь. Они неоднократно случайно проверяли, что SO работает на одном сервере. Это конечно не Java а .NET, но просто это иллюстрация идеи, что "нормально делай - нормально будет". Может и микросервисов никаких не нужно, и реактивщины, и еще какого мракобесия. И облаков они не используют, это просто on-premises машины, соединенные напрямую.
olegchir Автор
01.02.2026 13:24по большей части из библиотек на тему Spring и все что с ним связано
Spring это экосистема, сквозь которую работает всё остальное. Было бы странно, если какая-то библиотека не работала со Spring. Разве что это библиотека из другой экосистемы.
Siemargl
01.02.2026 13:24показать насколько весело в Java обстоят дела с разработкой обычного автономного CLI приложения
Внезапно в Шарпе с этим не лучше. Или не кроссплатформенный net4 или многомегабайтный монстр
Einherjar
01.02.2026 13:24Почему многомегабайтный?
Dhwtj
01.02.2026 13:24Видимо из-за jit
Go компилится под конкретный таргет, поэтому jit не нужен и сборка включает только компактный runtime (GC и горутины) без jit
C# тяжёлая среда выполнения и тащить её в сборку это десятки или сотни мегабайт
Native AOT помогает, но не пробовал. Тогда будет без jit
Einherjar
01.02.2026 13:24Я конечно мог бы душнить на тему с чего бы вдруг JIT увеличивал размер приложения, но начать тут надо с другого - а что, собственно, мешает .net скомпилить под конкретный таргет? Причин есть две - быть не в курсе что Native AOT завезли уже довольно давно, или иметь легаси которое с ним никак несовместимо. Обе причины никак не отменяют того факта что консольный Hello World не требующий никаких зависимостей занимает около мегабайта. Да, это значительно больше чем на чистом С, но и на многомегабайтного монстра не тянет.
Dhwtj
01.02.2026 13:24Говорю, я не пробовал. А вопросы про монстров к автору.
Einherjar
01.02.2026 13:24Ага, я обновление уже после увидел.
и тащить её в сборку это десятки или сотни мегабайт
.net затем и поставляется отдельно чтобы не было необходимости тащить его в каждое приложение. Тогда они маленькие и будут. Перфекционисты кто не хочет никаких prerequisites тащат конечно, но это не догма.
И что самое феноменальное, на просторах интернета это является недостатком только когда сделано микрософтом, ибо если какой-н корявый скрипт на питоне выкладывают в люди, требование установить в систему такие же сотни мегабайт хз-чего никого как правило не смущает.
Lewigh
01.02.2026 13:24Видимо из-за jit
Go компилится под конкретный таргет, поэтому jit не нужен и сборка включает только компактный runtime (GC и горутины) без jit
C# тяжёлая среда выполнения и тащить её в сборку это десятки или сотни мегабайт
Native AOT помогает, но не пробовал. Тогда будет без jit
Да не. В C# там более менее норм, бинарник примерно как у Go
Siemargl
01.02.2026 13:24Даже в Go с этим гораздо лучше. А правильнее для CLI брать C++ или D.
Ну или Nim, есть Питон ближе.
Lewigh
01.02.2026 13:24Даже в Go с этим гораздо лучше.
Минимальный консольный Hello world для win-64:
go 1.25.0
1 559 КБ
c# native aot net10.0
905 КБSiemargl
01.02.2026 13:24Там прогрессия разная ожидается с подключением дальнейших библиотек.
Я уже померял
Но несомненно, Шарп как язык поудобнее.
Поискав в дикой природе, чтобы посмотреть на реальные размеры, особо то и не нашёл самостоятельные CLI написанные на Шарпе.
Lewigh
01.02.2026 13:24Поискав в дикой природе, чтобы посмотреть на реальные размеры, особо то и не нашёл самостоятельные CLI написанные на Шарпе.
Ну я не о том что C# подходящий инструмент для написания полноценного целевого CLI, а в контексте того что автор утверждал что Java экосистема восхитительна по сравнению с "ничтожной экосистемой" C#, на что я и предложил попробовать реализовать банальный автономный CLI на Java и на CLI и потом поделиться опытом насколько такая базовая задача как CLI на Java будет просто сделано и посмотреть насколько эти утверждения хоть как то бьются с реальностью.
Siemargl
01.02.2026 13:24Претензий на универсальность Явы я не заметил. Экосистема там для других областей.
Lewigh
01.02.2026 13:24Внезапно в Шарпе с этим не лучше. Или не кроссплатформенный net4 или многомегабайтный монстр
Ну я не про то что в шарпе или в Go или еще в каком то языке который не Си/С++/Rust большой бинарник. Я про то что в C# очень просто создать консольное приложение которое собирается в автономный бинарник, сделать это можно секунд за 5, и есть библиотеки разные удобные, в отличии от Java где такая тривиальная история как консольное приложение превращается в муку.
Arragh
01.02.2026 13:24Чел же написал, что он жава-бро. О жава-бро, как я заметил, с высока относятся к другим языкам, а в особенности к C#. Не знаю, почему так, просто личное наблюдение из всяких статей и видео на тытрубе.
olegchir Автор
01.02.2026 13:24Забавно, я написал про то, что ни Java, ни C#, ни Go больше не нужны, а тут такой холивор :)
akhmelev
01.02.2026 13:24Весь смысл программирования и программистов сводится к определению "своего" языка с многолетним поклонением оному. С одновременным унижением всех иных в любых формах. Религия. Фанатики. Почти любой холиварный коммент хабра - зловещее доказательство этого непотребства ;)
А он (язык) один. И имя ему - машинный код. В который и нужна трансляция с человеческого. И да, С ближе всех. Так что смысл статьи почти ленинский. Религия - опиум для народа. Долой языки.
akhmelev
01.02.2026 13:24Но что если ллмки просто следующий слой абстракции? Нас же ждут увлекательные баталии джеминистов против гптшников, и клаудкодовцы угораюшие над олламой. И все повторится.
Siemargl
01.02.2026 13:24Но для всех остальных всё напишет нейросеть, и это чудесно.
И нужно выполнение всего пары условий
Иногда надо разобраться и поправить, что же ии нагенерило/сгаллюцинировало. Т. е. язык должен быть простым и человекочитаемым
Лишние юридические проблемы с языком не нужны
kivan_mih
01.02.2026 13:24Статья звучит так, как будто каждый java dev должен был хотя бы раз в своей жизни быть раздавленным корпоративным катком Sun/Oracle. Мне видимо не повезло: за 20 лет работы с Java, я обращал внимание на то, что "там происходит наверху" ровно два раза: когда Оракл купил Sun на сайте с документацией появились оракловые логотипы и он стал жутко глючить вплоть до невозможности что-то найти, и второй раз когда в конце 10х Оракл поменял какие то свои лицензионные политики и все дружно съехали с Оракл Ждк на что нибудь вроде Adopt Openjdk (нынче Temurin). Оба раза "смотрение наверх" отнимало примерно в три раза больше времени в курилке, чем рабочего времени потраченного на саму "проблему".
andyblaster
01.02.2026 13:24Без Delphi и Dart рассуждения считаю неполными. В интерпретации автора сильно картину не сдвинут, но позитивные нюансы для остальных есть.
Разговорный язык не принадлежит какой-то коммерческой компании
А окошко с чатом и секретные веса принадлежат. Причем украдено ещё более наглым образом - обучено на реальном выстраданном опыте и без отплаты и даже уважения к первоисточникам.
написание кода через AI на разговорном языке — это настоящая свобода
Хм, я правильно понял, что свобода - это заменить зависимость от условного майкрософта в лице шарпа на зависимость от условного майкрософта в лице копилота?
Оставшуюся мысль сложно иллюстрировать цитатами, так как конец статьи смазанный. В общем, без вливаний нового кода, либо без принципиального изменения фундаментальных концепций генеративной разработки, нейросети ничего нового больше то и не выдадут. Авторизация по почте в безликих веб-приложениях миллионы раз написана по гайдам и доке, а вот авторизация центра управления полетами в далеком луноходе для передачи команд на изменение мощности РИТЭГа - всего лишь единожды для каждого лунохода. Так что, на месте автора я бы либо более уважительно относился к труду людей, кто пишет вручную и поставляет сырье, либо перебалансировал взгляд в будущее с учетом изначальной ограниченности ключевой вероятностной механики современных LLM. Но, конечно, в первую очередь перестал бы называть нейросети и БЯМ искуственным интеллектом.
MountainGoat
01.02.2026 13:24это заменить зависимость от условного майкрософта в лице шарпа на зависимость от условного майкрософта в лице копилота?
Как думаете, что легче - перейти с Клауды на Дипсик или перевести проект с C# на Java?
а вот авторизация центра управления полетами
Как думаете, где больше бабла крутится - во всех безликих приложениях, сложенных вместе, или во всех центрах управления полётами?
без оплаты
Заплатить всему Интернгету, да ещё вперёд, может только Гугл. Зачем вы требуете, чтобы впредь ИИ можно было разрабатывать только Гуглу? Вы считаете, что IT придёт конец, если Гугл не будет там единолично контролировать вообще всё?
и даже уважения к первоисточникам
Все знают, что LLM сделаны из Интернета. А требовать прилагать источники к каждому ответу - это как требовать в пюре пронумеровать каждую картофелину.
andyblaster
01.02.2026 13:24Как думаете, что легче - перейти с Клауды на Дипсик или перевести проект с C# на Java?
Независимо от тяжести, зависимость остается зависимостью. Две зависимости еще хуже, чем одна. Ну и выбора скоро не останется, процессы, порождающие монополизацию, никуда не делись. Предлагаю вернуться к разговору, когда, после череды крупных сделок, выбора между клаудом и дипсиком не будет)
где больше бабла крутится
В абсолютном объеме возможно. В относительном, в пересчёте на бенефициара как будто бы ЦУПы выигрывают. Иначе зачем Илону Маску пускать ракеты и подсаживаться на госконтракты, если у него есть грок и твиттер. Предлагаю сравнить прибыль с твиттера и со SpaceX, чтобы говорить предметно.
без оплаты
Я написал "без оТплаты", немного другое значение у слова. Будьте внимательнее и не сводите все к товарно-денежным отношениям.
Все знают, что LLM сделаны из Интернета
Без которого не могли появиться, и которые без контроля и эволюции умрут в своих отходах жизнедеятельности, уничтожив и себя, и среду, как самые обычные дрожжи. Аналогия с дрожжами хороша тем, что продукт нейросетей вызывает такую же зависимость, как алкоголь - первичная эйфория, падение барьеров, чувство всемогущества, но в долговременной перспективе - потеря фокуса, утрата профессиональных навыков и деградация. Речь, конечно, об LLM общего назначения, потому что специализированные, по поиску трещин в бетоне или онкомаркеров в моче, хоть и не претендуют на революцию и хайп, но тихо и успешно автоматизируют свою предметную область.
Dhwtj
01.02.2026 13:24перестал бы называть нейросети и БЯМ искуственным интеллектом
Называю LLM болтуном. В разговоре понятно и адекватно по степени доверия
DenSigma
01.02.2026 13:24Интересная мысль, что при вайбкодинге на AI, надо диктовать, чтобы разрабатывалась программа на Си.
MountainGoat
01.02.2026 13:24Спорно.
Вот помню как вчера (потому что это было вчера):
Вот я ему командую на Rust. Он иногда пытается нарушить права доступа, и компилятор ему бъёт по рылу, после чего LLM даже исправиться не мог, пока я не понял причину. Причина была в том, что в памяти LLM откуда-то была неправильная документация на конкретный метод: String.trim() (обрезающий пробелы) возвращает указатель на содержимое в исходной строке, а LLM был уверен, что получит обрезанную копию, и потому не мог понять, откуда конфликт доступа после того, как он выкинул исходную строку.
Суть в том, что С это бы прокатило, а потом был бы segfault, но только в том случае, если пользователь перед своим паролем введёт пробел.
Зато, как я вчера убедился, LLM очень мешает то, что в Rust не пишут явно типы у переменных. Думаю, если бы LLM видел, что там вывелось `let trimmed: &str` вместо, как он думал, `let trimmed: String`, он бы не ошибся. Сейчас думаю, что с этим делать, попробую докопаться до разработчиков Roo.
Siemargl
01.02.2026 13:24Очевидно, ИИ пока настолько тупой, что ни С ни Раст ему не подходят.
Я бы поставил на то, что для этой спец олимпиады нужен свой язык.
Достаточно простой, прозрачный и безобидный. Где все будет указано явно
olegchir Автор
01.02.2026 13:24Он не "тупой", просто автор не настроил его на обработку этих ошибок. Вот сейчас автор сейчас всё понял и пропишет в промт пути обхода этих проблем, и больше они повторяться не будут (или будут но редко).
Dhwtj
olegchir Автор
Можно поставлю на обложку статьи?
Dhwtj
Конечно
nomanhero
Хехех, получилось неплохо действительно
SabMakc
А в чем генерировали?
olegchir Автор
Нанобанана?
Dhwtj
Говорю, случайно модель сменил на рисующую