Go - плохо задезайненный язык в котором нет практически ничего (какие там дженерики, они даже в перегрузку функций не смогли). Ввиду специфики языка и очень большого авторитета одной известной компании, язык собирает вокруг себя достаточно маргинальное сообщество, которое многим доставляет лулзов (в том числе и в /pr, за счет чего уже выходит #8 тред). https://www.reddit.com/r/gobashing/ https://www.reddit.com/r/programmingcirclejerk/
Что касается языка как инструмента. Политика языка построенная на том, что "им" лучше знать что тебе нужно и если после этого ты еще захочешь вкатится в этот язык, знай - единственно достойная там плюшка это горутины и все (хотя некоторые аноны ставят под сомнения их божественную важность, но тут стоит отметить, что технология корутин на самом деле интересная штука, но насколько она востребована "в таком" языке - непонятно). И знай, несмотря на свою компилируемою природу - го такой же медленный как джава с ее виртмашиной: https://www.reddit.com/r/golang/comments/62tmcg/why_is_this_go_solution_faster_than_the/dfpc7ca/ (хотя это лулз, но в этом что-то есть - го дает такой же перформанс как не прогретая джава, но при этом сравните что дает вам жаба и го).
Го - прост как палка и удобно на нем писать Чем больше в языке конструкций - тем разнообразнее и сложнее становится код (пример С++). Чем меньше в языке конструкций - тем больше вам писать бойлерплейта (ассемблер в пример). Как всегда побеждает золотая середина и гордиться тем, что язык уходит в сторону простоты, это как гордится ребенком дауном. Если серьезно, анон уже замечал как муторно писать код на го из-за того самого бойлерплейта (и я тоже это потверждаю), насколько удобно на нем писать большой проект - неизвестно.
Го - самый модульный язык Ага. Особенно когда в отсутствие обобщенного программирования (дженериков) приходится копипастить логику.
Го - быстрее питона Верно! То что такие трендовые компилируемые языки как свифт или го побеждают интерпретируемые языки (причем не всегда) - это просто кладезь лулзов.
Го умеет в ООП? Несмотря на то, что ранее евангелисты возносили, мол в го есть ООП, но специфичное, сейчас суслики активно топят за то, что язык чисто процедурный (вероятно методичка поменялась). Причем суслики упарываются настолько, что готовы рассказывать о том, что полиморфизм - это плохой дизайн (ввиду ограниченного мышления и трех святых слов ООП, суслики решили, что полиморфизм чисто ООП фича). На самом деле, разработчики принудительно-безболезненно заставляют по средствам ошибок циклического импорта использовать интерфейсы (о чем говорилось в их группе). Так есть ли ООП? Да не важно, важно что гоферами все равно придется использовать интерфейсы, а значит активно маневрировать между структурами и джава-объектами с геттрами и сеттерами (такой полу-ООП поневоле).
Стоит ли изучать язык? Несомненно стоит, потому что "завтра" этот язык заменит твой основной язык на работе (это неизбежно анон, начни любить его прямо сейчас)
>>967814 >Да и обычно пыхеры, насколько я спрашивал у знакомых, перекатываются как раз на Го То что делают пыхеры давно надо маркировать как порнографию. На самом деле, пхп настолько скопировал джаву и там настолько сильное ООП-головного мозга, что реально пахеры перекатываются на жабу (если задача требует перформанса или потоков, а так никто с динам языков никуда не перекатывает, скорость разработки важнее дроча на язык)
Го хороший язык для людей, которым по душе олдскульный дизайн языка и они делают маленькие проектики(либо очень специфичные). Я вот всякие мелкие парсеры пишу, всем доволен
Ну а для всего остального есть Node.JS, Java, Python, PHP. Давайте не будет тут морды друг другу грызть, ок?
>>967858 Поносить го нужно, чтобы создать противовес маркетинговому буллшиту, которое разносит го-коммюнити. Неокрепшим умам легко нассать в уши. Взять к примеру их йоба-гц, который на деле не предсталяет из себя ничего нового. Улучшили одни характеристики за счёт ухудшения других и рассказывают про первые, умалчивая про вторые. Если руководству вдруг придёт в голову принести го в проект, то донесу все минусы из https://github.com/ksimka/go-is-not-good. Не поможет - впизду такое руководство. Перейти с питона на го это как вернуться в каменный век.
Сап, /go/внач. Есть вопрос. Как в говне обойтись без копипасты секции проверок ошибки если производишь подряд несколько операций над файлами? Есть ли сахар для таких вещей?
Выражаю восхищение той одержимости с которой шизофреник "создает противовес маркетингу". Увы, для критики ему не хватает ума. Пустая растрата такой обсессии.
>>967878 >Поносить го нужно, чтобы создать противовес маркетинговому буллшиту, которое разносит го-коммюнити. Неокрепшим умам легко нассать в уши. Должен заметить. Что твой "противовес", мой слабоумный друг, выглядит как бредни сумасшедшего батхерящего хейтера. И неокрепшие умы, в общем и целом, не настолько безмозглые идиоты, чтобы серьезно воспринимать нечто подобное. Твои усилия, скорее всего, имеют в половине случаев противоположный эффект. Впрочем, частично они работают, но не в виде критики, просто людям неприятно интересоваться чем-то, вокруг чего, какой-то урод, разводит столько говна.
С другой стороны, /pr/ харкача, очень популярный ресурс, и представляет индустрию в целом, другими словами, ты работаешь вхолостую, никто этого не читает. Создай лучше бложик, или статью на хабре.
>Перейти с питона на го это Сеньер питонист.жпг
>Если руководству вдруг придёт в голову принести го в проект, то донесу все минусы из https://github.com/ksimka/go-is-not-good. Не поможет - впизду такое руководство. Вот честно, уволить уже за то, что ты на харкачах подобное пишешь. Хотя, я все таки сомневаюсь, что у тебя есть работа. Молодой еще слишком.
>>968116 >так хуесосят язык а в результате сами обсираются >все гоферы поджав хвосты давно разбежались хуй соси, я никуда сваливать отсюда не собираюсь довольно потешно смотреть на вскукареки джавадаунов, которые кроме ооп ничего не могут осилить
>>968119 >>Если руководству вдруг придёт в голову принести го в проект, то донесу все минусы из https://github.com/ksimka/go-is-not-good. Не поможет - впизду такое руководство. >Вот честно, уволить уже за то, что ты на харкачах подобное пишешь. Какой хороший лизоблюд.
Кстати, у ПХП похожая ситуация была: абсолютно все кругом срали язык, поделия пхп-кодеров говорили сами за себя и в итоге до сих пор считается зашкваром писать на пхп и начинать на нём серьёзные проекты. Так что всё правильно: для молодых неопытных надо засирать, чтобы даже не пытались, а кодеры посерьёзнее и сами понимают, что к чему с этим языком.
> 3-reasons-why-go-isnt-the-perfect-language-yet Чет лол, да все языки не идеальны и пилятся под задачу это только с++ сделали монстром > no unused imports и слава Аллаху нехуй тащить по 100500 библиотек для каждой хуйни > un-googlable name Я догадывался, что хейтят go в основном индусы, работающие методом stackoverflow based programming > no function overloading Нахуй оно нужно, если нет ооп? >>968143 >поделия пхп-кодеров говорили сами за себя и в итоге до сих пор считается зашкваро До 5.4 php был говном, позволявшим творить всякую хуйню. Это сейчас появился композер, классы, трейты и прочее, что притащили за собой любители обмазываться ООП.
>>968144 Это проекты стартовали в то время, когда пхп доминировал на беке. Переписывать сейчас не будут, ибо "всё работает, код отлажен за годы разработки".
>>968148 >Серьезные проекты в том же фейзбуке пишутся на окамле Я читал блог их разраба, что все чатики и реалтайм обработка сообщений на эрланге, оно снова мигрировало?
Но оно как раз и нужно, потому что нет ооп. Ну и помимо того нужны дженерики, тип-суммы, вменяемые средства для параллельного программирования и нормальная обработка ошибок.
>>968134 >Какой хороший лизоблюд. Лол. Просто такие работники вредны для коллектива и работы. Способны разрушить все что угодно. и при увольнении оставить баг в коде, или иным образом насрать.
С другой стороны, я понимаю, что большинство низкоквалифицированных кадров такие-же. Собственно, квалификация неотделима от личности. Даже если человек обладает некими полезными скиллами, они, в случае если он - дерьмо, не могут быть реализованы в коллективе на пользу тех кто еще жив. С другой стороны, даже если человек не является суперклассным специалистом, но имеет хорошую личность, и находится в здоровом коллективе, то таковым специалистом он скоро станет. Ну и в целом, коллективный разум играет ключевую роль, важно создавать условия для работы, то есть, для здорового коллектива. В этом со мной солидарен Ричард Брэнсон например. ЛУчше иметь дыру в коллективе, чем заполнить ее каким-то мудаком. С мудаками невозможно получить торт.
>>968143 Пхп хоть исправлялся, серьезно, он сейчас не такое говнише. Что касается критики API то только ленивый поверх стандартной либы не написал свою няшную обертку. Проблема Го - что говнище тебе впаривают как есть, зачесывая о серебряном инструменте и осознанно не развивают, так как лучше тебя знают что тебе макаке лучше (только постоянно натягивают ГЦ за цену твоего железа)
>>968163 >Пхп хоть исправлялся, серьезно, он сейчас не такое говнише. Да, соглашусь, с семёркой, вроде как, получше всё стало. И критика, надо сказать, поутихла за последний год.
Спешите видеть, какой глубокий психологический анализ. Мань, у меня с такими разговор короткий. Идите нахуй. Не о чём спорить с тем, кто пишет if err != nil каждые пять строки и копипастит шаблонные алгоритмы.
Он не исправится никогда. Рантайм -- терминальный пиздец, потому все пишут свой. Фактически все пишшут свой рантайм и свои либы, то есть пых используют дешевой рабочей силы ради.
Го говно, да, но как быстрый и компилируеый пхп сойдет. Собсна, оно и метит на замену пхп (язык для простых вещей, генерирующий дешевую рабочую силу). Пайк же сам сказал, что го для тупых.
>>968147 Школьные понимания индустрии. Как раз таки и переписывают узкие участки. В том и фишка, что могут переписать все, но никто вменяемый не будет писать морды на статическом языке.
Ты и рядом не напишешь такие проекты на Го (на джаве то нудятина, а на го это пиздец).
>>968182 В таком языке как пхп ты можешь получить данные и сразу их пробросить во вьюху. В общем минимум свистопляски по переводу данных из одного состояния в другое.
Я вообще не понимаю этот пиздец типа: model.set("user", user); model.set("product", product);
Постоянное маппирование данных из одной хуйни в другое. Ладно когда у тебя сущностей штуки три, но блять когда их 15.
Другая проблема если какой-то хуй напишет в другом контроллере типа: model.set("client", user);
и все, пукан дизайнера порван в клочья.
Мой месседж в том, что с со статик языками в малом проекте, большая часть уходит на ручной маппинг (преобразование) данных. А вот в крупном проекте с со сложной бизнес логикой без типов уже никуда.
>>968184 >То есть люди роботы? Это по твоему хорошо? Люди не роботы. Вещи, о которых я говорю, лежат немножко параллельно постмодернистской концепции человека-машины.
Речь идет об управлении сложными социальными системами и индивидуальном позиционировании в контексте идеологии.
К сожалению, люди-идоты на постсоветском пространстве, идеологии лишены напрочь. Приодетые дикие аборигены. На лицо ужасные, добрые внутри.
>>968181 >Ещё и политоту развёл Показательно пренебрежение совков к любому "гуманитарному" знанию, философии, политике. Абсолютные прагматики - вот еда на столе это да, понятно, жратва и бухло, еще бабло. Понятно же что управляет миром, жратва и деньги. Точно не политика. А страны сами собой, как плесень, появляются, знание и организация никакой роли не играют.
>свинорылый Мимо. И политоту разводишь тут именно ты, убогий дегенерат с мозжечковой дисфункцией.
>>968190 >Раз уж переходишь на национальности Эм, нет, о национальностях речи не веду. И нет, не "перехожу". Очень жаль, но неудивительно, что понимается написанное в качестве оскорбления.
>Даже глазом не моргнув свалю и ничего мне это стоить не будет. Сваливай уже поскорее, хвантазер.
>>968198 >В таком языке как пхп ты можешь получить данные и сразу их пробросить во вьюху.
>Постоянное маппирование данных из одной хуйни в другое. Ладно когда у тебя сущностей штуки три, но блять когда их 15.
У тебя своеобразное представление о статической типизации и архитектуре приложений, однако.
Но в одном ты прав, если пишешь гостевую страничку для локалхоста с логикой уровня "достать запись из бд, вставить в шаблон и вернуть на запрос", то от статической типизации будет мало профита, да.
>Update 2: If you’re coming to this blog post from a compendium titled “Go is not good,” I want to make it clear that I am ashamed to be on such a list. Go is absolutely the least worst programming language I’ve ever used. At the time I wrote this, I wanted to curb a trend I was seeing, namely, overuse of one of the more warty parts of Go. I still think channels could be much better, but overall, Go is wonderful.
>>968208 >Но в одном ты прав...то от статической типизации будет мало профита, да. Пиздец, я же сказал для веб-морды. Понятно что в динамический языках упарываться в большой проект это больновато, и да, динамический скрипт может дергать микросервис и напрямую кидать json как пхп-массив в общем массив)
>>968210 Этот список был ответом гоферов на хайп-хейтеров. Они думали что если собрать всю критику и показать как хейтеры критикуют одинаковые момент - то эта критика перестанет иметь вес.
По сути они начали собирать статистику проблем языка, на которую стоило бы обратить внимание, но маркетологи заставили восторгаться этим списком, мол "смотрите эти глупые хейтят одно и тоже, ну тупые".
Если собрать стадо годебилов - ими можно манипулировать до такого абсурда.
>>968227 >Этот список был ответом гоферов на хайп-хейтеров. >Они думали что если собрать всю критику и показать как хейтеры критикуют одинаковые момент - то эта критика перестанет иметь вес.
Не очень понимаю о чем ты, ибо я указываю на то, что критика не больно то и критика.
Из другой статьи из списка: >It was a good experience, Go is generally very nice, and we are all comfortable that this was the correct decision for many reasons. I'd recommend that anyone curious about Golang to give it a try
> но маркетологи заставили восторгаться этим списком Откуда инфа?
>По сути они начали собирать статистику проблем языка, на которую стоило бы обратить внимание А кто они такие вообще?
>Если собрать стадо годебилов - ими можно манипулировать до такого абсурда. Я хз что происходит вообще, ибо хейтерин в готреде больше выглядит как антифорс хейтерства. Но вс еэто настолько тупо и грязно, что я в недоумении вобще. Какие-то кривляющиеся клоуны, и школьные обзывашки, по типу ГОдебилы ГОвно итд.
>>968243 >Я тебе кинул хистори этого броса Кинь еще раз.
>Хронология событий 2015 года Где ее посмотреть?
>Комьюнитти, конкретно у нас активно форсил divan (он же Ваня, лучший друг Илюши) Как это комьюнити найти?
>Специально для тебя и пояснил, хотели сделать фарс, а собрали реальную статистику проблем языка. А, ну просто, на реальную статистику как-то не тянет совсем. Все таки на 80% фарс.
>>968286 >Все таки на 80% фарс. Ты все правильно понял. По сути, список высмеивает хейтеров -авторов статей. Потому что, большинство проблем, которые там указаны это или отсутствие фичи другого языка или не так как у других( нет ооп, ошибки по-другому обрабатываются), или вообще идиотия типа "плохое название", "маскот не нравится".
>>968286 >Как это комьюнити найти? Слишком толсто пошло, опять таблетку не принял?
>>968286 >фарс Ну никто не мешает подкрутить под себя, но первые версии состояли именно из всех хейтерских статей (и автором был, по-моему, изначально диван)
Я бы тебе пруфанул бы даже статьей с графиками, но ты шизофренойдный гандон, который обосрался еще в том треде, поэтому заслуженно пососи тунца.
>>968286 >>968349 >>968438 >>968447 Зарепортил хейтеров. Если модератор не отреагирует - напишу Абу, пусть объясняет почему оплаченная реклама не отрабатывается.
1. Что пишите на Го (не обязательно точно, но чтобы было понятно)? 2. Как долго пишите на Го? 3. Какой язык он вам заменяет. Или с каким языком его противопоставляете? 4. Что раздражает в го? 5. Что нравится в го? 6. Юзаете ли вы каналы или по старинке мьютексы (или что чаще)?
>>968555 1. Разные парсилки, чекеры, бруты, автопостеры-автопубликаторы и пр.
2. ~год с хером.
3. Любой другой язык. Думаю, все, что я на нем пишу, так или иначе можно написать на любом другом языке общего назначения.
4. Убогий дизайн языка, полное отсутствие всякого сахара (лямбды, перечисления...), отсутствие дженериков и коллекций. Я бы хотел GO частично с синтаксисом Java, но без всей тяжелой ООП и JVM. Невозможность управлять жизненным циклом горутин, невозможность проверить канал на закрытость, отсутствие чего-то вроде Option (и, соответственно, присутствие nil). Вообще полная стагнация языка, за все это время не было никаких заметных изменений в синтаксис, никаких новых облегчающих жизнь кейвордов, никаких фичей. Постоянные проверки if err == nil, с этим надо что-то делать.
Я конечно простой ремесленник и не претендую на роль дизайнера языка, но имхо что-то можно из этого впилить, те же дженерики, в конце концов, слайсы, каналы и мапы фактически являются дженериками, просто это глубокая фича языка. И в том же Rust например в мане четко показано, что итераторы и лямбды имеют нулевую стоимость.
5. Статические бинарники, независимость от сторонних либ/фреймворков (.net, JVM, MSVC etc), скорость. Пресловутые легкие потоки. Довольно много библиотек уже написано, почти все вопросы, которые возникают, уже отвечены. То, что решение проблемы как правило одно, то, что код, написанный разными людьми по крайней мере выглядит одинаково (хотя это не так важно). Нравится обработка ошибок и отсутствие исключений, возврат более одного значения с функции и присвоение сразу нескольким переменным (словом, недо-тьюплы)
>>968555 1. Микросервисы для IaaS платформы. 2. 3 месяца. 3. Python или даже баш. Я раньше на Java писал, но это вещи не сравнимые. 4. Хуевое коммюнити, хуевый тулинг и ебучая пропаганда. У меня в команде долбоебы говорили что зря я на локах сделал участок кода, хотя по перформансу CAS занимает не более чем 26 нано секунд, а прочитать сообщение из ченнела - 1 микросекунду, т.е. распиаренные ченнелы это говно собачье. Бесит уебишьный менеджмент горутин, нужно городить отдельный signal ченнел, чтобы ее застопать. Бесит, что нету нихуя коллекций кроме слайсов и мапы. Бесит, что большинство девелоперов - хайповые дегенераты, которые нихуя не шарят как все это говно работает внутри. Самый показательный пример это спросить любого годауна про GC. 5. Нравиться, что язык сделан, как для дебилов, т.е. я просто делаю свою задачу без выебонов (особенно из мира ФП) и иду вечером спокойно играть в игры/бухать/курить шмаль. 6. sync.Locker, sync.RWMutex, sync.Waitgroup активно использую, но каналы тоже приходиться.
Чем Го помогает делать инфра сервисы и насколько он выигрывает по сравнению с пистоном, к примеру, только исключая разговоры про перфоманс и конкаренси/параллелизм?
>>968555 1. прокся, работающая со статистикой пайтон дергается как надо что-то в базу записать, го просто складывает это в бд (используем хуёвину от яндекса здесь) 2 на работе полгода, а так год с лишним 3 не противопостовляю, язык как язык, с плюсами и минусами 4 хз, иногда, очень редко не хватает генериков, в основном доставляет - делаешь все в лоб 5 никакой магии, в то время как на пайтоне приходится разгребать декораторы, вспоминать что делает каждый, тут очень сложно наговнокодить, на крайняк тут все очень легко переписывается 6 каналы редко используются, ибо работа однопоточная - взял запрос и положил в бд по определенным правилам, хранящимся в редисе
>>967828 (OP) Чем Го лучше хаскеля? Все ваши фичи из Го уже 10 лет как есть в хаскеля, и только вылезшие из крестобункера /Го/спода им могут радоваться.
>>968579 > только исключая разговоры про перфоманс и конкаренси/параллелизм? Ты не поверишь, но именно ради этого. Но еще важно время старта сервиса, которое составляет около 1 миллисекунды, т.к.на выходе статический слинкованный бинарь, кторому не надо делать парсинг/выполнение кучи скриптов из virtualenv/pip. Для Blue-Green deployment, время рестарта это очень важно в highly available системе. Многие еще пиздят, про легкость деплоймента, что мол бинарник засунул на сервер и все, но у нас Docker и нам похуй.
>>968580 >Буферезированный ченел? Любой, даже не буферизированный все равно выдает хуевый перформанс по сравнению с мютексами.
>>968692 В плане concurrency Go ничем не лучше C#, в дудке есть async/await, фючеры, промисы, Rx, ParallelFX и вообще куча всего.
>>968584 На самом деле Java лучше чем go во всем, кроме простоты. Например мне не составило труда перечитать исходники Go, чтобы понимать как он работает изнутри, в то время на как разобраться как работает HotSpot у меня ушли годы. Ну и ощущение у меня от Go как от Java 1.4, но чувство полного понимания что происходит под капотом греет душу.
Т.е, если я примерно занимаюсь тем же самым, что и ты(только не совсем дев), то смотреть на Голанг и ждать, что он надолго застрял в клауд вещах, стоит?
> то мол бинарник засунул на сервер и все, но у нас Docker и нам похуй.
У докеров с Голангами есть плюсы, а именно то, что ты можешь хуйнуть FROM scatch и получить леговесный контейнер
> Буферезированный ченел?
Абстракция же. Просто атомики с мутексами должены работать быстрее, чем канал, в который пишется куча инфы о том, что там в буфере, всякая мета и пр, не считая того, что операции там тоже потокобезопасны.
>>968761 Гугл - это джяяява. Потому что он из всего до чего дотянется - делает джяву. Го - исключение, потому как это быдлоскрипт уровня баша, а не язык.
>>968726 Как бы тебе объяснить, чтоб ты своим господским умом допёр... В винде не нужны легкие потоки просто потому что исторически нет говна мамонта под названием форк. Вообще вся эта многопоточная залупа, асинки, и прочая дрисня перехайплена сообществом линукспараши, потому что они 30 лет живут с тормозным форком и не понимают, что ос треды могут просто работать. Как в вендопараше например.
>>968744 >которое составляет около 1 миллисекунды >время рестарта это очень важно в highly available системе А то так важно между стартами в 10мс и 1мс.
Вообще хайлоад, если это не нативный сервис (типа сетевой свистелки дробящей айпи на С++ с ассемблером), очень сильно зависит от кэша. Приложение без данных это не приложение, а скрипт Чаще кэшем мы размениваем время при старте, в пользу выигрышного времени в момент работы (если бы мы собирали его по ходу, если конечно вы вообще кэш юзаете). Для продащена кэш лучше собрать при старте, для дебага, во время (чтобы старт был быстрый).
В общем тут суть в том, язык не имеет значения. Скорее всего на го не пишут и не будут писать приложения такого уровня.
>Многие еще пиздят, про легкость деплоймента Под диплоем в ИТ подразумеваю - автоматизированное развертывание. Вся суть деплоя это развертывание по "одному клику". Поэтому легковесный деплой звучит как масло масленное. И да если ты бинарник руками копируешь - то действительно для тебя это будет легковесный деплой.
Проблема Го, что его облепили индивиды, с юношеским максимализмом.
>>968818 >В винде не нужны легкие потоки просто потому что исторически нет говна мамонта под названием форк. Создает процессы, а не потоки. Блин, чувак, ты что, реально противник асинхронного программирования? Ты ведь буйнопомешанный по полной.
Ты хоть одну GUI программы под виндовс видел? Там все асинхронное. await async в шарп то-же добавили от того, что он ненужен видимо. Я короче в шоке.
>>968839 Серьезно, ты клиент дискорда видел? Батя говорит малаца, хорошо сделали. Как в 2017 и положено делать GUI приложения.
А по теме - асинк параша перехайплена. В первую очередь красноглазиками и их нодой. Нет, мы все понимаем, что если Илюша будет в свое гуё поделие пихать асинк во все поля, то от этого он получит прирост производительности. Но такой же прирост он получил бы если бы просто засунул свою 1 (одну) числодробилку в отдельный тред. В теории эти ваши асинки можно запускать параллельно, получая от этого выигрыш. Например можно запустить все sql запросы сходу. Это реальный профит асинк технологии. Много макак так делает? Не думаю. Так же асинки позволяют экономить треды. Положа руку на сердце, скажи, много ли местных битардов упираются в количество виндовых тредов, если изначально в винде нет проблемы с тредами и их там можно создавать тысячами? А?а?А? В итоге имеем что имеем. Асинк во все поля - это конечно хорошо, но оверхайплено чуть более чем полностью. И не всегда используется для профита даже там где его можно было бы извлечь.
>>968826 >В общем тут суть в том, язык не имеет значения. Скорее всего на го не пишут и не будут писать приложения такого уровня. Ты путаешь хайлоад и хай фреквенси. Хайлоад приложухи можно писать на чем угодно если их можно скэйлитб в ширь. А вот для хай фреквенси приложух нужна высокая отзывчивость и там над этим, как разу, угорают в си и го.
>>968848 это понятно, но штука в том, что хайлоад это не скорость ответа, это возможность обработать любое количество запросов за адекватное время, и при возможности приложухи идти в ширь, это вообще не будет ни от какой технологии зависеть, только сколько ресурсов у тебя есть.
>>968849 Хайлоад - это, например, мейлру. У тебя почта начинает тормозить, пользователи садятся на трактор и уезжают на гмейл. На этом хайлоад заканчивается.
>>968850 и хули нам твой мэйл ру? ты читать умеешь, что тебе пишут? Приложуха не зависит от локальных состояний, деплой ее на новые инстанцы и прикрепляй их к лоудбалансеру, хули тут еще надо для твоего хайлоада? Всем до пизды на чем это написано, пока все эти правида могут соблюдаться.
>>968840 >Серьезно, ты клиент дискорда видел? Батя говорит малаца, хорошо сделали. Как в 2017 и положено делать GUI приложения. Там все асинхронное. Как и в любом другом гуи.
>А по теме - асинк параша перехайплена. В первую очередь красноглазиками и их нодой. "Асинк парша" была задолго до ноды. И будет задолго после.
В современном мире, очень тяжело найти приложения, не использующие асинхронный подход. Консольные утилитки разве что.
Это потому, мой полоумный друг, что аппаратная платформа, железо, асинхронно от природы.
>Нет, мы все понимаем, что если Илюша будет в свое гуё поделие пихать асинк во все поля, то от этого он получит прирост производительности. Нельзя делать гуи поделия другим способом, так как API OS для создания гуев - асинхронные. И внутренности ОС - асинхронные.
>Положа руку на сердце, скажи, много ли местных битардов упираются в количество виндовых тредов Понятия не имею о чем ты сейчас вообще.
>изначально в винде нет проблемы с тредами и их там можно создавать тысячами? Где угодно можно создавать треды тысячами.
Я все так и не могу понять, ты траллишь, или серьезно. Сколько все таки тебе лет?
>>968744 >Например мне не составило труда перечитать исходники Go, чтобы понимать как он работает изнутри, в то время на как разобраться как работает HotSpot у меня ушли годы Ты тут кстати сам себе "ответил", объемы человеко-часов в Го и рядом не стояли с такой технологией как HotSpot (в которую влили туево тучу ресурсов и речь не только про время и доллары, а так же о исследованиях).
Выросло то поколение, которые не видело свалку кода в процедурных проектах и почему ООП в свое время дал хороший толчок для реальной сложных проектов. Проблема в том, что в природе сложное нельзя представить легко (или упростить без потерь), единственный способ - это разбить его на составляющие и структурировать, работая в какой момент только с отдельным звеном (юнитом). Такие юниты предоставил в свое время ООП. Сначала ты смотришь на проект сверху, смотришь как модули взаимодействуют (у тебя появляется какое-то общее представление), далее ты погружаешься все глубже и глубже и работаешь уже с каким-то определенным модулем, который в свою очередь тоже может иметь высокую сложность и в себе иметь подмодули. Все это слеплено из интерфейсов (контрактов), поэтому копаясь в своем модулем - ты не поломаешь модуль твоего соседа (если работаешь в рамках контракта между вами - то есть не ломая интерфейс, о котором вы могли договориться ранее совместно).
Именно это и есть прорыв технологий того времени, плюс это еще дало возможность по средствам интерфейсов работать несколькими крупными командами над одним проектом (не грызясь за всякую мелочь)
Объектное программирование важно не выучить, важно его еще понимать, конечно в процедурном стиле легче и проще писать скрипты и простые проекты, но вот такого гиганта как HotSpot в процедурном языке написать было бы дороже и сложнее (да можно, можно и ядро линукса, но сложнее это, это понимание приходит с опытом).
Гордится тем, что го процедурный язык или имеет обгрызки вместо ООП - это по мне странно
>>968861 Мне кажется ты немного не понимаешь, о чем говоришь. Потому что асинхронное программирование последние несколько лет перехайплено. Безусловно асинхронное апи существовало давно. Но ты же понимаешь, что, внезапно, это не единственный способ не блокировать уи тред, да? Можно - внезапно - воспользоваться неблокирующими ИО операциями. Или - так же внезапно - создать отдельный тред и заблокировать его. На каждый файл и сокет. И в винде это будет работать, причем нормально. В линуксе - не очень. Что реально принес этот асинк/авейт хайп - это парадигму асинк во все поля. Которая, как я уже писал, во-первых позволяет ленивым/неразбирающимся программистам легко не вешать гуи тред своими поделиями, а во-вторых в теории позволяет при тысячах одновременных ио операций не упираться в максимум ос тредов, которые ты можешь создать.
>>968873 Я думаю по историческим причинам, в винде развивали треды, а линуксоиды сидели с наследством юникса в виде форка. Для хеллоу ворлдов этого хватало. Готов поверить что к 2017 проблему решили и треды у них уже не тормозят.
>>968869 > Потому что асинхронное программирование последние несколько лет перехайплено. Как перехайпленность чего-ли в последние несколько лет, каким либо образом связанна с моим пониманием чего-либо на свете?
>Можно - внезапно - воспользоваться неблокирующими ИО операциями. Это называется асинхронное IO.
>Или - так же внезапно - создать отдельный тред и заблокировать его. На каждый файл и сокет. И на каждое устройство ввода, мышку, клавиатуру, ага. Пока у тебя ввода вывода немного, 1-2 файла, пофиг в принципе.
>И в винде это будет работать, причем нормально. В линуксе - не очень. Ну с чего ты взял, что за бредни сумасшедшего? Потоки линукса ничем принципиально от виндовых не отличаются. Но в целом, планировщики в никсах более гибкие и мощные, и позволяют держать БОЛЬШЕ тредов.
>, а во-вторых в теории позволяет при тысячах одновременных ио операций не упираться в максимум ос тредов, которые ты можешь создать. Господи, всем посрать на МАКСИМУМ тредов. Это НЕ ограничения использования тредов для интенсивного IO.
>33-лвл-5-лет-в-этой-вашей-веб-параше-кум. Стыдно должно быть, такую ересь нести, с уверенность 20летнего. Советую или не лезть в область знаний, в которых ты слаб, или изначально хоть знакомится сними. Почитай челе что нибудь по архитектуре пека и системному программированию.
Ты хоть понимаешь как потоки работают? Переключение между ними происходит по заданному интервалу времени. У тебя есть 10 потоков. 1мс выполняется один, потом он останавливается, и запускаться второй, через еще 1 мс, второй останавливается, запускается третий и так по кругу. Эти остановки запуски и переключения довольно затратные операции. Поэтому, когда у тебя уже 100 одновременно активных потоков, эти затраты становятся ощутимыми. Плюс, тебе их зачастую так или иначе приходится синхронизировать, а срабатывающие локи это еще потери.
Вторая составляющая цены - это память, которой нужно прилично для потока.
Поэтому, ничего, что работает с IO сколь нибудь интенсивно, не пишут в блокирующем режиме.
>>968890 >>968891 Я не понимаю, о чем можно говорить с местными кукаретниками, если они не понимают разницы между асинхронным ио, неблокирующим ио и блокирующем ио. Почитайте маны ваши чтоли сначала, там все расписано.
>>968892 >Я не понимаю, о чем можно Можно срать на головы дебилам, дурачок. Собственно, говно для того и придумано - собрать совсем дебилов в кучу и сжечь
>>968892 >Я не понимаю, о чем можно говорить с местными кукаретниками, если они не понимают разницы между асинхронным ио, неблокирующим ио и блокирующем ио. Почитайте маны ваши чтоли сначала, там все расписано.
Няша поняша, синхронное IO это прошлый век. А ты все труп ебешь. Асинхронное IO, это не последние несколько лет, это уже в 2005 было в массах. Когда еще делфи был жив.
>>968901 >То есть в случае асинхронного ио операция выполняется асинхронными гномами без траты ресурсов цпу? Да. Гугли the is no thread
Конечно, какие-то ресурсы тратятся, но они на порядки меньше стоимости многократного усыпления пробуждения потока и бесконечных переключений контекста.
>>968906 >The device driver’s Interrupt Service Routine (ISR) responds to the interrupt. An interrupt is a CPU-level event, temporarily seizing control of the CPU away from whatever thread was running. You could think of an ISR as “borrowing” the currently-running thread, but I prefer to think of ISRs as executing at such a low level that the concept of “thread” doesn’t exist - so they come in “beneath” all threads, so to speak.
>>968868 >Проблема в том, что в природе сложное нельзя представить легко (или упростить без потерь), единственный способ - это разбить его на составляющие и структурировать, работая в какой момент только с отдельным звеном (юнитом). Такие юниты предоставил в свое время ООП. >Сначала ты смотришь на проект сверху, смотришь как модули взаимодействуют (у тебя появляется какое-то общее представление), далее ты погружаешься все глубже и глубже и работаешь уже с каким-то определенным модулем, который в свою очередь тоже может иметь высокую сложность и в себе иметь подмодули.
Отчасти оно так. Всякие джавы и прочий сложный ООП были созданный для организации конвейерного производства ПО, что в IT заимело термин интерпрайз. Интепрайз подход позволяет разбить сложную задачу создания ПО на очень очень много мелких и очень простых. Что позволяет задействовать большой и очень дешевый чселовекоресурс. Любой может работать в IT.
Но такой подход возымел и недостатки, приложе6ния стали становится мягко говоря громоздкими. Стали появляется разного рода архитектурные проблемы, ведь люди, которые это ПО создают, понятия не имеют, что они делают, как пресловутая собака. Стали расти издержки, на содержание сложной управляющей и координирующей системы. В общем, то, что хорошо выглядело в теории, на практике возымело множество побочных эффектов.
Сложность ООП зачастую лишняя. И существует только ради себя самой.
А сейчас, вместо конвейерного производства, продвигается концепция "3д печати", унификации возможностей производственных средств. Видимо, мир разработки ПО в ближайшем времени будет двигаться в сторону упрощения.
>>968803 >Т.е, если я примерно занимаюсь тем же самым, что и ты(только не совсем дев), то смотреть на Голанг и ждать, что он надолго застрял в клауд вещах, стоит? Лишним не будет, тем более это не хаскелль. Выучить Go не сложно. >только не совсем дев Братишка дев-опс? С чем работаешь? Kubernetes щупал?
>У докеров с Голангами есть плюсы, а именно то, что ты можешь хуйнуть FROM scatch и получить леговесный контейнер Да, но у нас один base-image на основе CentOS от которого наследуются все остальные, в котором уже настроена куча security related фишек. Так, что лично для моего проекта плюс сомнительный.
>Абстракция же. Просто атомики с мутексами должены работать быстрее, чем канал, в который пишется куча инфы о том, что там в буфере, всякая мета и пр, не считая того, что операции там тоже потокобезопасны. Так никто не спорит, я сам люблю высокоуровневые канкарренси примитивы, особенно Rx. Но годауны наслушались от своего фюрера "share memory by communication" и не признают ничего больше.
>>968926 >Так никто не спорит, я сам люблю высокоуровневые канкарренси примитивы, особенно Rx. Но годауны наслушались от своего фюрера "share memory by communication" и не признают ничего больше. Бред какой-то.
Гофер пишет что он использует мьютексы вместо каналов. Хейтер говорит что гоферы используют каналы и потому тупые.
>>968930 Сама по себе концепция отказа от разделяемого доступа к памяти прекрасна. Многопоточное приложение будет плохо работать, если все треды будут писать в одну и ту же переменную. В каком-то смысле многопоточность вообще не нужна, потому что ядра (а тем более цпу) не могут эффективно передавать друг другу данные, т.е. максимально эффективно будет работать тот код, в котором каждый поток по-максимуму работает только со своими переменными (ну и читает общие разделяемые данные которые не меняются).
>>968924 >Видимо, мир разработки ПО в ближайшем времени будет двигаться в сторону упрощения.
Да ну, из основых языков на рынке только Go идет в сторону упрощения, kotlin, scala, rust, elixir - вот это современные языки, которые развивают разработку по, а go решает узкий класс сетевых задач.
>>968937 Ты пишешь об opencl. Только есть один нюанс: у обычных дебилов вроде вас всех переклинит всё и навсегда при попытке написать хоть что-то эффективное и сложнее "hello 2+2" Так что пишите на го, вот и маскот жизненный - как раз для вас.
>>968938 > kotlin, scala, rust, elixir - вот это современные языки, которые развивают разработку по Они то-же идут по пути упрощения. Просто разные вещи на разных уровнях упрощаются.
>>968938 >elixir >dynamic, functional >Elixir leverages the Erlang VM Хорошо, что про это говно с ходу написали, что это говно.
>kotlin Это кодогенератор над джавой с местами странным синтаксисом?
>scala Язык для тех, кому нравится анальный секс в пассивной роли и философское втыкание в немыслимые сочетания стрелок и черточек... Ах да, там же еще медленная компиляция и неприлично жирные бинарники, ну и та же трансляция в джаву.
>а go решает узкий класс сетевых задач Так сейчас есть только два широких круга задач - это фронтэнд и серверные приложения. Все остальное - узкий круг.
>>968943 Вот именно упрощаться должны правильные вещи, а не вырезание синтаксиса под корень с анальным контролем над расставлением скобочек и импортом библиотек.
Кубы щупал немного, понравилось то, что много интеграций есть для него, при том даже у странных вещичек, да таких, что у меня слюни течь начинают. Но из за некоторой специфики моей говноконторки, типа ОЙ СЛОЖНА, НУЖНА ШТОБЫ КАК ДОКЕР-КОМПОЗЕ, пришлось выбирать Rancher со сторонними решениями, вместо встроенных в него (вроде консула для service discovery вместо их ДНС серва на нодежс).
> С чем работаешь
Сейчас готовлю стойку новую, поэтому пихаю всё на новый/подпиленный старый стэк, избавляясь от старого барахла. Стэк вырисовывается интересный и хипстовый достаточно.
Если интересно, то могу расписать чутка. Быть может и подскажешь что-нибудь, ибо я маленько костылей нахуячил с управлением конфигурацией. Перекатил с паппета на ансибл, а ОСь, которую юзаем использует cloud-config для бутстрапа и я ощущаю странные чувства на эту тему, а мой, кхм, лид, ударился в бумажную работу и вообще немного любит сделать всё так быстро, что потом половина всего отваливается или работает через "поправь там в двух файлах версию, чтобы новый сертификат нашло", что даже и спрашивать как-то не могу/не успеваю(до того достало, что планирую вообще перекатиться оттуда).
А у вас что за стек? Как деплоите контейнеры? Как блю-грин сделан?
>>968868 >Выросло то поколение, которые не видело свалку кода в процедурных проектах и почему ООП в свое время дал хороший толчок для реальной сложных проектов.
Забавно, >>968868 >Выросло то поколение, которые не видело свалку кода в процедурных проектах и почему ООП в свое время дал хороший толчок для реальной сложных проектов. Проблема в том, что в природе сложное нельзя представить легко (или упростить без потерь), единственный способ - это разбить его на составляющие и структурировать, работая в какой момент только с отдельным звеном (юнитом). Такие юниты предоставил в свое время ООП.
ООП макака копротивляется за ооп в 2016 году.
ООП как раз потому и провалилось, что кому-то подумалось, что если инкапсулировать состояние в объекты -- станет проще. В итоге получили тонны говнокода, сложное стало еще сложнее, а вместо реюза кода получили лишние сущности.
Конечно, ООП-макаки и дальше могут убеждать себя в реюзе кода, да только за пределами их тырпрайз мирка с жабой ооп не пошло.
Почему? Ответ прост, его еще Бахус дал в 70-х. Человек мыслит декларативно. Нам удобнее представлять знания в декларативной форме. Удобнее писать регулярку или bnf вместо конечного автомата, удобнее писать сигму вместо лупа, дифур вместо класса с кучей переменных. Физика, химия, лингвистика, математика от и до декларативны, и только оопуны копротивляются и утверждают, что если добавить инкапсуляцию состояния, сложное станет простым.
Собсна, потому современные языки медленно но верно движутся в сторону функциональщины: начиная со скалы, свифта и раста и заканчивая новшествами в крестах и джаве.
Ну кроме говна, да, эти переизобретают сишку в 2017.
>>969008 >что кому-то подумалось, что если инкапсулировать состояние в объекты -- станет проще Сколько вы ещё будете повторять эти обоснования «если-то-иначе», программистишки? ООП двигал в массы вполне конкретный человек, отложивший вполне конкретных кирпичей, когда всё ПО для его третьей венды внезапно начали запускать Mac OS 8.x, OS/2 3.x и даже IRIX. Оттуда же растут реестры драйверов, COM/DCOM/ActiveX и флеш-заставки на домащних сраничках. Сейчас он имеет миллиарды, а ваше место на помойке, и даже Canonical закрывается, вот и всё.
Пишу на Go. 1. Ошибки очень круто придумали, сначала прописываешь поведение программы на случай ошибки, затем пишешь что будет если все ок. Пока пишу, заметил, что программы на порядок стабильней.
1.1. То, что функции из-за множественного возврата нельзя вкладывать в функции, кажется минусом, но если учесть концепцию в пункте выше, то понятно что это никак не обойти. Единственный вариант: описать wrapper, который /будет сам обрабатывать ошибку, и/или возвращать основной результат. Таким образом можно вызов в вызов вложить. Однако, концептуально, язык обязывает "войти в ритм" и обрабатывать ошибки каждый раз, когда ошибка вообще может появится.
2. Мир устал от абстракций. Вначале ты тратишь 3 дня чтобы описать абстракции и интерфейсы, потом начинаешь только писать реальный проект, который реально работает, а не состоит из trait, interface, abstract class, abstract method. Тут же сразу начинаешь херачить: создал структуру, описал методы, создал анонимное поле структуры (унаследовал), и погнал. Короче, быстро все.
3. Язык по своему уникальный, да, вырезано много, да, много повторяющихся строк, но... скорость разработки зависит не от количества строк в файле, а от отсутствия подводных камней и не естественного поведения программы, а Go позволяет писать стабильные программы, и притом работающие многопоточно.
Сейчас он сбежал с тонущего корабля, который тонет как раз из-за этих недотехнологий, а его компанию так взъебал оракл, что они и дотнет, и скульсервер на линуксе выпустили. Да только кто со скалы и оракла на это говно перейдет, даже не знаю. Даже их новый браузер этот твой активх не поддерживает. Как поняли твои люди, что обосрались, так сразу индусов каких-то посадили, мол, не при делах, бгг.
>>969025 >Мир устал от абстракций. Вначале ты тратишь 3 дня чтобы описать абстракции и интерфейсы, потом начинаешь только писать реальный проект, который реально работает, а не состоит из trait, interface, abstract class, abstract method.
>>968952 >Вот именно упрощаться должны правильные вещи, а не вырезание синтаксиса под корень с анальным контролем над расставлением скобочек и импортом библиотек. Критерий правильности разный бывает.
>>969008 >Собсна, потому современные языки медленно но верно движутся в сторону функциональщины: начиная со скалы, свифта и раста и заканчивая новшествами в крестах и джаве.
>Использование изоморфизма Карри — Ховарда позволило создать целый класс функциональных языков программирования, среда выполнения которых одновременно является системой автоматического доказательства, таких как Coq, Agda и Epigram >таких как Coq >Coq (фр. coq — петух) — интерактивное программное средство доказательства теорем, использующее собственный язык функционального программирования (Gallina) Каждый день что-то новое узнаешь. Спасибо харкачь.
>>968924 Сразу видно человека, который знаком с ИТ только по "интернету". Один шаблонный взгляд за другим.
Но все же вкину тебе месседж: Какие там трудности у тебя возымели, когда ты одним только maven'ом может собрать у себя за минуту библиотеки, которые имеет тысячи человеко часов работы? Представь за минуту ты решаешь вопрос тысяч часов работы.
Иди сделай такое в го - то обгрызок на обгрызке, то баг на баге. И это при том, что в го, до сих пор не пизнают менеджер зависимостей.
Давайте уже называть своими именами, го исключительно для скриптов. Как там? ДевОПс или как?? В общем, тупоголовые макаки админы играют в программирование.
>>969025 >Мир устал от абстракций. А еще мир устал от скушных обоев (с)
То то я вижу вечерами люди ассемблер берут, нахуй говно ваше, только голые команды процессору. От каких абстракций ты устал?
>Вначале ты тратишь 3 дня чтобы описать абстракции и интерфейсы, Нахера ты сам себе интерфейсы пишешь? Почему ты не можешь одним кликом сделать рефакторинг и создать интерфейс по классу с автозаменной по коду? Почему ты программируешь как в конце девяностых?
> Ошибки очень круто придумали Ты что, это же тренд семидесятых, особенно когда ошибку может обработать только вышележащая функция по стеку и ты как баран руками прокидываешь через ретёрны, а в той функции кастуешь по каждому типу (хотя какие типы, вы там текст парсите)
> сначала прописываешь поведение программы на случай ошибки, затем пишешь что будет если все ок Нет, мой мечтатель, сначала ты пишешь строчку поведения, а потом три строчки одного такого же кода шаблонного кода обработки. Всегда, каждый день. Через полгода тебя уже будет воротить, если ты будешь видеть что в API фунция возвращает еггора
>Тут же сразу начинаешь херачить: создал структуру, описал методы, создал анонимное поле структуры (унаследовал), и погнал. Короче, быстро все.
Создал структуру и поля, понадобился интерфес, переписал на геттер/сеттер - перелопатил весь код Создал структуру и поля, понадобился мьютекс, переписал на геттер/ - перелопатил весь код Создал структуру и поля, понадобились пре-вычесления, переписал на геттер/сеттер - перелопатил весь код ... А не лучше ли сразу писать геттеры и сетерры? - И тут суслики открывают опыт джавы времен начала нулевых.
>>969059 >Сразу видно человека, который знаком с ИТ только по "интернету". Один шаблонный взгляд за другим. Я боюсь, ты просто не понимаешь написанного. И\или интерпретируешь оное через призму каких-то своих познаний из "интернета". Я, к своему глубокому счастью, новости не читаю. А в тех материалах, которыми все-же интересуюсь, взгляды аналогичные моим, не встречаю. В IT, такое неприятно обсуждать. Как и темы о корпоративной культуре например. Запретное знание для рабов.
>Иди сделай такое в го - то обгрызок на обгрызке, то баг на баге. Не хочу, не буду.
>И это при том, что в го, до сих пор, не пизнают менеджер зависимостей. Это сложная тема. Что он должен по твоему делать? Например, меня сильно удивило, что этот самый ГО, норовит стянуть что-то с гитхаба постоянно.
>>969061 >Неблокирующие i/o это и есть асинхронный ввод вывод. Нету там, блядь, больше нечего - это синонимы и пиар фраза. ТЫ ЧЕ, ДЕБИЛ! Я больше 20 лет в ВЕБ ДЕЛЕВОПМЕНТЕ, А ТЫ МНЕ ТУТ ХУЙНЮ НЕСЕШЬ ТАКУЮ!
>>968908 >Тред какбы есть но его какбы нет, верьте, адепты. Боже, какой сказочный дебил. Или это троллинг, пусть психиатры разбираются.
Во первых, нового треда не создается, а ОС, в зависимости от реализации может использовать или специальный тред, который всегда существует, или что-то, Что тредом не является(треды внезапно, механизм предоставляемый Ос для выполнения приложений, а не священная корова).
Во вторых. Тред как бы есть, но его как бы нету, когда ты используешь асинхронное IO. Но когда ты используешь синхронное IO, то у тебя, тред как бы есть, но его нет + тред который точно есть.
>>969076 Мальчик, а ведь ты на самом деле неполноценен. То есть до уровня разрушенных алкоголем мозгов обычного русского еще не дошел - но направление то самое. Удачи.
>>969025 >Мир устал от абстракций От тех, что есть - да, потому что они слабы. Я не претендую на то, что знаю, какие лучше, кстати.
>Вначале ты тратишь 3 дня чтобы описать абстракции Рашн софтваре девелопмент эс из, забьем на этап проектирования, давайте сразу навертывать говнокод. Вроде в самых заштатных вузах дают понятие о жц программного продукта, или вы совсем неуч?
>>969059 >Какие там трудности у тебя возымели, когда ты одним только maven'ом может собрать у себя за минуту библиотеки, которые имеет тысячи человеко часов работы? 1. maven в 2017 аааа. 2. Может, вставить депенд с сайта мавен репо это и быстро, но, поверь мне, это местами довольно сложная система сборки и там не все так просто. Хотя что тебе объяснять, ты ж диванный.
>>969065 >Создал структуру и поля, понадобился мьютекс, переписал на геттер/ - перелопатил весь код А еще потом такой скопировал эту структуру и мьютекс вместе с ней.
>>969077 >Ты там в 90хтых застрял? Java 8 вполне современный язык (в плане последняя версия популярнейшей платформы) и там до сей поры надо писать геттеры и сеттеры. Есть конечно плагины для IDE, но по сути это делается.
>>969205 >веб уровня amazon, гугл+ Лол, так амазон, пейпал, tunein, гугл и прочие как раз и форсят простые средства разработки. C++/java это конечно круто, но оно нужно не везде.
У меня такой вопрос, Го компилируемый и максимально простой язык, почему по производительности, даже в число-дробилках он не уступает интерпретируемой джаве (не разогретой, а той которая байткод исполняет, без HotSpot)?
Если не трогать всякие ГЦ то он должен исполняться почти вровень С/C++ ?
>>969184 Ну, конечно есть более полные реализации ООП, в том же C++. Но на практике, больше половины из этого оказываться бессмысленным и беспощадным злом. Которое используется только в laba2 и kursach.
>>969317 У вас нет пропертей, при этом все завязано на джава-стайл Как только го начнут писать реал приложения, путем спотыкания поймут, что открытые поля зло и нужны аксессоры. Ты думаешь 20 лет назад в джаве не использовали публичные поля и не юзали классы как сейчас гоферы? Не от хорошей жизни аксессоры стали юзать.
Вы сейчас проходите эволюционный путь времен 80-90 годов (да да, когда ты еще не родился или срал в подгузник). Большая проблема даже не в этом, что вам гуано скормили, а то что язык не развивается и заставляет вас хомяков верить во все говно, чтобы вы не критиковали, хотя реально го можно было допилить
>>969335 Что тебе мешает сделать accessors в Go? Есть у тебя пакет, создай Struct с полями. Добавь к структуре методы. Все. Делай поля неэкспортируемыми, и все ок. Конструктор, обычно, это функция New() принимающая аргументы, и возвращающая структуру которая тебе нужна. Извне на методы ты никак не повлияешь. Есть два понятия: сокрытие свойств и защита. Защита - тема другого урока. А сокрытие есть как в Java так и в Go.
>>969388 Если так подумать, то геттеры и сеттеры нужны только для того, чтобы не сделать глупых ошибок, типа присваивания не тогда, когда надо. То есть они нужны тем, кто не может нормально контролировать свой код.
>>969413 Ну вот например, в PHP есть способы читать, писать в свойства налету. И не важно, private, public или protected они. Достаточно получить ссылку на объект, и через Closure::bind мы добавляем в объект метод, который может изменить, прочитать и сделать что угодно. И нахуя нужны геттеры и сеттеры? А нужны они для того, чтобы предоставить API для тех, кто будет использовать пакет. Создал, ты, скажем, кешер. Написал метод GetTotalKeys() int и получил себе поле length структуры cache. Но это не значит, что эти значения защищены, и никто не сможет изменить их, это не гарантия защиты. Поэтому геттеры и сеттеры - это API и ничего больше.
Поясните ньюфагу программирования, что такое дженерики о которых так много говорят, и как бы выглядел код в Go если бы они там были, какие плюсы и минусы. Вычитал тут http://www.quizful.net/post/java-generics-tutorial что якобы основное преимущество - ошибка компиляции, а не скомпилируется а на запуске выдаст ошибку. Но на сколько я знаю в Go и так на этапе компиляции будет ошибка, если в string int записать. Тогда какие у дженериков плюсы, если можно именно на примере кода Go и на примере до и после появления дженериков.
Короче говоря, дженерики позволяют тебе делать обобщение твоего кода. Написал пример со структурами и понял, что он не очень удачен. Более понятный будет такой:
func insert<T>(a []T) { // Вставим в массив элемент }
Темлейты в крестах дают возможность указывать типы. Го и кресты вообще не сравнимая вещь, тут лучше вообще сравнить с пуре Си по возможностям(правда сейчас набегут ебанутые и начнётся). Но даже если ты сделаешь просто макросы, коих в голанге нет, то ты всё равно не получишь полной типобезопасности в рантайме, впрочем, как и в джаве, лол, но там другая история и про то, что там обсирались со стиранием я особо и не слышал. Слышал, что как и во многих языках тут можно сделать это с помощью рефлексии, но это пиздец какая просадка по перфомансу.
>>969568 Но если в гопараше нет типобезопасности то нахуй она вообще нужна? Я просто какбы намекну что типобезопасность и строгая типизация повышают производительность числодробилок на порядок.
> Я просто какбы намекну что типобезопасность и строгая типизация...
> сделать это с помощью рефлексии, но это пиздец какая просадка по перфомансу.
Т.е. месседж такой, что если ты юзаешь то, что в языке дано, то всё будет заебись, но если тебе нужно обобщать и делать рефлексию, касты, то ты охуеешь с просадки перфоманса.
> нахуй она вообще нужна
Там много кто чего говорил и я повторять не буду этих доводов, хотя там много припизднутых было. Но для меня лично только большое кол-во проектов, которое написано на нём. Я бы писал на пистоне и вообще в ус не дул, но рыночек порешал по другому.
>>969577 А какая разница, ГЦ или тот же malloc или даже нормальная реализация аллокатора? Все равно, если ты хочешь эффективности, ты просто не будешь создавать объекты. Не используешь new - не работает ГЦ / не надо вызывать delete.
>>969388 > Го - это процедурное программирование, жаба вся в сложных абстракция, жаба говно. >Но ведь структуры без пропертей приведут вас к тем же акссесорам, вы пишите на джаве как девяностые >Что тебе мешает сделать accessors в Go как на жабе? Лол, приехали.
>>969396 >Если так подумать, то геттеры и сеттеры нужны только Плохо думаешь
-твоя иммутабельность данных -пост или пре вычисления (например валидность данных) -ленивые вычисления -геттер для несуществующего поля (вычесляемый за счет -значения некоторых полей, которые мутабельны) -синхронизация/мьютексы -интерфейсы -банальна чистота кода - твой класс это то что он делает, чтобы его понять, тебе надо изучить только публичные методы (в го тебе надо изучать весь пакет). Когда у тебя и методы и поля публичные - код выглядит грязно.
Проблема в том, что никогда не знаешь заранее, где потребуется аксессор, но если понадобиться - то придется перелопачивать весь код. И чтобы не выглядело как говнокод (где у тебя аксессоры, где публичные поля и все в перемешу, тебе придется делать геттеры и сеттеры для всех полей). И нужно не забывать что сервисы - как и либое статичное окружение, должны иметь данные только на чтение (быть иммутабельными)
Если честно, если программист не может с ходу рассказать зачем нужные аксессоры - то это явный показатель его низкого опыта.
>>969470 Как я понял это что-то типа рефлексии в пхп? Так вот рефлексия - это другой круг задач. Это не для диверсии в коде, а чтобы делать гибкий API (например для какого-нибудь фреймворка)
>>969554 Статический язык позволяет отловить куеву тучу проблем по типам еще на этапе компиляции, а не когда-то во время работы как в динам языках. Дженерики дают такое покрытия для обобщенных случаев.
Простыми словами, отсуствие дженериков, превращает статический язык в тыкву подобную скриптам.
Правда в го параметризовали слайсы и мапу и на том спасибо.
>>969613 Статический язык нахуй не нужен кроме как для числодробилок. Сейчас все хуячат на js и питоне и им норм. Всю эту вашу валидацию кода и интерфейсопарашу можно прикрепить к любому языку. Даже к js. Единственное, для чего нужна статическая типизация - для оптимизации кода как в крестах. Когда у тебя каждое поле - не строчка в словарике, а конкретное смещение.
>>969618 Я хз можно ли перекинуть именно в отдельных ос-тред, скорее всего хуй, так как ты работаешь только с грин-тредами. Если можно, то го менее говно чем я думал.
>>969620 >Статический язык нахуй не нужен кроме как для числодробилок.
С голословными утверждениями подписанными чисто на юношеском максимализме, а не на знаниях, тебе вообще можно нас нахуй слать, ты и так уже ТОП в программировании, чувак
>>969622 Так я и шлю, двач же. Вон для js есть поделия уровня http://www.contractsjs.org Люди делают и им норм. А эта ваша статическая типизация и тайпскрипт не нужны нахер. Фактически мировая закулиса пытается из js сделать кресты вместо того чтобы научиться эффективно компилить js код, выкидывая словари из зашкварных мест.
>>969629 Ну а нахер она нужна если контракты и так можно валидировать? Считай что аргументы у функции должны реализовывать все методы и свойства, которые в ней же и используются. Такой неявный контракт. Нужна валидация? Она в 99% случаев элементарна.
эх, для быстрого переката с динамического и интерпретируемого языка голанг хорош. Я пишу приблуду, которая взаимодействует с PBX-сервером (слушает события, шлёт команды, следит за состоянием абонентских устройств) и на го получилось во всем быстро разобраться. Встроенный рейс-детектор нашёл хуёвые участки кода, где я обмазал всё рв-мьютексами а металинтер помог написать код более идиоматический и цикломатически допустимый.
И эта хуйня работает месяцами, пока я новый релиз с фичами не выкатываю (около 2 сотен абонентских номеров и много-много входящих). Скорость разработки и общая штабильность в таком сочетании щас нигде не встречается.
Свифт вот стал доступен под линукс, тоже весьма хорош и дженерики есть, но местные гоферы подняли меня на смех, когда я предположил, что это отличное решение для фулл-стек разработки приложений, например
Вот в том то и дело, что в динамике очень много контрактов именно в голове программиста. А то, что есть только в голове, то быстро забывается и ведёт к ошибкам.
> Сейчас все хуячат на js и питоне и им норм.
Стартапам охуенно, да. При росте кодовой базы начинаешь охуевать от того, что там за пиздец. Ну и тесты вроде if (typeof arg1 == "string") тоже очень удобно, да.
>>969653 Я блуждал среди скриптовых языков, не находя себя. Но вот, в один прекрасный день я попробовал Го! И знаете я узрел, пускай я теперь пишу кода в 10-30 раз больше, но с го моя жизни перевернулась, все заработало стабильно, я обмазал код мьютексами и что вы думаете? Код стабилен -Аллилуйя! *громкий крик в зале - Аллилуйя, Аллилуйя Брат! Теперь я сам стал стабильнее и моя скорость разработки даже выросла на пару сантиметров. Аллилуйя!
>но местные гоферы подняли меня на смех, когда я предположил, что это отличное решение для фулл-стек разработки приложений, например Аллилуйя Брат!
>>969631 Мое имхо что скриптовому языку вообще ничего не нужно, кроме функций да хештаблицы подобной массивам в пхп. Ввод типов без компиляции это уже долбаебизм высшего пилотажа. В общем когда людям нужен статический язык, они лепят его из динамического.
Зачем нужен статический язык? Все просто, чем больше кодо-база твоя, тем больше она превращается в мусор с непонятным взаимодействием. На js было все срать в свое время - юзали реально как скрипты, но сейчас фронтент становится тяжелее бэкенда и вот тут нужен другой язык (а не переделывать старый)
>>969610 >Ты вообще нормальный? Как ты утверждение о качестве кода сопоставил со своим этим высказыванием? Что твориться твоей голове? Ты меня пугаешь анон
Объясняю на пальцах. Ты мне топишь за то, как на го сложно делать то-то и то-то, как будто я утверждаю нечто противоположное. Я этот ГО вообще не пользую пока, мне пуфик.
А противопоставление ГО интернпрайзу вообще бессмысленно и беспощадно. Скажем так, вначале кто-то сделает нечто крупное на го, пару раз, и тогда уже можно будет о чем-то говорить.
Пока это бессмысленно, ибо нет данных сопоставимых метрик.
>>969615 >Чтобы ты расчувствовался и стал писать больше по делу, а не бомбить впустую на публику. Но я не бомблю. Писать больше по делу? Что можно ответить по делу на заявле6ния типа >У ТИБЯ БАМБИТ ЛАЛКА ?
Бомбил бомбящий перефорсер, И всюду батхерд ванговал! Пукан свой потушить не в силах, Он болью Го тред заливал!
>>969683 >Что можно ответить по делу на заявле6ния типа Не маневрируй, ты конкретно на тематический пост ответил слезами на весь тред (собственно всегда так делаешь, мы поняли, тебе больно, но нам срать на твои чувства - либо по теме пизди либо, рыдай без нас)
>>969620 >Статический язык нахуй не нужен кроме как для числодробилок. лол, ага, именно поэтому второй ангулар переехал на тайпскрипт, типизация нинужна
>>970047 Тогда нахуя там производительность и компилируемость? Что вы мне в уши ссыте годауны? Не нужно биты дрочить и SSE из коробки - гоняйте свои словарики на питоне и нодке.
>>970038 >Го - не для вычислений, го это для души Поясняю, безмозглому тупому шизику. Корутины есть видоизмененный евент луп, и предназначены исключительно для IO. С тем же успехом можно предложить делать тяжелые вычисления в UI потоке.
Для тяжелых вычислений ненужны корутины, и прочая асинхронщина, по определению.
>>970053 >Тогда нахуя там производительность и компилируемость? Производительность разная бывает, в разных задачах.
> Что вы мне в уши ссыте годауны? Да никто тебе в уши не ссыт, дегенерат безмозглый. Иди нахуй, очень тебя прошу, не используй го.
>Не нужно биты дрочить и SSE из коробки - гоняйте свои словарики на питоне и нодке. Тебе какое дело, сын собаки? Каждый ебется как хочет, не нравится, ну, пойди убей себя.
>>970088 Так я его и не использую, нужно же понимать, почему я это делаю. Если язык компилируется - значит на нем можно и нужно писать числодробилки. А вы мне ссыте в уши что нельзя, кококорутины кококо ресурс нельзя больше тредов кококо
>>970110 Я тут на забавную ссылку наткнулся http://www.space.com/36402-peggy-whitson-takes-command-watch-live.html >The trio will leave Whitson in charge, with two other crewmembers: French astronaut Thomas Pesquet and Russian cosmonaut Oleg Novitskiy. >NASA recently extended Whitson's stay on the station by three months. Короче девочки. Если вам лень вчитываться - то в двух словах: мужчины ненужны. Расходимся.
>>970038 САЙТИК ПОЛУЧИЛ КАРТИНКУ С ТЕКСТОМ @ ПОЛОВИНА ЮЗЕРОВ НЕ МОГУТ ПОЛУЧИТЬ ДОСТУП НА САЙТ, ТАК КАК ОБРАБОТКА КАРТИНКИ ЗАНЯЛА ВЕСЬ ТРЕД НА ОДНОМ ЯДРЕ
>>970088 >Производительность разная бывает, в разных задачах. Присоединюсь, какие нахуй разные задачи производительности, круды чтоли? Ты же понимаешь что всякие круды будут что на питоне одинаково тормозить что на го, так как там упирается чисто в БД и сеть.
Нахуя Го с суперпараллельностью, если на нем нельзя юзать эти все потоки для вычислений?
>>970123 >САЙТИК ПОЛУЧИЛ КАРТИНКУ С ТЕКСТОМ >@ >ПОЛОВИНА ЮЗЕРОВ НЕ МОГУТ ПОЛУЧИТЬ ДОСТУП НА САЙТ, ТАК КАК ОБРАБОТКА КАРТИНКИ ЗАНЯЛА ВЕСЬ ТРЕД НА ОДНОМ ЯДРЕ
Если у тебя сервер с одним ядром, и ты засовываешь хеви мат в IO тред, то я не знаю что тут еще поможет. Только лоботомия.
А так да, 99.9999% бекенда именно так себя поведет в такой ситуации.
>Го - не для вычислений, го для дебилов Я тебе верю. Ты донес свою точку зрения.
>>970125 Искренне надеюсь, ты так толстишь. Нет никакой темы, с тобой я ни о чем не спорю. Ты не пишешь сколь нибудь внятных тезисов, к которым можно было бы апеллировать, будь у меня такое желание. На любые разумные доводы ты отвечаешь одно и то-же >я вас затралел
По теме, твое высказывание никак не коррелирует с приведенной тобой цитатой и статьей по ссылке. Это даже не эмоциональная манифестация, не школьные понты, а простая ругань.
>>970132 >Нахуя Го с суперпараллельностью, >суперпараллельностью Это что за технология такая?
>если на нем нельзя юзать эти все потоки для вычислений? корутины - это не потоки. Использовать их в любом языке для вычислений, не лучшая идея. Хоть в джаве, хоть в луе, хоть в расте.
>>970110 > Если вам лень вчитываться - то в двух словах: го нинужен. Расходимся.
Не гофер, но забавно, что ты действительно считаешь, что тут все такие тупые и не почитают статью. А уж к тому же не знают отличий concurrency и parallelism. А ещё адекватный хейтер/гофер должны знать про GOMAXPROCS. Хотя постойте. ОХ БЛ~
>>970163 Нет, я хочу сказать, что с таким количеством ёбли и постоянным подглядыванием в сорцы на предмет засирания базовой библиотеки мутексами проще плюнуть на всю эту залупу и ставить асинки во все поля на своих яве/питоне/шарпике.
Лол, го даже непригоден для сайтика-бложика. Го пригоден только для неблокирующего ввода-вывода, то есть на том, что давно уже есть в других языках и так под капотом.
Вы просто непредставляете какой это ШИН! Язык с набором задач уровня nginx сервера.
Я в уверен что в это говно завезут какую-нибудь команду-функцию, которую нужно будет вставлять, чтобы не положить весь поток
В нормальных языках вычисления (например картинки) кидаешь в отдельный поток, занимаешься бизнес логикой, потом получаешь из потока результат и все. Ну или на месте вычисляешь потому, что так проще.
А теперь вин. Если в норм языках ты можешь кинуть асинхронщину руками, то в го ты должен дергать внешние функции, чтобы невьебать весь поток на своем сервачке с четыремя ядрами.
Если у первого варианта все явно и понятен мир асинхронной хуйни, то у го это просто костыль чтобы работало.
Какой нахуй хайлоад на го?? Если последующие потоки зависят от вычислений предыдущего. Если на один поток приходится 10мс, то на 100 коннектов - мои юзеры будут сидеть по секунде?
>>970264 Ну он какбы намекает нам, что в нормальных языках не занимаются бизнес-логикой потому что бизнес-логика для крудопетушков из пхппараши. Но если пхппараша с бизнес-логикой не для го, числодробилки не для го, то какова его область применения? Это язык для автоматизации эзотерической мастурбации?
>>970270 >го делает все языки и джаву >го простой и удобный, он лучший >... >го не предназначен для веба >го и не предназначен для вычислений. >ты сам виноват, что используешь его неправильно Ах эти маневры.
И вот тут пойми - кто больше проиграл - node.js дебилы в своей лапше калбэк-хела или гоферы, которым нельзя ничего вычислять (лолец)
>>969554 Мапы и каналы в го - фактически дженерики. Ты можешь объявить любой канал (int, string, свой тип). Если бы были полноценные дженерики, ты мог бы сам создавать подобные структуры.
>>970632 >Мапы и каналы в го - фактически дженерики Они параметризованы.
> Если бы были полноценные дженерики, ты мог бы сам создавать подобные структуры. Но увы.... их нет cast'уй пока молодой, мальчик, кастуй пока молодой...
Самая большая проблема отсутствия дженериков это конечно обесценивание компиляции и дублирования кода. А отсутствие полиморфизма (по средствам наследования, то есть задания типа <T extend X>), делает реализацию дженериков в го просто полу-костылем.
Простыми словами, дизайн языка такой, что проебано уже все. Мне думается - отгрызок-ООП они тоже поверх натягивали, так как получился какой-то монстр, в том числе всплытие таких багов как проверка интерфейса на nil
>>970696 Я про зеленные потоки и как они себя ведут при высоких нагрузках (имея при этом какие-то вычисления), хеллоу ворды понятно что летают, это любой язык возьми.
>>970698 >Я про зеленные потоки и как они себя ведут при высоких нагрузках Хорошо себя ведут. Можешь думать о них как о тшреадпуле.
> (имея при этом какие-то вычисления) Зависит от типа нагрузки.
Короче, большинство ЯП отличаются работой со всякой многопоточностью только внешне. На деле все упирается в железо и твою задачу. Поэтому вопросы касательно производительности ЯП по большому счету бессмысленны.(не всегда и не везде).
Определись с решаемой задачей. После чего станут понятны стратегии для ее решения.
>>970700 >После чего станут понятны стратегии для ее решения. Грамотная архитектура это 80% решения задачи и 80% производительности. От конкретного ЯП и инструментов зависят оставшиеся 20%.
Зачем в го мьютексы если там грин треды и ченелы во все поля, просто поясните мне. Код с мьютексами не может быстро работать по определению. Особенно на сервачках с несколькими ЦПУ.
>>970742 дата рейс же. Если будешь писать одновременный рид-райт одного и того же поля в мапе, то соснёшь/получишь неконсистентные данные для одной/нескольких горутин
>>970700 >На деле все упирается в железо и твою задачу. Поэтому вопросы касательно производительности ЯП по большому счету бессмысленны Ну конечно, то то на моем селероне питон сишку рвет, а вот на кор-дуо выигрывает руби всех.
>На деле все упирается в железо и твою задачу. Да ты просто капитан очевидность, а еще люди дышат.
>>970700 >Хорошо себя ведут. Скорость с которой будут переключаться потоки, будет зависит от скорости с предыдущей горутины (ее какой-то большой атомарной функции). Вьебаться в теории сложно, но если вьебешься то это будет тотальный пиздец, по сути ты даже не будешь понимать почему твой сайт иногда так тормозит, а ты лишь картинку там обрабатываешь (ведь го не предназначен для этого)
>>970701 >Грамотная архитектура это 80% решения задачи То есть, если я неграмотно напишу круд, или вебсайт без MVC, то моя задача, которая все равно будет решена, в твоей теории будет решена только на 20% или что? Ловите этого гения математики.
>>970895 >по сути ты даже не будешь понимать почему твой сайт иногда так тормозит, а ты лишь картинку там обрабатываешь (ведь го не предназначен для этого)
То есть, в норм языках, парся видео или картинку ты просто просядишь по отклику (так как проц будет забит), но твой сайт будет отвечать. А вот в корутинах ты просто часть запросов повесишь.
И чем больше у тебя ядер, тем сложнее будет эту проблему поймать самому.
Как решения, задать в настройках го - большое число ОС-потоков. Но проблема будет проявляться всегда. Так как корутины и вычисления несовместимы.
>>970895 >Ну конечно, то то на моем селероне питон сишку рвет, а вот на кор-дуо выигрывает руби всех. Нужно понимать как работают используемые инструменты, и использовать их в соответствии с их особенностями. Подноготная шизика раскрывается, питонист с целероном и корой дуба.
>Да ты просто капитан очевидность, а еще люди дышат. Ты кокой-то агрессивный буйнопомешанный. Был вопрос есть ответ.
>>970897 >Как решения, задать в настройках го - большое число ОС-потоков. Но проблема будет проявляться всегда. Так как корутины и вычисления несовместимы.
Или вынести в другой сервис эту обработку, (этакие микросервисы поневоле)
В общем архитектура приносит больше скрытых проблем, чем решает насушные
>>970895 >Скорость с которой будут переключаться потоки, будет зависит от скорости с предыдущей горутины (ее какой-то большой атомарной функции). Вьебаться в теории сложно, но если вьебешься то это будет тотальный пиздец, по сути ты даже не будешь понимать почему твой сайт иногда так тормозит, а ты лишь картинку там обрабатываешь (ведь го не предназначен для этого) Я пожалуй устал от твоего больного потока сознания.
>>970901 >Я пожалуй устал от твоего больного потока сознания. Ну тогда поясни где я не прав? Это реальная проблема.
Если одна функция в горутине - в одном потоке отрабатывает 100мс, то десятая в очереди горутина с этой же функции отработается только через секунду. Когда в нормальных потоках они бы обрабатывались независимо от своей работы.
>>970905 >Если одна функция в горутине - в одном потоке отрабатывает 100мс, то десятая в очереди горутина с этой же функции отработается только через секунду. >Ну тогда поясни где я не прав? Это реальная проблема.
1. Это реальная "проблема" асинхронной обработки запросов в любом языке\фреймворке. Го тут непричем.
Вот в этом ты конкретно серьезно полностью неправ. В привязывании распространенных архитектурных нюансов проектирования ПО на один конкретный языкнейм.
2. Существует множество подходов к решению этой "проблемы". Которая существует только в сценарии непрерывного общения с клиентом. Сценарий вида: клиент послал запрос на обработку изображения, и тут же ждет промежуточный результат этой обработки в ответе.
3. >Когда в нормальных потоках они бы обрабатывались независимо от своей работы. Примерно до 100 одновременно обрабатываемых запросов среднее время ответа сервера будет одинаковым, в подобном сценарии. Больше, реализация на "нормальных потоках" будет иметь большее время ответа, нежели асинхронный вариант.
Асинхронный сервер масштабируеться почти линейно, до сотен тысяч запросов с секунду. Синхронный на "обычных потоках" экспоненциально.
>>970929 >1. Это реальная "проблема" асинхронной обработки запросов в любом языке\фреймворке. >Го тут непричем. Согласен, я вообще за то что проблема серьезная, а ее замалчивают. То есть корутины не серебряная пуля, а может еще не очевидных проблем внести
2. Решение одно, вынести тяжелый вычисления в отдельный микросервис. Го, помоему руками не дает отдельный тред создать.
3. Не понял, я тебе про функции которые могут до 100мс просадить на запрос.
Вот пример. Купил ты vsd c одним ядром, у тебя сайт с котиками, юзеры добавляют картинки и видео, ты ставишь ватермарку - то есть обрабатываешь фото и видео. Так вот, когда будет эта обработка тяжелая, сайт будет недоступен?
>>970960 >Согласен, я вообще за то что проблема серьезная, а ее замалчивают. Никто ее не замалчивает. Этой "проблеме" столько же лет, сколько и программированию. Все возможные пути решения давно затерты до дыр.
>>970960 >То есть корутины не серебряная пуля, а может еще не очевидных проблем внести Не существует средства, позволяющего сказать >сделай мне заебись(на одном ядре нагрузку гугла) И получить годный результат, и даже хоть какой-то результат. Нужно думать. ЯП за тебя думать не умеет.
>>970973 При чем тут блять асинхронный подход. Боже. У тебя есть сервер, есть таски, есть тред пул. Сервер распределяет таски по тредам из тредпула. С помощью тасковых гномов. Так вот, вся разница подходов состоит в том, что у синхронного сервера часть тредов будет простаивать, ожидая ответа ио. Асинхронный сервер будет переключать юзер треды после каждой ио операции. Но и в том и в другом случае ты получишь свой ответ после 100 мс если треды не кончились и вся эта система не пошла по пизде. Просто асинхронный сервер может обойтись меньшим числом ос-тредов чем синхронный. Но при этом там больше переключений в юзер спейсе, на которые тоже тратится какое-то время.
Так вот, /го/спода, поясните мне. Я живу 5 лет в вебе и я считаю что многопоточность не нужна в принципе. Во-первых многопоточность - это слишком сложно. Во-вторых многопоточные программы не могут эффективно работать на современном железе. Реально круто будет работать программа, в которой есть много независимых асинхронных тасков, каждый из которых работает только со своими переменными. Плюс некоторые средства коммуникации - какие-то producer-consumer конструкции, медленно меняющиеся кэши - реализованные на быстрых и эффективных алгоритмах умными бородатыми дядями. В самом языке и в реализации основных библиотек не предполагается никаких средств синхронизации, всяких мутексов, хуютексов итд, потому что всё работает или с локальными переменными или с immutable кэшем. Насколько ваше говно похоже на платформу моей мечты?
Запрос 2 получит почти сразу ответ так система распределит на равных (запрос 2 получит свое процессорное время), в го же, тот кто смотрит котиков получит через котиков ~110мс, потому что кто-то раньше запустил дробилку.
>>970977 >Не существует средства, позволяющего сказать Существуют обычный ОС-поток. Ты не получаешь невидимой магии, при этом ты можешь использовать язык в тяжелых расчетах (го, напомню, не может)
Миру нужны были только асинхронный ввод вывод, что решается в рамках обычного языка, все покрывать грин-тредами носит скорее проблемы, чем решения.
>>971005 Подожди, почему будут юзеры страдать? У меня есть допустим FIFO, в которое я кладу async хвосты и новые таски. Как только го-тред освобождается - я в него запихиваю из FIFO первый элемент. Где тут будут простои или тормоза?
>>971013 Го маневры, как только мокнули в проблему с горутинами, гофер стал лепить поверх гошного планировщика еще один какой свой планировщик? Тебе даже высраться в другой тред руками не дают, а значит ты просто множишь проблему и все.
Проблема даже не в корутинах, а в том что планировщик в го такой бестолковый и не может резать исполнение (а если бы мог, то накладывал оверхед ощутимый, но все лучше чем вьебать поток).
>>971077 Я не гофер, не путай детектор чини! Я просто не понимаю почему нельзя сделать 100 го тредов. И чтобы ос между ними переключалась. А го планировщик между ними бы го задачи рассовывал. Я вообще рассказываю как бы я го на шарпе делал лал.
>>971081 >Я не гофер Да мне срать кто ты, главное что ты хуйню несешь как гофер. Гофер это состояние ума.
>Я просто не понимаю почему нельзя сделать 100 го тредов Да хоть 100.000 го тредов. И все 100К у тебя встанут из-за дробилки, если все в одном потоке (если не в одном потоке, то встанет какая-то часть и при нужном числе запросов, то есть когда-то в будущем).
Единственное решение (правильное, из неправильных), сделать микросервис для парсинга и кидать дробилку в него. (Но реально круто было бы, если го мог позволить создавать отдельные ОС-потоки для таких ситуаций, как это можешь сделать ты в шарпе)
В общем это сложности ради сложностей. Когда у тебя асинхронных И/О, то это реал круто, но когда у тебя асинхронно все (корутины) - это не серебряная пуля, это кусок головной боли, который проявит себя не сразу (и при магических обстоятельствах - у тебя будут падать продажи, а ты даже не будешь понимать в чем дело).
>>971131 Под го-тредом я подразумеваю ос-тред в который го-шедулер может свою го-парашу назначать. Я не знаю как он у них называется, честно. Почему я не могу 100 штук их запустить когда у меня 4 проца по 4 ядра? Поясни. И почему у такой системы будут проблемы при загрузке в 70% по цпу?
>>971000 >Во первых Го исполняется в той же среде и на него тоже действуют оверхед на переключение потоков (только с другими в ос). Действует, только причем тут это? Он действует всегда.
>Во вторых откуда такой сказочный оверхед на шедулер в ОС? Там уровень микро-нано секунд. было слово "допустим". Набросай модель, сделай бенчмарк, и впиши точное значение.
Ибо все-таки ждать окончания такой обработки не самая веселая затея. Делать каждую такую обработку в отдельном потоке - за такое нужно расстреливать.
Есть два решения проблемы. (предположительно у нас одноядерная система) 1) В лоб. Мы просто дробим обработку котика на мелкие фрагменты.
2) СВЯТЫЕ УГОДНИКИ, ДА ЭТО ЖЕ ПРОДАКШЕН-КОНСЮМЕР ШАБЛОН!. Нам нужен отдельный тред, который будет брать котиков из очереди и обрабатывать их. Ставим в настройках планировщика количество тредов равное 2м! Запускаем одну единственную горутину читающую очередь и обрабатывающую котиков. А остальное делаем как и раньше 1. Запрос на добавление котиков 2. Отправляем котика в очередь 3. Ответ.
Профит!
IO в отдельном потоке, котики в отдельном. Асинхронность производительность доминант субмиссив.
Ну, собственно, можно теперь и отправку котиков реализовать, без отдельного потока причем.
Это ОЧЕВИДНОЕ решение, которое сразу же приходит в голову. Это притом, что я документацию не читал, ГО твоего не знаю, и один разок глянул на схему работы планировщика горутин.
У тебя или рак мозга, или серьезное психическое расстройство. Прекращай уже скатываться в истерику в каждом ответе, жутко прям от тебя.
>>971003 >Ты не получаешь невидимой магии, при этом ты можешь использовать язык в тяжелых расчетах (го, напомню, не может) Что Го не может? Использовать язык(чей?) в тяжелых расчетах? Я думаю твой язык годится только для вылизывания туалетов, шизик.
>>971137 >Я не знаю как он у них называется, честно. Машины.
>Почему я не могу 100 штук их запустить Можешь. Не то чтобы лучшее решение, но как вариант. А шизик просто ебнутый на всю голову. Он то-ли пхпист, то-ли сеньер питонист-пехепист. Для него это все за гранью понимания.
>>971187 Мыши плакали, кололись, но продолжали грызть кактус
Мне нравится как мартыхи маневрируют, пытаются решить проблему, которые они должны были решать уже в своих проектах (но они походу тупо не догадывались - ведь го это супер-палка).
Как работает мозг гофера. >Мы просто дробим обработку котика на мелкие фрагменты. Вместо того чтобы в коде обработки (например в цикле) иногда вызывать внешнею функцию (чтобы дернуть планировщик), гофер пытается расхерачить котика добавив радости для ГЦ и головной боли для того кто будет сопровождать потом это все. Кстати бывают неделимые дробилки, чтобы реализовать там такое дробление, придется целый фреймворк написать. Адовое решение, больного разума для обработки картинки на vsd серваке.
>Запускаем одну единственную горутину читающую очередь и обрабатывающую котиков. Опять! Опять гофер решает проблему и придумывает новый планировщик. Или ты нам там отдельный микросервис описал (о решение котором я и так говорил)? В общем я даже не стараюсь в эту хуйню вникать, так как там не один паттерн не работает (если конечно не написать какой-то аналог ОС-тредам, по переключению функций во время их работы)
Го настолько революционен и охуенен, что тебе даже в такой задаче как бложик с картинкой, приходиться прибегать к удалению гланд через жопу, а сами гоферы начинают плонить такой ад в архитектуре - что я бы не позавидовал сопровождать код гофера в будущем.
>>971241 Верно, ведь го это эксперимент по удешевлению рабочий силы. Нарастив число ядер, это решит эту проблему. Продавцы железа рады, менеджеры тоже, ведь 10 круд-программистов на го дешевле 2-3 спецов (да и пишут они медленней этих десяти) А если код не расширяем и вообще говно? Не беда, еще наймем 10 и они напишут новый код, причем напишут еще быстрее чем те 10.
Идеального кода больше нет, теперь есть только ручная кодогенирация Генерируй, генерируй макака!
>>971263 Я правда не знаю как это назвать. Давайте назовём её залупа с сыром. Так вот я хочу запустить сервер с го на сто залуп с сыром на своем сервере у которого 4 цпу по 4 ядра на каждом. Чтобы го шедулил свои грин-треды на залупы с сыром а ос шедулили залупы с сыром на ядра. Что я делаю не так? Спасите котиков!
>>971263 Ну так все популярные языки простые, чтобы можно было легко найти новых сотрудников, это началось еще с пхп(легкий аналог перла), js, джава, c# (по сравнению с крестами) и теперь go
>>971268 Суть проблемы? Какой сыр. Там выше описали пример с одним потоком - на ядро. Чем больше ядер, тем больше размазывается проблема с дробилкой. Можно и в го ОС-потоков прикрутить.
В реале два решения. 1) Если функция тяжелая, дерни просто внешнею функцию в промежутке (например в цикле по условию на 1000 итерации), го-шедулер сработыет и переключит.
2) Выноси дробилку в отдельный сервис.
Вообще это все муть, я бы обмазался каким нибудь современным языком с асинками, фьючерами. Го это макака-строй промышленного уровня.
>>971271 Все языки решали конкретные проблемы предыдущих в том числе упрощения. асм -> си (росла сложность программ и на асме писать было уже неудобно) с++ -> жаба (на сях тяжело писать большие и безопасные промышленные приложения) си/перл -> пхп (для веба не было простого и удобного бэкенда, а питон не был похож на си, так как побеждает все что похоже на си)
жс - просто тотальный монополист, а новые технологии с трудом внедряются во фронтент. шарп - появился ввиду того что Sun выиграла суд и они написали "свою джаву", с блэкджеком и..., в общем, более крутую (так бы мог сейчас сделать и гугл, вместо ебанутого го)
>>971297 Можешь хоть 100500, проблему это не решает, а как уже сказал минимизирует.
Пришел у тебя покупатель за айфоном, а у тебя на 3.453 ОС-потоке дробилка запустилась и у него страница не открылась и он пошел ко мне и купил у меня айфон, так как у меня магазин был написан на котлине/скале.
Я просто с позиции ASP.net смотрю, там вроде всю эту async/await идиотию пофиксили и теперь котики не тормозят, всем все платится, у всех все шедулится.
>>971342 Ну то есть там все нормально, просто годауны не могут а) сделать на сервачке по-больше треугольников и б) обосновать за свои кружочки в этом итт треде.
Анон, скажи мне, как его выучить ? Я не верю в эти ебаные книжки, верю только в проекты и официальную документацию. В книжкахте что по ЯП, не по базовым штукам по кругу обсасывают одну и ту же воду.
Проблема в том что меня все, нет идей что на нем сделать. Все что я хотел для персональных нужд, уже давно запилил на питоне, для работы использую джавуя не пограмист по профилю если че, но мелкие штуки программировать приходится, но чую через через пару лет придется укатываться, а у сабжа как раз расцвет. Какие есть платинове проекты которые не стыдно будет закинуть в гитхаб и которые познакомят меня с основой этого говнаязыка ?
Короче я почитал всю эту гочушь. И могу вам ответственно сказать. Для котиков нужен отдельный шедулер, но одного шедулера на всех котиков достаточно. Потому что вся асинк параша оптимизирована для маленьких тасков, и если нагружать ее большими тасками - она скрипит и перекашивается. Но возникает вопрос - зачем же тогда нужен го?
>>971318 >Как он может попасть в тот поток, там же котики
ОС-ПОТОК НОМЕР 3.453 показ котиков <- исполнение тут показ котиков показ котиков дробилка с котиками показ котиков показ котиков <- новый юзер попадает сюда
>>971379 Не, чувак, там все чуть более чем не так работает. Говорю же, прочитал я этот кал. Расчет идет на то, что треды очень часто юзают шедулер. Поэтому есть локальные очереди. Они минимизируют оверхэд на синхронизацию, потому что мы хотим очень часто в них залезать. Соответственно иногда вместе с котиками в такой системе могут залипнуть несколько тасков, это неизбежно. Что нужно - нужно 2 шедулера. Один как в го и локальными очередями, с рассчетом что в него часто срут тасками. Второй - с одной глобальной очередью, в которую пихаются долгие таски. Так как таски долгие - то пихаются они нечасто и мы готовы терпеть оверхэд на синхронизацию при пихании. Хоть бы один /го/даун объяснил...
>>971388 Скажу честно: я нихуя не понимаю в этих шедулерах, GC, контекстах и т.д., но вот тут статью что я скинул я нагуглил секунд за 15. А теперь посчитайте, сколько людей и человекочасов потратили на то, чтобы изойти на говно и доказать что гоферы неполноценны? Короче, вместо того, чтобы говном тут поливать, давайте напишем коллективно два проекта, возьмем VPS-ки и запустим там наши сайтики с бенчмарками, и проверим кто во сколько RPS уложится.
>>971389 Ну как бы я и сказал, асинки нужны на ввод и вывод (где реально проц спит), весь язык делать асинхронным (корутины) приводит на то, что даже с котиками можешь встрять.
>>971388 Весь в поинт в том, что страдать не нужно, а просто принять что у го очень узкий круг задач (ну или дробить сайтик котиков на микросервисы). Я хотел понять, понимают ли это гоферы, которые обмазываются языком "асинхронным под копотом".
>>971426 Какой узкий круг задач? Что ты несёшь. Го это обёртка над epoll и aio_read. Такая же как шарп или питон. Все можно сделать на любом из этих языков и на любом из них тебе нужно 2 шедулера, один для асинков, один для котиков. Просто потому что шедулер для асинков гарантирует тебе чуть менее чем нихуя. Он оптимизирован под другое. А твой самописный шедулер для котиков он же микросервис будет гарантировать тебе нормальную балансировку и при правильном написании парочку свободных ядер.
>>971372 >чую через через пару лет придется укатываться, а у сабжа как раз расцвет Расцвет языка который появился 8 лет назад. Он у нас каждый го цветет, как вода в озере
>>971427 Ты обосрался чтоли? Только привели пример с котиками, что го срет даже в обычное веб-приложениии. И тут же начинается высер что го общего назначения.
Какой второй блять шедулер, когда ты уже в одном потоке сидишь и уже в го-очереди (стартовый поток тоже горутина). Да хоть 200 блядь шедулеров, ты уже помещен в жопу (в горутину), кого ты переключать собрался?? Единственно что тебе дали это runtime.Gosched(), чтобы ты реально не въебал поток на дробилке.
>>971429 Сколько вакансий 58 против 2000 js или 1500 java или 1300 питона в Москве? Обжували, это даже не 1% от общей суммы. И скорее всего придется работать на перделки от предыдущего раба, так как у го еще сырое время для библиотек
>>971431 >Единственно что тебе дали это runtime.Gosched(), чтобы ты реально не въебал поток на дробилке.
Ирония в том, что в совокупности сотня горутин может быть как одна дробилка по весу, то есть кто-то недождется своих потому, что у кого-то мало ядер :)
>>971388 > Поэтому есть локальные очереди. Они минимизируют оверхэд на синхронизацию, потому что мы хотим очень часто в них залезать. Соответственно иногда вместе с котиками в такой системе могут залипнуть несколько тасков, это неизбежно.
В go есть спецфункция runtime.LockOSThread() Которая закрепляет горнутину на конкретном одном единственном потоке.
>>971450 Ну в питоне или там джаве, или даже в пхп, скорее всего будут общепринятые либы, а на го большой риск самописного чуда (а мы выше видели как гоферы строят архитектуры с двойными шедулерами или дроблением котиков)
>>971453 >общепринятые либы Результат от этого меньшим говном не станет Я бы с радостью подался в питонисты, да хуй там без опыта питониста найдешь
> а на го большой риск самописного чуда Да хуй с ним с чудом, все равно либы надо глазами смотреть перед тем как в продакшен пихать если ты не макака, конечно Но импорт сразу с мастера гитхаба это конечно полный пиздец
>>971451 >LockOSThread Тебе с этим придеться столько говна въебать и все равно у тебя не получиться держать дробилку от котиков отдельно. Нет бы гоферам дать создание ОС-треда, они навернули такую жопу через жопные врапперы, что пиздец: https://github.com/golang/go/wiki/LockOSThread
>>971462 Судя по примеру, правильно использовать только от main(). Так как законченная горутина автоматом отцепляется. То есть писать шедулер какой-то, вообще это пиздец там, еще циклического импорта навсосешь
>>971468 Ну я и говорю. Шедулер го - хуёвый. Как и шедулер любой другой асинк параши в твоём любимом языке. В этом его смысл - это трейдофф такой. Иначе бы гошедулер запихнули бы в ось. А гопетушки будут продолжать кукарекать что у них всё самое лучшее, всем всё платится и гарантии во все поля.
>>971462 >А что будет с запросами которые уже отшедулены на этот контекст? Надо протестировать. Скорее всего вернутся в общую очередь. Это ожидаемое поведение.
Я так ПониМаю, горутину с подобной функцией стоит запускать самой первой. Чтобы избежать возможных проблем.
>>971461 По твоей ссылке совсем другая проблема в совсем другом контексте. Ты походу даже собственные посты не читаешь. Это что-то вроде раздвоения личности.
>>971471 >Ну я и говорю. GC го - хуёвый. Как и GC любой другой рунтайм параши в твоём любимом языке. В этом его смысл - это трейдофф такой. Иначе бы GC запихнули бы в ось. А гопетушки будут продолжать кукарекать что у них всё самое лучшее, всем всё платится и гарантии во все поля.
>Это ожидаемое поведение. >Эта фраза и го - несовместимы Вообще это эмпирическое наблюдение, если ты этого не заметил, то скорее всего это твой первый язык (ну или ты настолько туп).
>Ты единственный, кто воспринимает Го как волшебную пулю которая ДОЛЖНА. >Больше таких же упоротых идиотов нет. Все сообщество, в том числе и ты. Давай уже признаем, если такое говно выпустил бы какой-нибудь ХуйПойми-компани, мы бы тут и не сидели даже. Это многое объясняет.
>>971497 >Остальные думают что пуля из /го/вна. И правильно думают. В мире вообще, все, из говна. Тех, кто считает иначе, ждет жестокое разочарование в жизни. Я уже молчу про законы Мерфи.
>>971503 Ну и хорошо, что хоть на дваче за Го не дрочат в две руки. Но перекатывать я вас больше не буду, я теперь kotlin-господин (там кстати тоже подобие корутин завезли, но я еще не обмазывался)
>>971502 >Все сообщество, в том числе и ты. ТЫСКОЗАЛ? Я вот точно не считаю. Если ты считаешь, что тебе виднее, что там считают другие люди, вопреки их заявлениям, то у тебя серьезные, серьезные проблемы с ГОловой.
>Давай уже признаем, если такое говно выпустил бы какой-нибудь ХуйПойми-компани, мы бы тут и не сидели даже. Не вижу смысла рассматривать подобные идеи с точки зрения признания или непризнания. Лично мне, глубоко плевать, кто там что думает, что признает, а что нет. У тебя же видимо на этом какой-то серьезный пунктик. Ты не инвалид часом?
Так вот, неинтересны признания, интересны факты, здравый смысл, и логика. Например, есть lua, которая чуть постарше ГО, попроще, и не такая производительная, хотя недавно в нее завезли гринтреды, как и в го. За lua не стоит никакая крупная корпорация, тем не менее, она популярна и распространена. Касательно же ГО, я бы не сказал, что гугл его прям вот пиздец как продвигает. Большинство моих друзей занятых в IT о нем слышали только краем уха, а некоторые вообще не знают.
>Давай уже признаем, если такое говно выпустил бы какой-нибудь ХуйПойми-компани, мы бы тут и не сидели даже. >мы бы тут и не сидели даже. Ты хочешь сказать, что гугл виновата в том, что ты битард харкачер? Причина твоего присутствие в готреде - ненависть к гуглу, а не к языку как таковому? Я тебе уже много раз говорил, скажу еще раз, ты ебанутый, на всю голову. Это многое объясняет.
(цифры приблизительные, которые ближе к концу времени) Го - 35-40 вопросов в день, за два года поднялось на пунктов 10. Свифт - больше 200 JS - 1200 пхп - 700 жаба - 900 котлин - 10 скала - 70 шарп - 700 раст - 14 питон - 800 D - 4 nim - 2
Так как эти данные мало кому известны, данные непредвзяты и маркетологи еще туда не лезли - графики показывают реальное положение дел как го, так и котлина, так и других языков. То есть никакого роста Го толком и нет.
>>971528 >Я рад за перефорс, значит зацепило. Не я первый это говорю, да? У тебя правда проблема какая-то с логикой. WTF это вообще значит? Перфорс чего? Что не первый говоришь? У меня еще проблемы с логикой, ебанутся.
Я таки не понимаю, если у хейтеров этого языка так горит, то почему они просто не съебут отсюда в свои уютные загоны, а носятся с порваной сракой, доказывая себе, что go плохой?
>>971571 Никто бы на это говно не обращал внимания, просто этот хейтинг есть следствием его дикого пиара, абсолютно неоправданного. От которого блядь уже просто трисет.
>>971571 Это реакция на агрессивный маркетинг, от того что у шизонутых каждый год Го растет (уже лет 8), потом придется какую-то очередную хайп-перделку поддерживать (-"ну и че, он же простой, выучи за два дня" - как будто выучив синтаксис ты сразу впитаешь все АПИ сделанное, по ощущениям, каким-то неадекватном школьником самоучкой).
Ну а так же все наслаждаются винами и тупостью гоферов. Так что да, пошёл нахуй быдло.
>>971709 > все АПИ сделанное, по ощущениям, каким-то неадекватном школьником самоучкой
У ТВОЕГО САЙТИКА С КОТИКАМИ НА КОНТРОЛЛЕРЕ СЛУЧАЕТСЯ ПАНИКА @ ТЫ ПОРЯДОЧНО ЛОВИШЬ ЕЁ НА УРОВНЕ HTTP, ЛОГИРУЕШЬ, ПОКАЗЫВАЕШЬ ПОЛЬЗОВАТЕЛЮ СТРАНИЦУ С ОШИБКОЙ @ ТАК КАК БЫЛ ЯВНЫЙ КРЭШ В ПОТОКЕ, ЛОГИРУЕШЬ ЕГО В FATAL УРОВНЕ @ НЕ ПОНИМАЕШЬ, ПОЧЕМУ СЕРВЕР ПАДАЕТ. @ ОКАЗЫВАЕТСЯ ШКОЛЬНЫЙ ГЕНИЙ, В ЛОГГЕР, ДОБАВИЛ НА КАКОЙ-ТО ХУЙ OS.EXIT(1) @ ПОНИМАЕШЬ ЧТО АВТОРЫ ЯЗЫКА НЕ ЗНАЮ ДАЖЕ ТАКИХ БАЗОВЫХ ВЕЩЕЙ КАК SRP @ БОИШЬСЯ БРАТЬ ПОЛЬЗОВАТЕЛЬСКИЕ БИБЛИОТЕКИ, ТАК КАК НЕ ПРЕДСТАВЛЯЕШЬ КАКУЮ ХУЙНЮ ТВОРЯТ ТАМ ГЛУПЫЕ ГОФЕРЫ
>>971714 За своей паранойей, ты даже не замечаешь, что треды держатся исключительно на поддуве хейтеров. Сюда как в цирк заходят, поглядеть, потыкать палкой в гоферов.
>>971552 Кстати говоря, в процессе общения с шизиком-хейтером, пришлось углубится в Го. До этого я смотрел на Го со скепсисом, но после более подробного ознакомления отношение стало скорее позитивным. Вроде все есть, и очень даже неблохо. Хейты же шизика не находят реальных оснований.
>>971722 >За своей паранойей, ты даже не замечаешь, что треды держатся исключительно на поддуве хейтеров. Анончик, миленький, у тебя очень характерный тип письма. Твое семенство очевидно.
И твои обвинения в паранойи нелепы. Я бы понял, если бы кому-то казалось, что будто-бы целая куча анонимных хейтеров засирает тред, это можно назвать параноей.
Но ведь ты тут один. Бедолага.
>ты даже не замечаешь, что треды держатся исключительно на поддуве хейтеров. Ну, допустим замечаю, или не замечаю, что с того?
Если тред держится на потдуве хейтеров, то треду лучше утонуть, и не всплывать.
>>971719 >ТАК КАК БЫЛ ЯВНЫЙ КРЭШ В ПОТОКЕ, ЛОГИРУЕШЬ ЕГО В FATAL УРОВНЕ
ПИШИ @ ДОКИ НЕ ЧИТАЙ @ УДИВЛЯЙСЯ, ЧТО LOG.FATAL НЕ ПОКАЗЫВАЕТ УРОВЕНЬ ЛОГГИРОВАНИЯ @ "РЯЯЯЯЯЯЯ, НО ВЕДЬ В ПЫХЕ/ЖАБЕ ЛОГ СТАНДАРТ ДРУГОЙ" @ ЮЗАЕТ ВНЕШНИЕ ЛИБЫ ДЛЯ ЛОГГИНГА В ВЫШЕУПОМЯНТЫХ ЯЗЫКАХ
>>971772 Ты используешь ссылочный тип и возвращаешь nil и оказывается валидно. Потом ты используешь атомарный тип и удивляешься, что невалидно. Ты троллишь или сейчас серьёзно, лол?
>>972456 >Сап, Ананасики! Решил вот серьезно вкатиться в ГО. >С чего стоит начать? С настройки рабочего окружения. Качаешь компилятор, настраиваешь редактор, или сразу goglang устанавливаешь. Потом читаешь оф документацию, и проходишь tour of go.
>Какие подводные камни? 1. Встречаешь шизика-хейтера, он начинает тебя преследовать. 2. Ты и есть шизик-хейтер.
Анон, давай составим список, чем можно заменить какие-то вещи (техники, паттерны и тд) из других языков программирования. К примеру, из очевидного, декораторы легко заменяются принятием и возвращением функции из функции:
>>972641 1) Го оперирует теми же объектами 2)>Смешанная портянка логики в одной функции на целую страницу, где одновременно могут ебать низкоуровневые задачи (вплоть до байтов) и тут же оперировать логикой уровня выше (при этом каждая функция выглядит как компостная куча). А пример ты приведешь?
>>972641 >Что пишут с пруфами на го в гугле и пишут ли? 3)>Что пишут с пруфами на го в гугле и пишут ли? https://github.com/google Вот полистай проекты. Как минимум, Grumpy заслуживает внимания.
4)>Почему гугл не вкатил норм язык, опираясь на опыт ООП (какой нибудь свой шарп/котлин/скала/свифт компилируемый) А зачем? Кому надо еще один объекто-ориентированный язык, если все равно все пишут на джаве/си шарпе/свифт/си++ ?
5)>не вкатил няшную сишку без ООП Го - это и есть "няшная" сишка.
двачаны, что значит такая конструкция (*Some).Do() Вот оборачивать в скобки переменную для чего? Че-то учу по тихоньку, и забыл для чего это делается. А найти в книге не могу заново.
Почему говорят что в Go нету ООП? Допустим, тут есть интерфейсы, есть структуры, есть методы и поля структур (экспортируемые и не экспортируемые), есть наследование (через анонимные поля структур). Чего ещё не хватает? В методы можно передавать любой тип, который есть: базовые типы, ссылочные типы, кастомные типы (type Celsius float64) и т.д. Тут даже есть неявная имплементация: например если ты подключаешь какой-то пакет, и тебе нужно, чтобы структуры этого пакета удовлетворяли какой-то интерфейс, можно запилить интерфейс под структуру, и не редактируя пакет, структура уже удовлетворяет интерфейсу. В других языках нужно явно указывать что чему удовлетворяет. Помоему это логично. Ещё понравился синтаксис, чистый и прозрачный. Очень легко читается код после всяких PHP или боже упаси JS. Все пакеты в одном едином стиле, быстро учишься. Вокруг if нету скобок, switch без предусловия, вколотил switch{ case case case case case case}. Ещё понравилась работа с ошибками. Чтобы там не говорили, а ловить эксепшены ещё хуже, чем явно обрабатывать каждую ошибку, да это скурпулезно, но зато стабильность выше.
>>972766 Хаврониос! ругатель закоснелый, Во тьме, в пыли, в презренье поседелый, Уймись, дружок! к чему журнальный шум И пасквилей томительная тупость? Затейник зол, с улыбкой скажет глупость. Невежда глуп, зевая, скажет ум.
>>972724 Почему говорят что говно это не шоколад? Допустим, оно коричневое, его можно есть, можно завернуть в фольгу. Чего ещё не хватает? В рот можно передавать любой тип, который есть: жидкий кал, твёрдый, с глистами и т.д. Тут даже есть неявная имплементация: например если ты подбираешь какой-то чёрный пакет, и тебе нужно, чтобы говна этого пакета были в форме твоего ануса, можно запилить интерфейс под анус, и не редактируя пакет, структура уже удовлетворяет интерфейсу.
>>971769 Отправил почту, отформатировался еще и винт... Какого хера логер, чья задача логировать, занимается еще тем чем должно заниматься как минимум ядро приложения? Нахуя он имитирует какую-то панику?
Если разрабы не имеют банально в SRP, какой же пиздец творится у хомяков?? Походу реально клепают индустрию недо-программистов.
>>972724 >Ещё понравилась работа с ошибками. Чтобы там не говорили, а ловить эксепшены ещё хуже, чем явно обрабатывать каждую ошибку, да это скурпулезно, но зато стабильность выше.
Как ты обрабатываешь ошибку? В панику или ритёрн? Как вообще понять что там может возвращаться? Если ленивая жопа не задокументировала это? Или забыла поправить когда меняли? Как узнать все ошибки, просто логировать (выводить в консоль) и каждый раз удивляться чему-то новому?
Ладно там метод какой, у которого на nil проверить, а если это целая сложная система? Конечно ты за разработчиков сядишь писать свой фрейворк обработки ошибок, а другой Васян свой...
Хотя ничего ты писать не будешь, уровень го - это хуяк-хуяк скрипт.
>>972790 Баранам дали возможность писать логику программы в одном месте, а обработку исключительных ситуаций в другом, чтобы тупо не мешать все это говно в куче, но нет же, какое охуенное открытие сделали в го.
Когда уже дауны поймут что вам вообще никакую обработку незапилили. Хуй с ним - пусть исключения зло, но у вас вообще нет ничего.
>>972778 >>972766 Кто о чем, а джависты о говне. >>972790 >Как вообще понять что там может возвращаться? Если ленивая жопа не задокументировала это? Это проблемы плохого кода, а не языка >>972790 >Как узнать все ошибки, просто логировать (выводить в консоль) и каждый раз удивляться чему-то новому? А как ты это сделаешь в большой системе на джаве? Будешь искать список возможных ошибок, которые могут возникнуть в функции? Или тупо словишь все эксепшны, без определения типа?
>>972790 >свой фрейворк обработки ошибок, а другой Васян свой... А зачем оно надо? Ошибка - это ошибка, значит что-то пошло не так. Выведи её в лог и заверши программу. В джаве по-другому? >>972791 >Баранам дали возможность писать логику программы в одном месте, а обработку исключительных ситуаций в другом, чтобы тупо не мешать все это говно в куче А в try-catch по-другому? Ловишь себе ошибки в логике. А функция уровнем повыше тоже ловит ошибки. А еще одна повыше тот же try-catch использует.
>>972791 >Когда уже дауны поймут что вам вообще никакую обработку незапилили. Хуй с ним - пусть исключения зло, но у вас вообще нет ничего. Правильно, обработки ошибок нет. Потому что в 95 % случаев обработка ошибок - это написать в лог, остановить программу или написать в лог, но продолжить работу.
>>972793 >А, да, еще исключения тормозят. В моём сайтике который 15 запросов к БД делает. Пиздец как тормозят просто. На 15 запросов не тормозят, а на 15 тысяч запросов?
За год появилось порядка десятка новых веб фреймворков, но так и нет даже подобия питоновского NLTK. Что еще раз доказывает истину, которую я озвучивал ранее, Go - замена пхп. У меня всё.
>>972824 >Go - замена пхп. Хуевая какая-то замена, деградация прямо. Да и пхпдебилы те еще дебилы, конечно - но все же не настолько омерзительны как, например, вот это животное >>972821
>>972824 Все эти фрэймвёрки говно полное, многие просто обёртка над стандартной библиотекой. Появится что-то уровня yii2 или laravel тогда и приходите. На go пока очень больно писать стандартные веб странички, вот всякие маленькие api сервисы другое дело.
>>972921 > На go пока очень больно писать стандартные веб странички Так а я о чём. Вот чатик сделать или парсер многопоточный, тут го достаточно неплох, или демоны какие несложные.
Мне вот интересно, Го-программистам потом, наверно, тяжело будет устроится на работу на другие языки. Ситуация: Гуглу надоело вдувать тонны денег в этот язык, все вдруг прозрели, переписывают свою хуйню на очередной %языкнейм%, работы становится меньше, все перекатываются с Го. Гоферу не вкатиться в тырпрайз, потому что он не помнит ООП и не знает паттерны проектирования, не пойти в байтоеблю, потом что указатели вроде как были, но работать с ними и памятью он не умеет.
Помимо зарплаты каждый кодер должен постоянно повышать свой скилл, а не стагнировать и уж тем более не деградировать. Зачем мне изучать/писать на том языке, который меня не делает лучше в профессиональном плане? Это я всё в очередной раз к тому, что язык этот выгоден исключительно для бизнеса и менеджеров. Если он нравится кодеру, то либо у него нет амбиций, либо он не особо одарённый, либо просто зарабатывает деньги, либо всё вместе.
>>972938 > го не пригоден для дробилок Вполне себе >горутины не дадут никакого преимущество 16 поточный проц в домашнем пк уже реалии сегодняшнего дня. Писать однопоточную лабуду в 2017 уже должно быть моветоном. > сях написать микросервис в 1000 строк не больно. В говне сотни библиотек для работы со всем, даже Аллахом из каробки. 1000 строк на с = 100 строк на го.
>>972928 >Го-программистам что-то из разряда html-программист? Писал раньше на пайтоне, потом на другую работу перекатился писать под ios, причем меня сами нашли. Самым сложным было с gc на Objective C рабобраться. Сейчас тут же пишу на go бэкенд. Думаю, без проблем за недельку разберусь с любым другим стеком/технологией, на java стек наверно больше немного времени уйдет. Хз, в чем проблемы у хейтеров. Хотя недавно что-то загорелся и хочется съебаться в Италию, видел там пару вакансий на smalltalk.
Ввиду специфики языка и очень большого авторитета одной известной компании, язык собирает вокруг себя достаточно маргинальное сообщество, которое многим доставляет лулзов (в том числе и в /pr, за счет чего уже выходит #8 тред).
https://www.reddit.com/r/gobashing/
https://www.reddit.com/r/programmingcirclejerk/
Что касается языка как инструмента.
Политика языка построенная на том, что "им" лучше знать что тебе нужно и если после этого ты еще захочешь вкатится в этот язык, знай - единственно достойная там плюшка это горутины и все (хотя некоторые аноны ставят под сомнения их божественную важность, но тут стоит отметить, что технология корутин на самом деле интересная штука, но насколько она востребована "в таком" языке - непонятно).
И знай, несмотря на свою компилируемою природу - го такой же медленный как джава с ее виртмашиной:
https://www.reddit.com/r/golang/comments/62tmcg/why_is_this_go_solution_faster_than_the/dfpc7ca/
(хотя это лулз, но в этом что-то есть - го дает такой же перформанс как не прогретая джава, но при этом сравните что дает вам жаба и го).
Го - прост как палка и удобно на нем писать
Чем больше в языке конструкций - тем разнообразнее и сложнее становится код (пример С++).
Чем меньше в языке конструкций - тем больше вам писать бойлерплейта (ассемблер в пример).
Как всегда побеждает золотая середина и гордиться тем, что язык уходит в сторону простоты, это как гордится ребенком дауном.
Если серьезно, анон уже замечал как муторно писать код на го из-за того самого бойлерплейта (и я тоже это потверждаю), насколько удобно на нем писать большой проект - неизвестно.
Го - самый модульный язык
Ага. Особенно когда в отсутствие обобщенного программирования (дженериков) приходится копипастить логику.
Го - быстрее питона
Верно!
То что такие трендовые компилируемые языки как свифт или го побеждают интерпретируемые языки (причем не всегда) - это просто кладезь лулзов.
Го умеет в ООП?
Несмотря на то, что ранее евангелисты возносили, мол в го есть ООП, но специфичное, сейчас суслики активно топят за то, что язык чисто процедурный (вероятно методичка поменялась).
Причем суслики упарываются настолько, что готовы рассказывать о том, что полиморфизм - это плохой дизайн (ввиду ограниченного мышления и трех святых слов ООП, суслики решили, что полиморфизм чисто ООП фича). На самом деле, разработчики принудительно-безболезненно заставляют по средствам ошибок циклического импорта использовать интерфейсы (о чем говорилось в их группе).
Так есть ли ООП? Да не важно, важно что гоферами все равно придется использовать интерфейсы, а значит активно маневрировать между структурами и джава-объектами с геттрами и сеттерами (такой полу-ООП поневоле).
Стоит ли изучать язык?
Несомненно стоит, потому что "завтра" этот язык заменит твой основной язык на работе (это неизбежно анон, начни любить его прямо сейчас)