"Непонятно, почему люди вообще считают что го как-то специально сделали чтобы что-то. Го просто сделан дедом, как дед умеет делать, и делал всю жизнь, и читать этот дед перестал в 70-е годы" :-)
@@vladimirlos5432 Rust, Haskell, Scala, Gleam, Mojo. Огромное количество языков, откуда можно было бы подчерпнуть идеи по эффективной и удобной обработке ошибок, корректной и удобной работе с изменяемыми и неизменяемыми значениями, удобной и эффективной работе с обобщёнными функциями. Я уж не говорю про EDSL.
Объясните мне, дураку. Вот есть C# с неплохими женериками (женерики поверх структур используют мономорфизацию, а поверх классов - стирание типов), работает хорошо, но как там в недрах - хз. Почему все разработчики, которые вертятся вокруг Go, говорят, что их сделать сложно или нереально и дают в пример джаву, где женерики, откровенно говоря, сделаны плохо?
@@ИванИванов-к1ь7с 1,2,3,4,5 -Ок, значит сейчас нужно. 6. Значит вы не разработчик библиотек и в принципе смирились с тем, что нужно использовать кодоген и копипасту для всего. >Ну так зачем усложнять компилятор? Чтобы он этой рутиной сам занимался, и чтобы всякие встроенные в язык функции можно было выразить, как обычный код.
@@ИванИванов-к1ь7с нет. Просто я ни разу не сталкивался с такими вещами, которые требуют надёжность такого рода (сдаётся мне, что это где-то около ВПК, авиационной и медицинской техники). В моём понимании "язык промышленной разработки" - это язык, который активно используется для решения прикладных задач (не для научной работы, не для сбора статистики, и не для выполнения запросов к реляционным базам данных), а значит в моём понимании (и в понимании гугла) под такое понятие подпадает и C++, и Js, и Python и много других языков, которые берут "от бедноты". Ну и если уж мы спорим, подходит ли тот или иной язык для промышленности - го тут тоже мимоходом, тк не ясно, сколько времени будет длится пауза на сборку мусора и прочее.
Пару лет назад вообще о гоу разве что слышал, соответственно щупал чудовую игрушку, забавная была, но выбирая из двух чудных игрушек поиграться выбрал DLang, куда интереснее. Год назад бывший коллега предлагал к нему на работу, писать на гоу. Мои увещевания "акстись, я его разве что поиграться пробовал" его не удовлетворили: программировать умеешь, синтаксис знаешь, справишься. В этом году вдруг на работе сказали, что все разработчики гошечные вымерли, готов взять на поддержку их продукт. Ну поддержка - это делать, баги там какие мы завсегда и на чем угодно можем поправить. Пару вечеров по вспоминал синтаксис, полез в проект. И меня стошнило. Уж простят меня разработчики на Go, но, как бы это помягче сравнить: вот я носитель русского языка, говорю на английском, французском, испанском. И тут мне предлагают побыстренькому изучить греческий и сделать перевод. Вроде буковки все теже, смысл понятен, но мозг просто различает на части от этой смеси латинских, кириллических и собственно греческих буковок, котрые складываются порой просто в чудовищные конструкции. И если само отвращение к языку побороть удалось (никак за плечами C/C++, Java, Perl, Python, JavaScript, само собой разумеющиеся Basic и Pascal, приходилось и PHP, но почти все языки примерно одинаковые и логичные в плане использования скобочек, передачи данных и так далее, то тут в Go какие-то безумные инициализации данных в фигурных скобках, а перед этим указание типа для карты в квадратных, ну да ладно, это все вопрос привычки), то проект просто вызывает боль костей. Ощущение, что все непрлдумано и неструктурировано, типы заводятся на лево и направо (коллега тут доказывал, что это позволяет избежать ошибки в использовании параметров. Серьёзно, то есть 100 раз по коду введён новый тип int, и это позволяет от чего-то защититься? Может надо от разраба, который не понимает, что ему надо в функцию передать, раз приходится защищаться введением нового типа, избавиться?) Интерфейсы - это вообще боль. То есть очень хотелось сделать простой язык функциональный, поэтому отказались от ООП. Окей, изобрели бэйсик. Потом поняли, что не конкуренты. И вкрячили костыль в виде интерфейса. То есть не признали факт, что надо делать ООП, а именно присобачили интерфейс, чтобы самому данному довесить метод работы с ним. И чтобы не путаться типа кинули всю эту кучку какашенций в один файлик, котрый тут же свалили тут в один каталог, что приводит порой просто к дичайшим зацикливаниям импортов. Да, я понимаю, что каждый хвалит свой насест. Я никогда ни один язык не изучал, не было времени да и не хотел, досконально, потому что язык - это инструмент, как и механику башенного крана мне не надо знать, как там рассчитана ферма крана, мне надо знать базовые параметры, чтобы понимать, что работа будет безопасна, что-то типа массы противовеса при определённой длине стрелы и массе груза. Поэтому и Python, на котором я пишу сейчас для меня открыт, есть что поизучать. Но когда понимаешь, что нужно тратить часы времени, за которое платит работодатель, чтобы послушать вот такие видосы и понять, что язык все равно говно, то это крайне вредная штука. И что многие работодатели готовы платить сотни 2-3 тысяч за разработчика на Гоу, хотя тоже самое можно дешевле (да-да, дешевле, потому что будет быстрее и проще разработка) сделать на Python с использованием C++ в узких местах, для меня загадка. Разговоры про быстроту Гоу на самом деле только разговоры, потому что быстрее, чем сам сервер, работать не будет. У меня, конечно, был разработчик, котрый умудрился втупить 16ядерный сервер с 64 Гб быстрой оперативки, на в целом не самой сложной задаче по обработке большого количества данных, потом все это было переписано и легко работало на 4 ядерном серваке с 16Гб оперативки. Но там и проблема была не в языке и Гоу бы не помог, там проблема была в обработке большого количества данных, которая была сделана неверно, и на Гоу она так же была бы сделана неправильно. В любом языке все равно разработчик упрется в медленный ввод/вывод, нехватку ресурсов или ещё какую "нежданную радость". И что кто-то сумел за 7 минут опросить мульон серверов на Гоу, хотя раньше еле успевал за сутки на Python - это сказки заядлых рыбаков о пойманном каркасе на полтонны и в 10 метров. В общем язык вызывает какую-то тошнительную реакцию.
@@ИванИванов-к1ь7с экономики чего? Тут важно понять, что вы хотите экономить, человеческие ресурсы или ресурсы машины? Я в 10 раз быстрее решу задачу на Питоне, чем на Golang! И не потому, что я питонист, го я тоже знаю и умею писать на нем, а все потому что, го слишком многословен и плохо продуман. Как думаете, каков процент задач решается на го в Гугл? Минимум!Основа С++/Java, Python
ООП в го есть, но оно своё... особенное... Если в других ооп-языках оборачивают всё в класс, задают поля и методы, то в го это сделано структурами... но это не беда. Беда в том, что реализация этих методов может быть где угодно. Даже если методы структуры идут сразу после самой структуры (а я уверен, кто-то может кодить так, что методы будут вообще в какой-то попе), визуально, на глаз воспринимается это крайне не читабельно
@@aquinary.и дженерики в методах не работают (по состоянию на 1.21.4). А вообще, количество велосипедов, которые заставляет писать язык - просто зашкаливает. Печально это всё.
Крутой доклад, эдакий экскурс в историю! Спасибо автору :)
Почему большинство докладов по голангу двухлетней давности?
Потому что уже трёхлетней.
Отличный доклад, спасибо!
Очень классный доклад. В следующий раз когда мне скажут что-то про го, буду отвечать "посмотрите в историю"
профи конференция ..."не читал, но одобряю..." профи,НА!
Норм доклад.
было ощущение, что слушаю свободный пересказ вот этого видео ua-cam.com/video/k0VsfTAqqEA/v-deo.html
Слизал с Запада
4:01 Что-то никто не оценил прикол...
Сейчас - мало, кто понимает, что было произнесено. Контекст утерян...
По моему это Автор доклада странный. Как по мне этот язык уже давно был запрос. Если бы не Go был бы rust или язык D
Щорсу привет!
"Непонятно, почему люди вообще считают что го как-то специально сделали чтобы что-то.
Го просто сделан дедом, как дед умеет делать, и делал всю жизнь, и читать этот дед перестал в 70-е годы"
:-)
Глупый мальчик... совсем дурак.
А после 70-х читать и нечего. Все основные идеи (от сервисной архитектуры до модели акторов), все парадигмы программирования появились до 80-х годов.
Вы - не дед. И вы готовы что-то удивительное, неординарное и небывалое показать дедам?
@@vladimirlos5432 Rust, Haskell, Scala, Gleam, Mojo. Огромное количество языков, откуда можно было бы подчерпнуть идеи по эффективной и удобной обработке ошибок, корректной и удобной работе с изменяемыми и неизменяемыми значениями, удобной и эффективной работе с обобщёнными функциями. Я уж не говорю про EDSL.
Объясните мне, дураку. Вот есть C# с неплохими женериками (женерики поверх структур используют мономорфизацию, а поверх классов - стирание типов), работает хорошо, но как там в недрах - хз. Почему все разработчики, которые вертятся вокруг Go, говорят, что их сделать сложно или нереально и дают в пример джаву, где женерики, откровенно говоря, сделаны плохо?
В твоих фантазиях они "вертятся и говорят". На самом же деле всем похуй.
@@ИванИванов-к1ь7с
1,2,3,4,5 -Ок, значит сейчас нужно.
6. Значит вы не разработчик библиотек и в принципе смирились с тем, что нужно использовать кодоген и копипасту для всего.
>Ну так зачем усложнять компилятор?
Чтобы он этой рутиной сам занимался, и чтобы всякие встроенные в язык функции можно было выразить, как обычный код.
@@ИванИванов-к1ь7с что вы понимаете под промышленной разработкой? Просто в моём понимании Что C#, что C++ подпадают под неё, как и все остальные
@@ИванИванов-к1ь7с Ну так объясните, что значит "промышленная надёжность" и каким образом *язык* может её гарантировать?
@@ИванИванов-к1ь7с нет. Просто я ни разу не сталкивался с такими вещами, которые требуют надёжность такого рода (сдаётся мне, что это где-то около ВПК, авиационной и медицинской техники).
В моём понимании "язык промышленной разработки" - это язык, который активно используется для решения прикладных задач (не для научной работы, не для сбора статистики, и не для выполнения запросов к реляционным базам данных), а значит в моём понимании (и в понимании гугла) под такое понятие подпадает и C++, и Js, и Python и много других языков, которые берут "от бедноты".
Ну и если уж мы спорим, подходит ли тот или иной язык для промышленности - го тут тоже мимоходом, тк не ясно, сколько времени будет длится пауза на сборку мусора и прочее.
Чота и не постарел даже на вид )
Пару лет назад вообще о гоу разве что слышал, соответственно щупал чудовую игрушку, забавная была, но выбирая из двух чудных игрушек поиграться выбрал DLang, куда интереснее.
Год назад бывший коллега предлагал к нему на работу, писать на гоу. Мои увещевания "акстись, я его разве что поиграться пробовал" его не удовлетворили: программировать умеешь, синтаксис знаешь, справишься.
В этом году вдруг на работе сказали, что все разработчики гошечные вымерли, готов взять на поддержку их продукт. Ну поддержка - это делать, баги там какие мы завсегда и на чем угодно можем поправить. Пару вечеров по вспоминал синтаксис, полез в проект. И меня стошнило. Уж простят меня разработчики на Go, но, как бы это помягче сравнить: вот я носитель русского языка, говорю на английском, французском, испанском. И тут мне предлагают побыстренькому изучить греческий и сделать перевод. Вроде буковки все теже, смысл понятен, но мозг просто различает на части от этой смеси латинских, кириллических и собственно греческих буковок, котрые складываются порой просто в чудовищные конструкции. И если само отвращение к языку побороть удалось (никак за плечами C/C++, Java, Perl, Python, JavaScript, само собой разумеющиеся Basic и Pascal, приходилось и PHP, но почти все языки примерно одинаковые и логичные в плане использования скобочек, передачи данных и так далее, то тут в Go какие-то безумные инициализации данных в фигурных скобках, а перед этим указание типа для карты в квадратных, ну да ладно, это все вопрос привычки), то проект просто вызывает боль костей. Ощущение, что все непрлдумано и неструктурировано, типы заводятся на лево и направо (коллега тут доказывал, что это позволяет избежать ошибки в использовании параметров. Серьёзно, то есть 100 раз по коду введён новый тип int, и это позволяет от чего-то защититься? Может надо от разраба, который не понимает, что ему надо в функцию передать, раз приходится защищаться введением нового типа, избавиться?) Интерфейсы - это вообще боль. То есть очень хотелось сделать простой язык функциональный, поэтому отказались от ООП. Окей, изобрели бэйсик. Потом поняли, что не конкуренты. И вкрячили костыль в виде интерфейса. То есть не признали факт, что надо делать ООП, а именно присобачили интерфейс, чтобы самому данному довесить метод работы с ним. И чтобы не путаться типа кинули всю эту кучку какашенций в один файлик, котрый тут же свалили тут в один каталог, что приводит порой просто к дичайшим зацикливаниям импортов.
Да, я понимаю, что каждый хвалит свой насест. Я никогда ни один язык не изучал, не было времени да и не хотел, досконально, потому что язык - это инструмент, как и механику башенного крана мне не надо знать, как там рассчитана ферма крана, мне надо знать базовые параметры, чтобы понимать, что работа будет безопасна, что-то типа массы противовеса при определённой длине стрелы и массе груза. Поэтому и Python, на котором я пишу сейчас для меня открыт, есть что поизучать. Но когда понимаешь, что нужно тратить часы времени, за которое платит работодатель, чтобы послушать вот такие видосы и понять, что язык все равно говно, то это крайне вредная штука. И что многие работодатели готовы платить сотни 2-3 тысяч за разработчика на Гоу, хотя тоже самое можно дешевле (да-да, дешевле, потому что будет быстрее и проще разработка) сделать на Python с использованием C++ в узких местах, для меня загадка. Разговоры про быстроту Гоу на самом деле только разговоры, потому что быстрее, чем сам сервер, работать не будет. У меня, конечно, был разработчик, котрый умудрился втупить 16ядерный сервер с 64 Гб быстрой оперативки, на в целом не самой сложной задаче по обработке большого количества данных, потом все это было переписано и легко работало на 4 ядерном серваке с 16Гб оперативки. Но там и проблема была не в языке и Гоу бы не помог, там проблема была в обработке большого количества данных, которая была сделана неверно, и на Гоу она так же была бы сделана неправильно. В любом языке все равно разработчик упрется в медленный ввод/вывод, нехватку ресурсов или ещё какую "нежданную радость". И что кто-то сумел за 7 минут опросить мульон серверов на Гоу, хотя раньше еле успевал за сутки на Python - это сказки заядлых рыбаков о пойманном каркасе на полтонны и в 10 метров.
В общем язык вызывает какую-то тошнительную реакцию.
@@ИванИванов-к1ь7с экономики чего? Тут важно понять, что вы хотите экономить, человеческие ресурсы или ресурсы машины? Я в 10 раз быстрее решу задачу на Питоне, чем на Golang! И не потому, что я питонист, го я тоже знаю и умею писать на нем, а все потому что, го слишком многословен и плохо продуман. Как думаете, каков процент задач решается на го в Гугл? Минимум!Основа С++/Java, Python
Полностью согласен! Хотели как лучше, а получился Golang.
Что за поток сознания?
ООП в го есть, но оно своё... особенное... Если в других ооп-языках оборачивают всё в класс, задают поля и методы, то в го это сделано структурами... но это не беда. Беда в том, что реализация этих методов может быть где угодно. Даже если методы структуры идут сразу после самой структуры (а я уверен, кто-то может кодить так, что методы будут вообще в какой-то попе), визуально, на глаз воспринимается это крайне не читабельно
@@aquinary.и дженерики в методах не работают (по состоянию на 1.21.4). А вообще, количество велосипедов, которые заставляет писать язык - просто зашкаливает. Печально это всё.
Ни о чём