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

Ошибаетесь.

Возможно. Но когда кто-то заводит шарманку о том, что проблемы с data race решаются тестами и что о data races можно подумать заранее, чтобы покрыть эти случаи тестами, то у меня есть веские основания считать, что человек в данной теме дилетант.

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

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

Что-то изменил. Например, добавил GC и поддержку модулей. Что-то унаследовал (вроде каналов, секций alt и adt). Поэтом на этом вырос Go.

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

Ответы от докладчика, который даже и близко свечку не держал? Блин, да это именно что «Карузо напел». Кроме того, ответ касался того как в реализации Go появился код, относящийся к Plan9/Limbo. Но это не имеет никакого отношения к тому, зачем Google нанимал Пайка.

Пайк, кстати говоря, пришел в Google в 2002-ом. А Go начал делать полуподпольно в 2007-ом. Вот и думайте (с)

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

Ну и какие предложения? Отложить релиз до тех пор, пока не получится конфетка? Разрабы языка не всесильны, чтобы успеть к сроку всё.

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

вот только перл в этот тред не несите пожалуйста

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

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

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

Если ты когда то это заучил и привык - ну молодец. А если пытаешься понять с точки зрения логики - ну ССЗБ.

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

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

Суть претензии вообще не очень ясна.

Это как бы не претензия. Это что-то вроде объяснения того, почему некоторые люди от выразительности Go плевались и почему у Go репутация языка «для дебилов» и «простых задач».

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

Тем, кто оказался в такой же ситуации, Go успешно зашел.

Для остальных остается вопрос «а нафига этот примитив вообще был нужен в наше время?»

Почему PHP лучше Node js для высоконагруженных баз данных

Для остальных остается вопрос «а нафига этот примитив вообще был нужен в наше время?»

В чём примитивность? Неспособность написать стрелочки <> возле реализации своего контейнера O(n^n)?

Чисто предъявы по цвету кожи.

Реальный примитив — это, например, async/await.

Возможно. Но когда кто-то заводит шарманку о том, что проблемы с data race решаются тестами

У вас явные проблемы с понимание прочитанного, потому что я такого не говорил. Я говорил о том, что тестами проверяется отсутствие таких проблем. Иными словами проблемы с data race решаются вовсе не тестами.

дилетант

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

Я говорил о том, что тестами проверяется отсутствие таких проблем.

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

Иными словами проблемы с data race решаются вовсе не тестами.

И как это соотносится со сказанным вами ранее:

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

Это ведь вы именно так ответили на вопрос о том, научился ли Go защищать от data races.

Может быть дилетант - как раз вы сами?

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

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

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

Наверное, только я и генерировал этот трафик :)

В чём примитивность?

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

Неспособность написать стрелочки <> возле реализации своего контейнера O(n^n)?

Обобщенное программирование – это не только контейнеры. Но даже если взять контейнеры, то что предлагал пользователю первый Go, если пользователь хотел реализовать свой разреженный вектор?

Есть у меня подозрение, что типичный перекладыватель JSON-ов или условный админ, вроде @ugoday, которому иногда нужно небольшой утилитарный скрипт наваять, не нуждается ни в каких разреженных векторах. Поэтому им хватает того, что в Go положили авторы.

Ты опять неправильно прочитал вопрос. Вопрос в том почему такая система типов оказалось мало распространенной хотя ещё дедушка Вирт эксперемениторовал с ней в лохматые годы?

ЗЫ, хватит уже скармилавть мои сообщения БЯМ, я с ней и сам поговорить могу.

Ничуть не удивлюсь, наверняка чтобы не было такого https://xkcd.com/303/

Чего?

Как инжектить эти и будущие реализации двух и более интерфейсов?

Как решишь инжектить так и будешь инжектить, не понял вопроса.

наверняка чтобы не было такого https://xkcd.com/303/

По-моему один из рассказов о том, как вообще появился Go начинался с того, что «пока у Пайка шла 45-минутная компиляция C++ного проекта Томпсон и Пайк разговорились о том, что бы они хотели иметь вместо C++ и Java».

Так что это и не комикс вовсе :)

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

Прекращайте разговаривать сами с собой. Тем более на форуме.

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

Доказать математически наверное не могут. Доказать практически могут.

Иными словами проблемы с data race решаются вовсе не тестами.

И как это соотносится со сказанным вами ранее:

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

Это ведь вы именно так ответили на вопрос о том, научился ли Go защищать от data races.

Так и соотносится. У вас есть способ найти проблему и дальше решить её другими имеющимися в Go способами. Вы этому противопоставляете свойство Rust не допустить такую проблему в принципе, но умалчиваете о цене этого свойства Rust. В итоге такого рода проблемы в Go легко выявляются и относительно легко решаются, в то время как в Rust вас заставляют жить по уставу и за малейший отход от политики партии и правительства ломают билд с громкими воплями от компилятора. Я не говорю, что подход Rust априори неверный. Он просто неуниверсальный и годиться лишь для определённого типа проектов, а именно для системного программирования. Если же вы занимаетесь разработкой какого нибудь ERP, подход Rust будет изрядно мешать, увеличивать сложность, замедлять разработку и т.д.

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

Так и запишем, что вы ещё и с анонимными экспертами выпиваете :-)

Наверное, только я и генерировал этот трафик :)

Вернись, мы всё простим :-))

свой разреженный вектор

Просто хочу убедиться, что в вашем споре с @kaldeon понял вас правильно. Вы говорите про массив, большинство элементов которого равны ноль-значениям? Если так, то разве в том числе не для этого придуман map? А тогда зачем кому-то изобретать свой собственный разреженный вектор?

Как решишь инжектить так и будешь инжектить, не понял вопроса.

Как инжектить реализацию нескольких интерфейсов? В Java ты не можешь объявить тип поля класса несколькими интерфейсами одновременно. Ты можешь создать свой интерфейс, который наследует от нескольких, но реализации этих нескольких интерфейсов не будут реализовывать твой новый интерфейс, по крайней мере если автор этих реализаций не ты. Ну и как тут быть без утиной типизации?

Чисто для иллюстрации. В Java есть интерфейсы List<T> и Deque<T>. Класс LinkedList<T> реализует оба эти интерфейса и если тебя всегда устраивает эта реализация, ты можешь сделать coupling на неё. Но допустим тебе принесли стороннюю библиотеку с другой реализацией интерфейсов List<T> и Deque<T> в одном классе. Как его инжектить в твой код, то есть как всё таки сделать decoupling? Иными словами как использовать dependency injection с такими классами, сразу реализующими несколько интерфейсов которые тебе нужны одновременно?

Утиная типизация решает эту проблему не напрягаясь.

Начни с себя, аноним.

Доказать практически могут.

И практически не могут.

У вас есть способ найти проблему и дальше решить её другими имеющимися в Go способами.

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

Причем, что самое плохое, возникновение data races может зависеть чуть ли не от фазы луны. В 99.9% случаев у вас все работает нормально, затем при каком-то случайном стечении обстоятельств, одна гороутина отработала чуть медленнее, пересеклась по времени с другой и вы получили data race со всеми вытекающими.

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

Далеко не только. Какой-нибудь условный Excel, который будет использовать современные многоядерные процессоры для параллельного пересчет ячеек, связанных сложными формулами, тоже попадет под проблему с data race.

Но да, на Go такие задачи тоже не решаются.

Так и запишем, что вы ещё и с анонимными экспертами выпиваете :-)

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

Вы говорите про массив, большинство элементов которого равны ноль-значениям?

Не совсем. Их просто нет. Физически.

Но, в качестве некоторой апроксимации, вы можете считать что они равны ноль-значениям.

Если так, то разве в том числе не для этого придуман map?

map – это ассоциативный контейнер. Что ведет к двум последствиям:

1. Далеко не факт, что доступ через map будет эффективнее, чем доступ через специализированный разреженный вектор;

2. При некоторых способах реализации map (например, через хэш-таблицы) будет не так-то и просто делать перебор существующих значений строго слева направа (или строго справа налево).

А тогда зачем кому-то изобретать свой собственный разреженный вектор?

Чтобы программа не тормозила. Но если Go-шникам важно обгонять Python, то как бы да, зачем?

Да вы, сударь, шутник. Тут местную публику от map/filter/reduce десятилетиями ломало, бо на привычный for(int i = 0; i<n; i++) совсем не похоже. Оно конечно программист на фортране может написать программу на фортране на любом языке, но столкнувшись в тёмном переулке с хаскелем непривычный гражданин максимум сможет одарить его взглядом благородного животного Ovis aries на новые ворота.

понять что нужно от программы тем, кто её заказывал

Опасно, можно ненароком превратиться в менеджера.

путём минимальных изощрений.

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

Не совсем. Их просто нет. Физически.

Ну вот и в map их тоже просто нет.

Далеко не факт, что доступ через map будет эффективнее, чем доступ через специализированный разреженный вектор

O(1) - это недостаточно эффективно?

При некоторых способах реализации map (например, через хэш-таблицы) будет не так-то и просто делать перебор существующих значений строго слева направа (или строго справа налево)

Параллельно с map заводите сортирующую коллекцию индексов (они же ключи в map)

Чтобы программа не тормозила. Но если Go-шникам важно обгонять Python, то как бы да, зачем?

Ну а взять готовую реализацию в виде сторонней библиотеки - это некошерно?

Ну вот и в map их тоже просто нет.

Вы спрашивали что такое разряженный вектор. Я вам рассказал. Не нужно мне доказывать, что-то касательно map-а.

O(1) - это недостаточно эффективно?

O(1) говорит об условном количестве неких абстрактных операций для доступа к элементу. Но ничего не говорит о стоимости одной конкретной операции.

Параллельно с map заводите сортирующую коллекцию индексов (они же ключи в map)

И у вас увеличивается стоимость решения как по памяти (дополнительный map), так и по дополнительным действиям в операциях insert/erase.

Браво.

Ну а взять готовую реализацию в виде сторонней библиотеки - это некошерно?

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

Доказать математически наверное не могут. Доказать практически могут.

М-м-м-м… Это же моё любомое:

- У заказчика проблемы …
- У меня все тесты пройдены!!11

И практически не могут.

Голословно.

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

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

Причем, что самое плохое, возникновение data races может зависеть чуть ли не от фазы луны. В 99.9% случаев у вас все работает нормально, затем при каком-то случайном стечении обстоятельств, одна гороутина отработала чуть медленнее, пересеклась по времени с другой и вы получили data race со всеми вытекающими.

Именно для этого придумали юнит тестирование и на уровне такого низкоуровневого (если так можно выразиться) тестирования go test -race будет падать гораздо чаще 0.1% случаев.

Но да, на Go такие задачи тоже не решаются.

В Go плохо с десктопным UI, но если трансформировать ваш пример с Excel в нечто подобное на бэкэнде, Go с этим справится очень хорошо.

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

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

Но когда шаблоны в C++ добавили, то Гослинг сотоварищи просто проморгали это революционное изменение в языке.

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

У тебя тесты негодные ибо в TDD не умеешь.

Видео? Нет пути! Тем более, что спрашивалось-то опровержение вполне конкретных претензий к PHP, а не то, что какие-то другие языки ещё хуже PHP в каких-то задачах.

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

Начиналась так, да.

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

Справедливости ради нужно сказать, что в создание первой версии Java было вбухано столько ресурсов, что просто ой. И даже не столько в сам язык, сколько в JDK. Ведь к тому моменту Java стала чуть ли не первым языком с таким количеством «батареек» из коробки да забесплатно. Полагаю, что где-то в начале 1990-х Sun решило вбухать кучу бабок в Java на этот самый JDK. И когда процесс пошел, менять сам язык уже было невозможно.

Есть у меня подозрение, что С++ необратимо калечит мозги и в результате условный плюсовик, вроде @eao197, неиронично считает недостатком языка его неспособность почесать левое ухо правой пяткой. Кроме того отчего-то начинает считаться, что язык программирования это как жена или любимая футбольная команда — выбирается один раз и на всю жизнь. Тогда как у нормальных людей язык — это просто инструмент. Если он хорошо подходит для решения широкого класса задач — это замечательно. А если в каком-то случае лучше подходит другой язык, просто его и используешь.

Голословно.

Ну да, не далее как вчера в коде на реальных данных всплыл data race, который не всплывал на тестах. Это все не считается, нужно верить тому, что hummer рассказывает.

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

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

Точно так же, на практике, бывает и с предположениями о корректности кода.

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

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

ну вы поняли

У тебя тесты негодны

Ну вот! У нас теперь есть настоящий программист, который никогда не ошибается в тестах!

Да, помню, популярная была мулька «раз программа скомпилировалась, значит она работает правильно».

Это конфабуляция. Тревожный звоночек.

конфабуляция

Стадия первая: «отрицание».

Ты можешь продемонстрировать доказательства своего утверждения. Или не можешь?

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

Ты описал ситуацию которую утиная типизация как раз не решает а ухудшает.

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

архивы лора

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

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

Например: «Цель – если код скомпилировался, то он будет работать в соответствии со спецификацией.»

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

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

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

Ну вот нашелся близкий по смыслу, про Rust: тыц (linux.org.ru)

Disclaimer: по-моему, близкий по смыслу, а не точь в точь.

Вы спрашивали что такое разряженный вектор. Я вам рассказал. Не нужно мне доказывать, что-то касательно map-а.

Вы решили блеснуть умом и рассказать, что разреженный вектор не хранит ноль-значения физически, я вам рассказал, что map также хранить ноль-значения не обязан.

O(1) говорит об условном количестве неких абстрактных операций для доступа к элементу. Но ничего не говорит о стоимости одной конкретной операции.

O(1) говорит о сложности, то есть о росте стоимости с ростом количества данных или операций. На больших количествах данных сильный рост стоимости очень быстро перекрывает дешевизну первой операции. Например полное сканирование большого Си массива дороже поиска в двоичном дереве. Если же у вас немного данных, зачем вам что-то сложнее обычного массива?

И у вас увеличивается стоимость решения как по памяти (дополнительный map), так и по дополнительным действиям в операциях insert/erase.

А ваше решение не имеет никакой дополнительной стоимости?

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

Я говорил об использовании сторонней библиотеки. Причём тут язык программирования?

там какое-то засилие именно JS/TS

задайся вопросом: что пишут на этих языках. далее задайся вопросом: это они выросли или их конкуренты упали?

все таки на дворе массовые увольнения кнопкодавов.

пафосно выдавать их за IT индустрию.

Можно подумать здесь какие-то особенные хаскеллисты водились. Они и на хабре, и на хакерньюсе точно такие же были. Потом начали претворять свои лозунги в жизнь и ВНЕЗАПНО выяснилось, что отсутствие проблем с типами гарантирует только отсутствие проблем с типами.