Здравствуйте, dignom, Вы писали:
D>Подсунул мне ютуб видео про Go разработу. Собственно, насколько реалистично описаны в видосе работа разработчиком и доход? D>Понятно, что это для опытных инженеров. Но опыт можно будет наработать.
Ничего не знаю про насколько там реалистично, сам не из этого уголка, но знаю что именно на Go переписывают то что было когда-то написано на PHP. А на PHP было написано много. И довольно много Go-шников — это переученные PHP-шники.
Здравствуйте, diez_p, Вы писали:
_>Я .NET последний не особо смотрел, но там чет микрософт и для векторных операций добавил, и с памятью тож какие-то заморочки были, что можно все руками сделать. https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-8/
Но устанешь читать, хотя и занимательно, как "война и мир".
Если говорить о том, что прямо сейчас в коробке, то dotnet рулит понедетски. Я со Скалы в него окунулся и офигел. Просто как в магазине игрушек...
Число-дробилки летают, на яве и плюсах поседеешь пока до такого доберешься. Компилятор раз в 10 быстрее Скалы. Инструментарий просто на порядок удобней, особенно если JebBrains добавить.
Библиотеки... Где начать??? Хочешь веб с wasm и шлюхами? Есть. Хочешь богатый UI для любой платформы? Есть, даже два. Хочешь мега фрэймворк для compute grid/cloud с актерами? Есть, даже два. До Cuda пока не добрался.
В C#, как языке, мне не хватает ровно одной вещи для полной нирваны — discriminating unions. В F# оно есть, но там не хватает typeclasses и популярности. В CLR надо бы добавить зеленые потоки, но async/await помогает жить без них.
Здравствуйте, diez_p, Вы писали:
Pzz>>>>Вообще, во всей этой облачной инфраструктуре (именно в инфраструктуре, а не в веб-сервисах) go встречается очень часто. _>>>я бы на го побоялся писать сложную бизнеслогику,
_>Отсуствие исключений, многословоность, вывернутый наизнанку ООП, более слабые инструменты для диагностики по сравнению с jre например, еще скорее всего меньшие возможности в аннотациях/атрибутах, нет нормальной ide.
Насчет исключений, я не понимаю, чем они тебе так дороги.
Про многословность я бы поспорил. Программа на C++ получается более длинной, чем на Си. Программа на Go получается раза в два-три короче,
Гошный ООП хорош тем, что он не разрастается. На Го неудобно писать развернутую иерархию классов, и это хорошо.
Насчет инструментов для диагностики я бы поспорил. go vet весьма въедлив, хота это и простенький инструмент. Гошная очень дубовая и жесткая система типов не дает развернуться ненужной фантазии и вовремя бьет по рукам. А race detector чудо, как хорош.
Про аннотации, я не очень понял, что имеется ввиду.
Здравствуйте, diez_p, Вы писали:
Pzz>>Вообще, во всей этой облачной инфраструктуре (именно в инфраструктуре, а не в веб-сервисах) go встречается очень часто. _>я бы на го побоялся писать сложную бизнеслогику,
Обоснуй.
Pzz>весь этот системный софт это Си с GC.
Go это вообще Си 2.0. С GC и встроенными строками и ассоциативными массивами (map).
D>Подсунул мне ютуб видео про Go разработу. Собственно, насколько реалистично описаны в видосе работа разработчиком и доход?
За чистый Го никто не будет платить такие деньги. D>Понятно, что это для опытных инженеров. Но опыт можно будет наработать.
Меньше смотри ютуберов.
Подсунул мне ютуб видео про Go разработу. Собственно, насколько реалистично описаны в видосе работа разработчиком и доход?
Понятно, что это для опытных инженеров. Но опыт можно будет наработать.
Здравствуйте, Dair, Вы писали:
D>Ничего не знаю про насколько там реалистично, сам не из этого уголка, но знаю что именно на Go переписывают то что было когда-то написано на PHP. А на PHP было написано много. И довольно много Go-шников — это переученные PHP-шники.
Хм. Т.е. это гораздо более хороший инструмент для веб проектов, раз переписывают на нём.
Надо будет поглубже глянуть на это направление.
Здравствуйте, dignom, Вы писали:
D>https://www.youtube.com/watch?v=MtYfRrQ33gI
D>Подсунул мне ютуб видео про Go разработу. Собственно, насколько реалистично описаны в видосе работа разработчиком и доход? D>Понятно, что это для опытных инженеров. Но опыт можно будет наработать.
Не понимаю прям лютой ценности за язык го, возможно просто небольшой хайп
Но проблемы остаются теми же:
1) синхронизация данных в памяти и скорость ее работы.
2) Управление памятью: gc, аллокации, стек
3) Ввод вывод
Более менее серьезный софт сталкивается с такими проблемами
Здравствуйте, diez_p, Вы писали:
_>Не понимаю прям лютой ценности за язык го, возможно просто небольшой хайп
Ценность в нем ровно одна — АОТ. Все остальное плохо или очень плохо по сравнению с jvm и dotnet.
Здравствуйте, dignom, Вы писали:
D>>Ничего не знаю про насколько там реалистично, сам не из этого уголка, но знаю что именно на Go переписывают то что было когда-то написано на PHP. А на PHP было написано много. И довольно много Go-шников — это переученные PHP-шники.
D>Хм. Т.е. это гораздо более хороший инструмент для веб проектов, раз переписывают на нём. D>Надо будет поглубже глянуть на это направление.
Интересно, что на Go пишут довольно много системного софтвария. Например, docker, kubernetes...
Вообще, во всей этой облачной инфраструктуре (именно в инфраструктуре, а не в веб-сервисах) go встречается очень часто.
Здравствуйте, Pzz, Вы писали:
Pzz>Вообще, во всей этой облачной инфраструктуре (именно в инфраструктуре, а не в веб-сервисах) go встречается очень часто.
я бы на го побоялся писать сложную бизнеслогику, весь этот системный софт это Си с GC.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, diez_p, Вы писали:
Pzz>>>Вообще, во всей этой облачной инфраструктуре (именно в инфраструктуре, а не в веб-сервисах) go встречается очень часто. _>>я бы на го побоялся писать сложную бизнеслогику,
Отсуствие исключений, многословоность, вывернутый наизнанку ООП, более слабые инструменты для диагностики по сравнению с jre например, еще скорее всего меньшие возможности в аннотациях/атрибутах, нет нормальной ide.
Pzz>Интересно, что на Go пишут довольно много системного софтвария. Например, docker, kubernetes... Pzz>Вообще, во всей этой облачной инфраструктуре (именно в инфраструктуре, а не в веб-сервисах) go встречается очень часто.
Как я понимаю, такие вещи раньше писали на Perl, Python, Ruby, а потом Go приобрел популярность в среде питон-программистов. Вот и результат.
Здравствуйте, m2user, Вы писали:
Pzz>>Интересно, что на Go пишут довольно много системного софтвария. Например, docker, kubernetes... Pzz>>Вообще, во всей этой облачной инфраструктуре (именно в инфраструктуре, а не в веб-сервисах) go встречается очень часто.
M>Как я понимаю, такие вещи раньше писали на Perl, Python, Ruby, а потом Go приобрел популярность в среде питон-программистов. Вот и результат.
Пайк в какой-то статье писал, что рассчитывал в среднем привлечь сишников-плюсовиков, а привлек питонистов, к своему удивлению.
В среднем, Go — не питон. Не знаю, насколько комфортно питонисту жить с той мыслью, что два сабслайса одного слайса имеют общую память. Которая может неожиданно перестать быть общей, если одному из этих слайсов приписать в хвост append-ом. Или что если сделать из слайса очередь, приписывая в хвост и забирая из головы, то объем памяти, занимаемый этим слайсом, будет только расти.
Мне, как сишнику, такое положение вещей очень понатно. Но питонисту?
Такие вещи, как докер, я даже не знаю, на чем они раньше делались. Мне кажется, докеры всякие — это развитие виртуализации, а виртуализация скорее делалась на C++.
Здравствуйте, dignom, Вы писали:
D>https://www.youtube.com/watch?v=MtYfRrQ33gI
D>Подсунул мне ютуб видео про Go разработу. Собственно, насколько реалистично описаны в видосе работа разработчиком и доход? D>Понятно, что это для опытных инженеров. Но опыт можно будет наработать.
Тут основное — не сам Go, а то, что контрактор с большим промышленным опытом.
Любопытно, кстати, что в "Открытом Лектории Яндекса" (это видосы от мероприятий, которыми катят в стажёры) в этом году Go нет (в предыдущие пару лет был) и у нас на районе знаю одну контору, которая по каким-то причинам уже переписывает свой код c Go на Java.
Здравствуйте, Pzz, Вы писали:
Pzz>Такие вещи, как докер, я даже не знаю, на чем они раньше делались. Мне кажется, докеры всякие — это развитие виртуализации, а виртуализация скорее делалась на C++.
Докер это по сути обвязка вокруг штатных для линуксового ядра cgroups и namespases.
Здравствуйте, dignom, Вы писали:
d> Понятно, что это для опытных инженеров. Но опыт можно будет наработать.
Видео не смотрел, но go более чем актуален. Если хочешь попробовать, то никого не слушай — бери и пробуй. Работы на нем море (а в РФ так нормального специалиста днем с огнем не сыщешь), по финансам — тут уж как договоришься (но без хлеба с маслом точно не останешься).
Здравствуйте, mtnl, Вы писали:
Pzz>>Такие вещи, как докер, я даже не знаю, на чем они раньше делались. Мне кажется, докеры всякие — это развитие виртуализации, а виртуализация скорее делалась на C++.
M>Докер это по сути обвязка вокруг штатных для линуксового ядра cgroups и namespases.
Любая программа это обвязка вокруг чего-нибудь штатного
Здравствуйте, mtnl, Вы писали:
M>Любопытно, кстати, что в "Открытом Лектории Яндекса" (это видосы от мероприятий, которыми катят в стажёры) в этом году Go нет (в предыдущие пару лет был) и у нас на районе знаю одну контору, которая по каким-то причинам уже переписывает свой код c Go на Java.
Бывают такие конторы, которые свой код переписывают-переписывают, а потом глядишь, проект и закрылся, а то и сама контора.
Даже если код написан на Фортране-4, обычно это не настолько проблема, чтобы бросать всё и его переписывать. Но если код не делает что нужно, на чем его не переписывай, то никакое переписывание и не поможет.
Здравствуйте, mtnl, Вы писали:
Pzz>>Такие вещи, как докер, я даже не знаю, на чем они раньше делались. Мне кажется, докеры всякие — это развитие виртуализации, а виртуализация скорее делалась на C++.
M>Докер это по сути обвязка вокруг штатных для линуксового ядра cgroups и namespases.
На Go, кстати, не очень удобно писать обвязку вокруг cgroups и namespases. Потому, что они распостраняют свое влияние на процесс целиком, а для Go было бы удобнее, если бы на нить и ее потомков.
Здравствуйте, novitk, Вы писали:
N>Ценность в нем ровно одна — АОТ. Все остальное плохо или очень плохо по сравнению с jvm и dotnet.
Не скажи. jvm и dotnet — это переусложненное энтерпрайз дерьмо, создававшееся для уже неактуального варианта ооп с огромной кучей легаси в языках, библеотеках и платформе.
Здравствуйте, diez_p, Вы писали:
_>Отсуствие исключений, многословоность, вывернутый наизнанку ООП, более слабые инструменты для диагностики по сравнению с jre например, еще скорее всего меньшие возможности в аннотациях/атрибутах, нет нормальной ide.
Здравствуйте, mrTwister, Вы писали:
T>Не скажи. jvm и dotnet — это переусложненное энтерпрайз дерьмо, создававшееся для уже неактуального варианта ооп с огромной кучей легаси в языках, библеотеках и платформе.
Почему тебя занимает сложность vm? А если речь о языках, то давай конкретней. И там и там есть не только ООП языки.
Здравствуйте, Pzz, Вы писали:
Pzz>Насчет исключений, я не понимаю, чем они тебе так дороги.
Тем, что, что можно разрушить контекст, без отлова всяких ошибок в промежуточных состояниях.
Pzz>Про многословность я бы поспорил. Программа на C++ получается более длинной, чем на Си. Программа на Go получается раза в два-три короче,
Если сравнивать с java/С#/Kotlin про С++ — ничего не скажу.
Pzz>Гошный ООП хорош тем, что он не разрастается. На Го неудобно писать развернутую иерархию классов, и это хорошо.
В ООП надо уметь, но какой либо фреймворк на го интересно посмотреть как был бы сделан.
Pzz>Про аннотации, я не очень понял, что имеется ввиду.
Это метадата для обработки в рантайм или compile тайм, а ля если надо написать свой, узко специализированный спринг, хибернейт, рест контроллер и т.д.
Вообще языки я бы не особо сравнивал, т.к. сравнивать надо экосистемы, тут пожалуй только Си и С++ выбиваются, потому что в первых вообще все вручную делается во вторых — зависит, но тоже думать надо, в остальном плюс минус, а вот экосистемы это да.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, novitk, Вы писали:
N>>Ценность в нем ровно одна — АОТ. Все остальное плохо или очень плохо по сравнению с jvm и dotnet.
T>Не скажи. jvm и dotnet — это переусложненное энтерпрайз дерьмо, создававшееся для уже неактуального варианта ооп с огромной кучей легаси в языках, библеотеках и платформе.
Мне кажется вы просто такое готовить не умеете, на java и .net можно за день склепать ынтрепрайз приложение, которое будет ходить в базы, авторизации, с рестом и прочей хренью, накидав только конфигов/аннотаций и это все будет работать, огромное комьюнити для всего и вся.
Я не говорю про узкоспециализированный, нагруженный софт, там свои заморочки, хоть на джаве, хоть на .NET. очень много всего из коробки.
на .NET мощнейший linq, TPL и т.д.
Вот например на джаве хочу FTPS клиент с хождением через https прокси — пожалста, хочешь какую-то другую либу — пожалста.
тот же jmx — пожалста, какой-то ремоут дебаг — пожалста.
Если брать что-то абстрактно стоящее, типа гейтвей или что-то подобное, то го вполне уместен.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, novitk, Вы писали:
N>>Почему тебя занимает сложность vm?
T>Я тут не сколько саму vm имел ввиду, сколько всю экосистему
офигенная экосистема. есть абсолютно все
и да, вода у тебя течет в кране и чатгпт отвечает тоже благодаря энтерпрайзу. и скажи спасибо что он не написан на с++
и да, ghidra написана на java
N>>А если речь о языках, то давай конкретней. И там и там есть не только ООП языки.
T>Нестандартные языки на платформе — это маргинальная эзотерика, разве что кроме котлина (это лучшее, что случалось с джавой)
Здравствуйте, diez_p, Вы писали:
Pzz>>Насчет исключений, я не понимаю, чем они тебе так дороги.
_>Тем, что, что можно разрушить контекст, без отлова всяких ошибок в промежуточных состояниях.
Так это тебе не исключения дороги, а то, что с помощью деструкторов можно сделать контекст саморазрушающимся. В Go аналогичнпго результата можно добиться с помощью слова defer.
Pzz>>Гошный ООП хорош тем, что он не разрастается. На Го неудобно писать развернутую иерархию классов, и это хорошо. _>В ООП надо уметь, но какой либо фреймворк на го интересно посмотреть как был бы сделан.
Я как-то даже не могу припомнить навскидку какой-то гошный фреймворк. Фрейворки ведь претендуют, в отличии от библиотек, организовать по-своему всю жизнь программы, в довесок к тому, что что-то полезное делают. В Го обычно пишут библиотеки, а не фреймворки. Жизнь при этом организует язык и его стандартная библиотека, и как-то всех это устраивает.
Pzz>>Про аннотации, я не очень понял, что имеется ввиду. _>Это метадата для обработки в рантайм или compile тайм, а ля если надо написать свой, узко специализированный спринг, хибернейт, рест контроллер и т.д.
В Го можно приписать метадату к полям структур, но это довольно простой, прямолинейных механизм.
_>Вообще языки я бы не особо сравнивал, т.к. сравнивать надо экосистемы, тут пожалуй только Си и С++ выбиваются, потому что в первых вообще все вручную делается во вторых — зависит, но тоже думать надо, в остальном плюс минус, а вот экосистемы это да.
Здравствуйте, mrTwister, Вы писали:
T>Не скажи. jvm и dotnet — это переусложненное энтерпрайз дерьмо, создававшееся для уже неактуального варианта ооп с огромной кучей легаси в языках, библеотеках и платформе. T>Я тут не сколько саму vm имел ввиду, сколько всю экосистему T>Нестандартные языки на платформе — это маргинальная эзотерика, разве что кроме котлина (это лучшее, что случалось с джавой)
Притив таких аргументов мне нечего возразить. Ты победил и я сдаюсь. Идите все на ГО!
Здравствуйте, diez_p, Вы писали:
_>Я не говорю про узкоспециализированный, нагруженный софт, там свои заморочки, хоть на джаве, хоть на .NET. очень много всего из коробки.
А я говорю.
"узкоспециализированный, нагруженный софт" на jvm/dotnet писать быстрее, надежней и легче чем на GoLang. А в случае последних версий dotnet он еще будет быстрее работать и лучше использовать память.
_>Если брать что-то абстрактно стоящее, типа гейтвей или что-то подобное, то го вполне уместен.
На сегодняшний день после появления в jvm/dotnet АОT для Go нет уместного сценария для новых проектов, только legacy.
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, diez_p, Вы писали:
_>>Я не говорю про узкоспециализированный, нагруженный софт, там свои заморочки, хоть на джаве, хоть на .NET. очень много всего из коробки. N>А я говорю. N>"узкоспециализированный, нагруженный софт" на jvm/dotnet писать быстрее, надежней и легче чем на GoLang. А в случае последних версий dotnet он еще будет быстрее работать и лучше использовать память.
_>>Если брать что-то абстрактно стоящее, типа гейтвей или что-то подобное, то го вполне уместен. N>На сегодняшний день после появления в jvm/dotnet АОT для Go нет уместного сценария для новых проектов, только legacy.
Вот видите, даже тут мои предположения могут быть подставлены под сомнения. Я .NET последний не особо смотрел, но там чет микрософт и для векторных операций добавил, и с памятью тож какие-то заморочки были, что можно все руками сделать.
