О бедном Crystal замолвите слово

Каждый раз читая свой многопоточный код я читаю его так, будто в нём есть баг и мне нужно его найти. Я не представляю, что должно случиться, чтобы я наконец мог сказать «ага, эти функции полностью проверены, в них ошибки быть не может».

вот и я так же.

И это плохо, потому что это значит, что код фундаментально ненадежен.

Немного вброшу по поводу скорости.

Есть два ключевых и очень разных понимания что такое скорость работы.

Первое это холодный старт и скорость «локального выполнения», когда задача помещается на машине разработчика либо простом сервере.

А второе это кровавый продакшн, где может быть под 200 сотни ядер и физической памяти больше чем в вашем домашнем NAS.

Поэтому то что вам кажется избыточным и медленным - для вас просто не предназначено.

Вообщем наезжать на «тормозящую» на вашем домашнем компе джаву можете сколько угодно, но как только дойдет дело до нормального коммерческого проекта, серьезного оборудования и денег - там обязательно будет она.

Ну и понимание смысла существования «garbage collector» приходит только когда есть нормальное оборудование и задача «обеспечить бесперебойную работу годами» а не через kill -9 и watchdog.

А зачем нужда «сверхнадежность ценой скорости» вам быстро пояснят первым же счетом за простой важной системы. С пятью нулями и в час.

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

есть альтернативные технологии для многопоточности где возникает каким-то образом доказательство корректности?

есть альтернативные технологии для многопоточности где возникает каким-то образом доказательство корректности?

Можно глянуть тут. Это, конечно, не альтернативные волшебные технологии, которые сделают блокировки в принципе ненужными — но, по крайней мере, тебе не придётся заниматься этим самому вручную. Примерно как сборщик мусора не искореняет необходимость выделять и освобождать память, просто автоматизирует процесс.

Молоток может быть на деревянной ручке, пластиковой или металлической, и забивать любые гвозди примерно одинаково. map, filter и reduce могут одинаково работать со списками, векторами и строками. Не нужно изобретать гвозди для молотков с металлической ручкой и отдельные vector-map, vector-filter и vector-reduce.

Слабо замапить вектор в односвязанный список? Трансдьюсеры хороши, когда у тебя в ЯП всего 3-4 базовых контейнера и всё остальное строится на них. В том числе это актуально длы JS, как для типичного функционального языка.

не понял кто кого косплеит. или я не знаю, что значит косплеить

Костюмированные игры, когда детишки одевают костюм губки боба или человека-паука.

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

NH чрезвычайно говеный ресурс в информационном плане, с гнилой уродской зомби-публикой, орган тоталитарной фашистской пропаганды. и с изрядной долей местечковости причем.

Спасибо, ато мне казалось, что я один это замечаю.

есть альтернативные технологии для многопоточности где возникает каким-то образом доказательство корректности?

Да, Clojure. Конечно, там корректность опирается на корректность реализации самой Clojure, но это уже ограниченная решаемая задача.

Слабо замапить вектор в односвязанный список?

Чё там по эффективности? Если без ленивости. Линейная сложность, я полагаю?

Трансдьюсеры хороши, когда у тебя в ЯП всего 3-4 базовых контейнера и всё остальное строится на них

3-4 базовых абстрактных типа, ты хотел сказать. А зачем тебе больше? Вот последовательность, вот индексированный доступ, вот ассоциативная структура. Что ещё нужно?

Ты как я понял, говорил о бесполезности заложенной в жаву системы идей, в том числе касаемо упомянутого мной контракта equals/hash. атаковав его тем, что семантика сравнения носимая самим сравниваемым объектом - это так себе идея, т.к. часто этой семантика известна только клиенту мапы. и это в том числе подтверждает отсутствие ценности в том что авторы жавы напроектировали, то есть нет разницы между языком над которыми долго думали и, например, JS. и понятийной стройности в жаве нет, а только понятийная бесполезность.

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

при этом при всём, для обычных случаев коих 99% у обычных программистов, этот заложенный в жава контракт equals/hash вполне пригоден, и я уже повторяюсь, полезен. что доказывает, что java, как язык, который проектировали, лучше, чем какой-нибудь язык который не проектировали.

А если тебе нужно сделать точное сравнение картинки или сравнение по адерсу указателя — ты чем собрался пользоваться?

Ну так точное можно признать «дефолтным», «разумным» (кроме того для него hashcode сделать можно) и отправить в equals(). А кастомный да - там что-то пришлось поковырять, поколхозить (емнип я просто «обернул» все экземпляры в другие, у которых нужный).

Я повторюсь, для очень многих типов это (идея о дефолтном equals()) работает. Это работает в конце концов для строк в стандартной бибилиотке. Строки сравниваются вызовом equals().

Я пишу опять то, что писал уже выше. Это работает для самих мап даже, и вполне там удалось выбрать дефолтную семантику которая полезная. И в питоне так же сделали.

Костюмированные игры, когда детишки одевают костюм губки боба или человека-паука.

Ну так и где питон косплеит жаву в части операторов, их изобилия или перегрузок если в жаве вообще этого нет в принципе (кроме одного исключения о котором я упомянул)?

Можно узнать ответ на загадку про Apple?

Первое это холодный старт и скорость «локального выполнения», когда задача помещается на машине разработчика либо простом сервере.

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

А зачем нужда «сверхнадежность ценой скорости» вам быстро пояснят первым же счетом за простой важной системы. С пятью нулями и в час.

Я ПРЕКРАСНО понимаю, о чем ты, и в свое время участвовал в проекте, который далеко не ушел именно по этой причине.

Правда, я тебе вынужден сказать страшную тайну, которую от тебя скрывали евреи и мировое правительство, только ты держись: отказоустойчивая система — это не та, в которой не происходят отказы, а та, которая переживает отказы без значимых последствий. Именно так Сергей Брин пришел, выгреб дешевые пеки с помоек, и сделал на них крупнейшую систему сбора и обработки информации, пока серьезный бизнес взвешивал, стоит ли тратить очередной миллиард на вертикальное масштабирование.

JVM идет по парадигме безотказных систем, RAID 0, два независимых источника питания и автономный генератор, ECC RAM, если что-то сломалось — потом два дня бизнес стоит и разгребает ошметки, но такие случаи крайне редки.

В этом всём уравнении люди забывают, что между программой на жаве и реальным миром есть прокладки из железа, операционной системы, и собственно JVM, в каждой из которых могут быть баги и сбои. И, самое страшное, ОС и JVM написаны, о ужас, на C/C++. Эта детская наивность среднего энтерпрайз заказчика напоминает ребенка, который укрылся одеялом от бабайки, мол «не вижу — значит защищен». Всё, что вам нужно знать про серьезный бизнес.

Причем, в распределенных системах подход «не вижу — защищен» остается таким же, именно потому сейчас доминирует микросервисная архитектура (не имеющая ничего общего тем, как гугл использует cgroups), размазывающая ответственность, благодаря которой можно бесконечно переносить бутылочное горлышко или потерю данных после отказа из одного места в другое, или же просто делать вид «ничего не случилось» при потере данных после перезапуска сервиса (не вижу — значит защищен). Когда же спустя два месяц после поиска бага виновного ловят за руку с поличным и требуют «исправляй» — он со спокойной душой лепит костыль, который устраняет проблему в его сервисе и создает аналогичную проблему в соседнем сервисе. «Кручу-верчу, обмануть хочу».

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

Кончено, я всё это пишу с детским представлением о том, что программа пишется чтобы решать задачу заказчика, а не задачу по зарабатыванию мной денег. Теперь вы понимаете, почему IBM, Oracle, и SAP выбрали ту модель, которую выбрали?

Слабо замапить вектор в односвязанный список?

Чё там по эффективности? Если без ленивости. Линейная сложность, я полагаю?

Очень сильно зависит от ЯП и вообще используемой модели. Потому я и пишу, что никакой «универсальной» реализации быть не может, а когда возникает стандартная реализация, то библиотека становится узкоспециализированной на спектр задач. Именно потому STL является, как ни странно, узкоспециализированной библиотекой, которая была актуальна для многих проектов только потому, что на STL раньше в основном писали однопоточный GUI.

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

Это так не работает, для долгосрочного сотрудничества выгоду должны иметь обе стороны. Игра в одни ворота долго не продлится, сторона, оставшаяся без выгоды, будет искать выход и в конце концов его найдёт.

То есть в идеале программа должна решать задачу зарабатывания путём решения задачи заказчика. Для заказчика решение его задачи — цель, программа — средство. Для тебя заработок — цель, решение задачи заказчика — средство. Связь между вами — это решение его задачи.

Праксиология делает брррр %)

3-4 базовых абстрактных типа, ты хотел сказать. А зачем тебе больше? Вот последовательность, вот индексированный доступ, вот ассоциативная структура. Что ещё нужно?

Ничего, модель замечательна, JS примерно так и построен. Другое дело, что речь шла про Java, в которой такой простоты подавно нет.

нет разницы между языком над которыми долго думали и, например, JS. и понятийной стройности в жаве нет, а только понятийная бесполезность.

Если у тебя нет ног, то не важно, сколько ты будешь их тренировать. Java проектировали идиоты, потому не важно, сколько они над ней думали. Я только «за» язык, который был бы грамотно спроектирован и поддержан сообществом, но решения принимаю не я.

при этом при всём, для обычных случаев коих 99% у обычных программистов, этот заложенный в жава контракт equals/hash вполне пригоден, и я уже повторяюсь, полезен. что доказывает, что java, как язык, который проектировали, лучше, чем какой-нибудь язык который не проектировали.

Сложность языка в общем и специальные костыли в частности являются строго негативным свойством, а не позитивным. Потому твой пример лишь доказывает, что Java проектировали идиоты.

А глупый гугол выбрал быстрый старт на Go.

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

Это не означает что вся разработка внутри Гугла переехала на Golang. Точно также создавался Swift в Apple - как язык прикладной разработки для внешних разработчиков. Cам Apple все также использует Objective C ( информация из первых рук, от тех бывших коллег кто там работал).

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

Высказывать мнение по таким вопросам это примерно как высказываться о восходе и закате - конечно можешь оглашать что закат «это ниочем» и вообще плохо, но смысла будет ноль. Потому что закаты были до тебя и будут после, вне зависимости от мнения. Так зачем сотрясать воздух?

отказоустойчивая система — это не та, в которой не происходят отказы, а та, которая переживает отказы без значимых последствий.

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

Именно так Сергей Брин пришел, выгреб дешевые пеки с помоек, и сделал на них крупнейшую систему сбора и обработки информации,

Ты лично присутствовал при этом чтобы вот так легко и просто это описывать? Я например не присутствовал, но знаю что первая команда Гугла была 35 человек и штук 30 серверов, которые им донатили. Причем донатила та же страшная корпоративная Sun. Поэтому что это был исследовательский проект и только сильно позже это выросло в большую коммерцию. И не поверишь но Гугл не был ни первым ни самым крупным - уже существовал Yahoo и неплохо себя чувствовал.

В этом всём уравнении люди забывают, что между программой на жаве и реальным миром есть прокладки из железа, операционной системы, и собственно JVM, в каждой из которых могут быть баги и сбои.

Видимо ты не осознаешь что существует разделение на техническую и прикладную разработку. Техническими задачами занимаются системные программисты, прикладными - прикладные.

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

Для чисто технических задач есть однозначные способы верификации кода, тестирования и контроля качества, потому что любая техническая задача конечна.

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

Отсюда следует что у системного софта качество и надежность всегда будет выше, но писать его дольше и поддерживать сложнее.

Для прикладного софта есть три главных критерия: 1) соответствие задачи 2) скорость доработок 3) fail fast - быстрое падение с четким местом ошибки.

Все, на чем именно реализована песочница прикладному разработчику не очень интересно.

Всё, что вам нужно знать про серьезный бизнес.

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

JS примерно так и построен

С абстрактностью вот только беда.

Ну так и где питон косплеит жаву в части операторов, их изобилия или перегрузок если в жаве вообще этого нет в принципе (кроме одного исключения о котором я упомянул)?

Неочевидный факт: в исходном питоне не было классов:

https://github.com/python/cpython/tree/85a5fbbdfea617f6cc8fae82c9e8c2b5c42443...

Идея добавить классы и несколько специализированных функций с подчеркиваниями появилась где-то к версии 1.0, вышедшей в 1994 году:

https://legacy.python.org/download/releases/src/python1.0.1.tar.gz

Там был очень ограниченный набор из __init__, __del__, __repr__, __cmp__, __len__, __getitem__, __setitem__, __delitem__, __getslice__, __setslice__, __delslice__. Потом уже их количетсво увеличилось в разы. Я подозреваю, что такая упоротость перегрузками возникла не из Java, а из C++.

Можно узнать ответ на загадку про Apple?

Ruby.

Сложность языка в общем и специальные костыли в частности являются строго негативным свойством, а не позитивным.

Не применительно конкретно к жаве, или даже именно к языкам - а вообще - вот с этим я согласен.

Но хаотичская херня которую не проектировали оказывается сложной, пхп тому пример - зашкаливающе сложный язык, как в количестве явлений о которых можно знать, так и в силе этих «идиосинкразий». Я ничего не знаю о С++, но по «сложности» я думаю php если не приближен то сравним с С++.

То же, я догадываюсь, справедливо и для JS до какой-то степени.

Питон аналогично: чрезвычайно сложный язык (for no good reason), наверняка на уровне C++ или сравнимо.

Теперь сравни это с джавой, которую хотя бы пытались проектировать. Там этой проблематики нет, т.к. нет ненужной сложности.

Это не доказывает, конечно, само по себе, что джава хороший или более пригодный язык.

Потому твой пример лишь доказывает, что Java проектировали идиоты.

Ты не прав.

Я подозреваю, что такая упоротость перегрузками возникла не из Java, а из C++.

Ну наверное, ведь в Javа нет перегрузок операторов, да и вообще в Java нет операторов для reference types кроме, identity test (но это про ссылки, а не про объекты) и одного исключения для строк. Не знаю откуда это взял про «в питоне перегруженные операторы - косплей java»

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

… что это был исследовательский проект ЦРУ …

Поправил.

Я только «за» язык, который был бы грамотно спроектирован и поддержан сообществом, но решения принимаю не я.

Существует ли пример языка, который в твоем понимании был грамотно спроектирован, но не получил популярности?

Какой ЯП без классов порекомендуете?

у меня никогда не возникало мысли сравнить два ассоциативных массива простым оператором

Причем тут оператором-то?

Я говорил о контракте equals/hash в Java. Я не говорил про операторы. Ты почему-то начал про операторы сравнения объектов в Java (которых нет).

Уясни наконец: в джаве нет операторов reference types. Кроме identity test и одного синтактического исключения для строк. Java и python - это разные языки.

у меня никогда не возникало мысли сравнить два ассоциативных массива

Ну вот когда возникнет, ты обнаружишь, что в некоторых языках у словарей есть equals, eq и там вполне useful семантика. Подойдет ли она для твоей задачи - другой вопрос.

Сравнить два множества у тебя тоже никогда не возникало мысли?

вот про питон явно не так

питон со врем>н Бизли(1995) очень пророс на суперкомпах как скриптота для юзанья массовопаралельного фортрана на нихже

numpy (по началу Numeric(Paul Fred Dubois) на котором отрос scipy ) с тех времён

гугл как разтаки пытается подменить питон гофером

ваще забавно как более близкие по времени события «меняют прошлое» в восприятии людей не курившими спецом первоисточники

и снова нет

и С++ и Python отнаследовались прямо от Algol68

… что это был исследовательский проект ЦРУ …

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

Было, не было - уже не важно и для новых поколений не актуально.

в догонку

numpy (по началу Numeric(Paul Fred Dubois)(P. F. Dubois, K. Hinsen, and J. Hugunin, “Numerical Python”, Computers in Physics, v. 10, #3, May/June 1996.)(интересный источник https://pfdubois.com/biography#0d36d19b-6831-405e-8407-d1cde83579e4 в низу pdf на 103 страницы (https://img1.wsimg.com/blobby/go/040f68a0-de26-4bdf-9c3a-4a1d9f4a2b29/downloads/Computational%20Science.pdf?ver=1656175737088)с автобиографией сего чела и очень примечательным экскурсом как из Basis выросло то что теперь Python) на котором отрос scipy ) с тех времён

https://scipy.github.io/old-wiki/pages/History_of_SciPy

1995 где там гугл?

один из разработчиков сего пакеты был сначала консультантом первого лутцевого программируем питон в 1996 и соавтором изучаем питон 99 - так что у питона давнишнии завязки на академию а не удача гугла только

Нет никакого практического смысла ни выяснять эти детали

Было, не было - уже не важно

Ваше мнение очень важно для нас.

Да как угодно. Но смысл от этого не прибавится. Это вообще типично ЛОРовская дурь - копать «кто что и зачем сказал в таком-то году».

Это так не работает, для долгосрочного сотрудничества выгоду должны иметь обе стороны. Игра в одни ворота долго не продлится, сторона, оставшаяся без выгоды, будет искать выход и в конце концов его найдёт.

Ты мыслишь отсталыми терминами экономики, производящей материальный блага. Прогрессивная же современная экономика потребляет в 2-3 раза больше, чем сама производит, потому банкротство компании значит лишь «создадим следующую», а вопрос выиграша сводится к игре «кто обанкротился вторым».

Да, какому-нибудь SAP в идеале нужно, чтобы внедрение прошло до конца, до самой мошонки, чтобы заказчик заплатил и изначально обговоренную сумму, и увеличившийся вконце ценник. Дальше для SAP вообще нет разницы, что случится с заказчиком.

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

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

В гугле есть очень много собственных технологий, не доступных широкой публике. Конкретно Go решили сделать доступным. По духу фактической реализации языка это больше похоже на их внутренний язык для писания сервисов, чем на ЯП общего назначения — это к слову про «контролировать новую нишу». То есть, язык обладает ограниченным набором встроенных инструментов, которые довольно плохо расширяются вне заранее заложенных рамок (UTF-8 строки, массив, ассоциативный массив, структура-интерфейс).

Но сам факт того, что много кого не устраивает медленный старт JVM — показателен.

Высказывать мнение по таким вопросам это примерно как высказываться о восходе и закате - конечно можешь оглашать что закат «это ниочем» и вообще плохо, но смысла будет ноль. Потому что закаты были до тебя и будут после, вне зависимости от мнения. Так зачем сотрясать воздух?

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

Ты мыслишь отсталыми терминами экономики, производящей материальный блага.

Как будто в материальном производстве и торговле нет мошенников, которым наплевать на репутацию и долгосрочное сотрудничество, цель которых — урвать и сбежать. Конечно, они есть. Но заявления, что они составляют основу экономики (или её отдельных секторов) — слегка притянуты за уши, тебе так не кажется? %)

В гугле есть очень много собственных технологий, не доступных широкой публике.

Не могу подтвердить такое, серьезно. Есть коллеги там, как бывшие так текущие, которые несколько другую картину описывают: внутри куча исследовательских проектов, которые не доживают до прода. Это факт, но технологии там самые обычные: c++, python и так далее.

Конкретно Go решили сделать доступным.

Go was designed at Google in 2007 Go was publicly announced in November 2009,[27] and version 1.0 was released in March 2012.

Периоды примерно совпадают с той же Java и вполне адекватны для таких проектов: два года на переход от прототипа к чему-то работающему, еще три на первый релиз.

Нет ощущения что это какая-то тайная технология предков, тысячелетиями варившася внутри башен Гугла.

По духу фактической реализации языка это больше похоже на их внутренний язык для писания сервисов, чем на ЯП общего назначения — это к слову про «контролировать новую нишу».

Именно так и есть. Просто «написание сервисов» это теперь тоже ниша. Настолько большая что в JavaEE убили концепцию сервера приложений ради влезания в эту нишу по ноздри.

Но сам факт того, что много кого не устраивает медленный старт JVM — показателен.

Бедных программистов на дешевом оборудовании кратно больше чем богатых, что не будет сходу тормозить на их некрожелезе то считается «быстрым».

К сожалению это же приводит к разрыву в понимании, поэтому те кто начал на дохлом железе так на нем и продолжат, просто оно дальше будет в облаке и в виде микросервисов.

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

Ты так пишешь, будто писание кода с програмистом происходит помимо его воли, не может он выбирать что и на чем писать.

Не поверишь, но чаще всего так и есть. Потому что на один новый проект - тысячи существующих, нуждающихся в поддержке и доработках.

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

Ты про

А зачем нужда «сверхнадежность ценой скорости» вам быстро пояснят первым же счетом за простой важной системы.

? Знаешь, есть такое понятие «технический долг», которое оправдывает очень плохое качество кода тем, что «зато мы быстро выпустили софт». Проблема в том, что они не быстро выпустили софт, а при этом другая команда, следящая за качеством кода, выпустила софт плюс-минус за то же время, потому что хорошо писать код — это не обязательно «долго». Я уверен, что и в твоей практике были примеры писания «долго и плохо», потому что в моей они были.

То есть, человек, который насрал и размазал говно по комнате, не создал «технический долг» — он просто мудак, а «технический долг» — это оправдание, которым он прикрылся. Так вот, Java медленная не потому, что это требуется для сверхнадежности, а потому, что это говно. Да, говно долго проектировали, обдумывали, но по итогу получилось говно, потому что делали его мудаки. Даже если бы они 20 лет делали прототипы и обновляли архитектуру, то все равно получилось бы говно, и именно потому ЯП, сделанный за 10 дней, отнимает нишы у Java.

Если интересно, в чем же была ошибка архитекторов Java — я уже писал выше, главной ошибкой были классы, они позаимоствовали всё худшее из C++, потому что в их среде манагеров именно это худшее лучше всего продавалось, поскольку позволяло создавать видимость бурной деятельности через дополнительные сущности. Даже сам C++ по итогу отходит от идеи классов с наследованием и интерфейсами — и в том числе наличие виртуальных методов чудовищно бъет по производительности, поскольку процессорам тяжело предсказывать переход по динамическому указателю. И да, сам C++ точно так же продавался некомпетентным манагерам, именно потому он настолько ужасен.

Я например не присутствовал, но знаю что первая команда Гугла была 35 человек и штук 30 серверов, которые им донатили. Причем донатила та же страшная корпоративная Sun.

Тебя уже поправили — изначально это была два студента, Брин и Пейдж, которые на гранты ЦРУ (если быть дотошным — Massive Digital Data Systems) пилили системы обработки инфы в сарае. То, что их институту «задонатила» Sun — это был средний workstation/entry-level сервер, и вообще там был зоопарк «я его слепила из того, что было»:
https://www.pingdom.com/blog/original-google-setup-at-stanford-university/

И не поверишь но Гугл не был ни первым ни самым крупным - уже существовал Yahoo и неплохо себя чувствовал.

Довольно плохо себя чувствовал яху во время рассвета Google, они вообще не видели в интернет-поисковике перспектив и первое время использовали Google для поиска, а к кризису 2008 года подошли с массовыми увольнениями.

...любая техническая задача конечна.
Для прикладных задач всего этого нет, поэтому ты сможешь проверить какую-то низкоуровневую логику но не лапшу из REST-вызовов...
Отсюда следует что у системного софта качество и надежность всегда будет выше, но писать его дольше и поддерживать сложнее.

Опять же апеллируя к примеру с техдолгом: разница не в том, что задача требует писать «лапшу из REST-вызовов», а в том, что выполнять задачу поручат некомпетентному программисту, который знаком с прикладной задачей. Причем, зачастую главный фактор здесь «дешевый некомпетентный програмист», а не «знаком с прикладной задачей», потому что «прикладных задач» много, садить на всех них дорогих программистов не по карману. Но иногда бывают и сложные прикладные сферы, вроде мат моделирования (математики почему-то поголовно плохо программируют, но при этом среди химиков много способных программистов).

Однако же, я не вижу как вся эта аргументация вяжется с твоим посылом «жава — ­просто хорошая платформа для прикладников», и тем более я не согласен с подобными выводами.

Нет ощущения что это какая-то тайная технология предков, тысячелетиями варившася внутри башен Гугла

Например, система управления сорцами через монорепу у гугла собственная закрытая. Там еще дохерища других технологий, которые неопубликованы, но Go решили опубликовать. Факт публикации/закрытия никак не соотносится со степенью готовности к проду. Например, у них есть репозиторий, где они публикуют свои исследовательские проекты. Те же трансформеры, лежащие в основе ChatGPT, были разработаны и в 2017 году опубликованы гуглем.

Просто «написание сервисов» это теперь тоже ниша. Настолько большая что в JavaEE убили концепцию сервера приложений ради влезания в эту нишу по ноздри.

На момент публикации Go никакой микросервисной лихорадки не наблюдалось, стабильный Golang 1.0 вышел в 2012, альфа-версия Docker — 2013, Kubernetes 1.0 — 2015.

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

Но не все дойдут до понимания того, что один сервер — это одна точка отказа. Что производительность не является определяющим фактором — я даже не пытаюсь спорить, неспроста люди пишут веб-сервера на питоне (youtube и instagram не дадут соврать).

JS примерно так и построен

С абстрактностью вот только беда.

Когда пишешь на JS — представляй себе розовых бегемотиков, бегущих по лужайке.

Например, система управления сорцами через монорепу у гугла собственная закрытая.

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

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

Где-то это целесообразно, когда такая открытость потенциально дает бесплатных тестировщиков, где-то нет.

Там еще дохерища других технологий, которые неопубликованы, но Go решили опубликовать

Повторяю, это большая корпорация, внутренние процессы которой не поддаются оценке. Особенно если пытаться сделать это из Барнаула,Алтайский край.

Но не все дойдут до понимания того, что один сервер — это одна точка отказа.

«Да но нет».

Дело в том что имея один мощный сервер очень просто организовать отказоустройчивость - покупается еще один такой же сервер, настраивается и держится дальше в режиме ожидания.

Время от времени можно делать плановые проверки - запускать этот запасной сервер вместо основного.

Этим достигается максимально возможная надежность, поскольку все это просто и процесс поддается описанию и четким инструкциям.

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

Вообщем это целый отдельный мир со своими правилами и законами, лезть в который может себе позволить лишь крупная компания, давно прошедшая стадию больших серверов.

Когда пишешь на JS очередной my-twisted-set-map — представляй себе розовых бегемотиков, бегущих по лужайке.

Починил.

Извините а:

Go, конечно, куц

Это разве не означает что язык лаконичный ?

Знаешь, есть такое понятие «технический долг», которое оправдывает очень плохое качество кода тем, что «зато мы быстро выпустили софт».

Это лишь частный случай, может быть просто моральное устаревание, может быть хороший код но на неподдерживаемой более технологии или решении.

Так вот, Java медленная не потому, что это требуется для сверхнадежности, а потому, что это говно.

Барнаул, Алтайский край ага. Твоя проблема заключается в том что до сих пор и всерьез думаешь будто твое мнение по столь глобальным вопросам чего-то значит. Это не так.

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

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

Поэтому просто прими как факт что оно существует и будет жить невзирая на твою волю или пожелания.

именно потому ЯП, сделанный за 10 дней, отнимает нишы у Java.

Тут COBOL до конца похоронить не могут, а ты про современный язык такое пишешь.

Если интересно, в чем же была ошибка архитекторов Java — я уже писал выше, главной ошибкой были классы,

Это еще одна твоя большая ошибка: ты не можешь никак определиться со смыслом своей работы.

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

И тебе придется их полюбить - тех самых тупых недоучек, без полного высшего технического образования, ничего не знающих об алгоритмах, внутренностях ОС и работе компилятора.

Вот ты говоришь что классы это плохо. Не хочу развивать очередной технический спор, но взгляни на это глазами бизнесмена: если большая часть прикладной логики замечательно вписывается в концепции ООП - зачем от этого отказываться?

Выдав решение без классов, ты тем самым своими же руками ограничишь его популярность. Оно надо?

Однако же, я не вижу как вся эта аргументация вяжется с твоим посылом «жава — ­просто хорошая платформа для прикладников», и тем более я не согласен с подобными выводами.

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

Недавно в соседней теме это обсуждали. Классы это всего лишь одна из реализаций в ООП, и можно вообще обходится без классов в ООП.