История изменений

он не берет планку достигнутую десятилетие до него и ничего не упрощает

Допустим, вы не верите в маркетинг. Ну вы спросите пользователей. Хотя могу угадать, им «маркетинг мозги промыл», «стокгольмский синдром», «эти джуны ничего кроме го не видели» и проч.

это если даже не говорить о сломаном дизайне обработки ошибок

Ложь.

Дизайн обработки ошибок был сломан в C++. Жизнь стала лучше в Java, хотя основная проблема осталась: control flow разделён на две части, дисциплина обработки ошибок сведена к бюрократии.

Го исправил обработку ошибок. Конечно, даже она может быть улучшена системой типов как в Rust, но без этого никто не страдает.

откуда утверждения о том, что подходы и концепты для конкарренси в нем superior тем что были в языках для простых людей до голанга?

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

Не перепутайте «для простых людей» с «простые треды».

Если вы имеете ввиду async/await, то хотя это лучше pthreads, у них есть своя доля проблем: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Tldr: “Compared to goroutines, channels, and select, async/await is easier and smaller for language implementers to build or to retrofit into existing platforms. But it pushes some of the complexity back on the programmer, often resulting in what Bob Nystrom has famously called ‘colored functions’.”

В любом случае, нужно что-то лучше стиля pthreads.

что они вообще лучше работают на практике и их дизайн удачен?

Это проверенная модель, так что новые исследования не критичны, хотя никто не против. Кстати, такие исследования существуют:

https://songlh.github.io/paper/go-study.pdf

grep ‘Shared memory vs. message passing’

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

что reasoning относительно них проще и они будут приводить к меньшему числу некорректных программ?

Личный опыт. Некоторые вещи только так и можно установить и это абсолютно нормально.

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

На реализацию было пофиг. Ну мы, конечно, постараемся сделать всё возможное, но пусть полное решение завезёт кто-нибудь другой попозже. That’s life.

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

Что не так с моделью памяти? https://go.dev/ref/mem

[«Go создал Гугл для себя»] это маркетинговая болтовня не более

…

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

Ну а эту болтовню как назвать, «объективным непротиворечивым фактом» или «обязательным диалектическим выводом»?

не было такой разнарядки сверху «нам бы хорошо новый язык для себя создать»

Вы можете опровергнуть тезисы этой статьи? https://go.dev/talks/2012/splash.article

В разделе “Pain points” перечислены pain points. Они действительно существовали в Гугле? Ну я, конечно, не уверен на 100%, но никто из гугла, вроде бы, не утверждает обратное. Эти проблемы были исправлены Гошкой? Многие — да.

голанг всего лишь наполнитель этой внутригугловской политической конкуренции

Даже если так, что в этом плохого? Вы коммунист и желаете взорвать Манхэттен?

он не берет планку достигнутую десятилетие до него и ничего не упрощает

Допустим, вы не верите в маркетинг. Ну вы спросите пользователей. Хотя могу угадать, им «маркетинг мозги промыл», «стокгольмский синдром», «эти джуны ничего кроме го не видели» и проч.

это если даже не говорить о сломаном дизайне обработки ошибок

Ложь.

Дизайн обработки ошибок был сломан в C++. Жизнь стала лучше в Java, хотя основная проблема осталась: control flow разделён на две части.

Го исправил обработку ошибок. Конечно, даже она может быть улучшена системой типов как в Rust, но без этого никто не страдает.

откуда утверждения о том, что подходы и концепты для конкарренси в нем superior тем что были в языках для простых людей до голанга?

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

Не перепутайте «для простых людей» с «простые треды».

Если вы имеете ввиду async/await, то хотя это лучше pthreads, у них есть своя доля проблем: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Tldr: “Compared to goroutines, channels, and select, async/await is easier and smaller for language implementers to build or to retrofit into existing platforms. But it pushes some of the complexity back on the programmer, often resulting in what Bob Nystrom has famously called ‘colored functions’.”

В любом случае, нужно что-то лучше стиля pthreads.

что они вообще лучше работают на практике и их дизайн удачен?

Это проверенная модель, так что новые исследования не критичны, хотя никто не против. Кстати, такие исследования существуют:

https://songlh.github.io/paper/go-study.pdf

grep ‘Shared memory vs. message passing’

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

что reasoning относительно них проще и они будут приводить к меньшему числу некорректных программ?

Личный опыт. Некоторые вещи только так и можно установить и это абсолютно нормально.

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

На реализацию было пофиг. Ну мы, конечно, постараемся сделать всё возможное, но пусть полное решение завезёт кто-нибудь другой попозже. That’s life.

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

Что не так с моделью памяти? https://go.dev/ref/mem

[«Go создал Гугл для себя»] это маркетинговая болтовня не более

…

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

Ну а эту болтовню как назвать, «объективным непротиворечивым фактом» или «обязательным диалектическим выводом»?

не было такой разнарядки сверху «нам бы хорошо новый язык для себя создать»

Вы можете опровергнуть тезисы этой статьи? https://go.dev/talks/2012/splash.article

В разделе “Pain points” перечислены pain points. Они действительно существовали в Гугле? Ну я, конечно, не уверен на 100%, но никто из гугла, вроде бы, не утверждает обратное. Эти проблемы были исправлены Гошкой? Многие — да.

голанг всего лишь наполнитель этой внутригугловской политической конкуренции

Даже если так, что в этом плохого? Вы коммунист и желаете взорвать Манхэттен?

он не берет планку достигнутую десятилетие до него и ничего не упрощает

Допустим, вы не верите в маркетинг. Ну вы спросите пользователей. Хотя могу угадать, им «маркетинг мозги промыл», «стокгольмский синдром», «эти джуны ничего кроме го не видели» и проч.

это если даже не говорить о сломаном дизайне обработки ошибок

Ложь.

Дизайн обработки ошибок был сломан в C++. Жизнь стала лучше в Java, хотя основная проблема осталась: control flow разделён на две части.

Го исправил обработку ошибок. Конечно, даже она может быть улучшена системой типов как в Rust, но без этого никто не страдает.

откуда утверждения о том, что подходы и концепты для конкарренси в нем superior тем что были в языках для простых людей до голанга?

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

Не перепутайте «для простых людей» с «простые треды».

Если вы имеете ввиду async/await, то хотя это лучше pthreads, у них есть своя доля проблем: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Tldr: “Compared to goroutines, channels, and select, async/await is easier and smaller for language implementers to build or to retrofit into existing platforms. But it pushes some of the complexity back on the programmer, often resulting in what Bob Nystrom has famously called ‘colored functions’.”

В любом случае, нужно что-то лучше стиля pthreads.

что они вообще лучше работают на практике и их дизайн удачен?

Это проверенная модель, так что новые исследования не критичны, хотя никто не против. Кстати, такие исследования существуют:

https://songlh.github.io/paper/go-study.pdf

grep ‘Shared memory vs. message passing’

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

что reasoning относительно них проще и они будут приводить к меньшему числу некорректных программ?

Личный опыт. Некоторые вещи только так и можно установить и это абсолютно нормально.

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

На реализацию было пофиг. Ну мы, конечно, постараемся сделать всё возможное, но пусть полное решение завезёт кто-нибудь другой попозже. That’s life.

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

Что не так с моделью памяти? https://go.dev/ref/mem

[«Go создал Гугл для себя» —] это маркетинговая болтовня не более

…

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

Ну а эту болтовню как назвать, «объективным непротиворечивым фактом» или «обязательным диалектическим выводом»?

не было такой разнарядки сверху «нам бы хорошо новый язык для себя создать»

Вы можете опровергнуть тезисы этой статьи? https://go.dev/talks/2012/splash.article

В разделе “Pain points” перечислены pain points. Они действительно существовали в Гугле? Ну я, конечно, не уверен на 100%, но никто из гугла, вроде бы, не утверждает обратное. Эти проблемы были исправлены Гошкой? Многие — да.

голанг всего лишь наполнитель этой внутригугловской политической конкуренции

Даже если так, что в этом плохого? Вы коммунист и желаете взорвать Манхэттен?

он не берет планку достигнутую десятилетие до него и ничего не упрощает

Допустим, вы не верите в маркетинг. Ну вы спросите пользователей. Хотя могу угадать, им «маркетинг мозги промыл», «стокгольмский синдром», «эти джуны ничего кроме го не видели» и проч.

это если даже не говорить о сломаном дизайне обработки ошибок

Ложь.

Дизайн обработки ошибок был сломан в C++. Жизнь стала лучше в Java, хотя основная проблема осталась: control flow разделён на две части.

Го исправил обработку ошибок. Конечно, даже она может быть улучшена системой типов как в Rust, но без этого никто не страдает.

откуда утверждения о том, что подходы и концепты для конкарренси в нем superior тем что были в языках для простых людей до голанга?

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

Не перепутайте «для простых людей» с «простые треды».

Если вы имеете ввиду async/await, то хотя это лучше pthreads, у них есть своя доля проблем: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Tldr: “Compared to goroutines, channels, and select, async/await is easier and smaller for language implementers to build or to retrofit into existing platforms. But it pushes some of the complexity back on the programmer, often resulting in what Bob Nystrom has famously called ‘colored functions’.”

В любом случае, нужно что-то лучше стиля pthreads.

что они вообще лучше работают на практике и их дизайн удачен?

Это проверенная модель, так что новые исследования не критичны, хотя никто не против. Кстати, такие исследования существуют:

https://songlh.github.io/paper/go-study.pdf

grep ‘Shared memory vs. message passing’

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

что reasoning относительно них проще и они будут приводить к меньшему числу некорректных программ?

Личный опыт. Некоторые вещи только так и можно установить и это абсолютно нормально.

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

На реализацию было пофиг. Ну мы, конечно, постараемся сделать всё возможное, но пусть полное решение завезёт кто-нибудь другой попозже. That’s life.

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

Что не так с моделью памяти? https://go.dev/ref/mem

это маркетинговая болтовня не более

…

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

Ну а эту болтовню как назвать, «объективным непротиворечивым фактом» или «обязательным диалектическим выводом»?

не было такой разнарядки сверху «нам бы хорошо новый язык для себя создать»

Вы можете опровергнуть тезисы этой статьи? https://go.dev/talks/2012/splash.article

В разделе “Pain points” перечислены pain points. Они действительно существовали в Гугле? Ну я, конечно, не уверен на 100%, но никто из гугла, вроде бы, не утверждает обратное. Эти проблемы были исправлены Гошкой? Многие — да.

голанг всего лишь наполнитель этой внутригугловской политической конкуренции

Даже если так, что в этом плохого? Вы коммунист и желаете взорвать Манхэттен?

он не берет планку достигнутую десятилетие до него и ничего не упрощает

Допустим, вы не верите в маркетинг. Ну вы спросите пользователей. Хотя могу угадать, им «маркетинг мозги промыл», «стокгольмский синдром», «эти джуны ничего кроме го не видели» и проч.

это если даже не говорить о сломаном дизайне обработки ошибок

Ложь.

Дизайн обработки ошибок был сломан в C++. Проблема была исправлена в Java, хотя основная проблема осталась: control flow разделён на две части.

Го исправил обработку ошибок. Конечно, даже она может быть улучшена системой типов как в Rust, но без этого никто не страдает.

откуда утверждения о том, что подходы и концепты для конкарренси в нем superior тем что были в языках для простых людей до голанга?

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

Не перепутайте «для простых людей» с «простые треды».

Если вы имеете ввиду async/await, то хотя это лучше pthreads, у них есть своя доля проблем: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Tldr: “Compared to goroutines, channels, and select, async/await is easier and smaller for language implementers to build or to retrofit into existing platforms. But it pushes some of the complexity back on the programmer, often resulting in what Bob Nystrom has famously called ‘colored functions’.”

В любом случае, нужно что-то лучше стиля pthreads.

что они вообще лучше работают на практике и их дизайн удачен?

Это проверенная модель, так что новые исследования не критичны, хотя никто не против. Кстати, такие исследования существуют:

https://songlh.github.io/paper/go-study.pdf

grep ‘Shared memory vs. message passing’

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

что reasoning относительно них проще и они будут приводить к меньшему числу некорректных программ?

Личный опыт. Некоторые вещи только так и можно установить и это абсолютно нормально.

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

На реализацию было пофиг. Ну мы, конечно, постараемся сделать всё возможное, но пусть полное решение завезёт кто-нибудь другой попозже. That’s life.

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

Что не так с моделью памяти? https://go.dev/ref/mem

это маркетинговая болтовня не более

…

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

Ну а эту болтовню как назвать, «объективным непротиворечивым фактом» или «обязательным диалектическим выводом»?

не было такой разнарядки сверху «нам бы хорошо новый язык для себя создать»

Вы можете опровергнуть тезисы этой статьи? https://go.dev/talks/2012/splash.article

В разделе “Pain points” перечислены pain points. Они действительно существовали в Гугле? Ну я, конечно, не уверен на 100%, но никто из гугла, вроде бы, не утверждает обратное. Эти проблемы были исправлены Гошкой? Многие — да.

голанг всего лишь наполнитель этой внутригугловской политической конкуренции

Даже если так, что в этом плохого? Вы коммунист и желаете взорвать Манхэттен?

он не берет планку достигнутую десятилетие до него и ничего не упрощает

Допустим, вы не верите в маркетинг. Ну вы спросите пользователей. Хотя могу угадать, им «маркетинг мозги промыл», «стокгольмский синдром», «эти джуны ничего кроме го не видели» и проч.

это если даже не говорить о сломаном дизайне обработки ошибок

Ложь.

Дизайн обработки ошибок был сломан в C++. Проблема была исправлена в Java, хотя основная проблема осталась: control flow разделён на две части.

Го исправил обработку ошибок. Конечно, даже она может быть улучшена системой типов как в Rust, но без этого никто не страдает.

откуда утверждения о том, что подходы и концепты для конкарренси в нем superior тем что были в языках для простых людей до голанга?

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

Не перепутайте «для простых людей» с «простые треды».

Если вы имеете ввиду async/await, то хотя это лучше pthreads, у них есть своя доля проблем: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Tldr: “Compared to goroutines, channels, and select, async/await is easier and smaller for language implementers to build or to retrofit into existing platforms. But it pushes some of the complexity back on the programmer, often resulting in what Bob Nystrom has famously called ‘colored functions’.”

В любом случае, нужно что-то лучше стиля pthreads.

что они вообще лучше работают на практике и их дизайн удачен?

Это проверенная модель, так что новые исследования не критичны, хотя никто не против. Кстати, такие исследования существуют:

https://songlh.github.io/paper/go-study.pdf

grep ‘Shared memory vs. message passing’

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

что reasoning относительно них проще и они будут приводить к меньшему числу некорректных программ?

Личный опыт. Некоторые вещи только так и можно установить и это абсолютно нормально.

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

На реализацию было пофиг. Пусть её решит кто-нибудь другой. Sad but true.

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

Что не так с моделью памяти? https://go.dev/ref/mem

это маркетинговая болтовня не более

…

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

Ну а эту болтовню как назвать, «объективным непротиворечивым фактом» или «обязательным диалектическим выводом»?

не было такой разнарядки сверху «нам бы хорошо новый язык для себя создать»

Вы можете опровергнуть тезисы этой статьи? https://go.dev/talks/2012/splash.article

В разделе “Pain points” перечислены pain points. Они действительно существовали в Гугле? Ну я, конечно, не уверен на 100%, но никто из гугла, вроде бы, не утверждает обратное. Эти проблемы были исправлены Гошкой? Многие — да.

голанг всего лишь наполнитель этой внутригугловской политической конкуренции

Даже если так, что в этом плохого? Вы коммунист и желаете взорвать Манхэттен?

он не берет планку достигнутую десятилетие до него и ничего не упрощает

Допустим, вы не верите в маркетинг. Ну вы спросите пользователей. Хотя могу угадать, им «маркетинг мозги промыл», «стокгольмский синдром», «эти джуны ничего кроме го не видели» и проч.

это если даже не говорить о сломаном дизайне обработки ошибок

Ложь.

Дизайн обработки ошибок был сломан в C++. Проблема была исправлена в Java, хотя основная проблема осталась: control flow разделён на две части.

Го исправил обработку ошибок. Конечно, даже она может быть улучшена системой типов как в Rust, но без этого никто не страдает.

откуда утверждения о том, что подходы и концепты для конкарренси в нем superior тем что были в языках для простых людей до голанга?

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

Не перепутайте «для простых людей» с «простые треды».

Если вы имеете ввиду async/await, то хотя это лучше pthreads, у них есть своя доля проблем: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Tldr: “Compared to goroutines, channels, and select, async/await is easier and smaller for language implementers to build or to retrofit into existing platforms. But it pushes some of the complexity back on the programmer, often resulting in what Bob Nystrom has famously called ‘colored functions’.”

В любом случае, нужно что-то лучше стиля pthreads.

что они вообще лучше работают на практике и их дизайн удачен?

Это проверенная модель, так что новые исследования не критичны, хотя никто не против. Кстати, такие исследования существуют:

https://songlh.github.io/paper/go-study.pdf

grep ‘Shared memory vs. message passing’

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

что reasoning относительно них проще и они будут приводить к меньшему числу некорректных программ?

Личный опыт. Некоторые вещи только так и можно установить и это абсолютно нормально.

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

На реализацию было пофиг. Пусть её решит кто-нибудь другой. Sad but true.

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

Что не так с моделью памяти? https://go.dev/ref/mem

это маркетинговая болтовня не более

…

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

Ну а эту болтовню как назвать, «объективным непротиворечивым фактом» или «обязательным диалектическим выводом»?

не было такой разнарядки сверху «нам бы хорошо новый язык для себя создать»

Вы можете опровергнуть тезисы этой статьи? https://go.dev/talks/2012/splash.article

В разделе “Pain points” перечислены pain points. Они действительно существовали в Гугле? Ну я, конечно, не уверен на 100%, но никто из гугла, вроде бы, не утверждает обратное. Эти проблемы были исправлены Гошкой? Многие — да.

голанг всего лишь наполнитель этой внутригугловской политической конкуренции

Даже если так, что в этом плохого? Вы коммунист и желаете взорвать Манхэттен?