Здравствуйте, 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 даже про размер отступа договориться не смогли, про другие языки вообще молчу.
Re[11]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
Здравствуйте, 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
Re[4]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
Здравствуйте, 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 раза меньше. Ну и это всё же не жава, а как бы подмножество, оно любой проект не запустит, нужно тюнить и дорабатывать.
Re[5]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
Здравствуйте, 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 нет.
Здравствуйте, so5team, Вы писали:
vsb>>А зачем от неё избавляться?
S>Чтобы снизить объем кода, с которым приходится иметь дело. Размер, к сожалению, имеет значение.
Имеет значение не размер, а когнитивная нагрузка. Шаблонные if err != nil { return fmt.Error("foo operation failed: %w", err); } ощутимой нагрузки не добавляют. А избавиться от дублирования тут можно только разработав новые языковые средства, что разработчику не по силу.
Re[14]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
Здравствуйте, 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>Мож и займусь на досуге.
Правда, одна из серьезнейших проблем подобных подходов, это наличие общей памяти. Т.е. (ко/го)роутины запросто могут работать с одной областью памяти, в том числе и мутабельной.
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, емнип, чего-то подобного можно достичь).
Re[2]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
Здравствуйте, 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 — там все нужные мне вещи из стандарта (сетевое программирование, например).
А в С++ — внешние.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
