Go на пальцах

Так о каких проектах все же речь?

побольше, чем хоум пейдж с гостевухой.

[субъективное мнение поскипано]

(Scala, Haskell)

заодно и перед нубами выпендриться можно. Тоже профит, гг

Erlang же. В этом он рвет Go по всем статьям by design.

экзотика всё-таки. Проще обучить человека go, чем erlang'у (кстати, хаскеля и скалы тоже касается).

Да практически любой язык. Тот же C++

спасибо, поржал.

В сети можно найти исследования на тему сравнения c++(tbb) и go

с ассемблером там не сравнивали?

Вот зря бисти удалил очень емкое и в тему сообщение анонима.

а я комент нопейсал :(


--- cut ---

4 [...] Ну вот например import «github.com/vlastelin/analpleasures». Да, только мастер, только хардкор. [...]

тут только четвертый пункт имеет какое-то отношение к реальности, хотя не вижу особых отличий от того же git submodule в проекте на любом ЯП

менеджеры зависимостей для go изобретают, но пока не очень выходит

А теперь плохие новости

открою тебе тайну - это потому что, в реальности людей, способных писать код для «100500 ядер на процессоре» на цепепе - не существует. Вернее они есть, но если гугль будет платить им зарплату, которую они просят - то ему придется брать с тебя деньги за каждый гуглёж

да, в гугле работают идиоты, раз уж додумались возместить недостаток iq у человечества компилятором %)
--- cut ---

спасибо, поржал.

А чего смешного? Тот же intel tbb имеет много всего, а так же поддерживает высокоуровневые абстракции конкурентности и распараллеливания. Не думаю, что go умеет и половину. Это вообще плохая идея, пихать такие вещи в язык.

Ну да:

Ну да, или _ написать или try/except. Вот если бы Го на синтаксическом уровне обязывал что-то делать с ошибкой, тогда бы был смысл, а так впервые соглашусь с Кроном, го — никчемная какашка. Разрабатывая на питоне я хотя бы уверен что получу fastfail.

Проще обучить человека go, чем erlang

Да откуда вы это берете? Go прячет незнакомую семантику за кажущимся знакомым синтаксисом. Erlang просто ничего не прячет, все абсолютно явно, потому выглядит страшновато. Но где семантика сложнее - это очень большой вопрос, Erlang все-таки очень простой язык.

При этом, один раз выучив Erlang, человек получает лучший на рынке в плане fault tolerance и инспектируемости рантайм и понимание определенных best practices(а также страдание, что нигде больше нет binary destructuring). Что из этого дает Go? Ничего.

git submodule в проекте на любом ЯП

Вот только submodule использовать приходится только в очень печальных случаях. Для большинства языков уже есть более вменяемые dependency tracking решения, нежели «pin to master» в go get. Даже убогие submodules - это pin to commit, что уже означает воспроизводимость билда.

Плюсую. Erlang только с первого взгляда пугает, на самом деле он прост как топор и мест где можно получить факап не так уж много.

в реальности людей, способных писать код для «100500 ядер на процессоре» на цепепе - не существует

Чушь. Даже я могу велосипедить хоть под кудой, хоть под openmp, хоть тупо вручную на pthreads с мьютексами. А уж программисту это вообще как два пальца об асфальт!

да, в гугле работают идиоты

Вот это — более правдоподобно.

да, в гугле работают идиоты
Вот это — более правдоподобно.

плюсую, они там жопы надрывают, а мы сидим с эдии на расслабухе, пользуемся на халяву и ничо им не платим, хаха лахи

Чушь. Даже я могу велосипедить хоть под кудой, хоть под openmp, хоть тупо вручную на pthreads с мьютексами.

Ага, а потом твой велосипед внезапно из 100500 ядер нагружает максимум 2. Писать многопоточный код уметь надо, то что у тебя хватает мозгов создать 100500 потоков и несколько мьютексов не значит что вся эта параша будет отлично масштабироваться.

Дисквалификация по Тьюрингу

TL;DR Я думаю что премию Тьюринга мало того что была зря выдана Томпосону и Ричи, эту премию еще у них нужно забрать.

Как можно выдавать премию Тьюринга каким-то хакерам, которые не представили ни одного формального алгоритма, не сделали никакого открытия в области программирования. Даже Гринблат и Госпер достойны этой премиии в большей степени чем Томпсон и Ричи. Для тех кто не знает, все что они сделали это написали С и UNIX. Если первый результат хакинга еще хоть как можен пригодится, то последниее 40 лет человечество пытается избавится от второго, как от вируса, который сжирает деньги и энергию датацентров. Премию имени Алана Тьюринга нужно давать математикам, которые верифицируют алгоритмы и создают верифицируемые инструменты и двигают науку вперед, таким как Лесли Лампорт, Робин Милнер, Тони Хоар, МакКарти, Барбара Лисков, Ричард Хемминг, Дейкстра, Кнут. Просто хакеры, которые слепили очередную OS, Inferno, Go не достойны этой премии. Если бы они доказали что их ОС работает, тогда да. Очевидно что их вклад бы переоценен в 1983 году. Теперь мы знаем, что это была ошибка. Не совершайте эту ошибку во второй раз доверяясь этим же людям и скачивая последний релиз Go. Что сделали Томпосон и Ричи? Создали огромную платформу для легаси кода, от которой все пытаются избавится изобретая docker и rump kernels. Они больше нашкодничали, чем сделали хорошего.

http://maxim.livejournal.com/454598.html

от которой все пытаются избавится изобретая docker

изобретая докер который написан на go

рекурсия прямо таки

Да, вот уроды, столько всего полезного понаписали, даже математикам ничего не оставили. Бедные до сих пор факториалы и числа Фибоначчи рассчитывают.

а так впервые соглашусь с Кроном, го — никчемная какашка

Я такого не говорил :) Я писал, что «Приятный язык ... лично для меня серьёзный минус — отсутствие исключений».

Мне Go очень нравится и как язык, и как платформа. Просто в бочке мёда есть черпак дёгтя.

Go прячет незнакомую семантику за кажущимся знакомым синтаксисом

вот это и есть киллер-фича

Erlang просто ничего не прячет, все абсолютно явно, потому выглядит страшновато.

и стоит дороже

При этом, один раз выучив Erlang,человек получает лучший на рынке в плане fault tolerance и инспектируемости рантайм

и хорошую зарплату. Ага. Работодатель смотрит на него и думает - «а нахрена мне один умник с ерлангом, когда я могу нанять пять жаба-погромистов и потратить пару недель на их обучение голангу?»

интересно, что он выберет?

Что из этого дает Go? Ничего.

а go делался не для того, чтобы выучивший его мог в cv писать кучу баззвордов про best practices, функциональщину, монады и прочую академическую хрень. А чтобы быстро и дешёво решать конкретные задачи. Ну вот почему-то выходит, что на правильных языках правильные программисты решают эти задачи сильно дороже. Или дольше, что в итоге все равно == дороже.

Вот только submodule использовать приходится только в очень печальных случаях.

при наличии gopkg.in - использование неверсионированных импортов в принципе так же можно отнести к очень печальным случаям.

А чего смешного?

tbb не решает главную проблему - не отбирает у обезьянок недоязык, созданный для прострела ног всеми возможными способами, зато дает этим обезьянкам несколько новых способов снести себе квазидумательный орган.

Не думаю, что go умеет и половину.

go умеет ровно то, для чего делался. А костыли, с которыми приходится превращать функции в классы, чтобы библиотека смогла их как-то распараллелить - делались ровно для того же, что и любые другие костыли - чтобы подпереть уже существующие.

не поверил на слово. do, try, catch, guard, throw - всё есть

А теперь почитай, что они делают. Это тупо сахар вокруг возврата ошибки. Причём в сигнатуре не видны конкретные типы «исключений», но обработать надо все.

Ну и как небольшой бонус - это всё появилось не сразу.

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

Ну да, смысл примерно такой же как сравнивать костёр с ядерным реактором.

автоматом вставить default: panic(r), если type switch по результату recover() - т.е. починить уже сломанный код

Постой. Кто будет «автоматом вставлять»?

Потому как паника и исключения - всё-таки разные вещи

И в чём они отличаются?

Ну и серьёзно - немного выше ты рассказывал, что в Го не надо городить мусорный код, а можно использовать панику, если хочется исключений. А теперь снова виляешь и это уже не исключения.

Это тупо сахар вокруг возврата ошибки.

и? Крякает как утка?

Причём в сигнатуре не видны конкретные типы «исключений», но обработать надо все.

не понял - языки, где в сигнатуре вообще исключения не указываются - выкидываем из списка языков с исключениями?

Ну и как небольшой бонус - это всё появилось не сразу.

а в каких языках появилось сразу?

Постой. Кто будет «автоматом вставлять»?

go fix, например

И в чём они отличаются?

как минимум скопом. В go паникует функция целиком, а не какой-то блок внутри.

а можно использовать панику, если хочется исключений.

не перевирай. можно использовать панику с целью «бросить все и сбежать», а не если хочется исключений. Если хочется исключений в цепепе-стиле try{ } catch{ } - то ничего не поделаешь.

быстро и дешёво решать конкретные задачи.

Эээ. Я не хочу тебя расстраивать, но если go-программер получает в два раза меньше erlang-программера, а на решение проблемы «сервер под нагрузкой зохавал всю память и упал» затратит в три раза больше времени - это выйдет дороже. Исходя из моего личного опыта и наблюдений за людьми вокруг, такая ситуация вполне вероятна.

выучивший его мог в cv писать кучу баззвордов про best practices, функциональщину, монады и прочую академическую хрень.

Во-первых, «best practices» и «академическая хрень» - это антонимы. И best practices в моем мире не пишут в CV, их применяют в работе.

Во-вторых, Erlang, в отличие от Scala и Haskell, придуман как раз для того, чтобы решать реальные проблемы. Кстати, мне кажется, ты меня неправильно понял - я не сторонник академических языков в продакшне, я их чисто как примеры достаточно мощной системы типов приводил. Сам я вебню пишу только на динамических языках.

Ты тут раньше по треду писал

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

Ты вообще в курсе, что именно этот класс ошибок Erlang срезает почти под корень? Про упомянутые тобой же NPE и вообще речи не идет.

Мне просто этот «новомодный» подход не кажется удобным, только и всего.

А разрабам языка меньше головной боли (%

Это теперь так модно

Erlang - тормоз.

import «github.com/vlastelin/analpleasures». Да, только мастер, только хардкор

если такое юзается значит для данного проекта такое не страшно

если для проекта это страшно то всё равно такое можно юзать, как:

если боитесь апдейтов — форкнуть библиотеку и подключить потому что так банально очень удобно

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

Erlang же. В этом он рвет Go по всем статьям by design.

За исключением одной, лол: линейных вычислений которые требовательны к производительности

erlang — это штука для создания эфективногог comet, остальное не для него

а на решение проблемы «сервер под нагрузкой зохавал всю память и упал» затратит в три раза больше времени - это выйдет дороже.

берем цифры из головы и получается клевый аргумент! Ну и в реальном мире эрлангер не только стоит в два раза дороже, но и затратит в три раза больше времени на парсинг трейса ерланга, бгг. Видишь, я тоже так умею

Во-первых, «best practices» и «академическая хрень» - это антонимы.

пропаганда эрланга/хаскеля/прочей функциональщины - это реклама академической хрени в качестве best practices.

И best practices в моем мире не пишут в CV, их применяют в работе

... что потом описывается в cv. Не? %)

придуман как раз для того, чтобы решать реальные проблемы

вот это новость, я-то думал шо ЯП придумывают из-за того, что в жопе свербит. А оно вот как

Ты вообще в курсе, что именно этот класс ошибок Erlang срезает почти под корень?

я-то в курсе. И что ты предлагаешь? Поменять вселенную на другую, где поколения погроммистов в глаза не видели императивщины, и всё ПО в мире является академической хренью?

а потом твой велосипед внезапно из 100500 ядер нагружает максимум 2

Только если вместо операционной системы используется игровая прошивка...

не значит что вся эта параша будет отлично масштабироваться

В куде я определяю параметры видеокарты и создаю наиболее оптимальное количество потоков, сообразно с этим. Аналогично при работе с мультипроцессорами: выставляю количество потоков в среднем равным количеству ядер.

не представили ни одного формального алгоритма

Thompson's construction algorithm.

По-моему, это такой PHP нашего времени - очередная большая ошибка.

+1 Такие же мысли, с поправками на то, что Go это PHP в мире статических ЯП.

В куде я определяю параметры видеокарты и создаю наиболее оптимальное количество потоков, сообразно с этим.

CUDA это вообще специфичная технология, и далеко не для всего подходит.

Аналогично при работе с мультипроцессорами: выставляю количество потоков в среднем равным количеству ядер.

И как это поможет NCPU потокам при доступе к разделяемому ресурсу? Если ты спроектировал многопоточную программу так, что в один момент времени в ней работает только один поток, то у меня для тебя плохие новости - твоя программа не многопоточная.

По-моему, это такой PHP нашего времени - очередная большая ошибка.

да ну, у меня блог на пхп, никаких ошибок вообще. помню года два назад был пик нагрузки, 8 человек одновременно, вообще все гладко прошло

и? Крякает как утка?

Нет. Ключевое отличие исключений - возможность неявно пролетать сколько угодно уровней. В свифте если функция кидает исключение, то все вызывающие её функции должны быть отмечены как throw, если они его не обрабатывают.

не понял - языки, где в сигнатуре вообще исключения не указываются - выкидываем из списка языков с исключениями?

Наоборот, «обычные» исключения как раз в сигнатурах не появляются. Да, есть checked exceptions в джaве, например, но их признали неудобными.

а в каких языках появилось сразу?

В C#, например. Подозреваю, что в джаве тоже. Но я не хотел сказать, что свифт убог из-за того, что исключения появились не сразу. Просто у них в инфраструктуре есть определённый подход к обработке ошибок. Раньше на свифте приходилось всё руками писать, сейчас появился новый сахар для упрощения, но к исключениям он отношения не имеет.

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

go fix, например

Ну то есть не автоматом. Я не знаю какая ситуация с Го, но когда у нас есть дофига кода на языке, то лучше делать как можно меньше ломающих изменений, пусть и требующих тривиального фикса. Собственно, с С++ именно такая ситуация - новые фичи добавлять хочется, но легаси по прежнему с нами. Вот и изворачиваются как бы ничего не поломать, в результате местами синтаксис хуже, чем мог бы быть.

В go паникует функция целиком, а не какой-то блок внутри.

То есть вот так написать нельзя или о чём речь?

void f() {
    ... // какой-то код
    try {
        ...
    }
    catch(...) {}
    ... // какой-то код
}

Если хочется исключений в цепепе-стиле try{ } catch{ } - то ничего не поделаешь.

А в чём разница? Если я правильно понял, то просто писать придётся немного иначе. Вон тот пример кода выше - просто вынесем код из try в отдельную функцию. catch тоже есть, только слегка иначе выглядит.

А разрабам языка меньше головной боли (%

Да в том и дело, что я не вижу уменьшения головной боли. И в го и в расте паника вызывает раскрутку стека, и там и там она может быть поймана и содержать конкретный тип. В расте достаточно добавить один макрос и исключения готовы. То есть я всё-таки вижу тут борьбу за мифические «упрощение», «наглядность» и т.д. Ну и навязывание стиля.

для создания эфективногог comet

Для создания эффективных, отказоустойчивых и поддерживаемых сетевых сервисов, так правильнее. С этим никто не спорит.

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

Нет. Ключевое отличие исключений - возможность неявно пролетать сколько угодно уровней. В свифте если функция кидает исключение, то все вызывающие её функции должны быть отмечены как throw, если они его не обрабатывают.

т.е. «настоящесть» исключений определяется синтаксисом?

Да, есть checked exceptions в джaве, например, но их признали неудобными.

кто признал? Меня наоборот бесили внезапные unchecked NumberFormatException из дебрей чужого кода.

Ну то есть не автоматом

мне почему-то кажется, что утилита, самостоятельно переписывающая old-style места в сырцах на new-style - это и есть «автоматом»

То есть вот так написать нельзя или о чём речь?

нельзя (по крайней мере без выделения блоков в функции, хоть бы и анонимные)

А в чём разница?

с паниками придется более лучше разбивать код на функции.

парсинг трейса ерланга

М. Давай тогда к конкретике. Есть продакшн сервер, потоково раздает что-то клиентам. Два кейса - «после двух гигабит все начинает тормозить» и «после двух гигабит сервер начинает истекать памятью».

Как ты будешь решать эти проблемы в Go?

Erlang
в глаза не видели императивщины
всё ПО в мире является академической хренью

Ты упоролся? Ты вообще в курсе, что Erlang абсолютно императивный? И даже можно сказать, объектно-ориентированный в оригинальном смысле этого слова?

А вообще, я начинаю что-то нехорошее подозревать. Ты вообще на каких языках писал в продакшн? А на каких еще не писал, но хочешь?

По-моему, это такой PHP нашего времени - очередная большая ошибка.

Го намного проще, и я бы даже сказал, примитивнее, PHP. Я понимаю, что это сделано с целью, я видел статью, где утверждалось, что Go сделан таким простым, чтобы в большом проекте, после того, как по коду пройдутся 5 разных программистов разной квалификации, код не превратился в полную какашку, глючную и нечитаемую. Короче Go это не замена PHP, это новый виток, так сказать.

т.е. «настоящесть» исключений определяется синтаксисом?

Скажи честно - ты придираешься или правда мысль не понимаешь? И не видишь разницы между «нормальными (обычными) исключениями» и возвратом значения. Последнее может во что угодно быть завёрнуто - растовый result, гошный возврат нескольких значений, свифтовый сахар, монады и т.д.

кто признал?

Да кругом пишут «Prefer runtime to checked exceptions», «Checked exceptions: Java’s biggest mistake» и т.д.

Меня наоборот бесили внезапные unchecked NumberFormatException из дебрей чужого кода.

Интересно, что бы ты сказал, если бы в каждом методе пришлось этот самый NumberFormatException и кучи подобных руками прописывать из-за того, что они где-то в дебрях использованы.

с паниками придется более лучше разбивать код на функции.

Мне это не кажется принципиальной разницей.

Как ты будешь решать эти проблемы в Go?

интересно, почему ты думаешь, что если такие проблемы возникают в ерланге - они обязательно возникнут в go. Из этих двух только один язык постоянно данные копирует.

Ты упоролся? Ты вообще в курсе, что Erlang абсолютно императивный?

шта? функциональщину вообще-то относят к декларативной парадигме

Ты вообще в курсе, что Erlang абсолютно императивный?

дай-ка время - хочу придумать зачем нужен erlang, если не писать в функциональном стиле. .... ммм... не придумал.

Ты вообще на каких языках писал в продакшн?

я в общем-то писал уже в то время, когда слово «продакшн» никто не знал, гг.

Имелось ввиду, что это очередной откровенно убогий язык, который продвигается за счет низкого порога вхождения в еще пока не занятую нишу, и выкинуть его оттуда в пользу чего-то нормального будет очень затруднительно. На PHP реально кто-то пишет до сих пор, вместо того, чтобы его выбросить и забыть.

Я не буду отрицать, в нем есть неплохие стороны - неплохой перфоманс, gofmt, неплохая стандартная библиотека, статические бинарники. CSP, в конце концов, не так уж плохи. Но общая убогость помноженная на нездоровый хайп меня от него отвращают.

Скажи честно - ты придираешься или правда мысль не понимаешь? И не видишь разницы между «нормальными (обычными) исключениями» и возвратом значения.

причем тут возврат значения? throw в сигнатуре - это возврат значения? Нет же - под капотом оно может быть как угодно реализовано (да хоть и через longjmp)

Да кругом пишут

отличный аргумент

Интересно, что бы ты сказал, если бы в каждом методе пришлось этот самый NumberFormatException и кучи подобных руками прописывать из-за того, что они где-то в дебрях использованы.

я бы сказал «большое спасибо»

ну просто потому что информация «вот на этом вот безобидном вызове с няшной сигнатуре твое поделие может грохнуться» - очень полезна

Мне это не кажется принципиальной разницей.

но оно заставляет писать код по-другому

Правда, лично для меня есть серьёзный минус — отсутствие исключений. Возврат кода ошибки — это совсем не то.

В go есть исключения: см. panic/defer.

throw в сигнатуре - это возврат значения?

В свифте - да. Ну и почему ты остальное проигнорировал? Ок, попробую ещё раз: с исключениями, если у нас какая-то функция в глубине стека вызов начинает что-то бросать нам не надо модифицировать ВСЕ промежуточные функции. С возвратом значения (в любой форме) - надо.

Даже специально уточню - речь про unchecked исключения в понимании большинства языков. В свифте их нет.

Ну или посмотри на растовый Result. Если бы в нём Err назвали Exception, то исключения в языке от этого не появились бы. Просто произошла бы подмена терминологии.

отличный аргумент

Ну вообще-то да. Если в разных обучающих книгах и прочих «best practices» такое пишут, то что-то оно да значит.

я бы сказал «большое спасибо»

Вряд ли. Так как у большинства функций сигнатуры на экран не влазили бы.

В go есть исключения

panic/defer — ни разу не исключение. Это такое извращение, что для обработки ошибок проще уже коды возврата использовать :)

panic/defer — ни разу не исключение. Это такое извращение, что для обработки ошибок проще уже коды возврата использовать :)

Почему? panic == throw. defer == catch. Стектрейсы можно захватывать. Синтаксис catch немного непривычный, но это ничего не меняет.

Почему?

1. «Закат Солнца вручную». Фактически приходится создавать на каждом вызове кашу проверок и прочего, что в других языках реализуется синтаксисом. Слишком многословно.

2. «Обработка исключения» (хотя, повторюсь, panic/defer — это не обработка исключения!) размазывается по коду вызова, затрудняется анализ кода.

3. В языке рекомендуется обработка ошибок через коды возврата, из-за чего при использовании panic/defer порождается каша. Часть ошибок обрабатывается кодами возврата, часть — через громоздкую реализацию вокруг panic/defer.

defer == catch

Нет. defer вызывается всегда и поэтому требует анализа контекста. Это порождает громоздкие синтаксические конструкции.

Для создания эффективных, отказоустойчивых и поддерживаемых сетевых сервисов, так правильнее. С этим никто не спорит.

Вобщем-то Go тоже для этого, вопрос в одном: нужен рилтайм или нет. если не нужен, лучше избегать ерланга

1. «Закат Солнца вручную». Фактически приходится создавать на каждом вызове кашу проверок и прочего, что в других языках реализуется синтаксисом. Слишком многословно.

Ты что-то путаешь. defer надо делать на самом верхнем уровне, где у тебя обрабатываются все ошибки.

3. В языке рекомендуется обработка ошибок через коды возврата, из-за чего при использовании panic/defer порождается каша. Часть ошибок обрабатывается кодами возврата, часть — через громоздкую реализацию вокруг panic/defer.

Это проблема стандартной библиотеки, её придётся переписать или обернуть своими обёртками, идиоматичных гоферов побить тапками. Тут согласен.

Нет. defer вызывается всегда и поэтому требует анализа контекста. Это порождает громоздкие синтаксические конструкции.

try-catch используется достаточно редко, чтобы это вызывало какие-либо проблемы.

Не знаю, с чего вдруг тебе конструкция panic/defer показалась неюзабельной. тебе нужен функционал ловить исключение с любой «глубины» на любом уровне выше исключения, так он именно через «панику» и организуется. лично я библиотеки специально пишу с генерацией паники, чтобы приложение, которое будет пользоваться само решало, как отрабатывать панику.

PS: может ты что-то иное имеешь ввиду?

PPS: а в целом, го доставил. о нем слышал несколько лет назад, но особо значения не придавал. в конце прошлого года он меня зацепил и я таки подсел на него.

тебе нужен функционал ловить исключение с любой «глубины» на любом уровне выше исключения, так он именно через «панику» и организуется

Это ничем не противоречит приведённым выше моим претензиям к panic/defer :)