Кожаев кстати, на которого ты ссылался в своем бложеке, где ты меня забанил, тоже теперь языки программирования делает: jobs.dou.ua/...​ies/new-language-service

У вас стадии болезни похоже в унисон развиваются: воркфлоу, язычек, бугага.

Лол, как тебя порвало. :-)
Судя по webcache.googleusercontent.com/...​vejournal.com/432082.html (гугл кеш все помнит, как бы ты не удалял, и не банил в своем бложике), ты оставил гавнопомойку кода на «серверах Hetzner», и срулил, оставляя других выгребать.

С чего ты взял что я в Нью-Джерси, и учился у Буя, и мне 45 лет? Борись со своими фантазиями, потом будет поздно!
Стартап кстати продан уже давно, теперь уже следующий этап покорения мира.

Поэтому вы на DOU пишете, а мы рабоатаем.

Где работаете? Тебя же с Приватбанка — того..

Есть, и я тебе уже отвечал.

В гугле 2 миллиарда строк на джаве и ц++ против 20 млн у ядра линукса.
Ну и ядро линукса — это специфическая ниша, к тому же ц — это еще и вопрос наследия.

Я уже обьяснил что я думаю по поводу твоего мнения. Можешь меня больше не коментировать.

В go нет никакой проблемы с return-кодами, и возвращать принято не код, а объект, поддерживающий интерфейс error.

Эксепшны позволяют иметь более чистый код.
Ну или делать обработку макросом как в расте.

panic/recover для ретурн кодов использовать не рекомендуют и никто так не делает, т.е. тебе прийдется пихать везде ретурн коды, потому что вся остальная экосистема (библиотеки) так устроена.

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

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

Но суть в том, что в Java, .Net этого не сделать никак.

С чего ты взял что он несовместимый между собой?
Грейдл прекрасно работает со всей мавен инфраструктурой — и тащит зависимости и умеет их публиковать.

Ну вот и в джаве так.

В случае с go исходники всех зависимостей принято хранить в своем репозитории.

Мне кажется в гугл как раз джава абсолютно преобладает над го, все офисные и бизнес преложения(дашборды, адвордс, джимейл, и т.д.) пишут на ней а не на го.

В случае го — это исходники, которые не факт что меньше, которые еще и скомпилить нужно.
Непонятно чем ты гордишься.

Ну и вытягивать нужно один раз в жизни, подле этого джарники кешируются локально.

Никак. В текущем тысячилетии у программистов как правило есть интернет.
Для читабельных зависимостей мавен поддерживает разные форматы, и еще есть грейдл: github.com/…​/blob/master/build.gradle

apt-get update
apt-get upgrade

— go поддерживает кэш скомпилированных модулей, поэтому перекомпилируются только измененные модули, а время инкрементальной компиляции огромных проектов редко превышает пары секунд (обычно меньше секунды);

а не искать/ждать джарники зависимостей под новую версию джавы;

Это ты опять коментируешь какие то странные свои фантазии.

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

Опять новости из альтернативной вселенной.
В мавене зависимости лежат отдельным от джара файлом: central.maven.org/…​3.5/commons-lang3-3.5.pom
И даже есть веб интерфейс где их смотреть можно: mvnrepository.com/…​commons/commons-lang3/3.5

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

он многословен;

Также в java принято писать абстрактные фабрики визиторов синглтонов через обязательный inversion of control на каждую строчку кода,

в java присутствуют почти полный набор «убийц времени» — эксепшны, наследование, перегрузка функций, конструкторы и generic’и.

скорость компиляции java вроде повыше, чем у swift, rust, scala и C++ , но все же не дотягивает до go;

Отсюда jvm hell — попробуйте быстро и безболезненно перейти на новую версию jvm.

замеров производительности и профилирования программ.

стандартная библиотека в java с одной стороны переполнена устаревшим хламом и кучей бесполезных штук, а с другой стороны, в ней отсутствуют удобные средства, требующиеся в большинстве программ;

Да.