Это копия, сохраненная 24 октября 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Дженериков нет пока что, эксепшенов нет, просто смирись.
Обработка ошибок получается охуенно через http://github.com/pkg/errors | в приложениях обычно можно просто паниковать на ошибках.
HTTP-сервер для убер максимального маня-хайлоада: https://github.com/valyala/fasthttp
Для вката в Go читай Донован, Керниган "Язык программирования Go", https://www.golang-book.com/, книги из списка https://github.com/dariubs/GoBooks, а также смотрим видео https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw
Вкатываемся в эпоху докера, микросервисов и адово кошерной сетевухи.
Предыдущий: >>1360787 (OP)
пук
Вопрос из разряда "должен ли я использовать composer, если вынес часть кода в либу на php", "должен ли я использовать npm, если вынес часть кода в либу на nodejs" и так далее.
Я придерживаюсь противоположного мнения. Но ты волен говнокодить как тебе душе угодно, особенно в петпроджекте.
В любом случае, используй vgo, потому что это уже почти стандартный менеджер зависимостей
Я не совсем правильно сформулировал вопроc. У меня есть библиотека и приложение, которое ее использует. Библиотеку я хочу выложить на гитхаб, я думаю она может быть полезна не только мне.
У обоих компонентов есть свои внешние зависимости, про которые, собственно и идет речь. На данный момент это просто исходники в GOPATH, при том у некоторых пакетов разные комиты на моем домашнем и рабочем компьютере, и все работает одинаково, тесты и там и там проходит.
Но если я жестко задам версию зависимости, и пользователь моей либы сам будет использовать эту же зависимость, но другой версии - это же приведет к увеличению как размера исходников, так и бинаря.
Или я что-то не правильно понимаю?
В бинарь попадает только использованный код, это раз.
Го модули (как и dep, к слову) нужен в первую очередь тебе самому, для того, чтобы управлять тем, какую именно версию твоей библиотеки ты используешь. Объясню на примере, чем плоха схема с GOPATH:
У тебя есть пакет alpha, который использует пакет beta. Ты сделал go get github.com/.../beta и выкачал себе его.
Потом у тебя появляется пакет gamma, который тоже использует пакет beta. Ты пытаешь скомпилировать gamma и ловишь ошибку, потому что обнаруживаешь, что у пакета beta вышла новая версия, и gamma использует beta v2.
Ты радостно перескачиваешь beta и обнаруживаешь, что gamma начал компилироваться - но теперь пизданулся alpha, потому что он писался так, что использует beta v1.
Получается вот как-то так:
В случае с gopath ты получишь очевидный конфликт, потому что никогда не знаешь, какую именно версию beta тебе сейчас нужно иметь.
Соответственно, для этого тебе и нужен менеджер зависимостей: там как раз и написано:
alpha <- beta v1
gamma <- beta v2
И теперь го будет использовать нужные версии библиотеки (там можно даже не версии, а просто коммиты указывать, по желанию).
Но это было в принципе про то, нахрена тебе нужен менеджер зависимостей. Когда начнёшь иметь больше 1 проекта в одной системе или попытаешься съехать на другую и обнаружишь что просто go get качает что-то некомпилируемое (потому что go get берёт тупо последний на текущий момент коммит с гитхаба) - поймешь.
Теперь про разницу между dep и го модули (vgo). Классический уже подход (привет композеру, npm-у и т.п.) - это когда менеджер зависимостей качает тебе исходники в папку vendor прямо в твоём проекте и поэтому два не связанных друг с другом проекта не конфликтуют (у каждого свой vendor). Но это засирает систему использованием одних и тех же пакетов кучу раз (особенно npm этим грешит).
Поэтому гоферы придумали го-модули. Они хитро качают пакеты в одну единственную папку на всю систему, но делят их по версиям: GOPATH/pkg/mod/{vendor name}/{package name}/{commit}/...
И это по идее должно снизить нагрузку на систему.
Плюс, vgo даёт тебе возможность в нескольких пакетах в рамках одного и того же приложения использовать один и тот же внешний пакет разных версий. Но это очень редкий случай, я таких почти не встречал.
>Но это засирает систему использованием одних и тех же пакетов кучу раз (особенно npm этим грешит).
Собственно по этому у меня такой вопрос и возник, по тому что я привык, что в каждом проекте node_modules, который занимает очень много. И у каждого пакета, который я явно указал есть свои зависимости, и в итоге это приводит к тому, что всяких лоудешей и jquery в проекте по 5 разных штук, при том что я их и не добавлял в package.json.
Но про vgo ты меня убедил
Никогда не понимал людей, которым нужны идеи для пет проекта.
Ты блять можешь написать ВСЁ. Интернет полон документацией, схемами, мануалами.
Тебя что, ничего в жизни не интересует?
Напиши свой крипто-мессенджер, аналог телеграмма (чтобы end-to-end шифрование). Сделай его распределённым, p2p.
Напиши свой игровой движок, поиграй с друганами в какую-нибудь самописную простенькую херню, 2д шутер.
Напиши свою базу данных, заставь потенциального работодателя охуевать от твоей крутости.
Напиши свой почтовый сервер, используй его и понтуйся перед братюнями.
Нагенерил тебе за полминуты.
Программа получает данные, и парсит. Парсинг и всегда один и тот же, а получать данные можно по сети, а можно, в отладочных целях, читать из файла.
В плюсах я бы отнаследовал новый класс, перекрыл функцию получения данных, и создавал нужный класс - с получением данных по сети или с чтением из файла.
Фактически надо, чтоб была возможно в одном единственном месте закоментить одну строчку, разкоментить другую и запустить прогу.
Тк работа идет со структурой, я придумал засунуть в эту структуру указатель на нужную функцию, но может есть более идеологически правильные способы?
> Ты блять можешь написать ВСЁ. Интернет полон документацией, схемами, мануалами.
Например.
То, что дальше - ГОвно.
> Никогда не понимал людей, которым нужны идеи для пет проекта.
Видимо потому, что у тебя от пет проекта другие ожидания, нежели у других людей. Некоторые, может, хотят что-то полезное или релевантное к их деятельности, чем они реально пользоваться будут, а не упражнение по написанию велосипеда в стол. В глубине души они чувствуют, что код это блоат и программисты должны сидеть в газовых камерах.
Обращайся.
да
>> Обработка ошибок получается охуенно через http://github.com/pkg/errors
Кто-нибудь шапку за последние лет 5 обновлял?
Во-первых, этот пакет уехал в STD - "errors".
Да и не часто им пользуются, есть же juju/errors от Canonical.
Я её почти не меняю, лень заморачиваться
Алсо, до сих пор в своих проектах просто возвращаю ошибку, без дополнительного контекста
Исключения не нужны, они рушат поток исполнения программы, замедляют код и делают его менее очевидным.
(Зря они пошли на поводу у публики и добавили паники).
Какой поток исполнения они рушат, почему они рушат что-то там у гоферов?
>замедляют код
Го и так относительно медленный, что-то среднее между джавой и питоном, до раста там как до китая.
>делают его менее очевидным
Мы тут всем коллективом по полу катаемся, то есть
if err != nill {
...
}
Делает код читаеме??
Исключение плохи лишь тем, что их нет в го, как и дженирики, это тупо поинт дизайнеров языка, которые не захотели парится и сделали просто палку, возложив переброску ошибок на руки программистов (как и много другое) собственно сейчас я смотрю научились заворачивать какой-то контекст и даже стектрейс. Я тебе уверяю, еще 2 года назад, меня пытались забанить за то что я доказывал что стектрейс очень важен, а мне говорили нет и вообще я тролль. А я лишь хотел сделать язык чуточку лучше
Через 5 лет, когда им добавят эксепшены и дженерики, они будут с ними носиться, как с откровением, мол, какой же го замечалньный язык, инфа 100%. А пока Пайк говорит нинужно, значит нинужно.
Дженерики нужны, не представлял, как без них можно жить.
Но как выяснилось можно, но не очень комфортно.
Их добавят.
А исключения - дичь. Вот по ним точно не скучаю.
> они будут с ними носиться, как с откровением, мол, какой же го замечалньный язык
и тут же, после того как стало известно что добавят дженерики:
Дженерики нужны, не представлял, как без них можно жить, ...можно, но не очень комфортно.
Суслики, вы неисправимы))
По прежнему не берем людей у которых в резюме го указан, это просто эталонный идентификатор невменяемости в ИТ
Ты не думай что мы забыли ваши косяки, просто на вас стало уже пофиг.
Из-за таких как ты, вполне себе хорошая идея языка, имеет херовую реализацию. Если такие как ты не ели бы говно, а требовали, то язык бы развивался и за эти года стал лучше.
Требовали же пакетный менеджер и дженериков - получили? Да!
Поэтому самое худшее в языке - это вы говноеды.
Ты школоло просто, но отвечу, просвещайся.
-Отсутствие вирт машины.
-Полностью асинхронный код, но пишешь как обычно.
-Кроссплатформенная компиляция.
-Единый fat-бинарник со всеми зависимостями
-Отстуствие говно ООП, который трудно изучать и сопровождать, потому что б-логика размазывается по десяткам и я видел сотням классам.
-Настоящие структуры.
-Стековые переменные, а не как в жабе почти все в куче.
...и еще что-то, что я может не помню.
Так что, мой юный друг, идея языка то хороша, а вот дизайн плох и будет он плох пока суслики не перестанут жрать "лень разработчиков" и не потребуют развитие языка.
Это все есть и прекрасно можно делать в плюсах.
>Отстуствие говно ООП
>б-логика размазывается по десяткам
То есть тебя надо силой заставлять не говнокодить.
Быдло as is.
> хорошая идея языка, имеет херовую реализацию
Я бы сказал наоборот, Го - отвратительнейшая спека языка с охуенной технической реализацией (gc, гоморутины, компайл в бинарь).
В любом языке есть проблемы, тупые места, дискомфорт, места для улучшения.
Пустой интерфейс лучше чем дженерики, после этого даже как-то непривично на других языках писать
Типы у значений есть во всех языках, нет типов у переменных
Чем питоньяче говно:
if isinstance(x, X1Type):
...
elif isinstance(x, X2Type):
...
Лучше type assertion'a в golang
бля хоть кто-нибудь из крупных компаний использует котлин в проде для бэка? с чего весь этот хайп воокруг него
>бля хоть кто-нибудь из крупных компаний использует котлин в проде для бэка?
Какая-то компания гугл использует в малоизвестной мобильной разработке
Лучшая джава.
Если вы не хотите писать на топорной джаве, и вы явно не альпинист - то котлин ваш выбор.
Котлин - это сишарп в мире jvm
бля, да на котлин бэкенд-разаботчика даже вакансий нет. в лучшем случае идёт вторым языком к джаве и то таких вакансий 40 штук в Москве. короче понятно, опять нексколько городских сумасшедших напридумывало себе какую-то хуйню в голове.
Сомнительно.
Джетбрейнс конечно рвет жопу что бы пиарить свой велосипед, но создать фанатиков котлина у них вышло только в отсталом постсовке.
Да и поздно они выкатили эту шляпу, когда они начинали пилить язык - да, сахар! Больше сахара! Ещё больше сахера!
Но у современной джавы тоже появились приятные упрощения, и котлин нахер никому не нужон.
Не знаю, зачем вам нужны эти дженерики. Обычно все примеры их использования сводятся к "Зато можно написать функцию сортировки универсальную"
Вот за что я люблю двач, так это за то, что он помогает понять: вокруг тебя целая куча идиотов с дерьмом в голове. Обычно они молчат и ты об этом не догадываешься, а тут они высказывают что-нибудь вида
> Го и так относительно медленный, что-то среднее между джавой и питоном, до раста там как до китая.
и хоть стой, хоть падай.
блять, относительно медленный для чего? с чем сравнивать? хорошо распаралеленный алгоритм на го будет скорее всего быстрее. линейные вычисления на специализированном железе затащит джава защёт JIT под особенности конкретной тачки. да даже для питона есть уже pypy и прочая хрень. Уже давно почти все языки работают очень шустро, а медленно работает конкретная бизнес-логика говнокод
Отдельно люблю читать, как люди кидаются какашками вообще в любой стек, относительно своего, чтобы показать, что они - такие илитные и пишут на "единственном правильном языке" (с).
В итоге всё сводится к тому, что решает не язык, а навык программиста решить бизнес-задачу так, чтобы её как можно дольше не пришлось переделывать. Можно писать на джаве, потому что удобненько, а выносить узкие места в отдельные маленькие сервисы на го, потому что дикая производительность из коробки. Можно всё на хаскеле херануть, если у тебя в голове команде сидит 100500 функциональщиков.
Срача по поводу дженериков вообще не понимаю, если не строить сотню слоёв абстракций, а писать AS IS (так называемый go way), то они нужны только, действительно, когда нужно тривиальную операцию типа сортировки написать для разных типов. За свою практику встречался с такиими задачами 2.5 раза, с такой частотой можно и скопипастить.
Имплементируй я всякие стратегии, абстрактные фабрики стратегий и так далее - да, было бы больно. Но го попросту не для этого, не надо на нём монолиты писать. Пишите блять конкретный код для того, чтобы расшить конкретные узкие места в вашем проекте и будет вам счастье.
> идёт вторым языком к джаве
Да потому что, пойми ты, котлин это и есть вторая джава. Котлин на бэке возникает, когда команда джавистов в какой-то момент начинает новый код писать не на джаве, а на котлине, при этом оставаясь на тех же джава-фреймворках, в той же jvm-экосистеме. И джавист может пересесть на котлин буквально за несколько дней, поэтому нет смысла в вакансии что-то требовать как обязательное.
Опять, пиарщики (долбанные партизаны) джетбрейнса пускали слухи, что котлин чуть ли не станет официальным андроид языком. Но хер там плавал.
Полторы калеки вероятно юзают, но мне как-то не попадалось.
Я не выписываю газеты про охоту и рыбалку.
Так стал же, причем теперь приоритетный
они убивают джаву, но вместе с джавой улетят на дно все jvm языки
Хз, все знакомые джависты, кто юзал котлин, ссутся кипятком и говорят, что это действительно лучше и удобнее. Понятно, что просто сахар, на всё-таки.
А лет пять лет назад ссались по скале.
И с тем и другим поиграли, а потом эти языки остались местячковыми решениями.
>Мужики, у вас там дженериков нет, лямбд нет, коллекций почти нет, элементов фп нет ну м.б. они и нахуй не нужны да и вообще язык stuck in the 80s
>Да не, давайте лучше введем бинарные и литералы))))) и еще суффикс для комплексных чисел)))000)))0)
гавкнул чет
Два чая, олды помнят.
Ну не на жабе же микросервисы делать. Покупать для каждого круд-сервиса по vps (или серваку)
Нету больше хорошей ниши.
Питон и всем динамическое тормозит, раст и С++ не для бизнес-логики
Спокойно делаем микросервисы на элике. Основная посуда на рельсах летает. Сейчас вот через неделю на 6.0 перейдем. Вопросы?
Не преувиличивайте, у меня был отличный проект на основе spring cloud, ни единой проблемы.
Джава, если умеючи, отлично живёт в контейнере с софт лимит 128мб.
Лол, покупаешь себе облачко с 512мб, а у тебя уже 128 нету, просто жаба ради жабы покушала.
На го с 128 можно весь пет-проект в памяти держать, или как минимум 6-8 микросервисов с дробилками поднять. А тут у нас целый спринг поместился.
>Джава, если умеючи, отлично живёт в контейнере с софт лимит 128мб.
Ага, урезаешь хип, начинает чаще ГЦ срабатывать, под нагрузкой все это ускоряется и тупо с каскадным эффектом крашится. За то в 128 поместился.
Да можно на брендфаке поднять, мы же говорим про эффективное использование железа, а не то что вы на сервер смогли рельсы поставить.
тоже лольнул как чувак флексит своим охуенным стеком с рельсами
Ну давай разберём по частям тобою написанное:
>дженерики
не нужны, выше уже объяснили, что пустые интерфейсы ничем не хуже
>лямбд нет
в го есть лямбды, имбецил
>коллекций нет
тут тоже обосрался, в го есть основные коллекции, а остальные не нужны
>элементов фп нет
ты долбоеб? функция в го - это объект первого класса, то что нет map reduce не означает, что в языке нет элементов фп
>Да не, давайте лучше введем бинарные и литералы))))) и еще суффикс для комплексных чисел)))000)))0)
если тебе эти вещи не пригождаются в каждодневной работе, то это прежде всего твои проблемы, макака, иди джсоны перекладывай
https://github.com/search?l=kotlin&o=desc&q=stars:>1000&s=stars&type=Repositories
Есть такой подход, как смотреть количество проектов по звездам. Не лучший, конечно показатель но все же определенную информацию можно достать.
Понятно, что в низу списка тысячи полузаброшенных реп и их считать не будем поигрались и забыли, далее идут само-пролайканные репы малых контор и просто сомнительные малопопулярные решения. Но! Вот где-то с 1000 можно уже начинать считать достойные библиотеки для языка, которые люди сами отметили. Так давайте посмотрим количество этих условно-достойных либ.
И что мы видим?см картинку Go почетно среди топов и имеет 1200 условно-хороших отмеченных людьми либ. При том что язык достаточно молодой.
У раста 193 репы
У котлина 147 репы
В общем, го не просто ворвался в мир разработки, он еще умудрился заполнить себя кодовой базой за такое время.
>>дженерики
>>не нужны, выше уже объяснили, что пустые интерфейсы ничем не хуже
Ещё первой версии не было, а на отсутствие дженериков пинали.
Сошлись на том, что они "в принципе" нужны, но в 99% случаев потребность закрывается интерфейсами, причем не пустыми.
Если вам не хватает, то скорее всего у вас проблемы.
на котлин даже самы разрабы поленились либы писать, поэтому язык имеет чуть ли не самую скудную стандартную библиотеку
Имхо, лучше уж интерфейсы чем wildcard или рекурсивные дженерики которые в реальности еще не все джависты до конца понимают или умеют их готовить
Так я не троллям, я вдохновить хомячков
Без либ он просто обертка для джава-тестов (как и груви)
Видимо создали решили сделать ставку на маркетинге, а не либах.
Думаю скоро они поймут на какую лошадь поставили.
У котлина есть фатальная ошибка.
Нужно иметь бэграунд джавы, чтобы комфортно кодить на котлине. Без косяков джавы и вообще принятых там обычаев, совершенно не понятны многие странные решения.
У тебя есть дата классы. Думаешь круто, а потом приятно рофлишь что нельзя пронаследоваться в них.
У тебя запрещен return в лямбдах, но есть вариант return@label, в итоге в сорца смотришь как все скачут - очень прагматично.
Еще больше путаницы привносят inline функции со своим return
DSL - мне показались притянуты за уши. Да можно, но достигаются они таким способом, что проще билдер через точку сделать и выглядят всегда однобока
Какая жесть с первичным конструктором и вообще треш какой-то, который заканчивается init, потому что кончилась магия. Человеку не из джава мира, эту магию трудно объяснить. хотя по честному все же можно сделать как в жабе без первичного конструктора
Закрытые классы - просто венец ООП архитектуры.
Нет обёрток над базовыми структурами типа списка [1,2,3] мап {k:v}, но есть костылизация.
Компаньёны - треш
Корутины, вроде пытались сделать лучше, без await, но получилось как всегда.
А причем тут статическая типизация интерфейс? Написано же иное! А ты что утвреждаешь?
>в го есть основные коллекции
Из всех коллекций для нас важнейшими являются list и map прям как Ларри Уолл завещал.
А множества, сортированные коллекции, очереди с приоритетом - это все буржуйские излишества и пролетариям такое не нужно.
Вы ведь в курсе, что есть множество вариантов реализация различных структур данных?
Какие-то языки решили реализовать "в среднем" лучший вариант, но по факту, когда тебе нужна хитрая структура - пишешь его сам. Для нужного тебе интерфейса.
Зачем раздувать стандартную библиотеку?
>А множества, сортированные коллекции, очереди с приоритетом
На ваших питонах и жабоскриптах с мапами и списками справляются. Все эти коллекции больше нужны чтобы было что спрашивать на собеседование, чем реальная потребность возникает в коде.
Я даже не знаю, что сказать, кроме как "и что?".
Это не создаёт никакого оверхэда на уровне приложения.
Не путайте чувака.
У докера есть вполне определённый оверхед на сетевое взаимодействие и работу с файловой системой, это легко считается и замеряется.
А вот оверхед на горутины и треды действительно находится на уровне статистической погрешности, потому что докер - это движок контейнеризации, а не виртуализации. Он не эмулирует виртуальную машину, а запускает внутренние процессы в той же машине, просто урезает им доступы и видимость, чтобы добиться изоляции. Соответственно, так как машина та же самая, то и оверхеда нет почти, если ты сознательно не урежешь контейнеру ресурсы.
Но это если говорить про докер на линуксе. Потому что докер на маке и винде запускается в отдельной виртуальной машине с линуксом - в таком случае оверхед, конечно, есть. Но это узкий кейс, когда ты запускаешь контейнер у себя, локально. На сервере у тебя, очевидно, будет линукс и нативный докер, так что всё норм будет.
А пруфы можно? У io тоже минимальный оверхэд.
У сети только в режиме nat, но есть возможность вынести сеть на хост. (Вроде так, я не админ - настройками сам не занимался)
Лучше запилите годную шапку с инфой, стёб уже приелся.
У io всё зависит от используемого storageDriver'а, читай про device mapper и прочие *FS в документации докера, там описаны их особенности.
К примеру, если ты пишешь в монитруемую директорию а у тебя BTRFS, то файлы не попадут сразу на диск, они промежуточно пишутся в журнал, импакт очевиден.
А выносить сеть на хост - это очень спорное решение, потому что ты тут же теряешь изоляцию между контейнерами. И ладно, если у тебя только два с половиной контейнера локально, а когда у тебя кластер на проде - то ты от неймспейсов и прочего не уйдёшь уже никуда.
какое джунское имхо
то что большое кол во задач где не критична производительность можно решить с помощью мап и листов это очевидно (в пыхе массивов и объектов), но это не отменяет тот факто что в более узких задачах где прохождение по массиву будет намного дольше чем по линкид листу не говорит нам о том что все реализуемые типы данных нужны только что бы дрочить на собесах
>где прохождение по массиву будет намного дольше чем по линкид листу
Схерали?? Одинаково будет
на самом деле лучше будет у массива
а на добавлении и удалении ?
очевидно что на 10 - 20 - 30 элементах это будет малозаметно , но например на 100кк 100ккк и тд , думаю суть ты уловил анчоус
Блин, только не говорите, что вы не можете написать линкед лист. Нахрена он в стандартной библиотеке? Он что по десять раз на дню нужен?
Быстро переобулся. Думаешь не заметили?
Приведи мне пример "а на добавлении и удалении ?" при фантастических "100кк 100ккк" Хотя не нужно, очевидно ты какой-то школьник или взрослый с мозгами школьника, уноси свои 100ккк
> какое джунское имхо
> прохождение по массиву будет намного дольше чем по линкид листу
Люблю, когда петушки с гонором обсираются.
В том и дело что любые структуры данных, отличные от списка и мапы, надо брать из внешних либ, где они хотя бы поддерживаются, а не заброшены в стд-либ, где для галочки существуют.
Ну или написать самому, раз 100кк и 100ккк данных, это повод научиться программировать самому
Как же это ООП говнище настапиздела
А у вашего котлина, даже наследования нет в дата классах
Это же очущуенно!!!
Да мои маленькие наблюдатели, там везде стринги, так и задумано, это просто пример, в реально жизни так дробить не имеет смысла из-за возможных пересечений данных
Не ври, нет такого листа, "где прохождение по массиву будет намного дольше чем по линкид листу"
А, извини, не заметил сразу. Тогда вопросов нет, Роб Пайк - пидорас, не стал добавлять такой лист. Совсем ебанулся со своей простатой языка, ну его нахуй, пойду в котлин, там дела с коллекциями лучше обстоят
>Зачем раздувать стандартную библиотеку?
Потому что такую роскошь как: map[string]int может себе позволить только стандартная библиотека. А остальным как известно: дженерики не нужны.
>>58951
>На ваших питонах и жабоскриптах с мапами и списками справляются.
Так их никто и не позиционирует как высокопроизводительные языки. У Питона вон попытались выпилить GIL - а потом сказали, да ну нахер нам чистота кода интерпретатора важней.
А Го как раз позиционируется как язык для высокопроизводительных приложений.
С питоном отдельная тема.
Никто в него не вливал кучу денег, а текущие кор-разработчики не могут придумать, как избавиться от Гила, без чувствительного замедления однопоточного кода.
Ну там были энтузиасты которые выпилили GIL https://www.artima.com/weblogs/viewpost.jsp?thread=214235 .jsp - какая ирония
Да, для однопоточной программы стало хуже, но я уверен, что если бы тогда его все же впилили - сечас бы уже все проблемы были давно решены и у Питона была бы полноценная многозадачность.
Блять никого не напрягло, что долбоеб выше высрал полную хуйню насчёт того, что в питоне не коллекций?
Во-первых, лист в питоне может играть роль очереди и стека за счёт методов pop и append, во-вторых, помимо листа и словаря есть ещё такие встроенные коллекции как set, frozenset и tuple. Также, в стандартной либе питона, внезапно, есть пакет collections, который предоставляет ещё несколько коллекций (самые часто используемые из него - deque и Counter).
Наконец, в стандартную либу входит ещё пакет heapq, который включает в себя очередь с приоритетами, пакет bisect, позволяющий поддерживать коллекцию в упорядоченном состоянии, и пакет array, предостовляющий чистые строготипизированные массивы (почти как в си).
В итоге имеем довольно приличный список коллекций, которого хватит в 90% ситуаций, не хватает только, пожалуй, одного связанного списка
Лол, го и есть "питон которого не смогли разогнать", одно только йоба наследие циклического импорта о чем говорит да, иногда циклические зависимости нужны
Дженерики и правда не нужны, это просто такой вот другой стиль, где не нужно чтобы компилировалось несколько минут.
Что действительно нужно, так это улучшить обработку ошибок и пакетный менеджер, все.
Зачем в питоне вообще какие-то там коллекции? Ты на скорости простого цикла просядишь больше разницу между ними увидишь
Забавно, но из-за неявно конвертации между новым и старым, можно даже реально так заюзать ну конечно не стоит
https://play.golang.org/p/qSCvqQA-yyh
1. Горутины в го, после переключения (остановки и продолжения работы), могут возобновить работу в другом системном потоке. Собственно как решит планировщик.
Это исключает перегруженности одного системного потока, как например в js
2. Сам факт переключение горутин происходит после вызовов функций (то есть вызываешь функции и планировщик решает что-то).
3. Если нужно вызвать переключение (планировщик), например если работаете с цифрами в цикле и не вызываете функций, то можно вызвать runtime.Gosched()
Обычная работа:
https://play.golang.org/p/3Wq5eHzX-Yo
Работа с вызовом планировщика
https://play.golang.org/p/8FvLwQ4IqoS
Работа с эмуляцией блокирующего вызова (например запрос в базу данных)
https://play.golang.org/p/waSYlXHdy0h
Вряд-ли это самая полезная и важная информация. А что такое перегруженность системного потока, что так мешает Js, я вообще не понял.
>>59758
Переключения горотин происходят не только после вызова функций и ручного вызова goshed. Но вопрос интересный, так что предлагаю погуглить и разобраться самому.
Но как по мне, это скорее вопрос для собеседования, в работе ни разу не приходилось думать об этом.
Только нужно не смотреть их, а читать пдф приложения (хоть там и куча опечаток) и ходить оттуда по рекомендованнм ссылкам.
Нужно простое изложение работы горутин и чем они буду лучше, скажем в js. Надо показывать достоинства языка новичкам, а то что информация тебе полезна или нет, это малоебучий факт.
>вопрос для собеседования
Надо знать базис, иметь представление как работает все, причем тут твоя работа и собеседование.
При том, что эти обрывочные фразы - непонятное говно или гуглтранслейт. Про goshed вообще неправильно, ты не вкурил.
Статическая строгая типизация, компилируемый, быстрый, рождён быть многопоточных, быстрая компиляция, что там ещё?
И три ссылки. На интерективный тур и на два курса на курсере. И 50 оттенков го с хабра.
Все.
Если материал для новичков, то надо показать преимущества, а не грузить непонятными вырванными из контекста фразами.
Компиляция, статик типы...
Это скорее характеристики языка, а не фичи.
Про фичи как раз забывают (хотя бы что с сетью удобно работать или что куча батареек). А про корутины - они видят какую-то магию и им не понятна чем эта магия от других магий отличается.
Новичков - я имел ввиду в языке, а не людей учащих программирование.
Да, лично мне понравиламь первая часть.
Никаких рассусоливаний по основам, а сразу практический подход. И домашки прикольные были.
Пиздос.
>Дженерики и правда не нужны
1. А для map их зачем сделали?
2. Без дженериков у тебя внутренние структуры данных смогут работать только со ссылками. А так у тебя тот же []int хранит именно int, экономия памяти и перфоманс.
Именно потому что контейнеры у тебя уже параметризованы, дженерики тебе и не нужны.
Придут обязательно жабо кодеры и начнут заворачивать абстракцию абстракций и мы получим не поддерживаемый говнокод ~60-80% кода на жабе ничего полезного не делают
У тебя нет полиморфизма на структурах, больше как для контейнеров тебе дженерики и не нужны кроме базовых операций для числовых примитивов, типа сложения, вычитания. Но это можно и ручками написать.
Реальность:
Среднестатистический программист очень тупой, он видит дженерики у себя в жабе и думает они так же войдут в совершенно другой язык. Ему просто привычно, он верит что будет сидеть на прагматичном языке клепать абстракции и контейнеры, а не решать структурно задачу.
И да, дженерик, в жабе а больше я это слово нигде не слышал, у С/С++ другая парадигма, обобщенная, они очень бестолковые и мало что можно сделать из-за затирания типов.
>>59854
Ну и быстрая компиляция, мне куда важнее типов. Я не хочу ждать по 15-600с старта каждый раз, я готов писать руками или юзать приведение типов.
Самый лол, что ни раз видел в жабе, когда человек не справлялся с дженериками или не хотел вилкарды юзать с рекурсивными дженериками, тогда тупо прибегали к Object типу и юзал условно договоренность по типам. Это называют джентльменской типизацией, джентльмены всегда смогут договориться
>Именно потому что контейнеры у тебя уже параметризованы, дженерики тебе и не нужны.
Вот только тех же контейнеров тут map + array и все. Ни очередей (вставка/удаление в начало массива очень дорого), ни сортированных деревьев. Я конечно понимаю что для среднестатистического гофера префиксное-дерево адский матан и вообще не нужно, но есть задачи где это нужно. И приходится писать руками и постоянно кастить.
>>59853
> больше как для контейнеров тебе дженерики и не нужны
Это тебе не приходит в голову, где они ещё может быть полезен контроли типов на этапе компиляции. Но это не значит, что таких вещей нет.
>>59854
>И да, дженерик, в жабе а больше я это слово нигде не слышал
Ну с твоим кругозором все ясно. Дженерики это частный случай обобщенного программирования и оно есть практически во всех современных языках не кроме го понятное дело. Где-то оно очень мощное типа List, Haskel, Scala, C++, где-то не очень Java, C#. В Ada дженерики появились в 1977. И только в Го дженерики не нужны.
>что для среднестатистического гофера
Го юзаю меньше недели, на жабе я 10 лет. Писал такое и в таком, что тебе и не снилось. О чем ты вообще? даже пописал без дженериков немного
Еще раз для контейнеров есть interface{}, с той разницей что на жабе тебе каст компилятор пишет, а тут сам ручками. В итоге тебе обещают какую-то гарантию типов, но замен дают костыльное обобщение Одно говно, на другое разменяли, но второе чтят как святыну
Смирись - го специфически-статически типизированный язык. Ты же блядь к питонистами не приходишь и не тыкаешь что у них типов нет? Хера ты до го докопался? Golang != Java
И да, типизация не панацея и в реале ловит где-то 1-5% ошибок в коде. Кто писал сложный домен те меня поймут не редко сложный домен реализуют через динамические языки. Поэтому вообще какие-то тут претензии, кто и где вам голову забивает про панацею статических типов?
>C++
>Дженерики
Ой, иди уже отсюда, дженерики он в С++ увидел.
https://rutracker.org/forum/viewtopic.php?t=5655300
Вот хороший курс про особенности языка, от этого же автора есть книга, а мылору просто сделали видеометодичку по синтаксису и в конце мини-обзор как сделать простенькое веб-приложение.
Я его давно смотрел, но не помню "видеометодичку", а помню как с места в карьер предложили написать конвейерную обработку, потом учили пользоваться поофайлером и в дз предложили оптимизировать программу.
>Ой, иди уже отсюда, дженерики он в С++ увидел.
Вот же тупое мудило, даже фразу целиком прочесть не может
>Дженерики это частный случай обобщенного программирования и оно есть практически во всех современных языках
В С++ шаблоны, в Lisp макросы, в C# дженерики, и только в Go - хуй вам.
>Еще раз для контейнеров есть interface{}, с той разницей что на жабе тебе каст компилятор пишет, а тут сам ручками. В итоге тебе обещают какую-то гарантию типов, но замен дают костыльное обобщение
А что же Го не использует interface{} для map и array?
>на жабе я 10 лет. Писал такое и в таком, что тебе и не снилось
Жабацелоп в треде, всем присесть и два раза ку.
>А что же Го не использует interface{} для map и array?
Потому что может себе это позволить. У тебя уже просто походу бомбить, раз ты уже просто херню несешь
>только в Go
Зачем в го дженерики? Нужны ли дженерики в Python?
Почему не компилируется PHP? Почему в java нет функций? Почему пи равен ~3.14? Почему долбаебы продолжают воевать с ветряными мельницами??
У меня на яйцах растут большие черные волосы, а у го нет дженериков. Есть вещи, которые нам не нравятся в этой жизни думаю тебе бы тоже не понравились эти волосы, раз не нравится отсутствие дженериков. Поэтому хватит звездеть и пошли писать код на Go, который хорошо утилизирует ресурсы системы.
Слишком хорошо, gc съедает добрую четверть проца.
Как будто мало подходов для работы памятью, кроме сборщика. Ленивые мудаки.
Там и так все топорно, ты еще хочешь чтобы на руки программистов передали память. Кто хочет страдать, те идут в раст или с++.
Задания может быть там интересные, но подача материала просто мегахуевая. Лектор говорит очень сбивчиво, упуская кучу важных деталей, один из самых худших преподов, с которыми я сталкивался.
P.S. Можно ещё похвалить с дополнительные материалы в конце каждой недели, помню там штук по 10-20 ссылок на годный вспомогательный материал.
Ну тебе не обязателен партнер, ты можешь сам одеть кожаный костюм, взять плетку, закрыться в комнате и начать массировать борроу-чекер
https://tip.golang.org/doc/go1.13
https://github.com/gorilla/websocket/blob/master/examples/chat/hub.go
Почему бы не напрямую вызывать методы h.register(client) и т.д ?
> независимо
Погоди, hub.Run() запущен через горутину, writePump/readPump тоже. То есть каждный коннекшон асинхронен в i/o операциях. Или я ошибаюсь?
В данном примере никакой. Профит будет тогда, когда у тебя будут воркеры, горутины которые запущены заранее и периодически что-то делают и блокируются, ждут. Понятно, что такой горутине ничем кроме как каналом инфу не сообщить. В этом примерно ровно никаких профитов от использования канала нет, точнее он есть, поскольку run это воркер, и отдать ему сообщения иначе не выйдет. Однако вызвать а перед этим создать метод broadcast будет ничем не хуже, а даже лучше для читаемости.
а что такое "батарейки", которые "почти как в питоне?
А в каких языках ORM присутствует в стандартной библиотеке?
Самое интересное падение скалы относительно роста котлина
Есть один момент. Язык может уже накопить какое-то количество ответов, поэтому количество вопросов может уменьшаться.
Так же играет роль документация, на молодом языке чаще опытные программисты, которые будут нырять в доку, чем спрашивать. Спрашивают обычно ленивые копипаст-кодеры.
Данная статистика больше показывает насколько язык становится попсовым.
Не согласен
Потому что ты так сказал или есть прецедент?
Не вижу принципиальных преимуществ по сравнению с xamarin или react native.
Хайп, как он есть.
А что о них думать? Сырые.
Так и не получилось их заставить работать с приватными битбакет репами.
СердцеКирилл хочет в геймдев(мёртв в России), разум говорит целиться туда, где можно выйти на $200k/год и больше(facebook, google etc) и не жалеть потом.
Джава, С, С++, Го... всё не осилю же.
Я что-то подумываю менять работу и хочу подготовиться а все же знают, что на собеседованиях спрашивают то, что к работе отношения не имеет, так что придётся вспоминать и/или учить
Я спрашивал у знакомых девелоперов, они говорят, что в основном спрашивают про общие практики и архитектуру, потому что го слишком простой и каких-то тонкостей типа настройки JVM или арифметики указателей там нет.
Но у меня такое чувство, что на собесах должны спрашивать какое-то хитрое дерьмо типа сборки мусора, планировщика, как устроены хэш-таблицы внутри мапов, как работают под капотом строки и всё такое.
Я спрашиваю о многопоточном программировании в целом, примитивах синхронизации, о scheduler, как он понимает, что можно переключить активную горутину, о том, как устроены каналы.
Парочку вопросов из 50 оттенков го, вроде работы со слайсами. Банально, но некоторые валятся, все гошные wtfки нужно знать, их не так много, сравнительно с другими языками.
>их не так много, сравнительно с другими языками.
Мне говорили что у гоферов есть стокгольмский синдром. Многие костыли в го фатальны и их правда надо знать пишу на го и не страдаю стокгольмским синдромом
> сборки мусора, планировщика, как устроены хэш-таблицы внутри мапов, как работают под капотом строки
У меня это и спрашивали. Еще про устройство слайсов и каналов, работу с многопоточностью. Ну и про базы данных, микросервисы и тд
>Я спрашиваю о многопоточном программировании в целом, примитивах синхронизации
Что на эту тему почитать стоит? Или всяких гоферских конф хватит?
>у гоферов есть стокгольмский синдром
А то!
Ты попробуй их спросить почему в map[int]string дженерики есть, а у тебя только interface{}.
Ну вот честно, нахуя они нужны в чистом виде? Вот если подумать? Ну все равно же все пишут <T extends Somethingable> в 99% случаев дженериков, потому что лень отдельный интерфейс выделять, так почему не просто интерфейсами всё писать?
>map[int]string дженерики есть
Хорошо что скоро в школу. Это не дженерики, это параметризованный тип, как string или структура, это часть синтаксиса.
В го параметризовать нечего, кроме самописных контейнеров и перегрузки функций для нативных типов.
>>62946
<T extends Somethingable>
Такое не возможно, так как структуры не полиморфны.
Это еще одна причина, почему дженерики не нужны.
То есть, тупо негде особо их применять жаба дауну это трудно понять вообще
Не пугайте людей, тут могут быть питонисты.
>Хорошо что скоро в школу.
И в какой класс ты перешел?
>Это не дженерики, это параметризованный тип, как string или структура, это часть синтаксиса.
И снова наша любимая тема - обобщенное программирование и все-все-все. map[int]string - это обычный пример обобщенного типа раз уж слово дженерик тебя тригерит. Реализовывать его можно по разному, можно в виде type cast как в Java, можно генерацией специализации в рантайме как в .Net, можно генерацией на этапе компиляции как в Rust. Но концептуально это и там и там - обобщенный тип.
>Такое не возможно, так как структуры не полиморфны.
В Го не полиморфны, в других языках это не так.
>>62946
>Ну вот честно, нахуя они нужны в чистом виде? Вот если подумать?
Посмотри тот же Stream API, если бы там не было дженериков то call chaining там бы выглядел так уебищно, что это было бы просто не юзабельно.
>это обычный пример обобщенного типа
Если ты смотришь на машину, а видишь капусту, это же твои проблемы, да? Тебе сказали что это, дальше можешь сидеть в своих маня-шизо-фантазиях и видеть в этом дженерики, лол.
>В Го не полиморфны, в других языках это не так.
Ты уже близок к тому, чтобы постигнуть эту мысль.
Если в го структуры не полиморфны, а в других языках полиморфны, значит в го не может быть как в других языках. Да?
>И в какой класс ты перешел?
В твой.
>Если ты смотришь на машину, а видишь капусту, это же твои проблемы, да? Тебе сказали что это, дальше можешь сидеть в своих маня-шизо-фантазиях и видеть в этом дженерики, лол.
Если бы ты еще мог аргументировать, чем же map[int]string принципиально отличается от Map<int, string>
Но увы, у тебя в голове одна капуста.
>Если в го структуры не полиморфны, а в других языках полиморфны, значит в го не может быть как в других языках. Да?
Да, в Го есть проблемы с дизайном языка, но гошники упорно защищают их под лозунгом "ХХХ не нужно".
Стокгольсмский синдром как он есть.
>Если бы ты еще мог аргументировать, чем же map[int]string принципиально отличается от Map<int, string>
Вот тебе параметризированный тип, а вот тебе дженерик с джавы, найди отличие.
А ты не очень умён, да?
>Да, в Го есть проблемы с дизайном языка
Да всем насрать. Люди просто берут инструмент и работают с ним. Но находятся "ограниченные", которые пытаются воевать с языком, с которым даже не работают. Ты понимаешь что ты просто болен, ты еще больнее тех гоферов которые восхищаются языком?
В го порядком больше проблем, чем дженерики на 2-3 случая, ради тормознутой компиляции.
Не, в видео речь идёт уже не о примитивах. Примитивы, в своей основной массе - это средства, которые предоставляет пакет sync
Нет, сборщик мусора и общая неторопливость go делает его не лучшим выбором для дров.
Но в учебных целях, писали. К примеру: https://out.reddit.com/t3_9uorh8?url=https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2018-ixy-go.pdf?utm_campaign=Golang%20Ninjas%20Newsletter&utm_medium=email&utm_source=Revue%20newsletter&token=AQAAmCFoXc9yDGe9YnKsm4jgMLmK6lKDId9AVAiXsqng-Ozvsy5t&app_name=mweb2x
Сетевой драйвер с отличным перфомансом.
>А ты не очень умён, да?
Аргументы уровня /go/
>Но находятся "ограниченные", которые пытаются воевать с языком, с которым даже не работают. Ты понимаешь что ты просто болен, ты еще больнее тех гоферов которые восхищаются языком?
Я ради прикола накинул дженериков на вентилятор, даже не думал что гоферы так тригернуться. Мне лично в общем-то насрать, я Го учу по фану, всегда могу дропнуть и пойти ржавого учить.
я геймдизайнер почти
Еще один больной утиной болезнью, пришедший с жабы. Терпи малыш, осилишь ты го.
Прикольно.
bump
В любом скомпиленном бинарнике существует дополнительный код, который проверяет переменные окружения?
А ты сам как считаешь?
К школе приготовился.
Можно Машку за ляжку и козу на возу.
Сейчас эксперты /pr с линейки вернуться и ответят тебе.
С хера ли ему не быть популярным? Отличный и простой язык под свои задачи, умело под капотом утилизирует ресурсы железа?
Все валят в го. Джавистов/шарпистов задолбали шаблоны на шаблонах погоняющие шаблоны и тырпрайзности кода.
Скриптовики (питон, руби, пыха) устали от медлительности языков, отсутствия типизации, отсутствия нормальной многопоточности.
И го радостно и легко отожрал изрядную долю разработки.
Джавистов задолбала бизнес логика размазанная по сотни полу пустых классов, где простая логическая задача, становится сложной не сопровождаемой херней, которую хочется только обернуть в другой фасад и забыть.
Я надеюсь когда-нибудь это признают антипаттерном, ну а пока я вкатился в го, где те же задачи решают на месте и в лоб.
PS Что насчет котлина, то это та же жаба, точнее это сладкая глазурь, которая покрывает собой большой слой джава-навоза и от этого не легче.
Как вы меня задолбали, просто в край как задолбали, как видимо и пайка задолбали, как и core-левелоперов задолбали, что они решились таки добавить контракты.
Блять, если вы не можете писать используя интерфейсы, и вместо этого суете пустые, это у вас кривые руки и валите из профессии.
А кто говорил, что они пряморукие?
У меня пустые интерфейсы разве что в обёртке логгинга есть.
Почти везде специфичные интерфейсы.
+ кодогенерация
Я хуею с таких маневров
Ну так-то дохера вакансий щас, где бэк пилят с нуля на котлине, либо переводят с джавы.
Можно, чтобы котлин был вместо хтмл?
Дохуя это сколько? Когда я искал в прошлый раз в мск на hh, то было меньше 60. Плюс в большинстве вакансий он шёл как вспомогательный язык к джаве
1. Как резон переводит код с джавы на котлин, если там интероп? Чтобы тупо получить дополнительное время компиляции?
2. Какой резон пилить сейчас на синхроном языке бэкенд? Без асинк/авэйт?
И не надо говорить про корутины, которые получилось убого и поддерживаются 1,5 фреймворком. Причем тот же ктор - реально тормозит по теста. Не понятно это корутины или сам ктор.
Самое забавно, это вместо await в IDE подсветка асинхронных функций. Такая неявная привязка к правильной IDE.
PS Не вижу я роста энтузиазма на бэкенде, но вижу ослабление jvm языков.
Лол, может не будем?
>Почти везде специфичные интерфейсы
Тогда придется всегда юзать подобие геттеров и сеттеров для структур.
1. Очевидно, чтобы упростить время и увеличить удобство разработки. Тут вот все радуются от перехода на Котлин https://www.reddit.com/r/Kotlin/comments/bj5k4m/kotlin_for_backend_development/
2.
>Какой резон пилить сейчас на синхроном языке бэкенд? Без асинк/авэйт?
Зависит от задач и требований, лол.
>И не надо говорить про корутины, которые получилось убого и поддерживаются 1,5 фреймворком. Причем тот же ктор - реально тормозит по теста. Не понятно это корутины или сам ктор.
Москва не сразу строилась.
>Тут вот все радуются
Как показывает опыт, недалеких в разработке хватает.
К сожалению, опытные и профессиональные разработчики чаще молчат.
>Зависит от задач и требований, лол.
Синхронный веб, это старый высер больших html страниц.
Я бы тут 10 раз подумал между каким-нибудь спрингом и джанго. При учете что по производительности они одинаковы эталон жабо-кодинга, сделать фреймворк, который будет тормозить на хеллоу-вордах как динамико-дрисня, даже с JIT
>Москва не сразу строилась.
Ты видел их решение по корутинам? Это провал.
> Это же пиздец, иде-лок и в код ревью в каком-нибудь гитлабе нихуя понятно не будет.
А и не должно быть, у тебя код будет выглядеть "плоским".
В этом и есть фишка корутин, то что асинхроный код выглядит как синхронный.
То что нет async/await или yield это блять - самое меньшее что должно ебать разраба.
Лучше чтобы они под капотом все сделали хорошо.
Почему тогда они оставили подсветку в иде, если инфа об асинхронности вызова нинужна?
Неужели так сложно сделать нормальную обработку ошибок? Например, если я присвоил результат вызова функции с значением и возможной ошибкой всего одной переменной - автоматом возращать ошибку в случае ее не nil-овости?
Да нахуй ты никому не нужен без опыта, хоть на пыхо говне, хоть на просто goвне
Бинарник так-то содержит не только твой код, но и сам гошный рантайм: сборщик мусора, планировщик, всё такое.
>Синхронный веб, это старый высер больших html страниц.
Но щас до сих пор почти весь веб синхронный, разве нет? Даже если у тебя SPA, и не надо высирать на каждый запрос большие html-страницы, в большинстве случаев на бэке будет обычный синхронный PHP. И изначальная же цель Котлина afaik - заменить жабу (которая всем остопиздела) везде, где только можно, и на это у него вроде бы есть все шансы, че так все доебались до корутин, я хз.
зато весь фронт асинхронный
Ну давайте ещё вспомним о том, что большая часть интернета на вордпрессе.
Это говорит о том, что нам ничего кроме пыхи и ВП не нужно?
Уже много лет, мне не попадалось синхронных проектов. Везде микросервисы, асинхронные коммуникации через groc/http/очереди.
И без поддержки этого языками было бы грустно.
Как только появился аякс, появилась необходимость высирать не 100-300кб html кода, а маленькие json ответы. И тут пришла проблема синхронности, слишком жирно для очень частых запросов. Поэтому речь тут даже не про SPA. Тупо просто пришла другая эпоха. никто не запрещает тебе клепать синхронные сайтики в старой эпохе, но поезд уйдет все равно без тебя
>изначальная же цель Котлина afaik - заменить жабу
Нельзя что-то заменить, имея основу того что пытаешься заменить. Даже когда долго пишешь на котлине, ощущаешь ту же жабу. Иногда даже путаешься.
Котлин ничего не меняет, он просто делает чуть удобнее саму жабу а иногда, кстати, делает хуже Жаба и котлин это эпоха тырпразных монолитов, но эпоха ушла и в кровавый пришла эпоха микросервисов. Да, там жабу пытается втиснуться в это, но с виртмашиной, с интерпретацией байткода, с проблемным JIT, с 100500 настроек GC и виртмашины, и тотальной прожорливостью с жирнеющими фреймворками понятно что тут котлин тебе не поможет - это все не так просто.
Есть конечно индивиды, которые пытаются сову на глобус натянуть, но это скорее инерция технологий, а не развитие.
Отсюда популярность node.js и отсюда относительная популярность го, это языки новой эпохи несмотря на не лучший дизайн языков, у них есть киллер фичи, дающие им буст
Так что мысли эпохами и смотри в будущее. Как бы не были круты паравозы, их все равно заменили электровозы.
Если бы они сделали котлин на рантайме го, вы бы офигели от роста нового языка. Но, к сожалению, они установили его на паровоз.
Потому что могут, лол.
Есть же kotlin native, но интерес к нему нулевой, как я понял.
Эпоха микросервисов "пришла" только в твоих влажных мечтах.
Микросервисы - инструмент, который создаёт проблем не меньше, чем решает. А то и больше.
Это (по уровню идиотизма), примерно, как заявить, что на си больше никто не пишет, потому, что наступила эпоха джаваскрипта. И привести в пример какие-нибудь diy-приблуды на контроллерах ESP32, у которых внутри прошит забагованный и тормозной интерпретатор js.
>Отсюда популярность node.js
Популярность node.js оттуда же, откуда популярность js.
А потом десятки тысяч смузихлёбов перекатились на него с руби.
И забурлила дегенератская движуха.
>популярность го
Ну нахуй.
> Эпоха микросервисов "пришла" только в твоих влажных мечтах
Ну и пили свои монолиты на пыхе/джаве/все равно.
А микросервисы и серверлесс уже здесь и захватывают рынок, вытесняя формошлепов. Это очень славно сказывается на зарплатах.
>монолиты
>формошлепов
Т.е., на микросервисах формы не нужны?
Всё само работает?
Понятно.
А что там с транзакциями на микросервисах?
Или это слишком сложно, и ну их нахуй вообще?
Не нужно верить всякой хуйне, которую смузихлёбы пишут в интернетах, сынок.
У них там своя атмосфера.
Например, на днях организаторы отменили европейскую конференцию по php, потому, что туда записались только белые мужчины. О чём пафосно рассказали в твиттере.
https://2019.phpce.eu/en/
https://wptavern.com/php-central-europe-conference-canceled-due-to-lack-of-speaker-diversity
Т.е., для них diversity важнее технологий.
Ты сейчас втираешь примерно такую же дичь.
Я не пишу на пыхе, если что
Какое-то "врёти" получилось.
Микросервисы дают масштабируемость как по железу, как по софту, так и по человеческим ресурсам.
Превосходство нового подхода для кровавого очевидно.
Конечно Васяну одиночке это кажется сложным, да и джава маркетинг проел весь мозг.
Тяжёлый рантайм.
Я, конечно, знаю эстетов, которые и лямбды (awsные) на джаве пишут, а потом мужественно борются с холодным стартом, нехваткой памяти и замедлением работы.
Но как-то на го легче выходит.
Когда ты крупная ИТ компания и можешь под каждый инстанс сервак подогнать.
А еще холодный старт и слетающий JIT радует.
И все равно это синхронная херня получается, с синхронным БД драйвером. И не рассказывайте что где-то гитхламе лежит асинхронные драйвера которые использовали 1,5 человека
>> Когда ты крупная ИТ компания и можешь под каждый инстанс сервак подогнать
Эм.
Наоборот.
Когда ты мелкая - купил ещё пару серверов и все ещё долго хорошо. Растет на пару серверов в год и в ус не дуешь.
А на масштабе твоя программа съедает не ного больше памяти, и на кластер уходит на тысячи баксов больше в год.
Каждый запус jvm кушает 50-150мб озу только на jvm
Туда же попадает вся статика под классы и сам jit и мета информация по jit
Там же настраиваешь хип, который еще состоит из поколений.
Для всего этого нужно нормальное облако, чтобы запустить хотя бы 3-5 сервисов
Все твои бюджетные мечты улитают в копейку.
На го запускаешь с десяток сервисов, под размер одного jvm сервиса, приятно урчишь.
Хочу забить на конторы, которые нанимают народ из восточной Европы для экономии.
Пробовал собеседоваться в чисто иностранные конторы - до сих пор потряхивает, невероятно сложно общаться с теми, кто ожидает флуент инглиша. А я по грамматике едва upper-intermediate, с явным провалом в общении.
Кто-нибудь ищет/собирается искать работу? Давайте поможем друг-другу, соберём по максимуму вопросов и задач для интервью, и потренеруемся отвечать их на ангельском.
Фейкопочта:
WE'LL CALL YOU BACK
Мм? Ну ок. Скопировал в нужный.
Но я размышлял, что гоферам будет легче найти точки соприкосновения.
Бесполезное занятие, у всех разные вопросы. Плюс в европах сильный акцент на личных качествах, их реально сильно заботит как ты впишешься в коллектив, что ты за человек и т.д.
>Микросервисы дают масштабируемость как по железу, как по софту, так и по человеческим ресурсам.
От микросервисов до распределенного монолита - один шаг, ты даже не заметишь тот момент когда ты его сделаешь.
Ровно как и грамотно спроектированные монолиты могут прекрасно масштабироваться по железу а сейчас сервер с сотней ядер и гигов оперативы это вообще обыденность
А у нас не так же? Но это не значит, что техническая часть не важна.
И если рассказ, о том, какой ты пиздатый можно потренировать с преподом английского.
А вот погонять по матчасти может только другой программист.
>А у нас не так же?
У нас в первую очередь смотрят технические скилы, а уже потом смотрят на общечеловеческие качества.
В европе же зачастую общечеловеческие качества важнее, компании готовы взять среднего специалиста, но который лучше впишется в команду, чем профессионала про которого они не уверенны, что он впишется в команду. Т.е. речь идет не о том, что откровенных долбоебов не берут это и у нас так, но могут не взять человека в котором они сомневаются: "мы не видим вас частью команды" реальный слова из отказа.
>И если рассказ, о том, какой ты пиздатый можно потренировать с преподом английского.
Тренировать надо рассказ о своих интересах профессиональных и личных, о том что тебя мотивирует, очень любят вопросы про всякие проблемы на работе и как ты их решал, ну и традиционно "про хобби".
>А вот погонять по матчасти может только другой программист.
Тут момент. что спрашивать можно сильно разные вещи: одни любят CS вещи - а напишите нам эффективный алгоритм ХХХ, другие теоретические вопросы: чем X отличается от Y, кто-то любит живой кодинг. Мое мнение продуктивней будет походить по реальным собеседованиям, так ты и реальные вопросы услышишь и самое главное - перестанешь бояться собеседований и отказов.
Да, да, избавимся от наследия проклятого прошлого.
И напишем всё с чистого листа на ассемблере ноде жс.
Как-то так это себе смузихлёбы и представляют.
Самый лол, что на node js IDE (vscode) работает быстрее чем на java.
Это же какого говна надо навернуть чтобы так на статик языке тормозить.
Как мне нравится когда школьники (или взрослые со школьным умом) на каком-то внутреннем восприятие понимают некоторые вещи и потом выдают за непоколебимую истину.
Типа на джаве ИДЕ такая вся навьюченная, что старт самой ИДЕ и хеллоу-ворда занимает минуты. А мол vscode он типа блокнотика, вот поэтому и быстро.
На самом деле нет никакого прецедента стартовать мой хеллоу-ворд проект в java IDE пол дня и потом еще подтормаживать и поддергивать на каждый выпук.
Нет бро, джава тормозит и жрет все ресурсы аки слон, даже IDE это доказывают.
Эх, сейчас бы бенчмаркать языки IDE'шками.
Хеловорлд можно и в vi написать. Нет, если это твое основное занятие, то ок VS Code твой выбор.
Но если ты хочешь, что-то более сложное писать и чтобы IDE тебе и семантику проверяла и инспекции кода делала, и автодополнение везде в том числе в файлах ресурсов и конфигурациях, то VS Code тебе такого не обсепечит даже близко.
Как сконвертировать str[2], чтобы нормально русская буква распечаталась?
Ясно. А как называется аналог strings.Index() для рун? Что-то в документации не находится.
А я сделал. Ты потерпел поражения по всем фронтам.
У тебя же нет тредов, как ты параллельно собрался юзать
> если я запущу гошное приложение на системе, которая не поддерживает треды?
Видимо как сам напишешь рантайм го в этой системе - так и будет
время тупых вопросов, видимо
Плюсы, джава, пхп, питон. Котлин еще не пробовал (нету задач), но чисто внешне нравится больше гоши.
Он апогей императивности, в 2019 это, конечно, воспринимается диковато. Зато техническое исполнение хорошее.
Любой у кого есть хотя бы минимальный смшный бэкграунд легко втягивается.
А вот тырпрайзникам и любителям метамагии тяжело.
Горутины это юзерспейс потоки с переключением контекста, так что будут нормально работать, если не делать системных вызовов.
А что тут втягиваться? Такая императивщина - самое примитивное, что может быть.
Короче, нужен аналог сишной setlocale()
Дык в плюсах и джаве - охуенный синтаксис! Си-подобные языки в принципе самые красивые имхо.
Гугол не умеет в юзабилити, в принципе, вообще никак.
Если гугол что-то разрабатывает/покупает - можно быть уверенным, что это неюзабельная хуйня. И даже анти-юзабельная. Даже если она делает что-то реально полезное, основана на охуенных алгоритмах и т.д.
Про Goвно всё понятно, я думаю.
А теперь они купили Котлин, и вливают в него тонны бабла.
Я совершенно не удивлён - Groovy они бы хуй купили, именно потому, что он юзабельный и практичный.
Типо гугл это один человек.
>А теперь они купили Котлин
Кто купил? Ты уроки сделал?
Котлин скорее всего продвинули внутренняя команда джава-андроид разработки, никаких тайных смыслов тут особо нет.
Если же брать гугл как компанию в целом, то думаю этот котлин им нафиг не нужен.
С го вышло тоже самое, запили язык под какие-то внутренние нужды и зачем-то опубликовали на самом деле понятно зачем, чтобы активировать сотни бесплатных рук
Никто тут никогда не будет работать под высоконагруженными проектами и тем более не будет писать качественный высоконагруженный софт (потому что это еще уметь надо). 90% просадки вашего пет-проекта будет все равно на i/o базы данных и пинга в любых потоках. А 100.000к запросов не уместятся в ширину бюджетного сетевого канала.
Этот язык надо было публиковать в восьмидесятых.
мимо вебмастер со стажем
Не говори так.
>С го вышло тоже самое, запили язык под какие-то внутренние нужды и зачем-то опубликовали
Я общался с несколькими инженерами из гугла и спросил про основной язык разработки: мне сказали что разрабы предпочитают Java, а SRE - Go.
Маленькая выборка.
Я знаю гуглера, который пишет только на питоне (не ml)
Не знаю, но полагаю, что у Гугла огромная кодовая база на с и плюсах.
Была целая санта-барбара с системой поддержкой версии, они объясняли это тем что у них внутри компании монолитный подход и поэтому какой либо пакетный менеджер просто им "ненужон" и значит типа всем тоже, то есть проект вообще не планировался делать под общее применение. Я надеялся что язык будет развиваться после его публикации. Но оказалось всем насрать, проще было написать статью, почему руками обрабатывать ошибки это правильно, а наличие двух типов для строк и тупо сырой поток байт в строке - это вообще инновация и фича сиди страдай с рунами, хоть у тебя по дефолту utf-8 как бы
>разрабы предпочитают Java
Есть целая группа "программистов", которая кроме джавы больше ничего не знает и кроме джавы учить больше ничего не хочет. Тырпрайз есть тырпрайз - там логики нет.
Пишу так чтобы без скроллинга в бок читалось в гите. На треть экрана примерно.
Разрабов на какой проект поставят, то они и будут предпочитать
На С++ они точно пишут, все эти google test, google log не просто так появились.
>запили язык под какие-то внутренние нужды и зачем-то опубликовали
Тупо двощую. Тоже давно сложилось впечатление, что запилили под свои нужды, а потом набежали маркетологи и начали продвигать его как язык пригодный для всего на свете. И сами создатели языка этому уже не рады.
>Не знаю, но полагаю, что у Гугла огромная кодовая база на с и плюсах.
Это тоже, всякие системы хранения данных, базы данных и т.п. Но чуваки занимались сервисами для Андроида, жмыла и т.п.
>>69350
>Была целая санта-барбара с системой поддержкой версии, они объясняли это тем что у них внутри компании монолитный подход и поэтому какой либо пакетный менеджер просто им "ненужон"
И поэтому у них есть тулы которые в автоматическом режиме могут править код при автоматической миграции с одной верии либы, на другую.
>Есть целая группа "программистов", которая кроме джавы больше ничего не знает и кроме джавы учить больше ничего не хочет.
У кого, у кого, но у гугла выбор кого нанимать есть и таких бы просто не взяли.
Её там не найти.
Есть еще кто в треде, кто настрадался от го?
Идите в тред пхп и джса, и ройте о том, насколько они кривое говно.
Гошечка лучшее, что есть на рынке для вебсервисов.
>А что будет, если я запущу гошное приложение на системе, которая не поддерживает треды?
Сейчас из таких только васм
>Будут ли работать горутины?
И да и нет. Работать они будут, но не так как ты ожидаешь. Будет ситуация как с тредами в Питоне - в случае I/O ты получаешь буст производительности, а в случае cpu задач - резко хуже чем последовательный однопоточный код
>Будут ли они выполняться одновременно?
Нет, но в случае I/O это нормально
То есть, например, для if a > b { print(a) }
Никак.
Для этого и форсанули единый стайлгайд, что бы нормальные люди не ломали глаза о код "эстетов".
Блин, если внутри однолинейных фигурных скобок только один оператор, то лучше было бы оставлять как есть.
По идее это несложно реализовать: если внутри скобок не встречается точка с запятой, то оставлять в одну линию.
Лишние две строки - это слишком много для одного оператора в скобках. Они накапливаются, а я не хочу лишний раз скроллить экран, чтобы окинуть взглядом функцию.
gofmt у односточных func f() { return } фигурные скобки не меняет.
умпутун то за го, но у него случилась попоболь
>ройте
Новый зуммерски тупой сленг, или няша опечаталась?
То есть, получается, ты даже не тестировал? Ясно.
>быстрый
Ты не видел еще си, обосаца шустрый
проигрываю с долбаебов, которым принципиально исполнение функции в 100наносекунд или в 200
Это пиздецки важно.
Ибо от этого зависит сможет ли функция укладываться в 50мс в 95 перцентиле или нет
А так же сколько вы заплатите за вычислительные мощности - x или 2-3 x
В то же время, нельзя писать на всем, тут уже стоимость труда слишком дорогая.
И го здесь предстааляется оптимальным выбором между производительностью кода - производительностью разработчиков.
>Ибо от этого зависит сможет ли функция укладываться в 50мс в 95 перцентиле или нет
>А так же сколько вы заплатите за вычислительные мощности - x или 2-3 x
Что?
>стоимость труда слишком дорогая.
Ты начинаешь догадываться.
Но ты же не платишь программистами ни капли, зачем ты эту фразу воспроизводишь тут?
Я знаю, мне маркетинг не победить, но все же ты же понимаешь что твоя программа в среднем простаивает в файловом/сетевом i/o или запросе в бд, где-то 80-95% времени не веришь, иди протестируй и проверь.
Почему в начале 2000 все поголовно пересаживались на скриптовые языки? Наверное потому что раньше было лучше и железо производительно да?
Мальчик, давай я тебе расскажу, что в есть не только компании, где все крутится на одном старом целероне, а есть такие компании, которые арендуют серваков на сотни тысяч вечнозелёных в месяц.
И никто не будет рад тому, что из-за того, что твоя любимая пыха или питончик любят подумать, придется взять в два раза больше серверов.
Опять же, видимо у ИП рулона обоева так не принято, пусть посетитель подождёт десять минут загрузки главной, но есть продукты, которым необходимо успеть дать ответ в жёстко заданные рамки времени.
И если раньше, нам приходилось мириться с тормозами питона, или другую память как не в себя джаву, то теперь у нас есть замечательный го.
Да, раньше скриптовые языки работали. Знаешь почему? Потому что у интернета было полтора пользователя. А сейчас даже захудалый нах никому не нужный сервис должен стоять под напором 1к rpc, потому что теперь это средняя нагрузка.
>Почему в начале 2000 все поголовно пересаживались на скриптовые языки? Наверное потому что раньше было лучше и железо производительно да?
Накидайте еще айтишных теорий заговора, мне понравилось.
В го нет точек с запятой в конце действия и они расставляются компилятором автоматически.
>Программа на go не простаивает, а берет и выполняет другую горутину
А если её нет, го программа выдумывает другую горутину, лол.
Ты думаешь потоки работают как-то по другому?
>а есть такие компании, которые арендуют серваков на сотни тысяч вечнозелёных в месяц.
Но ты же не из это компании, давай ты не будешь говорить о том, о чем не знаешь, выдумывая такие вещи, что железо дороже времени разработчиков.
Это пища для ума, чтобы заставить задуматься над той самой мнимой производительностью, которую хотят достичь в своих проектах, местные фантазеры а ты не понял
Нет, я именно из такой)
Мы отдаем кучу денег амазону за то, что бы мы могли гибко масштабироваться под нагрузку и выдерживать sla.
И хрен кто согласится писать на джаве, потому что придется резервировать в разы больше памяти под контейнеры, вот кому это надо?
Так же мы не миллионеры, что бы позволить сервисам просто так жечт деньги, нужна максимальная утилизация процессора, и опять же у го нет конкурентов. (Ну кроме плюсов, эрланга, раста,... Но на них бы мы писали в разы дольше)
Я повторюсь, в твоём ИП на надо - ок, дуй свой кактус, а многим - надо.
Ты несешь херню неопытного фантазера, который каким-то местом связан с ИТ, это настолько очевидно, что мне даже лень писать опровержения к твоим фентази-тезисам.
Тебе надо работать над своих актерским амплуа.
Не пойму, ты Джун с завышенным ЧСВ, который краем уха услышал, что скорость не важна, и не разобравшись считаешь это абсолютной истинной?
Или наоборот, уже старый опытный маразмтаик, который не понял, что и веб, и нагрузки изменились, и что "перла под cgi" не хватает?
А может он бэтмен??
Тебе сказали работать над амплуа.
Когда встает вопрос железа, большие дяди о го даже не вспоминают, потому что jit еще рулит (см картинку), а го, не обкатанная игрушка. Твой го тормозит как синхронная джава, и может уделать только питон. что вообще очень странно для асинхронной работы
Но никто письками не мериться, потому как все масштабируется и всем насрать, что где-то кто-то у кого-то выиграл пару процентов. Самый главный вопрос - это качество либ и скорость с которой ты можешь взять эти либы и развернуть проект.
Блин, в го даже нет вменяемого пакетного менеджера, о какой эволюции качественного кода можно говорить? Те же js-ваннаби программисты на голову впереди я уже молчу что го это сплошной бойлерплейт сам по себе
go build
Мне кажется, ты тупой.
Значит папу сообщений назад, чистый перфоманс был не важен, а теперь важен? Клал я на этот список, потому как под "топ фреймворков" никуя нет инфраструктуры.
И вообще, фантазируй сколько влезет, все аргументы в пользу го я высказал, но видимо ты их даже осознать не можешь, Вт и брызжешь слюной.
В моей мухосрани таких нет, удаленно все требуют с опытом работы на го от года. Сам я джва года на джаве.
Как правильно формат указывать, чтобы верно выводилась дата в формате "yyyy-MM-dd HH:mm:ss"?
Если по остальным спорным моментам можно дискутировать, то с датами у них как будто один человек дорвался до исходников и сделал как ему удобно.
А никто не знает,может в каких-нибудь языках такое-же ебанутое форматирование дат?
Не могли же они сами эту дичь придумать.
Нет, гребу в офисе. Понимаю, что работать на удаленке это отдельный скилл, готов к этому морально.
Так работает. Но странно, что в документации нет полного списка всех этих магических констант.
Прям в духе js, надо теперь 100500 библиотек, чтобы тупо с датой норм поработать.
Как же теперь людям нормально скриптики писать?
Почему говна? Получилось как в баше и прочих скриптах.
А как в данном формате задать месяц не числом, а словом?
console.log("a" + + "2ch" + "yMoUs");
> Когда встает вопрос железа, большие дяди о го даже не вспоминают, потому что jit еще рулит (см картинку), а го, не обкатанная игрушка
Охуеть, необкатанная игрушка. Учитывая, что гошников сейчас нанимают вообще все крупные конторы. От Амазона и Гугла, до Яндекса, Озона и Авито.
Там всех нанимают могут себе позволить, потому что похер на чем микросервис, главное чтобы специалисты были.
Зачем дженерики для динамического языка? Там же поебать что куда суешь, пока не упадет
Чтобы тупо пострадать?
Тебе код писать или нуллы с еггорами сравнивать?
К питону имеет смысл подтянуть си и научиться шустрые модули писать для питона, но не как не нырять в клоаку малопопулярных экзотических языков.
Хз, я вижу тренд, когда сначала пишется монолит на php (потому что быстро), взлетает, а потом узкие места начинают выносить в сервисы на го. Уже куча крупных компаний пошла по такому пути. С моей т.з. го уже взлетел и поздно об этом спорить.
Ну вот столкнулись с ситуацией, когда осталось только масштабировать горизонтально или извращаться со всякими pypy/cython. Хотелось бы некоторые места переписать на чем-то более быстром.
машинное обучение
Я тебе раскрою тайну.
Крупные компании позволяют разным группам программистам брать интересные для них языки, дабы удержать специалистов на рабочем месте (чтобы им было интересно, "модно и молодежно").
Агрессивный маркетинг новых языков сильнее и поэтому случается так что кто-то где-то "ручку" (микросервис) написал на го, кто-то на котлине, кто-то ерланге, кто-то на кложе.
При учете что даже в пистоне уже есть асинки (ну и в других языках), страдать на го уже не имеет смысла вообще. Получилось так, что его основная фича стала уже не фичей и спустя несколько лет бойлерплейта люди устают от го (как это случилось и у меня) и лично мне кажется его будущее сомнительным.
Графики тоже показывают что он достиг определенного максимума. Его "бум" прошел, максимум он не взял.
Я как-то тоже был таким юным и глупым. Написал какой-то участок на сях (а все было на пыхе), в общем получился микросервис, который почему-то тормозил больше чем на пхп.
Оказалось что быстро писать на быстрых языках надо еще уметь (я делал си обёртки для классических пхп функций). Даже если я и получал прирост, он был незначительным. Оказалось что масштабироваться в ширь, куда эффективнее, чем экономить на спичках.
Только что вернулся с доклада от компании Gett.
Их история вкратце: написали монолит на руби, потому что руби был на хайпе. Потом начало притормаживать, начали выделять отдельные сервисы. Какой-то критический сервис работал плохо, решили переписать. На выбор был нода и го, го оказался быстрее. Начали писать все на го и переписывать старые сервисы. На данный момент у них 160 сервисов на го и 10 на руби.
А когда им не будет хватать го они на ассемблер перейдут? Что за гуманитарное масштабирование?
У тебя был удобнейший язык, пришел прирост трафика - ну так масштабируй. Там разница в производительности 2-10 раза (в реальном проекте 2-5), то есть если проект реально быстро растет, то так же быстро они и в го упрутся.
На самом деле понятно, это классическое хипстерско-гуманитарное программирование. Был на волне руби - они няшились с ним, тут пришел в моду го, они перебежали, но что бы заглушить ту боль, после рубина, они нашли радость в приросте производительности. Ждем теперь откровений от раста, там боль будет еще сильнее.
Не, там было что связанное не с масштабируемостью, а со стабильностью работы вроде как.
Короче, их перестал устраивать руби, и они выбрали го, пока что им нравится.
Если у тебя не асинхронный фреймворк (aiohttp или всякие до-asyncio'шные торнадо или твистеды), то на большинстве задач, которые решаються выносом функциональности в микросервис ты не получишь прироста производительности, а только увеличишь нагрузку на io
Также и
>извращаться со всякими pypy/cython
Есть смысл только на числодробилках, т.к. бридж между языками - это всегда дорого.
Напиши не хуиту.
Можешь поподробнее рассказать, где я не прав?
Стоит учить Го или Яву или ДжаваСкрипт? Есть опыт С++, 6 лет назад, первый семестр НЕ айти спецухи, сука, как же я его ненавижу.
Хочу:
а) иметь скиллы на черный день
б) зарабатывать миллионыя гуглил что Го не популярнен, но на МоемКруге, напимер, нужен Го/руби-мидл Рокетбанку с з/п до 200к(до?) - значит ли это, что Го постепенно набирает популярность?
в) возмоность заниматься интересными мне темамаи, в идеале геймдев
Гейдев это C++. Вкатываться туда больно и долго. Нужно хорошо знать весь стандартный стэк CS (архитектура компьютера, ОС, ассемблер, алгоритмы и структуры данных, компиляторы и т.д.), понимать collision detection и работу физических движков (я подчеркиваю: это два отдельных топика), устройство видеокарт и графических API, а также математику (линейная алгебра, само собой дискретная математика, и др.).
Это если ты хочешь прям программистом в гей дев, а не клепать хуйню на юнити.
Ну и да, учить придется не столько язык (в гейдеве многие используют C++ как C с классами по ряду причин), сколько все вышеперечисленное.
Для понимания того, как работает opengl, неплохо уметь писать рендереры без него хотя бы на уровне пет проектов.
А как я рендерить то буду вилкой?!!
бамп нахуй
Ты какую-нибудь статью подкинул что ли, а то пока что твое пиздабольство бессмысленное уровня сикпа не впечатляет.
Если указатели у указателей в го нет pointer arithmetic то нахуя их вообще сделали?
И второй вопрос
Почему вот так можно
i:=10
ptr:= &i
ptr = 10
А вот так нельзя
type person struct {
name string
age int
head person
}
dep[0] = person{
name: "head",
age: 10,
head: nil,
}
dep[1] = person{
name: "emp",
age: 10,
head: &dep[0],
}
*dep[1].head.name = "head2"
Зато можно
dep[1].head.name = "head2"
Если указатели у указателей в го нет pointer arithmetic то нахуя их вообще сделали?
И второй вопрос
Почему вот так можно
i:=10
ptr:= &i
ptr = 10
А вот так нельзя
type person struct {
name string
age int
head person
}
dep[0] = person{
name: "head",
age: 10,
head: nil,
}
dep[1] = person{
name: "emp",
age: 10,
head: &dep[0],
}
*dep[1].head.name = "head2"
Зато можно
dep[1].head.name = "head2"
Обосрался с разметкой
https://play.golang.org/p/IpSFG5jNFYy
Вот так нельзя в общем, хотя с интом работает
Указатели нужны, чтобы передавать по ссылке и по значению, что дает возможность в одном случае менять переменную,а в другом работать с ее копией
Го сам разыменовывает указатель, если используется точка (x.f).
Твой пример не работает, потому что ты разыменовываешь строку, а не структуру, Должно быть (*dep[1].head).name
Спасибо, понял. Почему я сразу не догадался интересно
Хочу уйти с ноды в нормальный язык
Если хочешь и в гейдев и в банки макакой, то очевидный сишарп
В уроках по микросервисам на Го нет ничего сложнее простейшего роутера на каком-нибудь Mux или Gin и вызова функций на сервисе с клиента через GRPC.
Никаких тебе CQRS, Event Sourcing, NATS, Envoy и прочих real-world вещей. Только очередной туторитал с CRUD Do-To.
Чтобы чему-то научиться, нужно работать в компании с опытными программистами
Как, впрочем. и с любой другой технологией. 90% статей на том же медиуме - скам, обсасывающий одни и те же хеллоуворлды.
> ,
> ,
Это тест такой? На СМЕКАЛОЧКУ???
Нюфаня, решил немножко вкотится и поговнокодить на Го.
И у меня недопонимание с присваиванием значения.
Сначала сам, чисто интуитивно, по аналогии с пистоном, решил присвоить куче переменных одно значение. Словил ошибку компиляции, и забыл об этом.
Сейчас читал книгу, из списка рекомендованных на главном сайте, и заметил пик 2 в примерах. Книга 2017 года.
Вопрос: Это у меня что-то с компилятором, или множественное присваивание одного значения убрали?
На втором пике exists типа bool принимает значение True, если в мапе был создан такой ключ, иначе false.
Power же принимает значение по ключу если такого ключа не было, то принимает значение по умолчанию в соответствии со своим типом, в данном случае 0
Считай, что ты присваиваешь результат функции с двумя выходными значениями.
> 0 false
У меня в первый раз не скомпилилось вообще, а сейчас да, вижу. Плохой пример был.
Значит я не могу в го
присвоить, куче, переменных, одно = значение
Ничего страшного.
присвоить, трем, переменным = значение1, значение2, значение3
Вообще, пример хороший, но мб надо было показать его как на пикрил
Имеется библиотека php для работы с соц сетью.
Нужно брать оттуда некоторые данные, и отображать на страничке.
Сервер на го. Как вообще это будет выглядеть? Подскажите
Да, заглушка. Ты её ставишь, чтобы не тратить память на новую переменную.
И как бы ему в его вопросе помогло переворачивание списков? Нет бы документацию языка почитать и реальный пет проект начать.
Ему нужно не умение переворачивать списки, а привыкнуть к языку. Пет проект для новичка будет тяжелой ношей и, скорее всего, он его забросит.
Как обычно: сколько людей, столько и мнений
Мое мнение такое, что пиление чего-то реально работающего держит интерес лучше, чем монтонные упражнения.
>литкоде
>>75729
>пет проект
Спасибо за советы.
Вяло пилю свою программулинку на питоне, по лингвистике. Со стандартными гуями и сторонней библиотекой для проигрывания аудио. Есть желание переписать её на го, чтобы сразу компилировать в исполняемый файл, не играясь с сомнительными костылями. Вот и решил пока поучить синтаксис
Утраиваю этого гофера, должно быть стыдно такие вопросы задавать. В любом гайде по го или тем более в туре это освещяется.
Получается, что так. Похоже мне придётся как то запускать php скрипты с сервера и обрабатывать их. Это вообще можно нормально реализовать?
Это скорее всего не нужно реализовывать таким образом. Если тебе нужен доступ к соцсети, то найди такую же библиотеку на го и используй её (ну или напиши/сгенерируй свою это несложно, если нужен просто апи клиент).
Но если бы у тебя гипотетически была библиотека, которая существует только и исключительно на php, не имеет аналогов и не воспроизводится на других языках - то стоило бы php-шные вызовы этой библиотеки обернуть в апи, сделав таким образом микросервис.
>стоило бы php-шные вызовы этой библиотеки обернуть в апи, сделав таким образом микросервис
Можно об этом поподробнее?
Если я правильно понял, то предлагаешь сделать микросервисы на пыхе и го и через запросы производить обмен данными? Похоже, что я какую то чушь написал..
До сих пор топчусь на месте. Понятно, что php скрипт должен возвращать данные в json серверу go. Но как запустить сам скрипт.. Скорее всего не туда я копаю как баран
Поднимешь микросервис с пхп на другом порту, обращаешься через http что непонятно?
Эх, спасибо
Тебе скорее в тред по php, но отвечу тебе пока здесь.
Классическая схема работы php - это в паре с сервером (nginx) и php-fpm, когда сервер удерживает коннекты и через php-fpm запускает, собственно, скрипты (гугли примеры, их дофига).
Если ты используешь докер (а если нет, то стоило бы), то можешь взять, как пример, вот это (статей и примеров миллион, но этот хотя бы выглядит адекватно) - http://geekyplatypus.com/dockerise-your-php-application-with-nginx-and-php7-fpm/
Если тебе нужно просто заставить это крутиться локально, без усложнений, то в php есть простенький встроенный сервер, вызывай `php -S 127.0.0.1:8000 ~/path/to/script.php`, а внутри script.php уже читай запрос и отдавай ответ.
Очевидно, стучаться из го будешь по адресу 127.0.0.1:8000
Спасибо, анончик
Работаю на крупную контору в Штатах.
Энтерпрайз, десятки микросервисов на Го (и не только)
Поддерживаю/допиливаю старые, пишу новые.
Думаю может стоит взять какой-нибудь со строгой типизацией, но пщ как и питон в душу запал.
В Го строгая типизация.
Нет, просто хочу расширить так сказать кругозор и подстелить соломы если вдруг питон будет загнивать. Или если вдруг захочу в тырпрайз, сисярп не хочу из-за M$, а жаву просто не хочу.
>>Хочу уйти с ноды
>Молодец.
Зачем уходить с ноды? Она рано или поздно станет для людей, а он к тому времени будет прожженным ветераном нарасхват.
дурачок, вбей свой код в wandbox.org
Ты либо становишься экспертом в одном языке, либо становишься "так себе"-спецом, но уже с несколькими языками.
Не верь в расширение кругозора, ресурсы, в том числе и время, всегда ограничены. То что ты мог потратить на углубление одного языка, ты тратишь на поверхностное уже нескольких языков.
Знание языка это не только его синтаксис, это знание его экзосистемы
Самый лол, что ты боишься судьбы питона, выбирая менее популярный язык с сомнительным будущем. Гуманитарный программист как есть.
В языке мало что есть. Нет даже перегрузки функций.
Из-за этого код сплошной бойлерплейт. О какой читаемости вообще речь?
Особенно читаем формат даты.
Это мне реально мешает читать код.
>А она нужна?
Да, когда функция делает одно и тоже, но с разными аргументами, я хочу иметь единое название и вменяемое API
do(String s)
do(Strint s, Int i)
А не
doString(String s)
doStringInt(String s, Int i)
Фатальная ошибка котлина совсем другая - его соновная платформа, т.е. JVM, в которой нет грин тредов, а большая часть экосистемы это блокирующее легаси-говно, а та часть которая ну хоть как-то написано с асинкам едет каждая на своём велосипеде, кто на netty, кто на akka, кто на новых корутинах котлина. Суммарно всё равно говно, поэтому котлин это десткая хуйня и игрушка на фоне го. при всех его недостатках.
Забавно что асинхронное программирование в действительности нужно местному анону в 1 случае из 1000
Не слушай этого мудака. Смысл в расширении кругозора есть, просто потому, что новые языки - это новые концепции, которые во-первых, дают тебе больше опыта (вдруг столкнёшься), а во-вторых позволяют взглянуть на то, как ты решаешь свои текущие задачи на своёс текущем ЯПе под другим углом, что повышает твои навыки решать их. Ну и с медицинской точки зрения очень полезно, изучение новых концепций означает выстраивание новых нейронных связей в мозгу, что повышает эффективность твоей умственной деятельности.
Го как раз неплохой вариант для "поиграться", потому как очень прост. Можно за неделю пройти тур и написать несколько приложений, уже достаточно для того, чтобы понять, как работают горутины, типизация и всё такое.
>новые языки - это новые концепции
Лол, какие? Решение одной и той же задачи, но с либами у которых другое название или положение аргументов?
Охереть расширитель кругозора. Это никак не развивает вообще, скорее засоряет мозги.
>Ну и с медицинской точки зрения очень полезно, изучение новых концепций означает выстраивание новых нейронных связей в мозгу
Ой, да у нас тут доктор наук. То что тебе не нужно, моментом обнулиться в мозгу. А новый язык, обычно, нужен тебе как пятое колесо. То есть, чтобы не застрять на уровне хелло-вордов, надо постоянно подогревать знания, по сути, просто так, потому что какой-то хер в интернете так говорит.
Не тратьте время на то, что не будете явно использовать в будущем, тем более на мало-популярные языки, нельзя запастись знаниями наперед, будете только программировать через вечный поиск и StackOverflow.
Котлиндаун, ты?
Ну да, плюсы, эрланг, питон, хаскель и го - охуенно похожие языки, ничего нового ты не встретишь.
постоянно нужно, на работе все задачи связаны с ИО и интеграцией различных систем. вообще весь веб и сетевые штуки - это сполошной асинк.
Зачем именно нужно, без это абстракции, типа "у меня тут веб и значит надо асинхронно". Реальный пример, когда по синхронному встрял.
>Расширить кругозор
>С++
Очень смешно.
>питон
Это просто эталон того, как скопировать из других языков и при этом сделать все тоже самое, но по своему.
как ты вообще рядом привел си синтаксис и говнопитон
>эрланг, хаскель
Нескучные языки подъехали.
Ты можешь теперь внятно объяснить зачем их учить, как тебе это поможет развиваться? Особенно это ненужная экзотика? Или мне засчитывать слив?
Да запросто, нужно записать что-то в кэш после обновления либо отправить письмо посредине какой-то операции. Либо Нет никакого смысла выполняить эти оперции синхронно, можно продолжать выполнять бизнес-логику или уже отдавать ответ.
Я, мне казалось, объяснил уже. Программирование - это построение логических моделей реального мира, на самом деле. Каждая новая концепция показывает тебе ещё один способ выразить что-то логически.
Сидя на питоне ты не поймёшь, как всё работает на низком уровне, пока не попробуешь си либо плюсы. Не поймешь, что именно делает за тебя сборщик мусора и зачем он нужен. Не поймешь, что делают планировщики и зачем они вообще нужны, пока сам треды не попрограммируешь.
Без тех же плюсов либо скалы ты не поймешь силы действительно развитого метапрограммирования и чего лишены гошники и многие другие.
Сидя на питоне и не попробовав го, ты не поймешь, что такое горутины и как можно мыслить ассинхронно, учитывая планировщик.
Сидя на питоне и не попробовав эрланг ты не поймешь, к примеру, акторной модели и в итоге так и будешь сидеть, думая, что ООП - это наследование (спойлер: нет, ООП - это про объекты, посылающие друг другу сообщения).
Сидя на питоне, и не попробовав функциональщину, ты не поймешь, зачем вообще нужны чистые функции и в чём красота чистого кода, что такое монады и как можно элегантно обрабатывать, к примеру, нулевые значения (и почему джава с её null'ами сосёт с проглотом).
Не посидев на джаве или котлине, ты не сможешь попробовать действительно хорошую реализацию rx и не поймешь, в чём прикол представлять бизнес-модель как потоки данных и насколько удобно это обрабатывать.
А вот поигравшись со всем этим, ты сможешь рассмотреть любую бизнес-задачу с разных сторон и отобразить её технически наиболее удачным способом (расширяемость, поддерживаемость и вот это всё). Подобрать язык для микросервиса, способ закодировать сложную бизнес-логику и так далее.
А если сидеть и всю жизнь сидеть на одном стеке, не высовывая голову из задницы, то в итоге окажешься рабом только одного способа мышления, потому что всё есть гвозди, когда в руках кроме молотка ничего никогда и не было.
При этом, понятно, что нельзя поизучать всё подряд и объявлять себя уберсеньором, ты можешь и должен выбрать для себя специализацию и развивать в первую очередь в ней, в глубину. Но также верно и то, что нельзя забывать о кругозоре.
На этом я умолкаю, потому что заебался повторять одни и те же прописные истины. Если тебе интересно дрочить только свою ссаную на самом деле нет, нормальная технология, если не объявлять её божественной джаву - то пожалуйста, играйся. Главное, новичкам мозги не засоряй.
Я, мне казалось, объяснил уже. Программирование - это построение логических моделей реального мира, на самом деле. Каждая новая концепция показывает тебе ещё один способ выразить что-то логически.
Сидя на питоне ты не поймёшь, как всё работает на низком уровне, пока не попробуешь си либо плюсы. Не поймешь, что именно делает за тебя сборщик мусора и зачем он нужен. Не поймешь, что делают планировщики и зачем они вообще нужны, пока сам треды не попрограммируешь.
Без тех же плюсов либо скалы ты не поймешь силы действительно развитого метапрограммирования и чего лишены гошники и многие другие.
Сидя на питоне и не попробовав го, ты не поймешь, что такое горутины и как можно мыслить ассинхронно, учитывая планировщик.
Сидя на питоне и не попробовав эрланг ты не поймешь, к примеру, акторной модели и в итоге так и будешь сидеть, думая, что ООП - это наследование (спойлер: нет, ООП - это про объекты, посылающие друг другу сообщения).
Сидя на питоне, и не попробовав функциональщину, ты не поймешь, зачем вообще нужны чистые функции и в чём красота чистого кода, что такое монады и как можно элегантно обрабатывать, к примеру, нулевые значения (и почему джава с её null'ами сосёт с проглотом).
Не посидев на джаве или котлине, ты не сможешь попробовать действительно хорошую реализацию rx и не поймешь, в чём прикол представлять бизнес-модель как потоки данных и насколько удобно это обрабатывать.
А вот поигравшись со всем этим, ты сможешь рассмотреть любую бизнес-задачу с разных сторон и отобразить её технически наиболее удачным способом (расширяемость, поддерживаемость и вот это всё). Подобрать язык для микросервиса, способ закодировать сложную бизнес-логику и так далее.
А если сидеть и всю жизнь сидеть на одном стеке, не высовывая голову из задницы, то в итоге окажешься рабом только одного способа мышления, потому что всё есть гвозди, когда в руках кроме молотка ничего никогда и не было.
При этом, понятно, что нельзя поизучать всё подряд и объявлять себя уберсеньором, ты можешь и должен выбрать для себя специализацию и развивать в первую очередь в ней, в глубину. Но также верно и то, что нельзя забывать о кругозоре.
На этом я умолкаю, потому что заебался повторять одни и те же прописные истины. Если тебе интересно дрочить только свою ссаную на самом деле нет, нормальная технология, если не объявлять её божественной джаву - то пожалуйста, играйся. Главное, новичкам мозги не засоряй.
Так и знал что фантазер и маня архитектор.
>Да запросто, нужно записать что-то в кэш после обновления либо отправить письмо посредине какой-то операции
Вешать таск задачи на потоки с бизнес логикой, я бы тебя уволил сразу (на том же го решается +1 микросервисом, в монолите отдельным потоком очередей с тасками, но лучше микросервисом).
>можно продолжать выполнять бизнес-логику или уже отдавать ответ.
Произошла ошибка, а клиент думает что все ок, но видит некорректный результат (или вообще ничего не видит). Чистая магия, которая противоречит юзабельности.
Маня архитектор как есть, выдумал прям на коленке.
Не нужны тебе асинхронные задачи, ты же смело можешь положить второстепенными вычислениями основные рабочие потоки.
>плюсов
> метапрограммирования
Тут лучше посоветовать посмотреть D, в плюсах от него ничего кроме боли и страданий получить не получится. Кроме 3-х часовой компиляции.
> скалы
Даже на плюсах это метапрограммирование легче поддерживать после написания, лол.
>и не попробовав го, ты не поймешь, что такое горутины и как можно мыслить ассинхронно,
Вот этот пункт ещё дырявый, сейчас почти во всех языках +- похожая модель асинхронности, только без встраивания в язык и с другой терминологией (вроде того же GCD в эпловских продуктах), гринтреды не новинка уже давно.
>и не попробовав го, ты не поймешь, что такое горутины и как можно мыслить ассинхронно,
обжс тебе махает рукой кстати.
Классический гуманитарный программист. Абстрактные мечты и ничего по делу.
>А вот поигравшись со всем этим, ты сможешь рассмотреть любую бизнес-задачу с разных сторон и отобразить её технически наиболее удачным способом
Как я смогу это сделать, если ты только что сказал, что в одном языке что-то есть, а в другом нету? Я могу знать как писать хеллоуворды на многострочных лямбдах, но если у меня питон, что мне делать?
Ты сам же себе противоречишь. И весь твой текст не техническое изложение, а просто творческий нелогичный выпук.
Ты упоролся? У тебя сервер принимает входящие соединения. На каждое соединение будешь выделять системный тред? А потом дополнительный треды на соединения до других эндпойнтов, например баз или проксирование. Пиздец
Кого бы ты там уволил, лол. Ты джун без опыта, если тебе про асинк и грин треды надо пояснять.
Прикинь тебе джун без опыта, не знающий про асинки по твоим словам тебе объясняет за правильную архитектору и что ты тупо не смог обосрался.
Это в двойне обидно.
Морально устаревшая хуйня, даже блять модуль в саб-директорию не перенести без очумелой ебли. Работать дальше хеллоу-ворлда с ним невозможно, да и не нужно, когда есть современный эликсир со всеми фичами эрланга и возможностью вызывать нативный эрланг код.
>Произошла ошибка, а клиент думает что все ок, но видит некорректный результат (или вообще ничего не видит). Чистая магия, которая противоречит юзабельности.
А лучше когда клиент висит десятки секунд в ожидании ответа и потом разрывает соединение по таймауту?
Если не понял почему не правильно, то лучше спроси, не стоит дальше высирать чушь и позориться.
Почему вообще у тебя клиент запускает таску которая идет десятки секунд??
Представь себе в вебе есть задачи посложнее перекладывания джсонов, и, зачастую, выполнение таких задач может занимать продолжительное время. Сервер в свою очередь как раз таки и предназначаен для обработки запросов от клиентов. Хотя может в твоем понимании веба сервер сам себе создает задачи и сам же их выполняет.
>Если не понял почему не правильно" то лучше спроси, не стоит дальше высирать чушь и позориться.
Если подъедут аргументы, то сниму шляпу и извинюсь, а пока я не услышал ничего кроме пустого пиздежа на кривом русском языке.
Тебе это и говорили, маняврятор ты джуновый. Тебе и сказали что нельзя ложить таски в поток с бизнес-логикой. У го нет никакой возможности отделить мух от котлет, кроме как еще микросервис подымать.
Сейчас ты берешь и мне рассказываешь то, на чем я тебя подловил, лол.
Ты не мне отвечал в том сообщении, шизик.
>Произошла ошибка, а клиент думает что все ок, но видит некорректный результат (или вообще ничего не видит). Чистая магия, которая противоречит юзабельности.
Я вообще тебя только насчёт этого спрашивал. Какие у тебя есть решения данной проблемы
Снова какие-то маневры.
Решение простое - по бизнес-логике отвечаем клиенту полностью.
Если в запросе нужно задействовать таску о которой пишем/не пишем и отдельно запускаем таску (микросервис который может возвращать статус).
В бизнес логике никакие числодробилки не юзаем, даже если ватемарочку добавляешь (4 таких запроса для 4 ядер и веб сервер сосёт полностью).
Асинхронное программирование не серебряная пуля, она имеет и плюсы и недостатки, положить весь тред, с тысячью корутин - нефиг делать
>Если в запросе нужно задействовать таску о которой пишем/не пишем и отдельно запускаем таску (микросервис который может возвращать статус).
Как это поможет решить эту проблему:
>Произошла ошибка, а клиент думает что все ок, но видит некорректный результат (или вообще ничего не видит). Чистая магия, которая противоречит юзабельности.
>В бизнес логике никакие числодробилки не юзаем, даже если ватемарочку добавляешь (4 таких запроса для 4 ядер и веб сервер сосёт полностью) и дальше пиздеж про асинхронщину
Это вообще к чему? Кто-то предлагал решать cpu-bound задачи с помощью асинхронщины?
>Как это поможет решить эту проблему:
Что именно?
Если например идет сохранение документа, то вешается ответ что идет процесс сохранения.
Нельзя же юзеру сказать что все ок, хотя на серваке сохранение не может произойти. Надо уведомить, пускай тогда сохранит хотя бы у себя или повторит позже.
Веб-морда всегда должна взаимодействовать с клиентом, даже если ошибка не у тонкого клиента.
Иначе начинается магия.
вот ето метаирония
Это копия, сохраненная 24 октября 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.