Что происходит с популярностью Go?

Даже отдалённо Go с Rust не конкурирует. Rust - это язык системного программирования, а Go предназначен для апликативного программирования и микросервисов.

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

На Расте ты будешь постоянно воевать с borrow checking

Написать такое - расписаться в том что на rust не написал не строчки, а может и вообще ни на чём, потому что фраза эквивалентна «воевать с ошибками компилятора». Даже если бы ты программировать не умел, но попробовал бы, мог бы совершенно комфортно писать clone на каждый чих, без ссылок и, соответственно, БЧ. Работало бы, ЧСХ, всё равно быстрее чем go. В то что умеющим программировать БЧ не мешает ни разу, с таким уровнем поверить наверное сложно, поэтому не буду пытаться убедить.

и тяжёлым синтаксисом

Тяжелы синтаксис это if err != nil { return err } после каждого вызова который может вернуть ошибку. У rust в синтаксисе ничего тяжёлого нет.

Я подумал, что там питонисты решили в плюсы поиграть. И проиграли.

Круто, что так вообще можно. Но плохо, что так вообще нужно. Проще уж взять Go и не разводить зоопарк.

Ну там в целом вся реализация сплошная хохма. Например питон единственный у кого в жрпц удалось сделать стриминг медленнее чем unary

А вот раст поразил стабильностью. Вон у меня моя утилита для работы с клавиатурой месяцами не растет в потреблении ни на байт.

Чему там поражаться? Если переменные убиваются вместе с функцией, в которой они живут. Там утечку организовать только специально можно.

А вот в раст да - сделать утечки можно, но нужно очень постараться.

Это что значит? Я помню как то год назад тут разбирали какой то раст проект весь сплошной унсафе. А когда спросил почему так. Ну так или шашечки или ехать.

Вот, ускорьте его в 10 раз и горутины добавьте. Тогда можно будет начать рассматривать в качестве кандидата.

… Добавьте интерфейсы, уберите бросание ошибками и переименуйте его. И получите Го.

P.S. А вот что будет, если среднеми питонисту вручить Rust я предсказать не берусь.

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

Ну вот я - питонист. Про раст читал только в книжках.

В книжках? Вы про книгу официальное руководство по Раст? https://doc.rust-lang.ru/book/

Из современных только php хуже

Современный пых порядка на 2 лучше современного жса.

А есть какое-то целостное изложение чего там со времён приснопамятного фрактала плохого дизайна поменялось к лучшему?

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

Нет, Beginning Rust Хорошая книга, просто и доступно всё объясняет.

При чем тут самовнушение, если я вижу это на практике?

А я на практике вижу много–много программ написанных на C++ и подобных языках которые работают без утечек памяти.

В расте даже специально добавили функции для утечек, напр, Box::leak(), forget(). Вот товарищ такой, зачем я буду делать нормально? Тут же точно никогда логики не будет, поставлю forget(). А потом логика с drop появляется…

Javascript: фрактал отсоса

Главная проблема JavaScript — это ты

Но всё рушится, когда появляется один из тех программистов, которые искренне верят, что JavaScript это язык на котором будут разговаривать наши дети, а код на нём должен идти из глубины души. А тем у кого душа неспособна рождать код, чистый как слеза ребенка, чьим первым словом не было слово „var“, тем в душу надобно плевать до полного очищения. Что доморощенные гуру JavaScript и делают, неискренне упиваясь самопожертвованием от нахождения в среде таких бездарностей, и совершенно искренне гнобя эту среду. Конечно, наступление мира во всем мире при начале использования вами JavaScript такими его адептами не декларируется, но подразумевается. Также ими подразумевается, что все недостатки, находимые в языке — лишь продолжение его достоинств, а если кто с этим не согласен, то это неосиляторство. Хотя единственное, в чем можно обвинить неосиляторов — недостаток веры. Боже храни вашу команду от таких. Ну или пусть он будет один, но будет тимлидом.

К сожалению, эти же люди искренне не понимают как можно не любить JavaScript, хотя из доступных им аргументов можно перечислить всего два — их субъективную любовь к языку, а также его высокую популярность, которую они ошибочно обуславливают плюсами языка, которые в свою очередь неоспоримы (см. первый аргумент). Работать с ними тяжело, потому что грань между стремлением к совершенству и ЧСВ очень тонка, а конфликты на работе неизбежны. Их же советы использовать JavaScript для своих задач могут создавать стойкую иллюзию разговора с коммивояжером. Дискуссия же о недостатках JavaScript доставляет мало приятного.

Наверняка, многим серьезным веб-программистом преходилось испытать неприязнь, когда они узнавали, что чтобы выложить веб-сайт надо еще изучать пхп. Все соглашаются (и в интернете я тоже читал) что это очень, очень плохой язык. Это на самом деле глупость и когда я прочитал я долго не мог поверить ходил спрашивал и оказалось не зря. Тепер ьвеб-сайты можно писать на самом популярном в мире языке джаваскрипте. Это революционный переворот и он происходит прямо на наших глазах. Что это значит для нас, ребята? Что мы уже знаем, как писать сйты по сути. Я был шокирован, как там все организовано, но похоже они все вопросы продумали с самого начала и договорились что это будет очень востребованный проект.Более того, умные C++ перцы из гугл которые по утрам ездят в автобусах набитых баскетбольными мечами уже работают над тем, чтобы джаваскрипт работал быстрее С++, потому что он комплируется сразу в результат, минуя стадию вычисления! Вы наверняка заметили это по тому, что gmail.com открывается за 5 секунд, а не 20 как это было в до-интернетную эпоху, может хотя бы самые древние. Его кстати тоже делали в гугл. Что это если не порыв я не знаю. То есть, если вы напишете свой сайт на nodejs, он автоматически будет бытсрым и будет масштабироватсья (обрабатывать столько клиентов, сколько пришло, это настоящая проблема в пхп была и некто не знал как с ней быть). Например, данные между разными запросами не изолированны и вообще можно использовать одни и те же глобальные переменные для всех клиентов и экономить память. В том же пхп это в принципе не возмонжно и засчет этого у ноды такая гиганская производительность. Там даже продумано если вы будете работать с другом или кто-то допустим, то я зык специально за счет очень удобной типизации можно писать так что вы не будете знать что и как вам передает ваш друг. Это очень удобно потому что позволяет меняь програму в одном месте и вообще не парится о том же друге что там у него програма все равно запустится.Только представьте! Любой кусок кода можно насать один раз. Например, функцию, переворачивающущю строку, и вызывать ее из браузера или включать музыку с телефона. Особенно если заморочиться совместимостью северного кода и особеностей разных браузеров. Также они добавили возможность создавать внутри функции другие функции и это очень круто, но я пока не понял как потом вернуться в первую функцию. Но самое главное, что над нодой сейчас работает туча народу просто, они переписывают все что было до них написано на ноду и у них получается лучше потому что они сразу заточились на производительность и чтобы было лучше а так же просто использовать. Например нужно сходить в базу данных создал проект на гитхабе сразу набежали форкнули завтра только пуллреквесты принять и можно заливать в продакшн на свой ноутбук. Сообщество очень дружелюбное, если кому-то удается сделать что-то работающее на ноде его обязательно хвалят и подбадревают потому что это правда успех. Я пока не понял как допустим считать файл но говорят эт из-за безопасности,там все очень надежно, ведь если к тебе вдруг идет миллион клиентов и вы облажаетесь в 10% случаев ты облажаешься перед 100 000 человек. Поэтому например если где-то произошла ошибка лучше сразу аккуратненько завершиться чем пазориться перед остальными, тем более если перезапустить сервер то там и память лишняя освободится и бегать начнет пошустрее, да и перезапускается он очнь бытсро. Иногда бывает быстрее перезапустить сервер чем дождаться окончания сборки мусора. Ктому же nodejs так оптимизирован что никогда не займет больше одного ядра а это значит что базу данных например можно поставить на тот же ноут на другое ядро для экономии ресурсов и надежности (иметь что-то на той же машине всегда надежнее, много ли что, все у кого есть дома интернет вы это итак знаете) и все будет быстро бегать и даже можно во что-нибудь пошпилить или дальше форум по nodejs почитать но тогда надо побольше ядер купить. Но в серверы как раз много ядер и ставят и как видите nodejs прекрасно справляется с этой задачей. Правда что бы писать на ноде нужно купить макбук потому что все примеры в интернете написаны на мак буке но я думаю если выделаете высокопроизводительный веб-сервис, вам всеравно прийдется пройти раунд финансирования у родителей чтобы потом его запускать. Вообщем я в восторге хотя немного напрягает что гдето должны быть проблемы но я пока не понял не столкнулся ая уже очнь долго с ней разбираюсь и пока не понял.

https://tonsky.livejournal.com/266519.html

есть ощущение что это писал пользователь винды.

Критика PHP: множество толковых технических замечаний.

Опровержение: Какое-то словоблудие под гомосексуальным заголовком.

Фу!

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

Ian Lance Taylor присоединился к команде Go в 2008 году [1].

Russ Cox, будущий лид проекта, в 2009 год дал недвусмысленно понять, что Go не исключает включение в язык дженериков [2].

Первое предложение дженериков от ILT было выдвинуто в 2011 году [3].

В 2022 году дженерики были включены в язык [4].

Эти факты позволяют сделать следующие выводы:

. Го практически с самого начала не был против дженериков. Проблема была в том, как аккуратно внедрить их в существующую модель. Го — не Джава и не Си++, поэтому банальный перенос 1-к-1 исключён. Главным (но не единственным) препятствием была уникальная концепция интерфейсов в Го.

. На разработку дженериков у ILT ушло 11 лет. Назвать эту работу «большой и простой» как-то язык не поворачивается.

. Дженерики были добавлены в 2022 году. Сейчас 2026. За 4 года больше не было никаких значительных изменений в языке.

[1]: https://www.airs.com/blog/archives/670

[2]: https://research.swtch.com/generic

[3]: https://github.com/golang/proposal/blob/master/design/15292-generics.md

[4]: https://go.dev/blog/go1.18

Вот вышла статья разгромная довольно давно, есть какая-то актуализация по данной теме?

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

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

Хайп спал. Теперь в моде Rust. А язык выживет: Fortran, Ada, COBOL, Pascal, Ruby вон никуда не делись.

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

несознанка по вайлдкардам

Можно подробнее? Не понимаю о какой конкретно части языка идет речь.

куцые метод-левел дженерики

Дженерики на уровне методов будут добавлены в 1.27 [1]

[1]: https://go.dev/doc/go1.27

Мое имхо иногда удобнее бросить исключение чем прокидывать ошибку наверх через 100500 вызовов функций.

Основная проблема в том, что поощрение исключений превращает обработку ошибок в чью-то чужую проблему. И отдувается за всех, как всегда, main. И что сделает main? Ну покажет он стек-трейс, только какая польза в нём, если весь код построен на dependency inversion principle и значительный контекст ошибки, как следствие, потерян.

несколькими потомками Алгола

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

Ясно-понятно. А чего надо-то?

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

В нём можно точно также критические участки переписать на что-то компилируемое (где-то даже самому писать не придётся) и летать будет вполне шустро.

NumPy, SciPy, PyTorch, TensorFlow, OpenCV, и тысячи других библиотек, написанных на Си, C++ и других компилируемых языках.

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

Не понимаю о какой конкретно части языка идет речь.

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

будут добавлены в 1.27

Да, да, за столько лет комьюнити сумело наныть только это.

У тебя там какие-то линки на хабру? Что там?

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

function sum(int $a, int $b): int {
    return $a + $b;
}

sum(5, "10"); 

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

Думаю, наше разногласие конкретно в «Java была слишкамсложна». Вы и Роб Пайк говорите примерно одно и то же про студентов, но основа разная: у вас про сложность Джавы, до которой студенты не доросли, а у Роба Пайка про то, что студенты не исследователи, то есть не “researchers.” Ресёрчер — это человек, который работает над тем, чего вообще на рынке может не существовать. Соответственно, «навороченный» (“brilliant”) язык в контексте его фразы — это не темплейты C++, а нечто на одном концептуальном уровне с Erlang или Haskell.

Ну и как бы если студенты “probably learned Java,” зачем тогда было бы у них забирать, по-сути, готовый ценный навык: Джаву?

. . . авторы Go . . . Ибо начать делать в 2007-ом году язык без поддержки обобщенного программирования имея перед глазами опыт Java, C# (а так же D и Eiffel), чтобы затем, спустя 15 лет таки добавить генерики в язык…

Авторы Go начали делать дженерики ещё до 2011 года [1]. Проблема была не в том, что они не умели программировать на Java, а в том, что Go — не Java, поэтому перенести опыт 1-к-1 не представлялось возможным. Это все равно что просить Джаву сразу добавить в язык дженерики, имея перед глазами опыт C++.

Основная (но не единственная) проблема заключалась в особенной и нераспространённой в других языках концепции интерфейсов (утиная типизация с проверками компиляции).

[1]: https://github.com/golang/proposal/blob/master/design/15292-generics.md

особенной и нераспространённой в других языках концепции интерфейсов

Хмм, а почему она такая особенная и нераспространенная?

Кроме того, жизнь показала, что сами авторы Go не особо понимали темплейты

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

Утиная типизация с проверками компиляции. Чуть подробнее [1]:

Go's interfaces let you use duck typing like you would in a purely dynamic language like Python but still have the compiler catch obvious mistakes like passing an int where an object with a Read method was expected, or like calling the Read method with the wrong number of arguments.

. . .

Languages with methods typically fall into one of two camps: prepare tables for all the method calls statically (as in C++ and Java), or do a method lookup at each call (as in Smalltalk and its many imitators, JavaScript and Python included) and add fancy caching to make that call efficient. Go sits halfway between the two: it has method tables but computes them at run time. I don't know whether Go is the first language to use this technique, but it's certainly not a common one. (I'd be interested to hear about earlier examples; leave a comment below.)

Проблема с дженериками была в том, что интерфейсы уже были очень динамической частью языка и поэтому дженерики, как отдельная часть языка, неизбежно бы съел часть пирога интерфейсов. Эта одна из тех вещей, которую Go избегает всеми силами: использование разных средств для решения одной задачи. В итоге Go сделал нечто уникальное: скрестил интерфейсы с дженериками, сохранив старую форму интерфейсов как норму. To my knowledge, ни один другой язык ещё не делал такого.

Edit: только сейчас узнал, что Роб Пайк уже озвучил эту проблему [2]:

Critics often complained we should just do generics, because they are «easy», and perhaps they can be in some languages, but the existence of interfaces meant that any new form of polymorphism had to take them into account.

[1]: https://research.swtch.com/interfaces

[2]: https://commandcenter.blogspot.com/2024/01/what-we-got-right-what-we-got-wron...

Это ответ на мой вопрос? Кажется нет.

Я прочёл вопрос как «почему [ты считаешь её] особенной», а не «почему она должна быть такой, а не другой». Могу ответить и на второй вопрос.

В целом, идея в том, чтобы сделать композицию настолько удобной, чтобы программисты не хотели от неё убежать (или эмулировать) в другое средство полиморфизма (зачастую в иерархию типов). И это не я выдумал, а почти пересказ Роба Пайка [1]:

This fluidity of interface satisfaction encourages a different approach to software construction. But before explaining that, we should explain why Go does not have subclassing.

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

[1]: https://go.dev/talks/2012/splash.article

Ты не видишь разницу между application и system?

Я бы снял все огрничения и вернул бы Flash, Silverlight и Java–апплеты.

Ты извращенец?

А Go уже научился защищать от data races?

Давно научился выявлять такие проблемы тестами с -race. А вы в Rust тесты не пишите?

А откуда растовики появляются то. Из тех же самых студентов с питоном.

Нет, типичный растовик - это бывший сишник. И в большенстве контор, куда нанимают растовиков в требованиях вакансии значатся опыт и знание C/C++.

Или ламповый перл

Ой… вот только перл в этот тред не несите пожалуйста. Такого говна наелись сполна.

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

С таким подходом микросервисы можно и на ассемблере писать.

Написать такое - расписаться в том что на rust не написал не строчки, а может и вообще ни на чём, потому что фраза эквивалентна «воевать с ошибками компилятора».

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

Тяжелы синтаксис это if err != nil { return err } после каждого вызова который может вернуть ошибку. У rust в синтаксисе ничего тяжёлого нет.

Нет требования проверять все ошибки. Даже про сам факт наличия ошибки можно узнать не проверяя err. Result в Rust возвращает тебе всё тоже самое, но в одной обёртке. При этом тебе заботливо оставили небезопасный метод unwrap(), который крашит тебе весь код, в отличии от Go, где такого безобразия нет.

Что касается стек-трейса, на самом деле это одна из потенциально проблемных особенностей Go. В отличии от Java, на которой я долгое время работал раньше, в Go стек-трейсы автоматически не генерируются и вообще интерфейсом error не предусмотрены. И вот представь себе ситуацию когда вернулась ошибка, в ошибке даже есть какой-то текст с описанием что это за ошибка, но где именно в коде она возникла и тем более какова была цепочка вызовов из этого текста обычно понять сложно. Да, часто текст ошибки создают как конкатенация своего текста к тексту предыдущей ошибки (что в теории может заменить стек-трейс), но эта конвенция соблюдается далеко не всегда и расчитывать на это нельзя от слова совсем. Так же есть возможность создавать ошибки с вложеными ошибками (так же может заменить стек-трейс), но эта возможность появилась позже и в стандартный интерфейс error не вошла (видимо из соображений совместимости). При этом создать настоящий стек-трейс в Go таки можно, но отдельным вызовом соответствующей функции стандартной библиотеки.

Это все равно что просить Джаву сразу добавить в язык дженерики, имея перед глазами опыт C++.

Именно так и нужно было делать. Java изначально разрабатывалась, как более простой и безопасный C++. Поэтому там нет указателей, множественного наследования (методы по-умолчанию в интерфейсях появились лишь недавно, из-за необходимости притащить в язык жмению нового модно-молодёжного смузи) и прочено. По этой же причине изначально в Java не было ничего похожего на C++ темплейты. Затем в пятой Java таки их сделать, но сделать полностью так и не смогли, якобы из-за недостатка времени. Именно поэтому дженерики в Java - это говняное говно с type erasure и всем, что из этого следует. Например это не гарантирует не отхватить ClassCastException.

Основная (но не единственная) проблема заключалась в особенной и нераспространённой в других языках концепции интерфейсов (утиная типизация с проверками компиляции).

Основной проблемой была всё та же сложность корректной и достаточно эффективной реализации. Слава богам, что по пути недорешений Java в Go не пошли и богомерзского type erasure в Go нет.

мол я никогда не писал на языках с дженериками и не понимаю зачем они нужны.

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

ЕМНИП, в конце 1990-х и начале 2000-х во многих крупных корпорациях были код-стайлы для C++, в которых использование шаблонов запрещалось. Вот не помню, было ли такое в 2000-х в Google.

Хмм, а почему она такая особенная и нераспространенная?

Наверное потому, что распространённая концепция, как с implements в Java просто хуже. Например хуже для dependency injection. Представь себе что у тебя в Java есть два интерфейса и есть несколько классов, которые реализуют оба эти интерфейса одновременно. Как инжектить эти и будущие реализации двух и более интерфейсов? Как это делать со сторонними библиотеками, изменить которые ты не можешь? Утиная типизация помогает, просто потому, что позволяет создать общий интерфейс, включающий изначальные несколько и привязаться к реализации не меняя то, чего нет - того самого implements. Инжектить через такой общий интерфейс в Go можно, а в Java нельзя. Придётся либо отказаться от dependency injection вовсе, либо городить костыли в виде классов-обёрток.

Давно научился выявлять такие проблемы тестами с -race.

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

Вы вот попробуйте дать мутабельную ссылку на один и тот же объект в два треда в Rust-е.

А вы в Rust тесты не пишите?

Я C++ник, за Rust-ом только слежу, т.к. это единственная на данный момент адекватная альтернатива C++ в мейнстриме. И ряд вещей в Rust-е сделан гораздо лучше, чем в C++. В том числе и защита от гонок.

Кстати, на счет видео, которое вы подкинули. Чтобы не быть в ситуации «Пастернака не читал, но осуждаю» мне его таки пришлось посмотреть. И очевидно, что «Пастернака не читали» именно вы. В этом докладе нет ничего, чтобы противоречило сказанному мной (у Go корни из Limbo, а уж откуда растет Limbo углубляться в этом разговоре смысла не было). И уж чего там нет вообще – так это утверждений, что Пайка, Томпсона и др. брали в Google именно для того, чтобы они сделали для Google язык Go.

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

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

Вы вот попробуйте дать мутабельную ссылку на один и тот же объект в два треда в Rust-е.

Если бы это было можно, приводило бы это к data race в 100% случаев? А в 50% случаев? Если нечто более-менее полезное приводит к ошибкам лишь в относительно небольшом проценте случаев, оправдан ли запрет этого более-менее полезного нечто?

у Go корни из Limbo, а уж откуда растет Limbo углубляться в этом разговоре смысла не было

Смысл был, потому что некоторыми чертами Go ближе именно к Alpha, нежели к Limbo.

И уж чего там нет вообще – так это утверждений, что Пайка, Томпсона и др. брали в Google именно для того, чтобы они сделали для Google язык Go.

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

Думаю, наше разногласие конкретно в «Java была слишкамсложна».

Для многих она и сейчас слишкамсложна. Популярность Go тому прямое подтверждение.

это не темплейты C++, а нечто на одном концептуальном уровне с Erlang или Haskell.

Я еще могу понять, когда говорят, что шаблоны C++ не на том концептуальном уровне, что Haskell (хотя, скорее всего, говорящие это никогда в шаблонах от тов.Александреску не пытались разбираться). Но говорить про какой-то концептуальный уровень Erlang-а…

Это все равно что просить Джаву сразу добавить в язык дженерики, имея перед глазами опыт C++.

Так ведь авторы Java конкретно облажались с тем, что они так старательно выбрасывали из C++ все лишнее, что выбросили и шаблоны. Шутка.

Насколько я помню, контуры будущей Java у Гослинга и Ко наметились уже в 1989-1991гг. Когда шаблонов в C++ по сути, еще не было, было только их описание от Страуструпа (по крайней мере в 1989 и 1990). Но когда шаблоны в C++ добавили, то Гослинг сотоварищи просто проморгали это революционное изменение в языке. И потом им пришлось дженерики приделывать сбоку от уже существующего языка и VM посредством синей изоленты.

Важно другое, к 2007-му году уже были яркие примеры:

• Java появилась без дженериков, потом пришлось с трудом приделывать;
• C# появился без дженериков, потом пришлось добавлять, но сделали это быстрее и удачнее, чем в Java;
• D начался как язык без шаблонов в принципе. ЕМНИП, Брайт специально эказывал на сознательный отказ от шаблонов в начале 2000-х. А где-то в 2004 внезапно добавил их в язык, да так, что получилась конфетка по сравнению с тогдашним C++.

Т.е. делая в 2007-ом году новый язык без поддержки обобщенного программирования нельзя было не видеть опыт других языков.

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

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

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

Смысл был, потому что некоторыми чертами Go ближе именно к Alpha, нежели к Limbo.

Которые Limbo унаследовал из Alef.

но мы то понимаем

Ага, уж вы-то точно понимаете. Между строк читаете и все такое.

lavrov.jpg

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

Ошибаетесь.

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

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

Которые Limbo унаследовал из Alef.

В том-то и дело, что не унаследовал, а изменил. Унаследовал Go.

Ага, уж вы-то точно понимаете. Между строк читаете и все такое.

У вас проблемы с ушами или доклад и ответы на вопросы вы не слушали?

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

Это не ограничения, фишка языка, буквально единственная причина его существования. Уберите это «ограничение» и можете язык выкинуть на помойку. Нет, правда, не позорились бы.

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

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

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