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

var быстрее let

везде пихают именно let.

if (true) {
    var x = 'Hello word'
}
console.log(x)
var x = 'test'
console.log(x)

И тому подобные приколы с var. Надо десять раз подумать перед использованием var.

Мне удобно, когда wtf как можно меньше.

Так что в питоне такое не появится

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

Аргумент в стила «а у вас негров линчуют». Мы же сейчас не об этом.

Это в очередной раз о том, что вы не можете в предметную дискуссии – ни пруфов, ни кода, ни вменяемых объяснений.

Вопрос заключался в том, как инжектить любую реализацию этих интерфейсов в одном классе, а не только LinkedList

Куда инжектить, зачем инжектить? Вы примером кода разродиться можете?

Ваш код на Go у меня пока никак не соотносится с вашими словами про Java. А на прямые вопросы вы не отвечаете.

Это к вашему недоумению о том, почему кому-то не хватает ваших словесных «описаний» и зачем просят код.

А сверху ещё можно полирнуть…

Клим Чугункин - стаж!

Куда инжектить, зачем инжектить? Вы примером кода разродиться можете?

Ну дурак! Прямо как в Собачьем сердце: https://www.youtube.com/watch?v=n4SFu2qSGn8

Вы не работали со Spring, не знаете что такое dependency injection, не знаете куда чего инжектят и зачем вообще этот самый dependency injection существует. При этом вы всё равно лезете в спор на эту тему, не просто ничего не понимая, а ещё и будучи совершенно уверенным в своей правоте. Как вас ещё не уволили с таким уровнем необучаемости?

Ваш код на Go у меня пока никак не соотносится с вашими словами про Java.

Ну дурак же! В двух соснах… интерфейсах запутался. Простой пример из Java с простым примером из Go соотнести не в состоянии. Ничего не знает, ничего не понимает, но постоянно требует код, как Шариков водки.

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

Как вас ещё не уволили с таким уровнем необучаемости?

Может быть потому, что я не программирую на Java, не использую Spring, не связываю dependency injection исключительно с Java+Spring?

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

Простой пример из Java с простым примером из Go соотнести не в состоянии

А может ли это быть из-за того, что «простого примера из Java» не было?

Просто оставлю это здесь:

https://innovationgraph.github.com/global-metrics/programming-languages

Может быть потому, что я не программирую на Java, не использую Spring, не связываю dependency injection исключительно с Java+Spring?

А как же Rust? Ведь в нём, в отличии от Java, это как раз можно. Что же вы Rust не вспомнили?

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

Spring - это всего лишь пример фреймворка, в котором dependency injection активно используется. А сам dependency injection с утиной типизацией в Go или с fn foo(x: impl A + B) в Rust становится более гибким.

А может ли это быть из-за того, что «простого примера из Java» не было?

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

Вот, вы тут спорите-спорите, а серьёзные вопросы остаются без ответа: ЧТО СЛУЧИЛОСЬ СО SCALA??!!!!

Интересный график. Особенно если посмотреть по регионам.

Вот, вы тут спорите-спорите, а серьёзные вопросы остаются без ответа: ЧТО СЛУЧИЛОСЬ СО SCALA??!!!!

Один мой бывший коллега (вмести кодили на Java) сначала ушёл в Salesforce, где поначалу был очень рад условиями. Но года через два ушёл в какой-то стартап на любимую Скалу, сказав, что в Salesforce на Java и с тамошней организацией работы он лишь терял квалификацию. Когда мы работали вмести он писал на Java в Scala стиле. Например избегал бросать исключения и вместо этого возвращал их в Tuple.

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

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

Впрочем, влияние гугла отрицать нет смысла. Видимо, все учили, чтобы оффер получить.

Офер в Гугле? Наврядли в этом дело. Скорее влияние гугла больше проявлялось через их вес и их продукты, написанные на Go. Взять хотя бы K8s.

Что же вы Rust не вспомнили?

Зачем? Вы же сравнивали Go и Java. Типа в Java чего-то невозможно. Непонятно только что.

А сам dependency injection с утиной типизацией в Go или с fn foo(x: impl A + B) в Rust становится более гибким.

Чуть ранее вы говорили о чем-то, что на Java невозможно. Видимо, опять с пруфами у вас напряженка.

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

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

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

Что ожидаемо, т.к. вы вновь и вновь доказываете, что в предметную дискуссию не можете.

А что с ней?

Она утонула.

Зачем? Вы же сравнивали Go и Java. Типа в Java чего-то невозможно.

Ну а зачем вы в этой теме вообще Rust противопоставляли Go?

Непонятно только что.

Когда мозгов не хватает, действительно непонятно.

А сам dependency injection с утиной типизацией в Go или с fn foo(x: impl A + B) в Rust становится более гибким.

Чуть ранее вы говорили о чем-то, что на Java невозможно. Видимо, опять с пруфами у вас напряженка.

Я и сейчас это говорю и с пруфами у меня всё в порядке.

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

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

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

Появились. Хватит тупить.

Что ожидаемо, т.к. вы вновь и вновь доказываете, что в предметную дискуссию не можете.

В предметную дискуссию с идиотами действительно не могу. Я не психиатр.

Только у корпорасов. И правильно, ибо нефиг ломать обратную совместимость мимо мейнстрима.

Как бы график выше был по открытым репозитариям Github’а.

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

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

Интересная статистика, особенно по javascript и python.

Ну а зачем вы в этой теме вообще Rust противопоставляли Go?

Для человека, который других называет идиотами, у вас слишком короткая память и неспособность следить за разговором. Но здесь же все ходы записаны, поэтому несложно и напомнить: Что происходит с популярностью Go? (комментарий)

Я и сейчас это говорю и с пруфами у меня всё в порядке.

Ну и где ваши пруфы? Ссылку, плз.

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

Появились.

Пожалуйста дайте ссылку на свой комментарий где есть пример кода на Java.

ИМХО, slices.Sort показывает как оно должно быть. Тогда как sort.Sort без дженериков выглядит как крутой workaround

Workaround, конечно, крутой. Я с помощью sort.Interface смог написать сортировку матрицы по-диагонали, in-place. Абстракция, которая открыла метод, немыслимый напрямую.

Но я думаю, что причина, по которой slices.Sort кажется более правильным, заключается в привычке решать проблемы через иерархии типов. Если бы мы решали проблему в чистом ОО-стиле, то у нас бы должен был быть некий интерфейс SortStrategy, определяющий единственный метод sort, который бы потомки реализовывали как qsort/merge-sort/итд.

И в данном случае без дженериков родительский тип не имел бы гарантий насчёт дочерних типов:

void sort(List<T> list, Comparator<? super T> comparator);

Скажем, если бы мы написали Comparator для Dog, то без дженериков мы бы не смогли его передать в AnimalSortStrategy, по сути делая язык непригодным для полиморфизма.

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

И получить огромный расход памяти и просадку про производительности в случаях, когда хранить нужно int-ы или double-ы.

Машина не устанет :)

С тех пор раз в 3-4 месяца в это дерево добавляются какие-то новые фичи.

Раз в квартал — по-моему, нечасто. Проблема контейнеров без дженериков реальна, но на мой взгляд, не делает дизайн невыносимым (иерархии типов без дженериков намного хуже) и не сильно обременяет клиентов.

Если разработчик ноет про то, что работа с контейнерами недостаточно чисто написана, то что дальше? Ну вот проблема с контейнерами решена в Go, теперь будем ныть, что нельзя fmt.Println(«answer:», strconv.Atoi(«41»))? Не будет ли более зрелым принять тот факт, что идеальная чистота не всегда необходима?

Тип поля за именем стоит, но без разделителя.

Разделители | далеко | не | всегда | нужны.

С недавнего времени появился IO.println()

А так учитывая что тот же Роберт Гриземер прямо вместе с Виртом работал вполе очевидно откуда он и вытащил многие концепты

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

А вот Роб Пайк как раз больше всех остальных хвалил интерфейсы. “I feel that interfaces are one of the best-designed things in Go.” [1]

И если этого мало, то: “the result [of interface composition mindset] is an adaptability of design that is harder to achieve through type hierarchies.” [2] И здесь же, рядом с цитируемым отрывком, пример из Plan 9.

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

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

Go это язык для идиотов же официально? А их нейросети заменили и он стал не нужен

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

А вот факт того, что Go-шники много лет жрали sort.Ints, sort.Strings и пр., . . . очень показателен.

С точки зрения клиентского кода, между slices.Sort(numbers) и sort.Ints(numbers) разницы почти никакой. Здесь нет ничего показательного.

Если же речь идёт о слайсах произвольного типа, то использовали, как правило, sort.Slice, который на поверхности не многим отличается от slices.SortFunc, а в деталях даже мощнее будет, ибо позволяет сортировать в том числе по позиции и по данным из сторонних источников.

Что-то показательнее ещё осталось?

да еще и говорили «не надо нам усложнять язык дженериками»

Далеко не все.

Но ведь нотации типов в Си и Го диаметрально противоположные. В Си — спиральная (принцип соответствия использованию), в Го — постфиксная. Причём Кен Томпсон сам сказал, что решение сделать нотацию такой было принято за 10 секунд [1] (26:30).

[1]: https://youtu.be/sln-gJaURzk

Почему вы не можете в Java сделать обертку над чужим классом

Подозреваю, что ответа на данный вопрос до сих не было. Поэтому попробую ответить я: обёртку сделать можно и нужно. Однако, Go позволяет этого не делать. Достаточно объявить интерфейс на своей стороне и всё, пауза на бухгалтерию окончена.

Это приятное, но не основное предназначение неявной реализации. Основное — сделать композицию лёгким и повсеместным инструментом.

А разделение реализации и интерфейса правильнее объяснить так: реализация не зависит от абстракции и не даёт заранее предопределенных контрактов (implements this, implements that), что позволяет реализации проще их менять (изменения затрагивают только непосредственных пользователей отделённых интерфейсов).

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

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

Если бы мы решали проблему в чистом ОО-стиле

Мне, как C++нику, непонятно зачем решать проблему в чистом ОО-стиле, если ее можно эффективнее решить другим способом.

Машина не устанет

Машина тупо не потянет.

Если разработчик ноет про то, что работа с контейнерами недостаточно чисто написана, то что дальше?

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

теперь будем ныть, что нельзя fmt.Println(«answer:», strconv.Atoi(«41»))?

А ведь на этом примере можно хорошенько пофантазировать о том, что бы было, если бы Go изначально был более выразительным и менее догматичным (в частности по отношению к паникам/исключениям).

Например, были бы в языке дженерики и sum-types, был бы сразу условный Result[T, Err], можно было бы добавить в fmt.Println поддержку вывода для Result. И записывалось бы это так:

fmt.Println("answer:", strconv.FromString[int]("41"));

Или же:

fmt.Println("answer:", strconv.FromString[int]("41").or_else(-1));

Или же:

fmt.Println("answer:", strconv.FromString[int]("41").unwrap());

если нас устраивает выброс паники.

Или, допустим, до sum types не додумались, но относились бы более лояльно к исключениям/паникам:

fmt.Println("answer:", strconv.FromString[int]("41"));

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

Идеальная чистота и недостижима. Но в 2010-х годах отряхивать от нафталина наработки из Alef (конец 1980-х) и Limbo (середина 1990-х) игнорируюя при этом все, что происходило вокруг, чтобы получилось вот это:

v, err := strconv.Atoi("41");
if err != nil {
  v = -1
}
fmt.Println("answer:", v);

ну такое себе. Не следует после этого удивляться репутации «языка для дебилов».

ну такое себе. Не следует после этого удивляться репутации «языка для дебилов».

Вопрос к вам.

Зачем синтаксис C++ так усложнили?
На Си написано много популярных проектов.
Это подтверждает то, что для разработки алгоритмов Си вполне подходит.
И синтаксис прост.

Довольно быстрый и сравнительно простой язык.

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

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

«Где просто, там ангелов со ста. Где мудрено - там ни одного».

Не следует после этого удивляться репутации «языка для дебилов».

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

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

Универсальный и удобный во всём ЯП невозможно разработать с использованием контесных грамматик.

Может это он про англ.?

Я лично изучил чисто из уважения к Роб Пайку, потому что План9 хороший. Потом не использовал пока не пришли БЯМ.

Универсальный и удобный во всём ЯП невозможно разработать.

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

но go уже залез даже на микроконтроллеры https://github.com/tinygo-org/tinygo/

Туда и python залез. Но это уже совсем другая история.

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

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

Мне, как C++нику, непонятно зачем решать проблему в чистом ОО-стиле, если ее можно эффективнее решить другим способом.

Чистый ОО-стиль — бедрок современного программирования. Не подойдёт для sort — подойдёт для чего-нибудь другого, и вот тогда наличие дженериков будет критично.

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

В Го напрямую это выглядело бы так:

Sort(any, func(any, any) int)

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

Машина тупо не потянет.

Неуместный пессимизм.

А ведь на этом примере можно хорошенько пофантазировать

К какому выводу вы пришли, кроме «красиво» и «все остальные так делают»? Довольно поверхностно.

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

strconv.Atoi — это ведь не мелочь какая-то. Усложни его API на уровне языка — усложнится весь язык. Поэтому я лично очень доволен проверять ошибку Atoi каждый раз.

отряхивать от нафталина наработки из Alef (конец 1980-х) и Limbo (середина 1990-х)

А кто-нибудь кроме Go смог должным образом усвоить уроки Alef и Limbo?

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

Не следует после этого удивляться репутации «языка для дебилов».

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

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