Для вката в Go читай:
- Донован, Керниган "Язык программирования Go"
- https://www.golang-book.com/
- книги из списка https://github.com/dariubs/GoBooks
- а также смотрим видео https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw
Пэкеджи можно искать тут https://github.com/avelino/awesome-go
Живем в ожидании Go2, пробрасываем ошибки, смеемся над джавистами, которые не могут жить без ексепшенов, дженериков и размазанной бизнес-логики, ждем, когда нам подвезут аналоги эксепшенов и дженериков
Я так-то так и делал, только в слайс сохранял, т.к. в задаче сказано
>числа могут содержать до 1000 цифр
Пока писал - понял где обосрался:
echo 102 201 | go run solution.go
У меня выдает 3
Как это вообще сделать? Хардкодить максимальное время в тестах?
А какое покрытие? Только основные горячие пути?
>2 пик
А что, в этом вашем Го нет дженериков?
>Задание E необходимо решать на Go. По техническим причинам, тестирующая система выдает ошибку во всех случаях (программа считывает слишком много или мало чисел, вызов функции блокирующий и т.д.) кроме:
>IL = Idleness limit = функция работает слишком медленно
>OK = программа верно работает
В го теперь вытесняющая многозадачность? Хейтеры sosnooley?
>>Для Python, PHP, Node.js, Java или C# разработчиков с опытом больше года.
пиздец, а я на ++ писал и куда бля мне теперь?
>пришел тимлид и отменил с++, Python, ruby и perl.
Охуенный тимлид, лол.
Ладно еще перловку переписать на нормальный язык - это вполне нормальное решение. Код, который изначально на плюсах написан переписывать на язык с GC - явно деграднул у вас проект, конечно. А отруби и змеюку на язык для РазНоРабочих - это вообще ход гения, просто шило на мыло, только при этом наевшись говна. Я бы хер забил на этот проект сразу же.
> Питон - за язык не считаю, его и так все знают, он что-то вроде помошника, а не языка.
Так все говорят, но как только начинаешь на собеседовании спрашивать что-то сложнее хелоуворолда - все сразу сыплются
Тоже самое и про баш говорят, но по итогу мало кто может написать нормальный скрипт
https://habr.com/ru/news/t/501876/#comment_21613874
Судя по трендам пик популярности Go пришелся на 2018 год. Пройдет еще пару лет и будет высокий спрос на специалистов способных переписать код с Go на любой другой нормальный язык.
К слову я год назад сам таких видел. Искали человека который с Go на Python все обратно перепишет.
Тут уже вопрос, если оно будет работать с приемлемой производительностью даже на Python, то в чём изначально был смысл писать на Go?
Как один из аргументов изначального написания на Go: «мы пишем на модняво-кучерявом языке» :)
> - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Какие ваши комментарии?оправдания
Обычно бывает так, что есть какому-нибудь старшему разработчику поручают что-то сделать, он выбирает платформу, на которой ему удобно, которой он сам хорошо владеет либо которую хочет получше освоить на практике. Так в проект попадает какой-нибудь язык, платформа или инструмент.
Так оно и крутится в зоопарке других похожих инструментов. C++ легко могли выбрать не за возможности, а за опыт работы старших разработчиков.
Поступать к ним лень, я и так все знаю. Но интересно, откуда нытье и здесь и на Хабре.
Необходимо написать функцию func Merge2Channels(f func(int) int, in1 <-chan int, in2 <- chan int, out chan<- int, n int) в package main.
Описание ее работы:
n раз сделать следующее
прочитать по одному числу из каждого из двух каналов in1 и in2, назовем их x1 и x2.
вычислить f(x1) + f(x2)
записать полученное значение в out
Функция Merge2Channels должна быть неблокирующей, сразу возвращая управление.
Функция f может работать долгое время, ожидая чего-либо или производя вычисления.
Формат ввода
Количество итераций передается через аргумент n.
Целые числа подаются через аргументы-каналы in1 и in2.
Функция для обработки чисел перед сложением передается через аргумент f.
Формат вывода
Канал для вывода результатов передается через аргумент out.
https://golang.org/lib/godoc/analysis/help.html
godoc -analysis=type
open http://localhost:6060/pkg/io/#Writer
Больше вопросов, а решение на три строчки.
Сказано, что функция должна быть неблокирующей. Но что она должна делать, если в каналах in1 или in2 нет данных?
И что она должна делать, если выходной канал out забит и не может принять данные? Есть вариант, конечно, внутри Merge2Channels просто вызвать ещё одну горутину, в которой и проводить все эти манипуляции. Может быть это и требуется.
Всё равно задание ни о чём, ну не три, а семь строчек.
>>1702278
Ладно, говнокод тут:
https://ideone.com/J5hhSO
Содержательны тут функции background_merger и сама Merge2Channels, остальные - тест-платформа и демонстрация, их надо выпилить.
Наверное это можно лучше написать, но я тот анон, который пока ещё не начал учить го, но хочу потратить на него пару недель.
Будет, да, по-хорошему надо просто независимо каналы кормить. Здесь была просто тест-платформа, проверить, что это вообще работает, в ТЗ не сказано реализовать тест-платформу, этот код по итогу надо просто удалить.
Короче ТЗ не очень понятно. Я не люблю эти олимпиадные ТЗ, под практическую задачу делаются практические решения. Может им надо, чтобы я сначала освободил каналы со входными данными, а потом уже делал вычисления. Тогда надо тупо создать два новых канала на n элементов, считать-записать в них. Но вопрос в том, какого размера n, может там поток на миллионы чисел. Я же не могу закладываться на то, что n будет небольшим.
А есть какая-нибудь онлайн тест-платформа?
А где эта тест-платформа?
Я бы тут несколько потенциальных проблем выделил:
1) n может быть очень-очень большим, заведомо не вариант запускать n горутин, тут проблема синхронизации и памяти. Может даже выделить канал на n элементов сложно.
2) блокировки входных каналов. Если попытаться сначала считать все n значений в буфер, то может ждать облом. Их там не будет, пока не будет данных в out.
3) если делать вычисления последовательно, в один поток, то можно не пройти по времени. Если параллельно, то надо синхронизировать вывод.
Я бы чисто из спортивного интереса поупражнялся, если бы платформа для теста была. Но сами курсы Озона мне нахуй не нужны.
Идея устойчивого хайлоад-решения в том, чтобы держать пул воркеров, штук 16, делать отдельные горутины, которые будут читать данные из входящего канала и складывать в буферный канал умеренной ёмкости. Воркеры будут брать данные из буферных каналов, считать, и выдавать результат в буферный канал с результатом. При этом дополнительно надо id-таски складывать.
Отдельная горутина будет читать данные из буфера результатов, ждать там i-ю таску, как она придёт, выплёвывать её в исходящий канал.
Но, блин, это продакшн извращения, их надо делать по ТЗ. Когда известно примерно, что там может быть в каналах, характер вычислений и т.п. Делать решение под неизвестную задачу несерьёзно. Особенно когда идёт набор на курсы по языку, на котором тебе это устойчивое хайлоад-решение надо реазизовать.
Короче, идея такая. Создаётся структура-"задача". В ней два инта и одноразовый канал, куда будет положен результат.
Создаётся канал задач, буферизированных, примерно по числу воркеров с запасом.
Есть горутина, которая слушает входящие каналы, берёт оттуда инты, и создаёт задачу, то создаёт одноразовый канал для результата, эти два инта туда запихивает. Помещает эту структуру в очередь задач, а одноразовый канал, дополнительно, в очередь каналов с результатами, то есть в канал типа
out_channel := make(chan chan int, 1000)
Есть горутина, которая слушает этот out_channel. Как только там появился одноразовый канал, она ждёт результат в этом канале. Этот результат и будет тем, что надо отправить пользователю.
Надо чуть подумать о ресурсах, или использованный одноразовый канал надо убивать, или, альтернатива, отправлять в специальную очередь для свободных каналов.
Можно попробовать это в коде реализовать.
В этом случае на выходе должен быть id задачи. Либо какая-то структура с входными значениями.
В принципе ты можешь считать несколько задач одновременно, но порядок выдавать корректный.
То есть, у тебя например первая задача тяжёлая, а остальные лёгкие. Ты считаешь тяжёлую задачу, параллельно лёгкие, складываешь результат в буфер. Как только посчитал первую задачу, выдаёшь её и сразу после результат остальных.
Это, на самом деле, довольно типовая вещь.
Это скорее из-за того, что надо как-то память выделять, языки вроде го не предусматривают лёгкого пути для безлимитных массивов.
В питоне можно тоже ограниченные очереди делать, правда не сделаешь очередь с нулевым буфером, хотя бы один будет элемент (0 = без ограничений). Пожалуй в этом принципиальная разница, в го по умолчанию очередь без буфера. То есть не совсем очередь, конечно.
ребята из @ozon_go_contest2020 сломали тест систему, смотрите историю про "чит"
инфы от организаторов нет
в описании недостаточно инфы о требованиях к выполнению merge2channels
смотрите примерные тесты здесь https://github.com/Gasoid/last-task-go-contest-2020/blob/master/main_test.go#L11
Нихуя не понял, что к чему. Разочаровался, что тупой
>если обмажитесь typescript-ом и линтером
В том и дело, что походу обычно не обмазываются. Вообще нода производит впечатление места, куда фронты приходят тяп ляп рад говно по примерам с доков сделать. У бекендщиков от этого карточного домика агрессия и зубы скрипят. Так то можно вообще на чем угодно сделать хороший бек, кто же спорит, но из увиденных поделок фронтов на ноде - этот шанс не велик. Впрочем я живого бекендщика (именно бекендщика с опытом, а не вчерашнего фронта) пока еще и не видел. Хз почему такое решение у тимлида кроме того, что он ранее чтото радом ебанул на ней и его теплое чувство не покидает, ну и нода по правда довольно шустрая, только это не критично важно для хайлоада само по себе.
>>1703645
Будет TS и линтер. Предлагает потому что у него несколько лет опыта бекенда на ноде и потому что тут много людей с опытом JS/TS, много бывших фронтов. В контору его взяли в прошлом году сениором и сделали тимлидом не так давно. Сам я околомидл и как раз перекатился в го из фронтенда.
на любой вкус? да ладно. он же пока в разработке. глючит иногда. да и в сравнении с классическим вимом нехило потребляет память. откуда так много хз. удалил его к чертям. поставил православный классический вим. всё пашет как швейцарские часы. знаешь что такое швейцарские часы? в жизни когда-нибудь видел в реале? я думаю что нет.
Всем привет!
Как обещали, высылаем следующую партию ответов на вопросы.
1. Поступить в школу могут разработчики из любого города и региона. На момент отправки этого сообщения на школу откликнулся 3931 человек. Приоритет при отборе мы отдадим тем, кто прошел успешно все этапы отбора и готов после обучения стать сотрудником Ozon, писать на Go. Программа обучения будет проходить онлайн до момента пока не наладится эпидемиологическая обстановка. Для тех, кто пройдет в школу, но проживает не в Москве, будет организовано обучение онлайн.
2. В школу позовем около 40 человек.
3. Мы ознакомились со всеми замечаниями относительно формулировки задач. Мы считаем тот текст условий, который опубликован в задачах на текущий момент исчерпывающим. С момента начала соревнования мы внесли комментарии про формат вывода по задаче Е, разъяснения о том, как проще решить задачу F. В дополнение к этому, мы внесли поправку в лимит по времени по задаче F – теперь лимит 1,5 секунды вместо 1 секунды.
4. Проанализировав ваши посылки по задаче Е, мы пришли к выводу, что тест по этой задаче составлен слишком обще и широко. В данном случае одного теста недостаточно. Некоторые пограничные ситуации принимаются как корректные. Ошибка в системе, которая выдается в ответ на решение участника не всегда предсказуема. Доработать это в режиме реального времени у нас нет возможности: есть риск потерять уже существующие решения. Это мы будем прорабатывать уже после завершения отбора. Сложности связаны также с тем, что Go новый язык для платформы, Make как компилятор был добавлен по нашей просьбе, чтобы обработать решения задачи на Go.
5. Участниками отбора выгружен в сеть из Я.Контест тест по этой задаче. Написано и активно обсуждается несколько алгоритмов решения задачи в чатах, на форумах и т.п. Мы будем расценивать любое решение с использованием сторонних скриптов как читерское и не готовы его засчитывать. Для справедливости отбора все решения, которые поступят по задаче «Е», будут проходить код-ревью дополнительно к уже существующим этапам отбора. До момента написания чит-скрипта нами было получено 32 корректных решения этой задачи. Отборочные соревнования не предполагали никакого пентеста системы, поэтому просим вас добросовестно отнестись к решению задач отбора. Мы по-прежнему принимаем решения этой задачи на Go.
6. Поступает много писем с просьбой ответить на вопрос "что не так у меня в коде" или дать подсказку, как решить задачу. Мы не можем давать ответы на вопросы такого типа, так как у всех участников должен быть одинаковый доступ к информации об условиях.
7. Просим всех, кто не указал в качестве логина свои фамилию и имя или почту, а также решил три и более задач, прислать свой логин на go@ozon.ru. В противном случае мы не сможем соотнести ваш результат с профилем участника.
До связи!
go@ozon.ru
Картинко отклеилось
Взялись за производительность прям.
Вот именно. Django в вакууме на VPS за 10$ сделает 40-100 RPS с одного инстанса Gunicorn. Дай бог чтобы у твоих проектов была посещаемость чтобы занять хотя бы 50% этих мощностей.
Если мы говорим о гигантах с RPS измеряемыми в тысячах, они используют asyncio+asyncpg, технологии уже как пару лет production-ready.
Так что тезисный ответ - скорость деливеринга фич на Python выше чем у конкурентов в этой нише, технология может успешно держать нагрузку в миллионы пользователей (смотрим опыт дропбокс, варгейминг и итс), остальное для бизнеса не важно. Не понимаю этих макак которые гонятся за хайпом, они небось, нормально программировать на прежнем своем языке так и не научились. Поддались на провокации "го круче", "го быстрее". Ну-ну...
>гонятся за хайпом
И кто-то же накручивает этот хайп, и окешивается неплохо.
>Django в вакууме на VPS за 10$ сделает 40-100 RPS с одного инстанса Gunicorn.
Коньпильнуть to C-code еще шустрее будет! Про всякие хайпы сразу забудешь.
>Дай бог чтобы у твоих проектов была посещаемость чтобы занять хотя бы 50% этих мощностей.
Ну так в основном лепят продукты на джанге/ларавелях/ноджс и не парятся, потом задумываются о оптимизации расходов на вычислительные мощности.
Я сделал, переписывайте быстрее, пока в Озоне места еще есть.
Это динамическая обработка динамически поступающих данных.
Есть два источника (chan1 и chan2) в которых асинхронно появляются данные. Есть общая функция (CommonFunc) которая эти данные асинхронно обрабатывает.
Есть код, который должен получить n-е количество раз данные из двух источников, обработать их общей функцией ,сложить результат и поместить его в общий канал (в данном случае роль общего канала выполняется ConcurrentQueue ).
В результате в основном коде тебе не нужно ожидать последовательного выполнения обработки поступающих данных, ты можешь делать всё что тебе угодно, обрабатывая данные по мере их поступления в общий канал.
Для сравнения, если переписать всё на синхронный код, то время выполнения увеличится в несколько раз, потому что сначала у тебя будут ожидаться данные из первого источника, потом обрабатываться эти данные, потом ожидаться данные из второго источника, потом обрабатываться, и только после этого результат суммируется и добавляется в общий канал. И так несколько раз, в зависимости от первого аргумента.
>Для сравнения, если переписать всё на синхронный код, то время выполнения увеличится в несколько раз, потому что сначала у тебя будут ожидаться данные из первого источника, потом обрабатываться эти данные, потом ожидаться данные из второго источника, потом обрабатываться, и только после этого результат суммируется и добавляется в общий канал. И так несколько раз, в зависимости от первого аргумента.
Прямо как в ноде, или асинх пайтоне, только модно!
>>1704468
Такое на любителя конечно. Но если подобного плана вакансия интересует, то предвосхищаться не стоит или на что-то рассчитывать, отбор большой, как получится так получится. Проще всего нихуа не делать.
>>1704045
>Какой редактор кода вы используете?
Geany, там вроде даже дебаг сей раньше был. Codelite для сей, а для Golang же вроде вообще что-то свое было реккомендед типа, не помню как называлось, ставил 5 лет назад, оно после установки начинает пэкиджи обшаривать.
nginx медленнее. На сях.
>>1704772
Exceptions это единственный zero-cost способ обработки ошибок. А всё о чем C++ это о zero-cost abstractions.
И та дикая ситуация, которую ты описал, все еще лучше, чем в питоне.
А в 2020 году, когда у нас есть быстрое железо, мы можем вместо ассемблерного вызова функции делать запрос по сети. И теперь кусок приложения можно написать на го, а кусок - на питоне, даже на котлине можно сделать компонент. Представляешь, как удобно?
Народ, кто офисоблядок и пишет микросервисы на Go. Можете кратко расписать что сейчас в сфере используется, как поднимаете все, чем оркестрируется зоопарк, какие пакеты часто используемые и в целом что желательно знать помимо самого языка?
Я сам разработчик и решил сменить направление деятельности и перейти на Go. Хочется что-то вроде структурированного roadmap, чтобы примерно понимать в какую сторону пердолить. Благодарю.
А в чем плюсы использования ОРМ?
Из минусов, я вижу следующие:
1) Сложные запросы проще написать руками, чем через ОРМ
2) Ты не знаешь явно, какой запрос отправился в базу
3) Иногда гораздо проще оттестировать запрос напрямую в базе, а потом его перенести в код, чем изначально пытаться его в код писать
То что отправилось в БД можно и посмотреть.
Если не используешь ОРМ, то бизнес логика размазывается между твоим языком и sql. Более того, ОРМ страхуют тебя от sql инъекций. SQL еще кстати достаточно плохо комбинируется. SQL позволяют А теперь представь, что у тебя большой объект со множеством ссылочных полей, селект получился сложный, со множеством джоинов и тебе нужно его упаковать в объект. Руками заебешься это делать.
https://stepik.org/lesson/345547/step/15?unit=329291
пишите в тг @Unholydk , о цене договоримся
>Если не используешь ОРМ, то бизнес логика размазывается между твоим языком и sql.
Очень плохо спроектированная бизнес-логика, не делай такую. >Более того, ОРМ страхуют тебя от sql инъекций.
Стандартный sql драйвер позволяет передавать аргументы через плейсхолдеры и этого достаточно. Если очень хочется, в ногу стрельнешь и через орм.
>SQL еще кстати достаточно плохо комбинируется. SQL позволяют
Вообще ничего не понял.
ORM только для этого не нужна. Ручками пишешь интерфейсы и реализации репозиториев, внутри собираешь запросы через pgx и sq. Всё, у тебя есть логика хранения данных, инкапсулированная от бизнес-логики (которая вызывает функции вида FindByID, UpdateByID, DeleteByXAndY) и при этом логика хранения кристально чиста, в отличие от этих ваших orm'ок, в которых для того, чтобы построить эффективный запрос иногда приходится бороться с самой orm'кой и всё это ради преимуществ, что не нужно писать руками save/load функции (а они пишутся за 15 минут).
> Отлично! Покажете, как на классах (без дженериков) сделать параметрический полиморфизм? После этого можно будет посмотреть на то, как на классах сделать тип, например, вектора, где длина вектора была бы видна в типе, попытка zip'ования двух векторов разной длины привела бы к ошибке компиляции, но при этом можно было бы создать вектор произвольной длины, пришедшей, например, по сети или считанной из файла во время выполнения программы.
Это, конечно, достаточно абстрактный пример, но он отлично иллюстрирует то, что называется системой типов и что с помощью этого можно делать.
Смотри, во-первых, векторы или там координаты - это вполне прикладные штуки, например, будешь работать с геокодингом (для бизнесовых нужд) - столкнешься, как миленький.
Во-вторых, система типов позволяет тебе фиксировать требования к модели на уровне описания типов и их поведения. Неправильно написанный код у тебя просто не скомпилируется. Это напрямую ведет к повышению надежности твоего кода, поскольку защищает от целого ряда ошибок (не всех, к сожалению, но что поделать).
Разница примерно такая, как между слабой и сильной типизацией. Ты же (надеюсь) не будешь спорить с тем, что код на го надежнее, чем код на каком-нибудь pure javascript? А почему так? А потому, что дополнительное описание ограничений на уровне объявления типов или поведения не даёт тебе случайно передать name вместо age и не заметить этого локально, потому что name у тебя пустая строка и она молча закастилась в 0.
Опять же, простой пример, enum'ы, которых в го, к сожалению, нет. Представь, что у тебя есть какой-нибудь userType и он может быть admin либо general. И в каком-то месте ты, конечно, будешь проверять переменную на возможный тип, конечно, сделав это через switch.
Получится у тебя как-то так:
https://play.golang.org/p/KSAcycYo7xi
А потом у тебя появляется userTypeModerator и тебе придется вручную осматривать весь код на предмет того, как он работает с этим типом и везде ли ты всё учёл! И если ты пропустишь функцию Foo, то ты узнаешь о том, что пропустил её в лучшем случае на тестах, в худшем - на проде.
Напоминает темные времена php, когда переименовав поле у класса ты не мог быть уверен, что оно переименовалось везде и приходилось просто грепом искать по имени поля по всему коду и хорошо, если имя было уникальным, а не какой-нибудь name.
А в случае с enum'ом, то добавив новое значение в enum ты не сможешь скомпилировать код, пока не добавишь во все места switch'а по типу обработку этого нового значения.
В очередной раз кто-то обнаружил, что в го нет того, что есть во всех нормальных языках?
Уже есть: https://killedbygoogle.com/
Это хуйня синтетическая, где сверхразумы зачастую просто отдают один и тот буфер с текстом. Т.е. от реальных задач это далеко прости пиздец, и на реальных задачах сишарп выебут. Вот как будет полноценный аналог того же nginx или haproxy со всей функциональностью - тогда и поговорим, а пока нахуй катись со своей CLR-залупой.
>Напоминает темные времена php, когда переименовав поле у класса ты не мог быть уверен, что оно переименовалось везде и приходилось просто грепом искать по имени поля по всему коду и хорошо, если имя было уникальным, а не какой-нибудь name.
Ты там из блокнота кодишь?
https://www.typescriptlang.org/play/#code/KYOwrgtgBASg9gG2FA3gWAFBW1AggEQFkBJAOQBpMcpCB5fAURlwBVaZKscB6bqAVQDKTTgF9MmAMZwQAZwAuUAJazcAEwhKQUALxQAFACdEwAFywTASl0A+VFWyyA7kvmSAFgeNJr6LtWxJAENZZHgkADoCElJTBwCAw2B5MENteUMwYHiA4NCLSLpGZjYYOP8EnCSUtKgAMyCEUIkK6jVgBrAEeXLK6mk5RQB9cxBgADdgQ10ob2zWyvl3YycoMdWGQ2NDfQADYhBxxqU1WZNzABIUcOAAbSGAXVFdyxzxDFEgA
Из блокнота, ха.
У меня IDEA несколько раз цепляла лишнее при переименовании, потому что какой-то идентификатор глубоко в xml-файлах показался её похожим, и из-за этого приходится перепроверять каждую "исправленную" строчку. Надёжнее переименовывать руками. И это ещё в статически типизированной джаве, что там в пхп было бы, страшно представить.
мимо
Блять, у тебя есть функция на php:
```
function foo($a) {
return $a->name
}
```
И у тебя есть класс User с полем name. Я хочу name переименовать в first_name. Рассказывай, как IDE здесь мне поможет.
Предвидя вскукареки на тему типизации - оно не всегда работает, потому что ебаное легаси и ебаные фреймворки из нулевых.
В том же го так нельзя сделать by design, даже пустой интерфейс тебе придётся закастить к типу, чтобы достать из него поле (есть варианты через рефлексию, но это уже конкретный говнокод и так к счастью никто не делает).
Есть значит структура Tachki с разнородными полями и даже с другими структурами в полях, возможно рядом с полями стоят их названия в соответствующих таблицах. Нужно, чтобы командой LoadmyShit(Tachki) структура загружалась в БД, а командой DownloadMyShit(&Tachki) заполнялась из БД.
Например, sqlite: https://github.com/mattn/go-sqlite3
Ну а в своих функция делаешь запросы, считываешь записи и заполняешь структуры.
func (m Granny) Dosomething {}
func (m Dad) Dosomething {
m.Granny.Dosomething()
}
func (s *Son) Dosomething {
m.Dad.Dosomething()
}
Вместо наследования тут встраивание (embedding):
https://medium.com/german-gorelkin/embedding-in-go-6739e46c1be1
Ну а раз такая фича есть, значит, говновей.
> Пошел вот сознательно в одну компанию, поближе познакомиться с С++ так сказать
> Помимо специфичексих вещей проекта (ну, энтерпрайз писать на плюсах это так себе сама идея) есть и несколько общих выводов
> В целом получил что хотел. А хотел собственно спуститься еще чуть ниже по стеку (начал с джавы -> go) и на шкуре почувствовать что в свое время достало авторов го в этом самом ++ И да, этого сполна...
> Потрясающая неэффективность разработки. Это про то что плюсы хороши и плохи одинаковы для проектов любой сложности ну это утрированно. Но их как языка в общем не существует есть плюсы стандарта Х/Y и даже уже, компании А/Б, со всем своим - стектрейсером, шедулллером, базовыми типами и тд. Знать с++ абстрактно хорошо непонятно можно ли вообще. Время компиляции, дааааа.....
> UB это злосчастное. Имхо это такая отмазка сказать "не знаю". (кто не в курсе - undefined behavior). шаг вправо-влево - "UB" иди кури бамбук. Ну да формально выход программы без джойна всех тредов это UB. Но в среде c++ это такая волшебная мантра которая обозначает окончание беседы и задумчивое смотрение вдаль. А откуда тут UB когда компьютер детерминисткая железка вообще? В го (бинг) нет UB, в java нет. Если копнуть рантайм того же го - ьам вызов сисколла в главном треде закрывающий все треды процесса и даже некоторый цикл, чтобы процессор стек не распахал, и вуаля - и нет UB, надо подумать просто, и сделать. Так и в плюсах можно, но у плюсовиков кажется рефлекс - UB - и дальше не думаем. Очень расстраивает(
> Импенетрабельная (извините) стандартная библиотека с этими шаблонами и принципиальным кажется отсутствием документации в коде; язык с++ не только сложный но и не способствующий изучени. Так копошишься на своем уровне без особых шансов понять как оно внутри там устроено. + Деление backend/frontend (llvm) добавляет - очень на джаву похоже
> После этого посмотришь опяь на го - все чистенько аккуратненько, внутри сделано чаще всего good enough в 99% (и в такой же степени лучше чем сам бы пытался сделать с нуля) и просто работает. Кому не хватает сложности в го, вместо того чтобы тянуть рантайм DI и прочую магию энтерпрайза - займитесь плюсами немного, там этого хватает. И возвращайтесь в го, писать чистый понятный код
я не программировал на плюсах профессионально, но много лет назад когда интересовался, мне показалось, что С++ - это язык для написания языка программирования, а не программ. Потому, что и язык, и подход к разработке сильно меняется в зависимости от подключения Qt или Boost. Ну ладно, язык не меняется, но эти библиотеки вводят столько абстракций, что уже кажется, что это другой язык.
Плюс выбор компиляторов: гцц, борланд, майкрософт, кто-то еще. Думаю, что если выучил весь С++ - ты бог. Потому, что допускаю, что в разных компиляторах и может быть разная реализация стандарта и свои баги и особенности напополам с UB.
Да вот недавно на хабре изливали боль:
https://habr.com/ru/post/497114/
Еще интересно: плюсовики индифферентно относятся к го, но при упоминании раста бросются говном, как джависты-котлинеры в этом треде.
> вуаля - и нет UB, надо подумать просто, и сделать
Если так рассуждать дальше, в плюсах вообще нет UB. Сначала думаешь, что хорошая идея - дать мусорное значение неинициализированной переменной в качестве seed рандомайзера, ведь оно непредсказуемое. Или что можно полагаться на поведение, когда после максимального значения инта идёт минимальное.
Ну а потом у тебя выполняется и if, и else одновременно. Или printf ничего не выводит.
Не представляю, как на плюсах пишут большие проекты. В плюсах и джуны, наверное, как сеньоры в остальных языках.
> Сначала думаешь, что хорошая идея - дать мусорное значение неинициализированной переменной в качестве seed рандомайзера, ведь оно непредсказуемое.
Ни один нормальный разработчик так делать не будет, как раз потому, что никто не может гарантировать случайность. Непредсказуемое тобой, не значит случайное, нужно случайное значение - бери seed по правильному адекватному пути, от времени и прочих вещей.
> Или что можно полагаться на поведение, когда после максимального значения инта идёт минимальное.
Да же фигня, ну кто так будет делать? Переполнение переменной - зло и полагаться на то, что какая-то магия там что-то сделает есть идиотизм. Явное всегда лучше неявного, если хочешь циклический счётчик - сделай блять условие нормально.
Извините, накипело. Сначала пишут эталонный говнокод на чистой магии, он становится неподдерживаемым, а потом такие "мы сеньоры, пойдём понтоваться на конфах"
> Ни один нормальный разработчик так делать не будет
Нормальный разработчик не будет пытаться строить рассуждения на основе поведения UB, показавшегося ему рабочим, никогда и ни при каких условиях Он скажет: "здесь UB, и точка. Нужно переделывать". Даже если это сначала кажется безобидным.
Это вообще и всегда, бесприменительно к языку. "Магия = плохо", эту истину нужно высечь на жопе у каждого джуниора, чем раньше, тем лучше.
Говоря же про го - при всех своих недостатках (а они у него есть), он ну очень явный. Никакого UB. Никакой магии аннотаций. Никакого рантайм-патчинга чего-нибудь. Никакой динамической линковки. Даже исключений нет, ошибки явно возвращаются, как значения. Всё максимально явное, что написал - то и работает, чего не написал - то не работает. Идеальный язык для энтерпрайза, чтобы любой джуномиддл сразу садился писать рабочий код, не разбираясь во всяких "сложных штуках". Да, подход спорный, но если тебе не нравится - не пиши на го, всё просто.
А, да, про конструкторы. Тот же `new` не нужен, надеюсь его в go2 уберут. Остаётся var для нулевого значения, `:= сырое значение` для, собственно, сырого значения и make если нужно заранее задать размер мапы, слайса или канала (который на самом деле тоже слайс, кстати).
В го есть совсем немного вещей, которые дают избыточную сложность, это ёбаные слайсы (имхо, очень зря особенности их реализации вытащили на прикладной уровень, эталонная хуйня для собесов онли), хуйня с интерфейсами и nil (когда nil'овый интерфейс != nil), невозможность мутировать поле структуры, лежащей по значению внутри слайса или мапы и может ещё что-то.
Сравнительно немного, если посмотреть на другие языки.
> невозможность мутировать поле структуры, лежащей по значению внутри слайса
Чо ты несёшь, поехавший?
https://play.golang.org/p/loZ-RUPvJDK
https://go.googlesource.com/go/+/8157a31deb75768b5998ed925c15bf20241a3f18
С одной стороны нейминг мало что значит, с другой - очень плохо, что дикари и им сочуствующие могут так просто заставить крупные компании рефакторить свой код, просто по тому что им не нравяться какие-то слова. Современное западное (в широком смысле) общество болеет, и это - всего лишь один из симптомов. Олсо, аналогичное изменение 2 года назад сделал Python
Ещё и Rus Cox лайкает ани-республиканские твиты https://twitter.com/_rsc/likes?lang=en, куда вообще сообщество катится
Надеюсь в го нет расистских супермасистских архитектур вроде Master/Slave? Работал в эмбеддеде, где эти слова встречаются в каждом первом проекте, и могу себе представить боль прогрессивных смузихлебов от поделок бородатых махарайщиков в свитерах с оленями.
у кого-нибудь есть картинка в хайрезе?
На моей памяти это уже третий 10 тред. Неужели все хейтят это до сих пор?
и я увидел там очень много знакомых решений, которые используются в проекте над которым я работаю.
Вот хочу узнать, может есть какой-то ресурс или книги которые просто маст рид по лучшим практикам и архитектуре го приложений?
Олсо, прочитай https://habr.com/ru/company/otus/blog/503918/ - тебе при разработке может быть удобным replace
неовим мне не зашел, vim-go тоже не пользуюсь, потому что не только на го пишу
если интересно, то плагины только эти стоят и все:
https://github.com/editorconfig/editorconfig-vim.git
https://github.com/tpope/vim-commentary.git
https://github.com/natebosch/vim-lsc.git
https://github.com/tpope/vim-fugitive.git
https://www.youtube.com/watch?v=Dq0WFigax_c
Нет, не мешает, просто добавляет кучу функционала, которым я не пользуюсь и не переиспользуется
а vim-lsc универсальней - он делает линтинг, автодополнение, навигацию по коду (собственно все нужные мне возможности lsp протокола) для любого языка, для которого в конфиге есть мапа "расширение файла" => "lsp executable"
Сколько не пробовал - IDEшки дают ту же кучу возможностей и даже больше, но интуитивнее (потому что специально дизайнились под то, чтобы быть IDEшками) и при этом их не нужно настолько допиливать напильником.
А вообще удачи превратить вим в полноценную IDE, где и базу можно посмотреть, и гошный дебаггер интегрирован, и тесты можно запускать, и рефакторинг проводить, и линтер у тебя встроенный (можно от одного варнинга к другому прыгать и IDE даже сама будет подсказывать тебе варианты решения варнинга) и тп.
Да даже просто гошный дебаггер. Из консоли с ним работать адски неудобно, а в то, что в виме есть нормальный гуй для дебаггера я, извините, не верю.
Короче, лично я за все мои 10 лет "программирования" ничего луже продуктов JetBrains ещё не встречал, хотя пробовал кучу разных штук. кстати никто не знает, они платят что-нибудь за рекламу их софта на дваче?
Сколько не пробовал - IDEшки дают ту же кучу возможностей и даже больше, но интуитивнее (потому что специально дизайнились под то, чтобы быть IDEшками) и при этом их не нужно настолько допиливать напильником.
А вообще удачи превратить вим в полноценную IDE, где и базу можно посмотреть, и гошный дебаггер интегрирован, и тесты можно запускать, и рефакторинг проводить, и линтер у тебя встроенный (можно от одного варнинга к другому прыгать и IDE даже сама будет подсказывать тебе варианты решения варнинга) и тп.
Да даже просто гошный дебаггер. Из консоли с ним работать адски неудобно, а в то, что в виме есть нормальный гуй для дебаггера я, извините, не верю.
Короче, лично я за все мои 10 лет "программирования" ничего луже продуктов JetBrains ещё не встречал, хотя пробовал кучу разных штук. кстати никто не знает, они платят что-нибудь за рекламу их софта на дваче?
когда твой сервис становится немного сложнее того, чтобы поднять локальную бд и стартануть сам сервис, все эти плюшки с запуском тестов из иде и дебаггером очень сильно теряют свою ценность, потому что в конфигурациях с кубом/докером и развесистой инфраструктурой все становится только сложнее
и, я осознанно не делаю иде из вима, тк мне нужны только git blame, и навигация по коду с базовым линтингом; все остальное я из консоли/CI в состоянии запустить
ps пять лет уже живу без дебаггера в абсолютно разных экосистемах, полет нормальный, код лучше писаться стал
>плюшки с запуском тестов из иде и дебаггером
Не теряют. При создании какого-то сервера ты всё равно локально только юнит-тесты запустить можешь, их и надо пилить в иде. Дебаггер вещь просто незаменимая, я всего полгода назад узнал, что есть программисты, которые им не пользуются, и я не понимаю, как и зачем вы живёте.
У меня развесистая инфраструктура в кубе, это не мешает мне запускать один сервис локально, подключать его к тем, которые в кубе и ставить брыкпонты, чтоб поотлаживаться
> я всего полгода назад узнал, что есть программисты, которые им не пользуются, и я не понимаю, как и зачем вы живёте.
Они дебажат принтами, медленно и печально. Но в защиту го скажу, что дебаггер там не особенно удобный и не особенно стабильный, часть стркуткур в рантайме ты даже и просто не видишь, не говоря уже о том, чтобы их менять. Не выдерживает никакого сравнения с джавой или, прости господи, с пехапе.
Поэтому _очень_ много гошников уже просто привыкли обходится без дебаггера.
Ну и в целом, кстати, многопоточный код с туевой хучей горутин очень непросто отлаживается дебаггером, потому что пока ты прокликиваешь один процесс - другие работают себе, как хотят (или нет).
У меня всё в кубах, все линтеры и тесты обернуты в докер и запускаются в CI, но всё равно при разработке тебе придется работать с этим же локально, подебажить что-то, посмотреть базу, позапускать что-то. IDEшка реально удобнее для той же базы, чем смотреть что-то в консоли или там админер поднимать.
Код символа
То есть "a"[0]=97
http://www.asciitable.com/
Большинство существующих не очень прозрачно парсят что-то в свои структуры, а затем как-то собирают это все через темплейты.
Как-то громоздко все выглядит, может есть на других языках фреймворки, которые позволят сделать генерацию более лаконичной?
Ваш вклад имеет решающее значение для наших усилий по прекращению массовых тюремных заключений и чрезмерного наказания в Соединенных Штатах, борьбе с расовой и экономической несправедливостью и защите основных прав человека для наиболее уязвимых слоев населения американского общества. Спасибо!
Нужен совет сеньёров-помидоров. Берут в Go джунов? Насколько жесткие требования по сравнению с другими стеками?
Это понятно. Я про минимальынй объем знаний. Минимум синтаксиса, ООП нет, простая экосистема и деплой, простая модель конкаренси. Из этого должно следовать, что в Go низкий порог входа, и поидее требования в вакансиях должны быть меньше чем для тех же джавистов. Я прав?
Парсеры как правило пишутся на основе парсера из стандартной библиотеки, в интернете можешь найти примеры, он довольно простой в использовании. Главное учитывать, что он возвращает именно спарсенный текст, а не сигнатуры, к сожалению. То есть, `foo(a, b string)` спарсится как функция с аргументами `a` и `b string`, что не очень удобно.
Кодогенерация в большинстве случаев решается через шаблон с кодом, в который через gotemplate подставляется то, что тебе нужно. Естественно, никакой подсветки результирующего синтаксиса там нет, отлаживаться приходится "на глазок" и всё такое. Особенно бесят отступы. Некоторые из моих знакомых вообще на эти отступы забивают и генерируют код, как придётся, просто проходясь по нему потом gofmt.
Ещё есть gennifer, это кодогенератор, построенный на объектной модели. Кода получается многовато, но идея не так уж и плоха. Жаль, используется редко.
Тогда ты должен понимать, что объем знаний для джуна в джаве в 2-3 раза выше чем для джуна в го. Большие команды и проекты скорее минус чем плюс. В джаве многабукф, паттерны/ООП головного мозга, миллионы строк лапшекода, тысячи классов, новичкка кинут разгребать кучи говна за всеми, одни минусы. Количество вакансий не о чем не говорит. Чем меньше вакансий, тем меньше конкуренции.
На сколько я знаю - нет полноценного фремворка для этого, но можно вместо темплейтов использовать https://github.com/dave/jennifer
В го изначально высокие требования и однообразные задачи, которые им решают.
В более массовых языках задачи разные, и много тех, где не нужно такого объема знаний.
Мне питон ближе.
Разве можно сравнивать требования к джангисту, пилябщк у монолит на одной postgre + redis и питонщику пилящему микросервисы на aiohttp, где сразу россыпь всего - кликхаус, постргя, редис, эластик, Кафка, Кассандра?
И на го только требования второго плана.
>В го изначально высокие требования
К чему?
>однообразные задачи
Например? Го язык общего назначения.
>В более массовых языках задачи разные, и много тех, где не нужно такого объема знаний.
Какого объема? В Питоне языковых конструкций в 2 раза больше. Плюс большая и разрозненная экосистема.
Программирование это сложно, начнем с этого. Язык не важен, потому что программируют алгоритмы в голове, а язык используют только для выражения этих алгоритмов в виде кода. Я тебе уже написал, что Go довольно простой, в других языках требуется больше знать чтобы их использовать. Еще простой PHP, но он только для веба.
1. os
2. io
3. ioutil
4. другое
>джун го +-100
Что-то как-то вообще нет:
https://www.google.com/search?q=junior+go+developer&oq=junior+go+developer
https://blog.golang.org/generics-next-step
Охуенно, еще больше года кодогенерацию дрочить
ну чо, как вам?
Счас бы этого дебила слушать. Напомню, что Немчинский лет 5 назад пизданул, что Питон хуета, и вообще непонятно кто и что на нем пишет. Сказал, что ближайшее время он сдохнет. Что видим сейчас, Питон в 5 самых популярных языков, а Джава начала терять позиции.
https://github.com/go-gorm/gorm/wiki/GORM-V2-Release-Note-Draft
Сейчас нормально он о Питоне отзывается
https://www.youtube.com/watch?v=1bhvP1CZI5A
А можно тысяч 40, но на удаленке?
Как насчет context.Context, чтобы там `interface{}`не использовать. Да и вообще у тебя есть `grep -rc 'interface\{\}' $GOPATH` причин использовать дженерики.
Дженерики хороши тем, что ты блять можешь статически проверить свой код на валидность, используя какие-то структуры данных, те же векторы. Вместо того, чтобы сначала пихать данные хуй знает куда, а потом ассертить типы, постоянно рискуя словить панику, nil и всё такое.
> func(r reciecer) do(type T) (in T) (string, error) {...}
Здарова гач. Вкатился в пщ из пистона, недавно получил первую работу гачером. Вот намедни получил задание с байтоёбством и жидко пернув обмяк. К такому в пистоне я даже не притрагивался.
Посоветуй с чего начать, какой минимум для байтоёбства нужен? Мне для начала хотя бы общее представление заиметь. Я его имею, конечно, но сейчас оно очень туманное.
Думаю надо будет еще в каких-нибудь C, C++ тредах спросить
Да потому что докуя проприетарных бинарных форматов, готовую лиьу для которых куй найдешь. И даже полноценную доку куй найдешь. А кто писал этот сраный формат, давно за это говно сослали в Сибирь.
>>1727610
Доки по unsafe и вперёд. Нужно просто взять кусок памяти и заставить гошечку думать, что это структура. Дальше все просто.
разочаровываешь
>>1727631
> Доки по unsafe и вперёд
ты какой-то ебнутый
>>1727634
от тебя там скорее всего хотят что-то такое https://medium.com/learning-the-go-programming-language/encoding-data-with-the-go-binary-package-42c7c0eb3e73
ну или руками навелосипедь fixed-size заголовок, в нем длина тела сообщения, а дальше уже сообщение можно как угодно сериализовать
Так задача какая? В,ы долбоебы, очередной формат изобретаете? Или нужно декодить/энкодить в уже разработанный по докам?
Если изобретаете - всерьез обсуди накуя. В любой области есть стандарты и протоколы под них.
Если чужой, то это все есть, не еби себе мозги. Я говорю, самое простое, взять память и отобразить ее на структуру. Все так делают, и это даёт максимальный перфоманс. Но, если хочешь убить производительность, бери ссылку второго Антона.
Тоже находил эту статью, так и не успел прочитать, но судя по всему это очень близко к тому, что мне нужно.
Спасибо.
>>1727659
> Если изобретаете - всерьез обсуди накуя.
Я уже пытался, несколько раз предлагал другие варианты, но все тщетно.
> Я говорю, самое простое, взять память и отобразить ее на структуру.
В том то и дело что у меня базовых знаний не хватает чтобы это сделать качественно.
ты еще про баннер-попрошайку забыл https://golang.org/
Это реально мешает, примеры можешь спросить в плюсовом треде. В зависимости от стандарта, в плюсах парсинг угловых скобок натурально зависит от пробелов вокруг и если ты не угадал - получишь ошибку компиляции. Или чего похуже.
> они бы делали синтаксис на основе json или xml
Ды ты вообще зелёный походу. Среди языков разметки сложнее чем xml распарсить только html.
> в плюсах парсинг угловых скобок
Потому что лексер был сделан через жопу.
> Среди языков разметки сложнее чем xml распарсить только html.
Кто ж будет писать эти парсеры с нуля? Они давно написаны, достаточно юзануть одну функцию и пройтись по уже готовому дереву.
Или уже можно тащить в петпроджект?
https://github.com/robpike/lisp
Стоит ли учить Go как первый язык? Хочу зашибать 300к/неделя и больше на высоких технологиях. Короче, я не совсем офисную РАБоту хочу, а прикладывать Go к чему-то высокотехнологичному, в производстве каком-нибудь.
С программированием не знаком, вылетел с третьего курса мехмата
С такой мотивацией лучше иди впаривать лохам курсы "как разбогатеть". Программирование - это тяжелый интеллектуальный труд, необходимость работать даже дома, постоянно учить новое и постоянная работа со своими же ошибками, что тяжело психологически.
12 часовая смена на заводе проще, потому что ты можешь стоять, не думать, или даже работать "на отъебись". В "дорогом" программировании ты не можешь думать "на отъебись", сразу хуйня выйдет, и ты должен постоянно, весь день, загружать свой мозг (самый энергозатратный орган, между прочим) на 100%, что очень, очень тяжело. К концу дня ты натурально ощущаешь, что не в силах даже думать о чём-то, просто залипаешь в одну точку и всё (а ещё нужно нагружаться дома, чтобы учить что-то новое, ты понел).
Короче, если ты хочешь "войти в айти" ради бабосиков, то ты быстро вылетишь отсюда, охуев от того, насколько это тяжело и сложно.
А ещё до бабосиков нужно будет доползти, первые года три-пять их будет не особо много.
а как первый язык учи java или c#, го берут вторым или третьим языком к уже имеющейся базе
Hands-On GUI Application Development in Go (2019)
https://dropmefiles.com/Nvupy
Вроде как уже появился fyne, который прям приличный фреймворк. И смотреть на биндинги как-то странно.
https://assets.digitalocean.com/books/how-to-code-in-go.pdf
прикольно, она вышла уже устаревшей
а вообще из интереса полистал - это ребята из https://www.gopherguides.com пиарятся, не создавая никакой дополнительной ценности; лучше читайте go tour, офицальную документацию и исходники - пользы будет больше.
А ты чего такой злой?
>Какие претензии к самому популярному
>(по некоторым рейтингам)
Популярен он только по поиску, а поиск дергают либо студенты либо вкатывальщики. То есть, инфоцыгане, на хайпе ИИ и простоты языка, просто взяли и продали для хочух-в-айти это гуана. ну и студентам тоже, потому что позволяет хоть что-то объяснить и главное показать на минимальном уровне за счет фасадных либ
>Какие претензии к ... самому популярному встраиваемогу япам?
Что этот язык огрызок и годиться только для встраивания?
Что
Такой вопрос. Можно ли переписать этот фрагмент пизже?
Сам из пайтона.
Заметь, что у тебя в первом случае вызывается os.LookupEnv, а потом os.GetEnv. В первом случае у тебя есть проверка на то, что переменную засетили, во втором нету. Значит во втором и дальше случаях нет смысла проверять if !ok{}.
Либо везде меняй на os.LookupEnv или везде удаляй этот блок с if !ok{}
Также ты можешь заменить fmt.Printf() ,os.Exit(1) на log.Fatalf()