Вот посмотрел лекцию по GO.
Неплохой ЯП. Ед-ный вопрос к знатокам: почему нет readonly?
Но! Остался нишевым. Непопулярен среди настолок.
С другой стороны смотрю на zig это будто общая ветка rust -> go -> zig.
defer возвраты ошибок. хотя конечно зиг выглядит более низкоуровневым позволяя точнее контролировать более точно.
Про раст видел сравнение асм-кода с крестами. раст еще не достаточно оптимизирован(кол-во инструкций заметно больше на одинаковом коде).

Р>Вот посмотрел лекцию по GO.
Р>Неплохой ЯП. Ед-ный вопрос к знатокам: почему нет readonly?
Р>Но! Остался нишевым. Непопулярен среди настолок.
А какой популярен среди настолок ?
Го популярен среди меня — хочу на нем писать.
А раст и зиг среди меня не популярны...

Здравствуйте, LaptevVV, Вы писали:

LVV>А какой популярен среди настолок ?
Шарпы(WPF, WinForms), Кресты(Кютэ), возможно java(openFX)
дельфи/лазарус наверно.

LVV>>А какой популярен среди настолок ?
Р>Шарпы(WPF, WinForms), Кресты(Кютэ), возможно java(openFX)
Р>дельфи/лазарус наверно.
Дык давай двигать в эту нишу Го.
Первые 3 — импортозамещать нужно...

Здравствуйте, Разраб, Вы писали:

Р>Про раст видел сравнение асм-кода с крестами. раст еще не достаточно оптимизирован(кол-во инструкций заметно больше на одинаковом коде).

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

Здравствуйте, Разраб, Вы писали:

Р>Почему GO нишевый? Будущее за zig? Ошибаюсь?

Есть разные критерии оценок.
1. Количество вакансий.
2. Зарплатные ожидания.
3. Стек готовых решений.
И так далее.

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

С другой стороны есть популярные языки паразиты, которые просто присосались к C/C++, например, Python. Но потом всё равно оказывается, что нужны программисты, которые переписывают программы с Python на C/C++.

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

Конечно, каждое решение находит свою нишу, но лично тебе она может не понравится, она может не понравится пользователям и заказчикам. В конечном итоге, если сам хочешь, так и пиши на "rust -> go -> zig", никто ведь не запрещает.

Здравствуйте, LaptevVV, Вы писали:

LVV>>>А какой популярен среди настолок ?
Р>>Шарпы(WPF, WinForms), Кресты(Кютэ), возможно java(openFX)
Р>>дельфи/лазарус наверно.
LVV>Дык давай двигать в эту нишу Го.
LVV>Первые 3 — импортозамещать нужно...
Но почему не Oberon BlackBox?

LVV>>>>А какой популярен среди настолок ?
Р>>>Шарпы(WPF, WinForms), Кресты(Кютэ), возможно java(openFX)
Р>>>дельфи/лазарус наверно.
LVV>>Дык давай двигать в эту нишу Го.
LVV>>Первые 3 — импортозамещать нужно...
Р>Но почему не Oberon BlackBox?
Это тоже, но у Го значительно больше стандартная библиотека.
Инфраструктруа — блеск!
И параллельные горутины.

Кроме того, подход к разработке совершенно разный.
Го — традиционный текстовый подход.
А ВВ — это готовая заготовка для настольного приложения.
Народ пока даже не понимает такого подхода.
Если это ВВ вглубь освоить, то перспективы просто ошеломляют. По скорости разработки.
Это как СУБД вместо файлов.
Но стандартная библиотека маловата.

zig не нужен, go там, где сборщик мусора не мешает, rust там, где мешает. Повернуться в Светлое Будущее, с левой шагом марш!

Здравствуйте, LaptevVV, Вы писали:

LVV>Дык давай двигать в эту нишу Го.

ни в коем случае!
го нужно не в настолки двигать, а в ~/.local/share/Trash

LVV>>Дык давай двигать в эту нишу Го.
Ф>ни в коем случае!
Ф>го нужно не в настолки двигать, а в ~/.local/share/Trash
Одни эмоции.
Давай аргументируй...

Здравствуйте, LaptevVV, Вы писали:

LVV>>>Дык давай двигать в эту нишу Го.
Ф>>ни в коем случае!
Ф>>го нужно не в настолки двигать, а в ~/.local/share/Trash
LVV>Одни эмоции.
LVV>Давай аргументируй...

за бедные языковые средства. Выразительность просто никакая — ассемблер чем-то напоминает.
за отстутствие перегрузки функций
за отсутствие исключений и дурацкий способ обработки ошибок
за defer
за непродуманную стандартную библиотеку
а) за идиотизм в виде char/rune
б) за грабли типа функции append()
за go get / go mod vendor / go mod tidy / go clean -modcache (а особенно за то, как это всё временами работает)

отдельной строкой будет стоять go mod why

Здравствуйте, Разраб, Вы писали:

Р>Вот посмотрел лекцию по GO.
Р>Неплохой ЯП. Ед-ный вопрос к знатокам: почему нет readonly?

Не вырос. Спроси у Роберта Пайка.

Р>Но! Остался нишевым. Непопулярен среди настолок.

Не популярен для разработки гуевых программ потому, что для него нет (пока?) приличной гуевой библиотеки...

Р>С другой стороны смотрю на zig это будто общая ветка rust -> go -> zig.

Мне кажется, zig пока очень экзотичен и не вошел еще в mainstream.

А вот еще одна ниша: https://tinygo.org/
TinyGo brings the Go programming language to embedded systems and to the modern web by creating a new compiler based on LLVM.

Здравствуйте, Философ, Вы писали:

Ф>за бедные языковые средства. Выразительность просто никакая — ассемблер чем-то напоминает.
[...]

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

Вся эта херня написана на C с редкими вкраплениями C++. Регулярно падает. Ядро хери написано третьей стороной, которой уже нет. Но оно формально работает (ну, выкинув всю ругань), и надо дорабатывать. Усложнение — что это удалённые железяки и ARM. В плюс — что это ARM/64 со вполне достаточными ресурсами, давки по оперативе, диску, скорости процессора нет.
Уровень людей... ну наших — терпимо. Авторов исходного пакета софта... ну да, они умеют в Linux, а не Windows. На этом положительные слова заканчиваются. И во второй раз за неделю я вспоминаю столь любимого восточным соседом тов. Кобу: "Других людей у меня для вас нет."

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

А все причины, что ты привёл тут —

Ф>за отстутствие перегрузки функций

Не используют.

Ф>за отсутствие исключений и дурацкий способ обработки ошибок

Все ошибки проверяются явно.

Ф>за defer

По сравнению с C был бы даже в плюс.

Ф>за непродуманную стандартную библиотеку
Ф>а) за идиотизм в виде char/rune
Ф>б) за грабли типа функции append()

Все три — пофиг.

Ф>за go get / go mod vendor / go mod tidy / go clean -modcache (а особенно за то, как это всё временами работает)

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

Это называется — бобро поржаловать в реальный мир.

Здравствуйте, netch80, Вы писали:

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

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

Здравствуйте, netch80, Вы писали:

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

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

Здравствуйте, so5team, Вы писали:

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

S>А перспективы Rust или того же zig (если смотрели на него) в таком проекте как бы вы оценили?

Rust для наличного уровня людей неподъёмен.
Zig — вполне может быть, но я не уверен в достаточной поддержке параллельности, ну и таки его пока очень мало и обосновать начальству точно не смогли бы.

Здравствуйте, netch80, Вы писали:

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

У Go возможны data races, так что непредсказуемое поведение всё равно будет. Но в любом случае это сильно лучше чем C/C++

Здравствуйте, LaptevVV, Вы писали:

LVV> А вот еще одна ниша: https://tinygo.org/

Нишу гошечки давно и конкретно определил его создатель — язык для тупых

Автор: rudzuk
Дата: 15.02.22

. (прямая речь

Автор: rudzuk
Дата: 15.02.22

)

Здравствуйте, Разраб, Вы писали:

Р>Неплохой ЯП. Ед-ный вопрос к знатокам: почему нет readonly?
Р>Но! Остался нишевым. Непопулярен среди настолок.

Чем он неплох? Любой сервис на го с БЛ — это уже мрак и ужас. Классическая джава и C# легко его уделывают.
Держится за счет того, что относительно быстрый и хайповый среди хипстеров.

Р>Про раст видел сравнение асм-кода с крестами. раст еще не достаточно оптимизирован(кол-во инструкций заметно больше на одинаковом коде).

Байтосекс не везде нужен.

Здравствуйте, velkin, Вы писали:

V>Есть разные критерии оценок.
V>1. Количество вакансий.
V>2. Зарплатные ожидания.
V>3. Стек готовых решений.
V>И так далее.
+100500

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

V>С другой стороны есть популярные языки паразиты, которые просто присосались к C/C++, например, Python.

У Python — совсем другая ниша, я бы назвал его скорее сопутствующим, нежели "паразитом".

V>Но потом всё равно оказывается, что нужны программисты, которые переписывают программы с Python на C/C++.
Это если менеджеры и тим-лиды недосмотрели. Сразу же можно было (и нужно было) бы выбрать адекватный инструментарий.

V>В конечном итоге программное обеспечение используется в основном пользователями, а не программистами.
Но примененные решения, а особенно просчёты — вполне себе видны пользователю

V>То, что лично тебе было удобно писать встроенный или веб скрипт, может быть абсолютно неудобно пользователям при запуске.
Это должно было выявиться на этапе тестироваиня. Здесь задача выявления проблемы — скорее для QA.

V>Конечно, каждое решение находит свою нишу, но лично тебе она может не понравится, она может не понравится пользователям и заказчикам.
Здесь, если на стороне заказчика — просто пользователи (не поддержка/доработка продукта, а только user) —
нужно уметь отстоять и защитить применённые решения.

Если же заказчик будет развивать (изменять) кодовую базу — с ним всё должно быть согласовано.

Здравствуйте, IncremenTop, Вы писали:

IT>Чем он неплох? Любой сервис на го с БЛ — это уже мрак и ужас. Классическая джава и C# легко его уделывают.
А можете немного раскрыть?
(У меня опыта в GO меньше 0, поэтому просто упомянуть какие-то GO-специфичные конструкции, увы, для меня бесполезно, но если сможете в сравнении с C# показать — будет очень здорово!)

Здравствуйте, LaptevVV, Вы писали:

LVV>>>А какой популярен среди настолок ?
Р>>Шарпы(WPF, WinForms), Кресты(Кютэ), возможно java(openFX)
Р>>дельфи/лазарус наверно.
LVV>Дык давай двигать в эту нишу Го.
LVV>Первые 3 — импортозамещать нужно...

Qt используется в разработке для платформы Аврора.
Типа, наш ответ на Андроид и мобильные железки.

LVV>> А вот еще одна ниша: https://tinygo.org/
R>Нишу гошечки давно и конкретно определил его создатель — язык для тупых

Автор: rudzuk
Дата: 15.02.22

. (прямая речь

Автор: rudzuk
Дата: 15.02.22

)
Понятно, вам шашечки подавай.
А мне ехать надо, и мне пофиг, что язык для тупых — он едет куда мне надо.

Здравствуйте, LaptevVV, Вы писали:

LVV>Понятно, вам шашечки подавай.
LVV>А мне ехать надо, и мне пофиг, что язык для тупых — он едет куда мне надо.

Знакомые которые на нём пишут — одинаково рассказывают, не сговариваясь, что уровень, в первую очередь, копипастинга превышает все разумные пределы и все известные аналоги кода на других языках.
Ругань типа "пока я собирался поменять все 4 места, где что-то надо было менять, добавили ещё 6" совершенно типична.
А вот это уже наверняка результат отсутствия нормального наследования в объектах, соответственно, реюз кода катастрофически усложняется.

А вот куда _вам_ надо чтобы он ехал — я не знаю. Может, как раз в сторону такого копипастинга?

Здравствуйте, Разраб, Вы писали:

Р>Вот посмотрел лекцию по GO.
Р>Неплохой ЯП.

Слушайте, я знаю C#, JavaScript и TypeScript, F#, С и C++, python, ассемблер, изучаю rust, и когда-то давно писал на Delphi и даже немного на haskell.
Объясните в чем преимущество Go перед другими языками. Особенно с точки зрения именно языка, а не того, что вебсервис на pyhon переписанный на go в 100500 раз быстрее работает.

По Go туториал я тоже прошел и синтаксис более-менее знаю.

N>Знакомые которые на нём пишут — одинаково рассказывают, не сговариваясь, что уровень, в первую очередь, копипастинга превышает все разумные пределы и все известные аналоги кода на других языках.
Интересное наблюдение, спасибо.
N>Ругань типа "пока я собирался поменять все 4 места, где что-то надо было менять, добавили ещё 6" совершенно типична.
N>А вот это уже наверняка результат отсутствия нормального наследования в объектах, соответственно, реюз кода катастрофически усложняется.
Это больше отсутствие культуры (для тупых же ) писания кода

N>А вот куда _вам_ надо чтобы он ехал — я не знаю. Может, как раз в сторону такого копипастинга?
Мы копипасту в своей обучающей среде извели как класс.
Отсутствие копипасты мгновенно стимулирует студентов писать функции.
Но переходя к С++ они тут же "влезают обратно на пальму" копипасты...

Здравствуйте, LaptevVV, Вы писали:

N>>А вот куда _вам_ надо чтобы он ехал — я не знаю. Может, как раз в сторону такого копипастинга?
LVV>Мы копипасту в своей обучающей среде извели как класс.

И чем же вы заменили бесконечные if err != nil?

N>>>А вот куда _вам_ надо чтобы он ехал — я не знаю. Может, как раз в сторону такого копипастинга?
LVV>>Мы копипасту в своей обучающей среде извели как класс.
S>И чем же вы заменили бесконечные if err != nil?
вызовом функции...

Здравствуйте, LaptevVV, Вы писали:

N>>>>А вот куда _вам_ надо чтобы он ехал — я не знаю. Может, как раз в сторону такого копипастинга?
LVV>>>Мы копипасту в своей обучающей среде извели как класс.
S>>И чем же вы заменили бесконечные if err != nil?
LVV>вызовом функции...

Жаль, я думал вы говорите всерьез.

N>>>>>А вот куда _вам_ надо чтобы он ехал — я не знаю. Может, как раз в сторону такого копипастинга?
LVV>>>>Мы копипасту в своей обучающей среде извели как класс.
S>>>И чем же вы заменили бесконечные if err != nil?
LVV>>вызовом функции...

S>Жаль, я думал вы говорите всерьез.
1. У нас система обучения была написана в 2012 году. Ни о каком Го мы тогда не подозревали
Однако систему модулей и ООП мы тоже содрали с Оберона — для обучения получилось самое оно

2. Вообще-то я всегда говорил, что обработку ошибок надо проектировать.
Независимо от применяемого инструмента в языке.
Однако мало кто это делает.
Без предварительного проектирования механизм исключений выглядит гранатой в руках обезьяны.
То, что сделано в Го — это дань отсутствию проектирования обработки ошибок.
Ведь если об обработке ошибок не думали (никогда), то самое простое — просто проверить ошибку сразу после вызова функции.

Р>Но! Остался нишевым. Непопулярен среди настолок.

Потому что это язык для server-side backend. Точно так же как Delphi не лучший выбор для бэкенда, Go не позиционируется во фронтенд.

Здравствуйте, LaptevVV, Вы писали:

LVV>То, что сделано в Го — это дань отсутствию проектирования обработки ошибок.
LVV>Ведь если об обработке ошибок не думали (никогда), то самое простое — просто проверить ошибку сразу после вызова функции.

Как бы то ни было, эти постоянные if err != nil являются одним из основных источников копипасты в Go-шном коде.
Если вам действительно удалось от них избавится, то интересно как.

S>Как бы то ни было, эти постоянные if err != nil являются одним из основных источников копипасты в Go-шном коде.
S>Если вам действительно удалось от них избавится, то интересно как.
Еще нет.
Но я подумаю над этой темой при разработке нужной мне системы.

Здравствуйте, gandjustas, Вы писали:

g> Р>Вот посмотрел лекцию по GO.
g> Р>Неплохой ЯП.

g> Слушайте, я знаю C#, JavaScript и TypeScript, F#, С и C++, python, ассемблер, изучаю rust, и когда-то давно писал на Delphi и даже немного на haskell.
g> Объясните в чем преимущество Go перед другими языками. Особенно с точки зрения именно языка

1. горутины это вкусно

Здравствуйте, SkyDance, Вы писали:

SD> Точно так же как Delphi не лучший выбор для бэкенда

Вот это поворот! С бородатых времен на дельфях пишут трехзвенку, а тут, вдруг, она стала не лучшим выбором. А чой-то?

p.s. Загляните на сайт https://www.beginend.net/ в раздел About; Technology

Здравствуйте, netch80, Вы писали:

N>Уровень людей... ну наших — терпимо. Авторов исходного пакета софта... ну да, они умеют в Linux, а не Windows. На этом положительные слова заканчиваются. И во второй раз за неделю я вспоминаю столь любимого восточным соседом тов. Кобу: "Других людей у меня для вас нет."
N>Это реальный случай, когда я бы хотел Go вместо всей этой хери. Оно перестанет падать, оно будет лучше отлаживаться, и прочая и прочая.
если GC не проблема, то чем Java(Scala/Kotlin/etc) с АОТ(Graal) не подходит? Ну или .NET?

Здравствуйте, LaptevVV, Вы писали:

LVV>А вот еще одна ниша: https://tinygo.org/
LVV>TinyGo brings the Go programming language to embedded systems and to the modern web by creating a new compiler based on LLVM.
Там где работает TinyGo будут работать и JVM.
Пример для ЕSP32 https://developer.microej.com/create-your-first-application/get-started-app-development-on-espressif-esp32-wroverkit-v41/

R>1. горутины это вкусно

Гадость та еще.
Переходите на языки здоровых людей, где message passing и concurrency — first party citizens. Вот там действительно вкусно, компактно, удобно.

Здравствуйте, gandjustas, Вы писали:

G>Объясните в чем преимущество Go перед другими языками. Особенно с точки зрения именно языка, а не того, что вебсервис на pyhon переписанный на go в 100500 раз быстрее работает.

С точки зрения языка — Go строго хуже той же Java 1.4.

Но язык это ерунда.

Go лучше, тем, что:

1. Не требует IDE для разработки. vscode хватает за глаза.

2. У него легче рантайм. У жавы накладные расходы на хелло-ворлд примерно 50 MB. У go — единицы мегабайтов.

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

4. В го просто шикарнейший инструментарий. Просто сразу с языком идёт менеджер для зависимостей, система сборки, причём с поддержкой сборки на C (попробуйте настроить сборка на C в Java-проекте, посмотрю я на вас). В го идёт go fmt, которым пользуются 146% программистов, В Java даже про размер отступа договориться не смогли, про другие языки вообще молчу.

Здравствуйте, so5team, Вы писали:

LVV>>То, что сделано в Го — это дань отсутствию проектирования обработки ошибок.
LVV>>Ведь если об обработке ошибок не думали (никогда), то самое простое — просто проверить ошибку сразу после вызова функции.

S>Как бы то ни было, эти постоянные if err != nil являются одним из основных источников копипасты в Go-шном коде.
S>Если вам действительно удалось от них избавится, то интересно как.

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

Здравствуйте, Михаил Романов, Вы писали:

МР>(У меня опыта в GO меньше 0, поэтому просто упомянуть какие-то GO-специфичные конструкции, увы, для меня бесполезно, но если сможете в сравнении с C# показать — будет очень здорово!)
Просто представь C# без генериков, исключений, LINQ, платформо-независимых бинарей, JIT и т.д. И да привычного ООП там тоже нет(полиморфизм есть), хотя имхо это антипаттерн.
Интересных фич в Go нет, если не считать прибытый гвоздями CSP, которая в современных языках спокойно делают библиотекой.

Здравствуйте, vsb, Вы писали:

vsb>1. Не требует IDE для разработки. vscode хватает за глаза.
имхо на безрыбье и рак рыба.
Так то и VSCode с Металс для Скалы неплохо ездит, только уровень комфорта никакой по сравнению с IDEA.
В Го кстати завезли нормальный repl?

vsb>2. У него легче рантайм. У жавы накладные расходы на хелло-ворлд примерно 50 MB. У go — единицы мегабайтов.
https://www.reddit.com/r/programming/comments/8mqqn6/a_7mb_nativeimage_java_app_that_runs_in_30ms_and/

vsb>3. Самое главное: в Java кошмарное коммьюнити. Первое, что делает любой жавист, это тянет в проект спринг бут...
+1

vsb>4. В го просто шикарнейший инструментарий. Просто сразу с языком идёт менеджер для зависимостей, система сборки, причём с поддержкой сборки на C ...
+1

Здравствуйте, novitk, Вы писали:

vsb>>1. Не требует IDE для разработки. vscode хватает за глаза.
N>имхо на безрыбье и рак рыба.
N>Так то и VSCode с Металс для Скалы неплохо ездит, только уровень комфорта никакой по сравнению с IDEA.

Про скалу не знаю, я на ней писал сто лет назад последний раз. Проблема идеи в том, что она портится от версии к версии и в прошлом году я понял, что пора с неё слезать. Поэтому всё, что меня держит на ней мне в минус. Хотя до этого её использовал вообще для всего. На текущий момент использую только для Java, работы с БД и HTTP (хотя последнее вроде в vscode тоже есть, пока не разбирался).

N>В Го кстати завезли нормальный repl?

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

vsb>>2. У него легче рантайм. У жавы накладные расходы на хелло-ворлд примерно 50 MB. У go — единицы мегабайтов.
N>https://www.reddit.com/r/programming/comments/8mqqn6/a_7mb_nativeimage_java_app_that_runs_in_30ms_and/

Я пробовал грааль. Оно компилирует простой проект несколько минут и при этом жрёт больше 16 GB RAM. Какое-то издевательство. Не знаю, кому оно подойдёт. У меня на CI-сервере памяти в 4 раза меньше. Ну и это всё же не жава, а как бы подмножество, оно любой проект не запустит, нужно тюнить и дорабатывать.

Здравствуйте, vsb, Вы писали:

vsb>Про скалу не знаю, я на ней писал сто лет назад последний раз. Проблема идеи в том, что она портится от версии к версии и в прошлом году я понял, что пора с неё слезать. Поэтому всё, что меня держит на ней мне в минус.
Это другой и скорее политический вопрос и я в принципе согласен страдать тоже. Просто это не про Go. Ява работает в VSCode примерно на таком же уровне.
Проблема с vscode в зоопарке плагинов. Нужно МS прикрутить нечто подобное venv: code -env {python,esp-idf,julia,go,etc). В емаксе с этим было проще.

N>>В Го кстати завезли нормальный repl?
vsb>Не знаю, мне это никогда не было нужно. Плохо представляю себе, как это будет работать с go. Обычно для каких-то небольших экспериментов и проверок я либо использую отдельный проект, либо временный юнит-тест (который может стать постоянным по итогу).
Просаживаешь продуктивность раз в десять. Поэтому питон всех и забил. Без repl нет будущего. Впрочем в Golang он вроде есть: https://github.com/gopherdata/gophernotes.

vsb>Я пробовал грааль. Оно компилирует простой проект несколько минут и при этом жрёт больше 16 GB RAM. Какое-то издевательство. Не знаю, кому оно подойдёт. У меня на CI-сервере памяти в 4 раза меньше.
Come on, dude. 2023 год на дворе. У меня ноут 2012 года с 32 GB. В отличие от свистоперделок граль здесь память на дело тратит.

vsb>Ну и это всё же не жава, а как бы подмножество, оно любой проект не запустит, нужно тюнить и дорабатывать.
Без рантайм рефлексии запустит, а ее и в Go нет.

Здравствуйте, vsb, Вы писали:

vsb>А зачем от неё избавляться?

Чтобы снизить объем кода, с которым приходится иметь дело. Размер, к сожалению, имеет значение.

vsb>Нет никакой проблемы в копипасте.

Здравствуйте, SkyDance, Вы писали:

SD>Переходите на языки здоровых людей, где message passing и concurrency — first party citizens.

Типа chain в Go -- это не first class citizens, а так, нашлепка сбоку

SD>Вот там действительно вкусно, компактно, удобно.

Не думал, что встречается Erlang головного мозга, а вот поди ж ты.

Здравствуйте, so5team, Вы писали:

vsb>>А зачем от неё избавляться?

S>Чтобы снизить объем кода, с которым приходится иметь дело. Размер, к сожалению, имеет значение.

Имеет значение не размер, а когнитивная нагрузка. Шаблонные if err != nil { return fmt.Error("foo operation failed: %w", err); } ощутимой нагрузки не добавляют. А избавиться от дублирования тут можно только разработав новые языковые средства, что разработчику не по силу.

Здравствуйте, vsb, Вы писали:

vsb>Имеет значение не размер, а когнитивная нагрузка. Шаблонные if err != nil { return fmt.Error("foo operation failed: %w", err); } ощутимой нагрузки не добавляют.

Лисперы не видят скобочек, Гоферы не видят if-ов. Ну, OK.

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

Разработчику, как правило, и ЯП не всегда дают выбрать, приходится жрать что уже есть. Только это копипасту в Go не оправдывает.

Я в Го новичок.
Поэтому мои впечатления свежи.
1. После очень долгого перерыва (более 30 лет) мне вновь понравился язык программирования — Go
Более 30 лет назад я был впечатлен Си и С++

С одной стороны, жесткий синтаксис скобок "ограничивает свободу" — это я так воспринял сначала
А потом по мере углубления, и зная средний уровень программистов, понял, какое это благо — одинаковый стиль кода во всем мире...
Так что я — за!

2. Я совершенно офигел от горутин и каналов
Даже возникла мысль — надо написать либу для С++ на этой идее.
Мож и займусь на досуге.

3. Стандартная библиотека. В С++, куда ни кинься — везде требуются сторонние нестандартные библиотеки.
Особенно в сетевом программировании
Даже xml и json — надо тянуть что-то внешнее.
В Go почти все необходимое есть прямо из коробки

4. Готовая инфраструктура. Тестирование, сборка — прямо из коробки.
В С++ тут полный зоопарк. И все внешнее.

5. Полная совместимость с Си. Вон в Каспере в одном и том же проекте можешь писать одну часть на Го и другую — на Си.
И все работает и не валится из-за неправильных настроек-сборок-декорации имен...

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

Здравствуйте, LaptevVV, Вы писали:

LVV>В Go почти все необходимое есть прямо из коробки

Любая БЛ на го — это боль. Сервис больше 1000 строчек — боль.
Я уже не говорю о возможной реализации аспектов или пайплайнов — они уродские из-за синтаксиса.


LVV> 4. Готовая инфраструктура. Тестирование, сборка — прямо из коробки.

Это давно уже почти во всех языках есть.
Хотя тесты в одной папке с кодом — это мрак, конечно, но это же ГО(!).


LVV> Я совершенно офигел от горутин и каналов

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


Я уже не говорю о совершенно упоротом сообществе, где даже подобные дженерики не взлетели. Ощущение, как будто 20 лет прогресса и не было особо. Дикая смесь питона и С. Нунахер(с)

Здравствуйте, vsb, Вы писали:

vsb>Имеет значение не размер, а когнитивная нагрузка. Шаблонные if err != nil { return fmt.Error("foo operation failed: %w", err); } ощутимой нагрузки не добавляют. А избавиться от дублирования тут можно только разработав новые языковые средства, что разработчику не по силу.

Я хочу БЛ видеть и сразу понимать, а не инфру или обработку ошибок.

LVV>>В Go почти все необходимое есть прямо из коробки
IT>Любая БЛ на го — это боль. Сервис больше 1000 строчек — боль.
Стесняюсь спросить — а что такое БЛ ?
Не пишите 1000 строчек, разбивайте на функции.
IT>Я уже не говорю о возможной реализации аспектов или пайплайнов — они уродские из-за синтаксиса.
Синтаксис меня совершенно не парит. В С++ синтаксис тоже не сахар...
LVV>> 4. Готовая инфраструктура. Тестирование, сборка — прямо из коробки.
IT>Это давно уже почти во всех языках есть.
В С++ — нету
IT>Хотя тесты в одной папке с кодом — это мрак, конечно, но это же ГО(!).
Делай отдельный пакет и подключай, не?

LVV>> Я совершенно офигел от горутин и каналов
IT>Тоже офигел, когда узнал, что никакого толка от канала нет по сравнению со слайсом.
IT>Наверное, еще больше офигеете, когда узнаете об Акторах и Elixire.
Ты не поверишь, по Эликсиру у меня даже книжка есть и я ее читал...

IT>Я уже не говорю о совершенно упоротом сообществе, где даже подобные дженерики не взлетели. Ощущение, как будто 20 лет прогресса и не было особо. Дикая смесь питона и С. Нунахер(с)
Не. Именно Питон пошел лесом. Го гораздо лучше.

Здравствуйте, LaptevVV, Вы писали:

LVV>2. Я совершенно офигел от горутин и каналов
LVV>Даже возникла мысль — надо написать либу для С++ на этой идее.
LVV>Мож и займусь на досуге.

Уже есть, как минимум, Boost.Fiber, а там, помимо прочего, и каналы в наличии.

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

S>Уже есть, как минимум, Boost.Fiber, а там, помимо прочего, и каналы в наличии.
Ну, про файберы я еще у Рихтера читал
S>Правда, одна из серьезнейших проблем подобных подходов, это наличие общей памяти. Т.е. (ко/го)роутины запросто могут работать с одной областью памяти, в том числе и мутабельной.
Давай определимся, что корутины и горутины — это не одно и то же.
Про корутины еще в 63 году была статья Конвея, которая в СССР установила термин "сопрограммы".
А горутины — это параллельные легковесные потоки в Го.

Здравствуйте, LaptevVV, Вы писали:

S>>Уже есть, как минимум, Boost.Fiber, а там, помимо прочего, и каналы в наличии.
LVV>Ну, про файберы я еще у Рихтера читал

У Рихтера наверняка было про реализацию в Windows под названием Fibers. Т.е. прибитая гвоздями к одной платформе вещь.

В Boost.Fiber кросс-платформенная реализация.

S>>Правда, одна из серьезнейших проблем подобных подходов, это наличие общей памяти. Т.е. (ко/го)роутины запросто могут работать с одной областью памяти, в том числе и мутабельной.
LVV>Давай определимся, что корутины и горутины — это не одно и то же.
LVV>Про корутины еще в 63 году была статья Конвея, которая в СССР установила термин "сопрограммы".
LVV>А горутины — это параллельные легковесные потоки в Го.

В свою очередь то, что сейчас называется общим термином coroutines, делится на два типа: stackless coroutines (те самые "сопрограммы") и stackfull coroutines (иногда называемые green threads, иногда fibers). Горутины -- это как раз stackfull coroutines и есть.

А то, что добавлили в C++20 под названием короутин с co_await/co_return/co_yield -- это stackless coroutines.

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

Здравствуйте, gandjustas, Вы писали:

G>Объясните в чем преимущество Go перед другими языками.
Простота. Т.е. минимум ключевых слов. оригинальная концепция работы с ошибками. Это все впечатления из тутора и доклада 18го года.
Полная противоположность плюсам. Но меня смущает тот факт, что авторы анонсировали его
как системный, но потом что-то пошло не так. и внезапно — веб разработка основное применение. плюс Многовато критики.
Те же каналы в ди уже давно. так что именно горутины это не какое то ноухау как по мне.

LVV>>Ну, про файберы я еще у Рихтера читал
S>У Рихтера наверняка было про реализацию в Windows под названием Fibers. Т.е. прибитая гвоздями к одной платформе вещь.
Да, конечно. Но в бусте тогда еще не было.
S>В Boost.Fiber кросс-платформенная реализация.
Это тоже понятно.
S>>>Правда, одна из серьезнейших проблем подобных подходов, это наличие общей памяти. Т.е. (ко/го)роутины запросто могут рабоНтать с одной областью памяти, в том числе и мутабельной.
LVV>>Давай определимся, что корутины и горутины — это не одно и то же.
LVV>>Про корутины еще в 63 году была статья Конвея, которая в СССР установила термин "сопрограммы".
LVV>>А горутины — это параллельные легковесные потоки в Го.
S>В свою очередь то, что сейчас называется общим термином coroutines, делится на два типа: stackless coroutines (те самые "сопрограммы") и stackfull coroutines (иногда называемые green threads, иногда fibers). Горутины -- это как раз stackfull coroutines и есть.
S>А то, что добавлили в C++20 под названием короутин с co_await/co_return/co_yield -- это stackless coroutines.
С таким разделением согласен.
Но в 63 году об истинно параллельных сопрограммах еще в голову не приходило...
S>Так вот, когда в вашем распоряжении есть stackfull coroutines (например, в виде Boost.Fibers), то вы можете программировать практически в стиле Go. С поправкой на то, что в Go за счет рантайма языка происходит автоматическая передиспетчеризации гороутин при обращении к блокирующим системным вызовам. А в том же С++ такой поддержки нет (хотя посредством Fibers из Windows, емнип, чего-то подобного можно достичь).
Да, это понятно.
Но я не хочу на С++, я хочу на Go — там все нужные мне вещи из стандарта (сетевое программирование, например).
А в С++ — внешние.

Здравствуйте, LaptevVV, Вы писали:

LVV>Но я не хочу на С++, я хочу на Go — там все нужные мне вещи из стандарта (сетевое программирование, например).

Мои комментарии относились конкретно к этому:

2. Я совершенно офигел от горутин и каналов
Даже возникла мысль — надо написать либу для С++ на этой идее.
Мож и займусь на досуге.

Либы и для короутин, и для каналов (и для того, и другого сразу) в C++ уже в наличии.

Но если хочется именно Go, то что уж поделать.

Здравствуйте, so5team, Вы писали:

s> ...
s> С поправкой на то, что в Go за счет рантайма языка происходит автоматическая передиспетчеризации гороутин при обращении к блокирующим системным вызовам.

Там сейчас нормальное вытеснение сделано: https://habr.com/ru/articles/502506/

Здравствуйте, Разраб, Вы писали:

Р> так что именно горутины это не какое то ноухау как по мне.

Речь не о том, что это ноухау, а о том, что это номальная реализация зеленых потоков, с реальным вытеснением.

Здравствуйте, LaptevVV, Вы писали:

Хочу дополнить по Go:

1. Мне приходилось переписывать веб-сервисы с Java на Go.
Web-сервис на Java + Tomcat + JSP требовал для работы 200-250 Mb оперативной памяти.
Тот же сервис, переписанный на Nginx + Go + html template занимал 20-30 Мб ОЗУ.
Выигрыш по памяти значительный. Если сервисы крутятся в облаках — можно прилично сэкономить.

2. Обработка ошибок. Она проста и незатейлива. Мы писали так:

html, err := template.ParseFiles("tmpl/result.html")
CheckFatalErr(err)

...

func CheckFatalErr(err error) {
    if err != nil {
    log.Fatal(err)
}

Все просто и глаз не спотыкается об if err != nil.

V>2. Обработка ошибок. Она проста и незатейлива. Мы писали так:

Просто и незатейливо — это #letitcrash.

Примерно так:

{ok, Parsed} = parse_files("tmpl/result.html"),

А то, что на Go, угрюмо и страшно.

N>Просто представь C# без генериков, исключений, LINQ, платформо-независимых бинарей, JIT и т.д.

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

S>Типа chain в Go -- это не first class citizens, а так, нашлепка сбоку

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

S>Не думал, что встречается Erlang головного мозга, а вот поди ж ты.

Случается, что у некоторых есть опыт работы с разными языками, платформами и концепциями. Так что возникает понимание, где какая экосистема в чем лучше. И осознание, в чем, например, хорош C#, а где удобен Go. А также что проще отлаживать, и почему. И заодно — что отлаживать не нужно. Или где реализация устрашающа (ага, расскажите мне про отладку async/await программ в C# ).

Go имеет современную экосистему (которой Erlang не имеет). Это как раз менеджеры пакетов, отладчики и прочее. Но именно как язык Go по простоте и выразительности на две головы ниже.

Здравствуйте, SkyDance, Вы писали:

S>>Типа chain в Go -- это не first class citizens, а так, нашлепка сбоку

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



К first-class ваша ссылка не имеет отношения. Если бы chan не был в Go first-class citizen, то, например, его бы не поддерживала Go-шная функция make.

S>>Не думал, что встречается Erlang головного мозга, а вот поди ж ты.

SD>Случается, что у некоторых есть опыт работы с разными языками, платформами и концепциями.

Жаль, что к этому опыту не прилагается еще и осознание того, что это вовсе не уникально.

Здравствуйте, novitk, Вы писали:

N>Здравствуйте, netch80, Вы писали:

N>>Уровень людей... ну наших — терпимо. Авторов исходного пакета софта... ну да, они умеют в Linux, а не Windows. На этом положительные слова заканчиваются. И во второй раз за неделю я вспоминаю столь любимого восточным соседом тов. Кобу: "Других людей у меня для вас нет."
N>>Это реальный случай, когда я бы хотел Go вместо всей этой хери. Оно перестанет падать, оно будет лучше отлаживаться, и прочая и прочая.
N>если GC не проблема, то чем Java(Scala/Kotlin/etc) с АОТ(Graal) не подходит? Ну или .NET?

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

Здравствуйте, SkyDance, Вы писали:

SD>Все это появится, просто позже (если, конечно, гугль не решит сэкономить на команде, работающей над go), спираль — она на то и спираль.
Языку десять лет уже, а перечисленные фичи в базе лет так 30 уже.
if-ы в докере переписывать никто не будет.
Это не убьет основную фичу — "простоту"?

Здравствуйте, VladiCh, Вы писали:

N>>если GC не проблема, то чем Java(Scala/Kotlin/etc) с АОТ(Graal) не подходит? Ну или .NET?
VC>тяжеленное говнище для кучи случаев. жрут память как не в себя.
"Tяжелое говнище" это Спринги и Томкаты, которым давно пора на помоечку. В Go никакой магии в управлении памяти нет, GC там до сих пор хуже, a ValueType в Яву завезли.

Здравствуйте, Vladsav, Вы писали:

V>Все просто и глаз не спотыкается об if err != nil.
CheckFatalErr разве не должны быть распылену чуть менее чем везде?

N>Это не убьет основную фичу — "простоту"?

Убьет, конечно (вместе с другими фичами). Но это и есть та самая спираль. Каждый язык (включая С, ага) имел с самого начала "основную фичу, простоту". Избежать усложнения человеки, я так понимаю, просто не в состоянии, поэтому через сколько-то лет появится очередной язык, основной фичей которого будет являться простота.

Здравствуйте, SkyDance, Вы писали:

SD>Убьет, конечно (вместе с другими фичами). Но это и есть та самая спираль. Каждый язык (включая С, ага) имел с самого начала "основную фичу, простоту".

"C" всеже контрпример. Он не стал набирать фичи и в основном полировал синтакс.
Есть разная "простота". В понимание "golang" это не богатая композиция из минимального набора сущностей, а именно 'простота' в "быдлокодинге".

Здравствуйте, ArtDenis, Вы писали:

AD>У Go возможны data races, так что непредсказуемое поведение всё равно будет. Но в любом случае это сильно лучше чем C/C++

Ну, в Go заложено много интересных возможностей. Например, два сабслайса от одного и того же слайса (или массива) — у них общая память. Пишешь в один — в другом меняется. А после первого append-а — как повезет.

Здравствуйте, rudzuk, Вы писали:

R>Нишу гошечки давно и конкретно определил его создатель — язык для тупых

Автор: rudzuk
Дата: 15.02.22

. (прямая речь

Автор: rudzuk
Дата: 15.02.22

)

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

Здравствуйте, netch80, Вы писали:

N>Знакомые которые на нём пишут — одинаково рассказывают, не сговариваясь, что уровень, в первую очередь, копипастинга превышает все разумные пределы и все известные аналоги кода на других языках.

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

Я тоже пишу на Go, и как-то вот обхожусь без массового копипастинга.

N>Ругань типа "пока я собирался поменять все 4 места, где что-то надо было менять, добавили ещё 6" совершенно типична.
N>А вот это уже наверняка результат отсутствия нормального наследования в объектах, соответственно, реюз кода катастрофически усложняется.

Может здесь пора сделать рефакторинг?

Здравствуйте, SkyDance, Вы писали:

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

Вроде Пайк таки вышел на пенсию. Так что да, может и появится. Будет жаль...

Здравствуйте, gandjustas, Вы писали:

G>Объясните в чем преимущество Go перед другими языками. Особенно с точки зрения именно языка, а не того, что вебсервис на pyhon переписанный на go в 100500 раз быстрее работает.

Он удобный, как старые тапочки.

Pzz>Вроде Пайк таки вышел на пенсию. Так что да, может и появится. Будет жаль...

Ха, выгнали-таки.
Ну тогда ждем и генериков, и всего такого прочего!

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, gandjustas, Вы писали:

G>>Объясните в чем преимущество Go перед другими языками. Особенно с точки зрения именно языка, а не того, что вебсервис на pyhon переписанный на go в 100500 раз быстрее работает.

Pzz>Он удобный, как старые тапочки.

А можно пример без эмоциональных оценок?

Здравствуйте, Pzz, Вы писали:

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

Нет не должен. Давай будем Дейкстру цитировать:

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

Теперь можно вернуться к словам Пайка, говорящего о том, какими он видит гоферов...

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

Здравствуйте, novitk, Вы писали:

N>Здравствуйте, VladiCh, Вы писали:

N>>>если GC не проблема, то чем Java(Scala/Kotlin/etc) с АОТ(Graal) не подходит? Ну или .NET?
VC>>тяжеленное говнище для кучи случаев. жрут память как не в себя.
N>"Tяжелое говнище" это Спринги и Томкаты, которым давно пора на помоечку. В Go никакой магии в управлении памяти нет, GC там до сих пор хуже, a ValueType в Яву завезли.

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

Здравствуйте, VladiCh, Вы писали:

VC>С AOT это как-то решается (для небольших приложений), но из того что я слышал возникают другие проблемы, уже с большими приложениями.
Подозреваю, что речь идет о уже написанном коде. Понятно, что пропустить какой-нибудь Eclipse через АOT нетривиально, но так ли это и нужно именно для больших приложений?
Интересно был бы посмотреть на сравнение какого-нибудь gRPC на двух стеках с современными либам на стороне Граля. У меня есть подозрения, что разница будет околонулевая.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, ArtDenis, Вы писали:

AD>>У Go возможны data races, так что непредсказуемое поведение всё равно будет. Но в любом случае это сильно лучше чем C/C++

Pzz>Ну, в Go заложено много интересных возможностей. Например, два сабслайса от одного и того же слайса (или массива) — у них общая память. Пишешь в один — в другом меняется. А после первого append-а — как повезет.

Слайсам уже сто лет, грубо говоря https://duckduckgo.com/?q=dlang+slice&atb=v314-1&ia=web
ЗЫ в свое время с надеждой смотрел на ди, но почему то в его сторону тоже много критики.

Здравствуйте, SkyDance, Вы писали:

SD>Ну тогда ждем и генериков

Так уже же ж: https://go.dev/blog/intro-generics

Здравствуйте, gandjustas, Вы писали:

G>>>Объясните в чем преимущество Go перед другими языками. Особенно с точки зрения именно языка, а не того, что вебсервис на pyhon переписанный на go в 100500 раз быстрее работает.

Pzz>>Он удобный, как старые тапочки.

G>А можно пример без эмоциональных оценок?

Не Pzz, но перечислю аргументы, с которыми мне приходилось сталкиваться (в основном по сравнению с Си, C++ и Java):

* сборка мусора. Не нужно думать о памяти;
* проверки в run-time, выход за пределы массива не приводит к порче памяти и вот это вот все;
* defer. Удобно прибирать за собой без goto end, finally и RAII;
* простая и понятная обработка ошибок, нет исключений, не нужно думать о том, может ли что-то вылететь из функции/метода (при этом, есть ощущение, что на паники всем пофиг);
* простое и удобное ООП без многоэтажных иерархий классов;
* очень быстрая компиляция и удобная кросскомпиляция;
* маленький объем результирующих бинарников и нет необходимости таскать за собой многомегабайтные JRE.

Как по мне, объективными преимуществами являются только последние два пункта.

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

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

Здравствуйте, so5team, Вы писали:

S>Не Pzz, но перечислю аргументы, с которыми мне приходилось сталкиваться (в основном по сравнению с Си, C++ и Java):

S>* сборка мусора. Не нужно думать о памяти;

В Java тоже. Но думать иногда всё равно надо, что в Java, что в Go. См. "утечка горутин", например.

S>* проверки в run-time, выход за пределы массива не приводит к порче памяти и вот это вот все;

В Java тоже.

S>* defer. Удобно прибирать за собой без goto end, finally и RAII;

Чем defer удобней try-with-resources и RAII?

S>* простая и понятная обработка ошибок

if err := func1() {
    return err
}
if err := func2() {
    return err
}
if err := func3() {
    return err
}
...

Очень удобно, да.

S>* нет исключений, не нужно думать о том, может ли что-то вылететь из функции/метода (при этом, есть ощущение, что на паники всем пофиг);

Не всем. А кому пофиг на паники, тому и на исключения пофиг. В чём разница?

S>* простое и удобное ООП без многоэтажных иерархий классов;

В Go нет ООП. А довольно простое и удобное, например, в OCaml.

S>* очень быстрая компиляция и удобная кросскомпиляция;

У Object Pascal / Delphi тоже быстрая компиляция.

S>* маленький объем результирующих бинарников и нет необходимости таскать за собой многомегабайтные JRE.

Но по сравнению с C -- не такой маленький.

Здравствуйте, gandjustas, Вы писали:

g> А можно пример без эмоциональных оценок?

Крайне продуманная для своей ниши стандартная библиотека. Если твоя задача работать с перекладыванием JSON-ов (здесь вместо JSON можно подставить любое нужное слово) по сети (а это over 99% всех современных задач), то гошечка — это единственный разумный выбор на сегодня.

В качестве очень простого примера посмотри например реализации TLS Session Resumption в других языках (в Go это включается буквально одной строкой кода). И вообще все, что касается перекладывания байтов по сети с учетом современных требований (TLS, работа с сертификатами, алгоритмы шифрования, etc) — для Go "это все мое, родное".

Вот был (есть и сейчас, но "уже не торт") такой веб-сервер как nginx, написанный "админом для админов", без вот этой теоретической фигни, а исключительно для решения реальных практических задач high load. Язык Go находится где-то там же — он без вот этого теоретического bull-shit решает реальные практические задачи современного high-load.

Здравствуйте, korvin_, Вы писали:

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

S>>* сборка мусора. Не нужно думать о памяти;

_>В Java тоже. Но думать иногда всё равно надо, что в Java, что в Go. См. "утечка горутин", например.

Здесь в первую очень речь идет о чистом Си, в котором даже С++ных смартпоинтеров нет. Если человек много программировал на Си (а то и в C++ редко заглядывал, а если и заглядывал, то ужасался), то переход на Go для него реально выход в другой мир.

S>>* проверки в run-time, выход за пределы массива не приводит к порче памяти и вот это вот все;

_>В Java тоже.

Опять же, это касается чистого Си и C++.

S>>* defer. Удобно прибирать за собой без goto end, finally и RAII;

_>Чем defer удобней try-with-resources и RAII?

Касательно C++ не все умеют пользоваться RAII без написания классов под каждый конкретный случай (например, unique_ptr с кастомным deleter-ом -- это уже за гранью фантастики).

Какие претензии к try-with-resources не спрашивал

S>>* простая и понятная обработка ошибок

_>

_>if err := func1() {
_>    return err
_>}
_>if err := func2() {
_>    return err
_>}
_>if err := func3() {
_>    return err
_>}
_>...
_>

_>Очень удобно, да.

Сложно поверить, но да. Для определенной категории программистов (полагаю, именно на них Роб Пайк и нацеливался) это именно что:

a) обработка ошибок (да, вот такие у людей представления об обработке ошибок, return err -- это уже обработка по их мнению);
b) это просто и удобно (да, вот именно так и говорят).

S>>* нет исключений, не нужно думать о том, может ли что-то вылететь из функции/метода (при этом, есть ощущение, что на паники всем пофиг);

_>Не всем. А кому пофиг на паники, тому и на исключения пофиг. В чём разница?

Принципиальная разница в том, что человек пишет что-то вроде:

var err := func()

то он твердо знает, что func может только вернуть значение и все (как я раньше говорил, многим на паники пофиг). И ни о каких других путях исполнения можно не думать. Поэтому можно писать код в стиле:

make_change_A(); // сделали что-то.
var err1 := func();
if err1 != nil {
  revert_change_A();
  return err1;
}
make_change_B(); // сделали еще что-то.
var err2 := func();
if err2 != nil {
  revert_change_B();
  revert_change_A();
  return err2;
}

Типа здесь все под контролем и все очевидно.

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

S>>* простое и удобное ООП без многоэтажных иерархий классов;

_>В Go нет ООП.

Многие считают, что есть. И что оно правильно приготовлено.

S>>* очень быстрая компиляция и удобная кросскомпиляция;

_>У Object Pascal / Delphi тоже быстрая компиляция.

Только вот они сдохли еще в прошлом веке. Да, есть любители мертвечины. Но факт в том, что погоды прямые наследники Pascal уже лет 25 как не делают.

Здравствуйте, so5team, Вы писали:

s> _>У Object Pascal / Delphi тоже быстрая компиляция.

s> Только вот они сдохли еще в прошлом веке. Да, есть любители мертвечины. Но факт в том, что погоды прямые наследники Pascal уже лет 25 как не делают.

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

Здравствуйте, so5team, Вы писали:

s> * очень быстрая компиляция и удобная кросскомпиляция;
s> * маленький объем результирующих бинарников и нет необходимости таскать за собой многомегабайтные JRE.

s> Как по мне, объективными преимуществами являются только последние два пункта.

helloworld (linux_amd64): go 1.20.5 (ldflags "-s -w") — 1.2 Mb, freepascal 3.2.2 — 35 Kb.

Здравствуйте, rudzuk, Вы писали:

s>> Только вот они сдохли еще в прошлом веке. Да, есть любители мертвечины. Но факт в том, что погоды прямые наследники Pascal уже лет 25 как не делают.

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

Ну вот в Google пишут новый софт на Go и это оказывает влияние на весь мир (популярность и востребованность Go подразумевается). А вот разработка нового софта в Сбере на Delphi, полагаю, даже в масштабах РФ погоды не делает.

Так к чему претензия? Нравится Delphi, но не нравится, что его живым трупом кто-то называет?

Здравствуйте, rudzuk, Вы писали:

R>helloworld (linux_amd64): go 1.20.5 (ldflags "-s -w") — 1.2 Mb, freepascal 3.2.2 — 35 Kb.

Интересно было бы взглянуть еще и на выхлоп ldd для этих helloworld-ов.

Здравствуйте, so5team, Вы писали:

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

s> Ну вот в Google пишут новый софт на Go и это оказывает влияние на весь мир (популярность и востребованность Go подразумевается).

Было бы очень странно, если бы в гугле не писали на придуманном для себя языке И естественно, что такая огромная компания оказывает влияние на мир. Но это не более чем мода, а мода штука такая — сегодня модно одно, завтра другое.

s> Так к чему претензия? Нравится Delphi, но не нравится, что его живым трупом кто-то называет?

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

Здравствуйте, so5team, Вы писали:

s> R>helloworld (linux_amd64): go 1.20.5 (ldflags "-s -w") — 1.2 Mb, freepascal 3.2.2 — 35 Kb.

s> Интересно было бы взглянуть еще и на выхлоп ldd для этих helloworld-ов.

not a dynamic executable для обоих

Здравствуйте, rudzuk, Вы писали:

R>Было бы очень странно, если бы в гугле не писали на придуманном для себя языке И естественно, что такая огромная компания оказывает влияние на мир. Но это не более чем мода, а мода штука такая — сегодня модно одно, завтра другое.

Только вот эта мода оставляет мегатонны кода из-за которого Go так просто не умрет в перспективе ближайших 10-15 лет (а скорее 20-25).

s>> Так к чему претензия? Нравится Delphi, но не нравится, что его живым трупом кто-то называет?

R>Нет никаких претензий Дельфы, да и паскаль вообще, трупом называют уже лет двадцать. Некоторых называвших уже черви давно съели, а ей хоть бы что.

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

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

Вот Delphi за счет рывка в 90-х себе такое состояние обеспечил. Но (как и множество других, отнюдь не самых плохих языков, вроде Eiffel, Ada, OCaml, Ruby) погоды уже не делает.

Здравствуйте, so5team, Вы писали:

s> Только вот эта мода оставляет мегатонны кода из-за которого Go так просто не умрет в перспективе ближайших 10-15 лет (а скорее 20-25).

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

s> Ну так и COBOL не умер, т.к. и системы на нем работают, и их еще дописывают, и даже вендоры компиляторов COBOL-а что-то выпускают. Живее он от этого не становится.

Я не о легаси говорил, а о вполне себе новом Сберовском b2b софте. Его запросто могли писать на шарпе с впф, но выбрали не шарп. Это говорит о том, что современный паскаль весьма конкурентноспособен.

s> Вот Delphi за счет рывка в 90-х себе такое состояние обеспечил. Но (как и множество других, отнюдь не самых плохих языков, вроде Eiffel, Ada, OCaml, Ruby) погоды уже не делает.

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

Здравствуйте, rudzuk, Вы писали:

s>> Ну так и COBOL не умер, т.к. и системы на нем работают, и их еще дописывают, и даже вендоры компиляторов COBOL-а что-то выпускают. Живее он от этого не становится.

R>Я не о легаси говорил, а о вполне себе новом Сберовском b2b софте. Его запросто могли писать на шарпе с впф, но выбрали не шарп. Это говорит о том, что современный паскаль весьма конкурентноспособен.

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

Здравствуйте, so5team, Вы писали:

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

Использовать мертвый язык для нового проекта...

Здравствуйте, rudzuk, Вы писали:

R>Использовать мертвый язык для нового проекта...

Насколько я наслышан, в РФ для некоторых областей нельзя использовать Java, т.к. там JVM, а не нативный код.

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

AB>Если твоя задача работать с перекладыванием JSON-ов (здесь вместо JSON можно подставить любое нужное слово) по сети (а это over 99% всех современных задач), то гошечка — это единственный разумный выбор на сегодня.

Правильно, Go и проектировался для этой задачи. Но я отмечу, что и C# в этой роли ничуть не хуже.1
И заявление про "over 99% задач" напоминает про молотки и гвозди: если работать с бэкендом, то, конечно, 99% задач выглядят как перекладывание JSON/protobuf/thrift/... Но это на самом деле даже не половина задач.

Здравствуйте, so5team, Вы писали:

s> Насколько я наслышан, в РФ для некоторых областей нельзя использовать Java, т.к. там JVM, а не нативный код.

Что-то маленькое, встроенное и с полетным заданием?

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

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

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

То, что надо.
Синтаксис php очень похож на c++/java/c# и потому гораздо более мне привычен и понятен, чем python и golang.
А ведь на php можно писать и консольные и даже GUI приложения.
И exceptions там есть в отличие от golang.
Не понимаю, почему golang популярен среди python программистов.

Здравствуйте, Vladsav, Вы писали:

V>Выигрыш по памяти значительный. Если сервисы крутятся в облаках — можно прилично сэкономить.

Сколько по сравнению с временем программиста?

Здравствуйте, rudzuk, Вы писали:

s>> Насколько я наслышан, в РФ для некоторых областей нельзя использовать Java, т.к. там JVM, а не нативный код.

R>Что-то маленькое, встроенное и с полетным заданием?

Нет.

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

R>Да мне просто интересно, какие могут быть причины в предпочтении мертвой технологии

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

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

s>> Насколько я наслышан, в РФ для некоторых областей нельзя использовать Java, т.к. там JVM, а не нативный код.

R>Что-то маленькое, встроенное и с полетным заданием?

Для маленького и встроенного есть Java Card.

Здравствуйте, so5team, Вы писали:

s> s>> Насколько я наслышан, в РФ для некоторых областей нельзя использовать Java, т.к. там JVM, а не нативный код.

s> R>Что-то маленькое, встроенное и с полетным заданием?

s> Нет.

А где?

s> R>Да мне просто интересно, какие могут быть причины в предпочтении мертвой технологии

s> Может и еще более тривиально: проект стартует не на новом месте, а переиспользует наработки, сделанные давным-давно на Delphi. Чем переписывать уже работающее на что-то другое, проще продолжить на современном Delphi.

Проект написан под новый дельфийский фреймворк — Firemonkey, что равносильно переписыванию с нуля. Я потому шарп с впф и упомянул, и там и тут (wpf, firemonkey) делается упор на выразительные возможности. Вот только, пиши они его на шарпе, завести на линуксе не получилось бы, а дельфийское работает.

Здравствуйте, m2user, Вы писали:

m> s>> Насколько я наслышан, в РФ для некоторых областей нельзя использовать Java, т.к. там JVM, а не нативный код.

m> R>Что-то маленькое, встроенное и с полетным заданием?

m> Для маленького и встроенного есть Java Card.

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

Здравствуйте, rudzuk, Вы писали:



R>Проект написан под новый дельфийский фреймворк — Firemonkey, что равносильно переписыванию с нуля. Я потому шарп с впф и упомянул, и там и тут (wpf, firemonkey) делается упор на выразительные возможности. Вот только, пиши они его на шарпе, завести на линуксе не получилось бы, а дельфийское работает.

UNO совместимо с Blend (UI редактор для XAML) и работает под линукс. поддержка майков. Кроме того есть avalonia.
у дотнета другая проблема — прожорливость и тормознутость по сравнению с ЯП натив-компайл.
ЗЫ А в дельфи есть сборщик мусора?

PS multiple platforms (Windows, OS X, iOS and Android) — с сайта, линукса нет вроде.

Здравствуйте, rudzuk, Вы писали:

s>> s>> Насколько я наслышан, в РФ для некоторых областей нельзя использовать Java, т.к. там JVM, а не нативный код.

s>> R>Что-то маленькое, встроенное и с полетным заданием?

s>> Нет.

R>А где?

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

Оборонка и те самые полетные задания -- это вообще отдельная область со своими заморочками.

R>Проект написан под новый дельфийский фреймворк — Firemonkey, что равносильно переписыванию с нуля. Я потому шарп с впф и упомянул, и там и тут (wpf, firemonkey) делается упор на выразительные возможности. Вот только, пиши они его на шарпе, завести на линуксе не получилось бы, а дельфийское работает.

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

Кроме того, вы, похоже, как-то превратно восприняли формулировку "давно сдохли" и "мертвые". Эти формулировки означают не то, что язык мертв в медицинском смысле. А то, что он когда-то был мейнстримом и успешно конкурировал с другими мейнстримовыми языками. А потом из мейнстрима вылетел и глобального влияния на индустрию не оказывает, стал нишевым. Просуществовать в своей нише может еще не один десяток лет (см. Fortran, COBOL, RPG, MUMPS, SmallTalk и т.д., и т.п.)

Здравствуйте, Разраб, Вы писали:

Р> R>Проект написан под новый дельфийский фреймворк — Firemonkey, что равносильно переписыванию с нуля. Я потому шарп с впф и упомянул, и там и тут (wpf, firemonkey) делается упор на выразительные возможности. Вот только, пиши они его на шарпе, завести на линуксе не получилось бы, а дельфийское работает.

Р> UNO совместимо с Blend (UI редактор для XAML) и работает под линукс. поддержка майков. Кроме того есть avalonia.

Вот, кстати, софта на уно не видел вообще. Есть примеры, чтобы на десктое запустить? На авалонии видел.

Р> ЗЫ А в дельфи есть сборщик мусора?

Сборщика мусора нет. Управление памятью полу-автоматическое.

Р> PS multiple platforms (Windows, OS X, iOS and Android) — с сайта, линукса нет вроде.

Не понял о чем это. О дельфях?

Здравствуйте, so5team, Вы писали:

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

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

s> Если у вас есть доступ к таким подробностям, может вам поспрашивать и о других причинах?

Я бы спросил, была бы возможность...

s> А то, что он когда-то был мейнстримом и успешно конкурировал с другими мейнстримовыми языками. А потом из мейнстрима вылетел и глобального влияния на индустрию не оказывает, стал нишевым. Просуществовать в своей нише может еще не один десяток лет (см. Fortran, COBOL, RPG, MUMPS, SmallTalk и т.д., и т.п.)

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

Здравствуйте, rudzuk, Вы писали:

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

R>Речь явно не о байткоде, просто для работы с гостайной сертификация нужна. Есть JVM, которые такую сертификацию имеют.

За что купил, за то и продаю.

R>Уместнее сказать, что раньше мейнстримом было создание десктопного софта, а сейчас мейнстрим это веб и мобилки.

Java все еще применяется и там, и там, и там.

R>Следовательно, все прочие языки стали нишевыми, а мейнстрим сейчас это жаваскрипт/инструменты разработки для мобильных платформ. Но ставить дельфы в один ряд с языками из музея компьютерной истории... ну, такое себе.

Ну вот в моем списке был и Fortran, и SmallTalk (а ранее еще упоминались Eiffel, OCaml и Ada). Вы считаете это "рядом языков из музея компьютерной истории". Но для тех, кто продолжает использовать Fortran/SmallTalk/OCaml/Ada они таковыми не являются и они явно возмутятся тому, что вы их инструменты в музейные экспонаты зачисляете. Вот точно так же, как вы возбудились по поводу Delphi. И это мы еще лисперам на любимую мозоль не наступили

Здравствуйте, so5team, Вы писали:

S>Не думал, что встречается Erlang головного мозга, а вот поди ж ты.

А оно у большинства оставшихся сейчас на нём (а у пропагандистов — тем более)

Здравствуйте, vsb, Вы писали:

vsb>А зачем от неё избавляться? Нет никакой проблемы в копипасте.

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

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

vsb> Все проблемы от кривых абстракций, а не от копипасты.

Здравствуйте, so5team, Вы писали:

s> R>Уместнее сказать, что раньше мейнстримом было создание десктопного софта, а сейчас мейнстрим это веб и мобилки.

s> Java все еще применяется и там, и там, и там.

Жаба никогда не была популярной на десктопе

s> Ну вот в моем списке был и Fortran, и SmallTalk (а ранее еще упоминались Eiffel, OCaml и Ada). Вы считаете это "рядом языков из музея компьютерной истории". Но для тех, кто продолжает использовать Fortran/SmallTalk/OCaml/Ada они таковыми не являются и они явно возмутятся тому, что вы их инструменты в музейные экспонаты зачисляете. Вот точно так же, как вы возбудились по поводу Delphi. И это мы еще лисперам на любимую мозоль не наступили

Ну это не серьезно... Там в списке и кобол был. Тот самый кобол, на который в одной конторе в штатах, как-то, долго искали программиста и даже смогли, в конце-концов, найти. Фортран, ада изначально нишевые и ниши узначально узкие. На этом основании считать их "мертвечиной"? Не серьезно.

Здравствуйте, rudzuk, Вы писали:

R>Вот, кстати, софта на уно не видел вообще. Есть примеры, чтобы на десктое запустить? На авалонии видел.
если только из шаблонов. Хотя фшарпист русский русский доклад делал, он там Elmish.WFP прикрутил (презентер на F#, xaml на бленде).


Р>> PS multiple platforms (Windows, OS X, iOS and Android) — с сайта, линукса нет вроде.

R>Не понял о чем это. О дельфях?
Firemonkey вроде я смотрел

Здравствуйте, rudzuk, Вы писали:

R>... Фортран, ада изначально нишевые и ниши узначально узкие. На этом основании считать их "мертвечиной"? Не серьезно.
С чего бы им быть изначально нишевым. Это по ходу дела они нишевыми стали. Причем по разным причинам.

Здравствуйте, rudzuk, Вы писали:

s>> R>Уместнее сказать, что раньше мейнстримом было создание десктопного софта, а сейчас мейнстрим это веб и мобилки.

s>> Java все еще применяется и там, и там, и там.

R>Жаба никогда не была популярной на десктопе

А я и не утверждал, что она была популярна на десктопе. Да и начала она там нормально использоватья только когда "Java перестала тормозить" (с), где-то после 2000-го года. Когда уже Web-разработка расцвела буйным цветом.

Однако, Java для разработки десктоп-приложений успешно применяется до сих пор (одни написанные на Java IDE чего стоят).

s>> Ну вот в моем списке был и Fortran, и SmallTalk (а ранее еще упоминались Eiffel, OCaml и Ada). Вы считаете это "рядом языков из музея компьютерной истории". Но для тех, кто продолжает использовать Fortran/SmallTalk/OCaml/Ada они таковыми не являются и они явно возмутятся тому, что вы их инструменты в музейные экспонаты зачисляете. Вот точно так же, как вы возбудились по поводу Delphi. И это мы еще лисперам на любимую мозоль не наступили

R>Ну это не серьезно... Там в списке и кобол был. Тот самый кобол, на который в одной конторе в штатах, как-то, долго искали программиста и даже смогли, в конце-концов, найти.

COBOL в середине нулевых, как минимум, использовался в Сбербанке. Не удивлюсь, если в крупных компаниях РФ он до сих пор применяется.

R>Фортран, ада изначально нишевые и ниши узначально узкие.

Вы заблуждаетесь.

R>На этом основании считать их "мертвечиной"? Не серьезно.

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

Здравствуйте, Pzz, Вы писали:

N>>Знакомые которые на нём пишут — одинаково рассказывают, не сговариваясь, что уровень, в первую очередь, копипастинга превышает все разумные пределы и все известные аналоги кода на других языках.

Pzz>Мне кажется, эти люди внутри рассуждают, как если бы они писали на C++ или чем-то подобном, а фактически пишут на Go.

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

Pzz>Я тоже пишу на Go, и как-то вот обхожусь без массового копипастинга.

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

У меня предпоследняя работа была как раз такой где вообще наследование не было нужно (кроме особо специфичных мест), туда Go ложился практически идеально, хотя все писали на C++. А на одну раньше, наоборот, без многоуровневой иерархии впору было вешаться.

N>>Ругань типа "пока я собирался поменять все 4 места, где что-то надо было менять, добавили ещё 6" совершенно типична.
N>>А вот это уже наверняка результат отсутствия нормального наследования в объектах, соответственно, реюз кода катастрофически усложняется.

Pzz>Может здесь пора сделать рефакторинг?

И в какую сторону?

Здравствуйте, LaptevVV, Вы писали:

N>>А вот куда _вам_ надо чтобы он ехал — я не знаю. Может, как раз в сторону такого копипастинга?
LVV>Мы копипасту в своей обучающей среде извели как класс.

За счёт чего?

LVV>Отсутствие копипасты мгновенно стимулирует студентов писать функции.
LVV>Но переходя к С++ они тут же "влезают обратно на пальму" копипасты...

Вы им запретили функции?

Здравствуйте, VladiCh, Вы писали:

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

А вы видели, _во что_ он компилируемый? )

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

  48fcd7:       48 8b 05 a2 38 0d 00    mov    0xd38a2(%rip),%rax        # 563580 <os.Args>
  48fcde:       48 83 3d a2 38 0d 00    cmpq   $0x2,0xd38a2(%rip)        # 563588 <os.Args+0x8>
  48fce5:       02 
  48fce6:       0f 8c 2b 03 00 00       jl     490017 <main.main+0x377>
  48fcec:       48 8b 48 18             mov    0x18(%rax),%rcx
  48fcf0:       48 8b 40 10             mov    0x10(%rax),%rax
  48fcf4:       48 89 04 24             mov    %rax,(%rsp)
  48fcf8:       48 89 4c 24 08          mov    %rcx,0x8(%rsp)
  48fcfd:       48 c7 44 24 10 00 00    movq   $0x0,0x10(%rsp)
  48fd04:       00 00 
  48fd06:       48 c7 44 24 18 20 00    movq   $0x20,0x18(%rsp)
  48fd0d:       00 00 
  48fd0f:       e8 5c e3 fc ff          callq  45e070 <strconv.ParseInt>
  48fd14:       48 8b 44 24 20          mov    0x20(%rsp),%rax
  48fd19:       48 89 44 24 60          mov    %rax,0x60(%rsp)
  48fd1e:       90                      nop

Это соответствует исходной строке: tt, _ := strconv.ParseInt(os.Args[1], 0, 32).

ec...06: скопировали локальные переменные в стек, потому что функция берёт аргументы только из стека.
14...1e: скопировали результаты из стека (да, в Go результаты тоже на стеке, не в регистрах) в локальные переменные (точнее, одна — tt).
Потом эти значения снова вытащат со стека и будут использовать. Оптимизация работает только в пределах одного предложения, но не между ними. В результате сплошные перегонки через память (обычно через L1 кэш, но есть нюансы, и это всё равно нагрузка на интерфейс связи процессор — память).

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

Вишенка на торте: откуда финальный nop? Это не выравнивание, как покажется тем, кто видел выходной ассемблер какого-нибудь GCC. Это осталось потому, что я err не присваивал, а кодогенератор где-то по дороге потерял возможность сэкономить.

Качество и скорость выходного кода примерно соответствует GCC, Clang без оптимизации совсем (-O0) — ну разве что чуть лучше потому, что у этих двух ещё SSA добавляет странные копирования, когда они ещё не изведены.

Весь выходной код Go именно такой. Не верите — поставьте docker и напустите хоть `objdump -d`, хоть что вам удобнее. Это чтобы не надо было самому что-то собирать.

Так вот — выхлоп JIT в Java нормально оптимизирован, в отличие от, и работает в разы быстрее. Это даже не вспоминая решения типа "у нас тут единственный подкласс в реальности, поэтому меняем вызовы виртуальной функции по указателю на прямой вызов" (в Go тут были бы аналогичные поиски в свойствах класса, соответствующего интерфейсу).
Торможения идут только на прогрев — поэтому там, где важна скорость работы с самого старта, этот прогрев делается искусственно.

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

VC> и рандомного времени ответа.

Прогрев, однако. Причём чем дальше, тем меньше тормозит на этом прогреве.

VC>С AOT это как-то решается (для небольших приложений), но из того что я слышал возникают другие проблемы, уже с большими приложениями.

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

LVV>>Отсутствие копипасты мгновенно стимулирует студентов писать функции.
LVV>>Но переходя к С++ они тут же "влезают обратно на пальму" копипасты...
N>Вы им запретили функции?
Нет.
С большинства просто мгновенно слезает флер "цивилизации"...
Но отдельные личности все-таки становятся более "цивилизованными"...

Здравствуйте, vsb, Вы писали:

vsb>Но язык это ерунда.
vsb>Go лучше, тем, что:
vsb>1. Не требует IDE для разработки. vscode хватает за глаза.

На таком уровне и Java не требует.

vsb>2. У него легче рантайм. У жавы накладные расходы на хелло-ворлд примерно 50 MB. У go — единицы мегабайтов.

Из этих 50MB почти ничего не грузится, если не позвать.
А вот нахрена Go эти единицы мегабайтов на Hello World — непонятно.
Похоже, просто не захотели подумать соптимизировать.

vsb>3. Самое главное: в Java кошмарное коммьюнити. Первое, что делает любой жавист, это тянет в проект спринг бут, который сходу делает проект отстойным.

Вы каких-то странных джавистов наблюдали. Мне больше попадалось разумных.

vsb>4. В го просто шикарнейший инструментарий. Просто сразу с языком идёт менеджер для зависимостей, система сборки, причём с поддержкой сборки на C (попробуйте настроить сборка на C в Java-проекте, посмотрю я на вас).

Вообще строится — я делал, кажется, через Maven. Готовые рецепты прошли, даже когда я про этот Maven знал только имя и где лежит файл проекта.

vsb> В го идёт go fmt, которым пользуются 146% программистов, В Java даже про размер отступа договориться не смогли, про другие языки вообще молчу.

А зачем об этом договариваться универсально по планете?

Здравствуйте, LaptevVV, Вы писали:

LVV>>>Отсутствие копипасты мгновенно стимулирует студентов писать функции.
LVV>>>Но переходя к С++ они тут же "влезают обратно на пальму" копипасты...
N>>Вы им запретили функции?
LVV>Нет.
LVV>С большинства просто мгновенно слезает флер "цивилизации"...

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

LVV>Но отдельные личности все-таки становятся более "цивилизованными"...

которые этот опыт получили где-то ещё...

Здравствуйте, netch80, Вы писали:

vsb>>Но язык это ерунда.
vsb>>Go лучше, тем, что:
vsb>>1. Не требует IDE для разработки. vscode хватает за глаза.

N>На таком уровне и Java не требует.

Не согласен. Java требует. Я пробовал писать на Java и на Go на vscode и в Idea (все комбинации). И в vim пробовал писать на Go. Java юзабельна только в идее. Go юзабелен везде. Ну это моё мнение, кому и в ed в hex писать бинарники нормально.

vsb>> В го идёт go fmt, которым пользуются 146% программистов, В Java даже про размер отступа договориться не смогли, про другие языки вообще молчу.

N>А зачем об этом договариваться универсально по планете?

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

2. Нет проблемы, когда у одного IDE настроена так, у второго по-другому. И в пул-реквестах куча мусора, когда она переформатировала весь файл. Ходить за каждым и настраивать ему IDE это потеря времени. Настраивать в мавене всякие checkstyle-ы на каждый проект это потеря времени. Универсальный стиль на всей планете это нулевые потери времени на вышеописанное.

Здравствуйте, pagid_, Вы писали:

p> R>... Фортран, ада изначально нишевые и ниши узначально узкие. На этом основании считать их "мертвечиной"? Не серьезно.

p> С чего бы им быть изначально нишевым. Это по ходу дела они нишевыми стали. Причем по разным причинам.

Фортран делался для расчетных задач, что отражено в его названии, и сейчас используется только там, где нужна имено хардкорная скорость расчетов (со слов человека работающего с суперами). Ада разрабатывалась конкретно под мишшн критикал (встраиваемое ПО, системы управления) по инициативе МО США.