Re[4]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: rudzuk  
Дата: 10.07.23 20:20
Оценка: 2 (1) +3
Здравствуйте, Pzz, Вы писали:

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


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

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


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

Go не простой язык — он примитивный. И этот примитивизм, зачастую, играет злую шутку, делая простые вещи сложными. Взять те же интерфейсы. Как можно понять, что тип реализует те или иные интерфейсы? Да никак. Сравнивай сигнутуры методов. Пипец просто... Или: исключений нет, но вот вам паника и дефер, эмулируйте. Примитивизм, как он есть. Аккурат для целевой аудитории: тупеньких, но трудолюбивых.
avalon/3.0.2
Re[11]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: VladiCh  
Дата: 10.07.23 20:58
Оценка:
Здравствуйте, novitk, Вы писали:

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


N>>>если GC не проблема, то чем Java(Scala/Kotlin/etc) с АОТ(Graal) не подходит? Ну или .NET?

VC>>тяжеленное говнище для кучи случаев. жрут память как не в себя.
N>"Tяжелое говнище" это Спринги и Томкаты, которым давно пора на помоечку. В Go никакой магии в управлении памяти нет, GC там до сих пор хуже, a ValueType в Яву завезли.

Все правильно, но даже без спрингов и томкатов джава просто тяжелая. Go все таки полноценный компилируемый язык, без этих всяких джитов и рандомного времени ответа.
С AOT это как-то решается (для небольших приложений), но из того что я слышал возникают другие проблемы, уже с большими приложениями.
Re[12]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: novitk США  
Дата: 10.07.23 21:46
Оценка:
Здравствуйте, VladiCh, Вы писали:

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

Подозреваю, что речь идет о уже написанном коде. Понятно, что пропустить какой-нибудь Eclipse через АOT нетривиально, но так ли это и нужно именно для больших приложений?
Интересно был бы посмотреть на сравнение какого-нибудь gRPC на двух стеках с современными либам на стороне Граля. У меня есть подозрения, что разница будет околонулевая.
Re[10]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: Разраб  
Дата: 11.07.23 01:44
Оценка:
Здравствуйте, Pzz, Вы писали:

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


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


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


Слайсам уже сто лет, грубо говоря https://duckduckgo.com/?q=dlang+slice&atb=v314-1&ia=web
ЗЫ в свое время с надеждой смотрел на ди, но почему то в его сторону тоже много критики.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[7]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: so5team https://stiffstream.com
Дата: 11.07.23 05:30
Оценка: 1 (1) +1
Здравствуйте, SkyDance, Вы писали:

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


Так уже же ж: https://go.dev/blog/intro-generics
Re[4]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: so5team https://stiffstream.com
Дата: 11.07.23 05:40
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


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


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


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

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

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

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

Disclaimer: это не моя точка зрения, это аргументы в пользу Go, которые по моим наблюдениям чаще всего высказываются.
Re[5]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: korvin_  
Дата: 11.07.23 07:46
Оценка:
Здравствуйте, 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 -- не такой маленький.
Отредактировано 11.07.2023 7:47 korvin_ . Предыдущая версия .
Re[4]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: Anton Batenev Россия https://github.com/abbat
Дата: 11.07.23 08:04
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

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


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

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

Вот был (есть и сейчас, но "уже не торт") такой веб-сервер как nginx, написанный "админом для админов", без вот этой теоретической фигни, а исключительно для решения реальных практических задач high load. Язык Go находится где-то там же — он без вот этого теоретического bull-shit решает реальные практические задачи современного high-load.
Re[6]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: so5team https://stiffstream.com
Дата: 11.07.23 08:34
Оценка:
Здравствуйте, 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 как не делают.
Re[7]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: rudzuk  
Дата: 11.07.23 10:32
Оценка: :)
Здравствуйте, so5team, Вы писали:

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


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


Нет, просто ты не видишь толп фанатиков, каждый из которых считает своим долгом высраться в хабр постом или предложить свой курс по языку. Не модная тема. Однако, например Сберу, это не мешает писать новый софт на дельфях.
avalon/3.0.2
Re[5]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: rudzuk  
Дата: 11.07.23 10:32
Оценка: 1 (1)
Здравствуйте, so5team, Вы писали:

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

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

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


helloworld (linux_amd64): go 1.20.5 (ldflags "-s -w") — 1.2 Mb, freepascal 3.2.2 — 35 Kb.
avalon/3.0.2
Re[8]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: so5team https://stiffstream.com
Дата: 11.07.23 11:04
Оценка: +1
Здравствуйте, rudzuk, Вы писали:

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


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


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

Так к чему претензия? Нравится Delphi, но не нравится, что его живым трупом кто-то называет?
Re[6]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: so5team https://stiffstream.com
Дата: 11.07.23 11:06
Оценка:
Здравствуйте, rudzuk, Вы писали:

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


Интересно было бы взглянуть еще и на выхлоп ldd для этих helloworld-ов.
Re[9]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: rudzuk  
Дата: 11.07.23 12:47
Оценка:
Здравствуйте, so5team, Вы писали:

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


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


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

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


Нет никаких претензий Дельфы, да и паскаль вообще, трупом называют уже лет двадцать. Некоторых называвших уже черви давно съели, а ей хоть бы что.
avalon/3.0.2
Re[7]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: rudzuk  
Дата: 11.07.23 12:47
Оценка: 2 (1)
Здравствуйте, 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 для обоих
avalon/3.0.2
Re[10]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: so5team https://stiffstream.com
Дата: 11.07.23 13:13
Оценка: +1
Здравствуйте, rudzuk, Вы писали:

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


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

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


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


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

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

Вот Delphi за счет рывка в 90-х себе такое состояние обеспечил. Но (как и множество других, отнюдь не самых плохих языков, вроде Eiffel, Ada, OCaml, Ruby) погоды уже не делает.
Re[11]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: rudzuk  
Дата: 11.07.23 14:13
Оценка:
Здравствуйте, so5team, Вы писали:

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


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

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


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

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


У дельфей был тяжелый период со сменой собственников и она прилично подрастеряла аудиторию. Однако, сейчас компания снова возвращает язык в образовательную сферу (на самом деле делает это уже несколько лет), благодаря чему интерес к нему возрастает.
avalon/3.0.2
Re[12]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: so5team https://stiffstream.com
Дата: 11.07.23 15:23
Оценка:
Здравствуйте, rudzuk, Вы писали:

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


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


В бюрократической компании, вроде Сбера, за выбором технологии может стоять масса причин, главные из которых будут политическими.
Re[13]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: rudzuk  
Дата: 11.07.23 15:41
Оценка:
Здравствуйте, so5team, Вы писали:

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


Использовать мертвый язык для нового проекта...
avalon/3.0.2
Re[14]: Почему GO нишевый? Будущее за zig? Ошибаюсь?
От: so5team https://stiffstream.com
Дата: 11.07.23 16:11
Оценка:
Здравствуйте, rudzuk, Вы писали:

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


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

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