Anonymous
Можно заменить ioutil.readall на просто io.readall. разработчики языка рекомендуют переезжать. И в конце можно вернуть return json.unmarshal, без лишней проверки
Anonymous
Хотя я бы еще кое-что тут переписал )))
Grigorij
я в универе писал только на си++, все 5 лет, но начав карьеру пошел где деньги - php/js. последние года на го и могу сказать С must have
есть что посоветоватъ из материалов по С?
Anonymous
Vadim
от МТС тоже был контест, правда, почитав я понял что они как-то жестко стелют для обучения по Go:
- знание очередей
- работа с очередями в go
- etc...
Протыкал наугад очереди и какую то там субд, прошел на второй этап …
Anonymous
Ну я про это и говорю. Ioutil медленно закрывают без поломки обратной совместимости
Vadim
А что во 2 этапе?
2 задачи алгоритмические ( easy and medium) и мотивационные вопросы со ссылкой на cv
Vladislav
Vadim
Решил?
Легкую нет, было 3 попытки и все три завалил на последнем тесте. Задача была настолько проста, что я не понял где там можно было накосячить. Вторую решил
Vladislav
Легкую нет, было 3 попытки и все три завалил на последнем тесте. Задача была настолько проста, что я не понял где там можно было накосячить. Вторую решил
Ну я, вроде обе задачи решил. А вот на счет cv не уверен. Они там в конце 1 дня еще как минимум 1 степ добавили
Vladislav
Легкую нет, было 3 попытки и все три завалил на последнем тесте. Задача была настолько проста, что я не понял где там можно было накосячить. Вторую решил
Если интересно могу скинуть 1 задачу которая прошла с 1 раза все тесты
Vadim
Ну я, вроде обе задачи решил. А вот на счет cv не уверен. Они там в конце 1 дня еще как минимум 1 степ добавили
Там прямо в первом шаге нужно было ссылку оставить, потом шли вопросы поведенческие
Vladislav
Там прямо в первом шаге нужно было ссылку оставить, потом шли вопросы поведенческие
Нее. Они потом перед 1 вопросом добавили поле с просьбой сообщить email
Vadim
Нее. Они потом перед 1 вопросом добавили поле с просьбой сообщить email
Ну я видать успел до этих изменений
Vadim
Если интересно могу скинуть 1 задачу которая прошла с 1 раза все тесты
Спасибо, но не актуально, меня уже воротит от этих задач
Marek
eur rub sberbank
Aziz
как '123' вот это превратить 123 ?)
Aziz
то есть string на int
Sergey
func Atoi(s string) (int, error)
https://pkg.go.dev/strconv#Atoi
Null
Aziz
data := make([]byte, 8)
n, err := os.Stdin.Read(data)
вот тут создается тип 8 битный и передается на Read что бы он нам дал вводимые данные как бинарный я же правильно понимаю
Anonymous
Anonymous
- Падает производительность.
- Потребляет излишние ресурсы.
- Усложняется код.
- Частично теряется контроль.
- ORM не могут покрыть 100% функционала базы в отличие от чистого SQL.
Если уж сильно хочется, то можно воспользоваться генераторами
https://github.com/go-jet/jet
https://github.com/kyleconroy/sqlc
Но это все моё ИМХО, оно омжет не совпадать с мнением большинства.
Evgeny
- Падает производительность.
- Потребляет излишние ресурсы.
- Усложняется код.
- Частично теряется контроль.
- ORM не могут покрыть 100% функционала базы в отличие от чистого SQL.
Если уж сильно хочется, то можно воспользоваться генераторами
https://github.com/go-jet/jet
https://github.com/kyleconroy/sqlc
Но это все моё ИМХО, оно омжет не совпадать с мнением большинства.
а разве эти аргументы к го применимы в большей степени, чем к другим языкам и платформам?
Anonymous
а разве эти аргументы к го применимы в большей степени, чем к другим языкам и платформам?
У Go не полноценное OOP.
В той же Java ORM будет более предпочтительней.
Alexander
- Падает производительность.
- Потребляет излишние ресурсы.
- Усложняется код.
- Частично теряется контроль.
- ORM не могут покрыть 100% функционала базы в отличие от чистого SQL.
Если уж сильно хочется, то можно воспользоваться генераторами
https://github.com/go-jet/jet
https://github.com/kyleconroy/sqlc
Но это все моё ИМХО, оно омжет не совпадать с мнением большинства.
ну мне нравится через gorm-generate генерить модели. да и для скриптов одноразовых удобно. а вообще надо профилировать сначала
Farruh
Alexander
вон кстати, офигенная портативность гошных бинарников опять
Alexander
./apier: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./apier)
./apier: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./apier)
Alexander
собрано на последнем clear linux, попытался запустить на debian 11
Alexander
попробовал поставить ради теста пакеты build-essential и golang - то же самое
Alexander
откуда вообще эта байка про "закинул бинарник и все" пошла?
Alexey
cgo_enabled=0 сделай и "закинул бинарник и все" будет работать)
mertv0e
cgo_enabled=0 сделай и "закинул бинарник и все" будет работать)
А можно в двух словах что это за флаг?
Alexey
отключает зависимость от сишных либ
mertv0e
Благодарю
mertv0e
Но тогда что то может не работать?
mertv0e
Какой нить пакет
Alexey
Какой нить пакет
работать все будет. аналоги на го будут компилиться, они все есть. Просто разрабы решили что лучше пусть будет по дефолту сишные использоваться)
mertv0e
Alexey
а инфа сотка, что все есть?)
ну я вообще видел только про dns resolver. По-моему, только из-за него все проблемы. И он точно есть чисто гошный
Арман
- Падает производительность.
- Потребляет излишние ресурсы.
- Усложняется код.
- Частично теряется контроль.
- ORM не могут покрыть 100% функционала базы в отличие от чистого SQL.
Если уж сильно хочется, то можно воспользоваться генераторами
https://github.com/go-jet/jet
https://github.com/kyleconroy/sqlc
Но это все моё ИМХО, оно омжет не совпадать с мнением большинства.
Ускоряет написание кода, что иногда гораздо важнее всего вышеперечисленного
mertv0e
ну я вообще видел только про dns resolver. По-моему, только из-за него все проблемы. И он точно есть чисто гошный
да мне просто старый топик на стаковерфлоу попался, где тип подробно описал с чем это есть и отметил, что не все есть. Думаю его инфа устарела
Alexey
Ускоряет написание кода, что иногда гораздо важнее всего вышеперечисленного
ну тут спорно. сложные запросы дольше ORM делать чем руками написать, а некоторые вообще нельзя. а простые запросы, на сколько ускоряет, на пару минут?)
Арман
ну тут спорно. сложные запросы дольше ORM делать чем руками написать, а некоторые вообще нельзя. а простые запросы, на сколько ускоряет, на пару минут?)
Конечно. Это имеет значение, и запрос в орм выглядит лаконично
Alexander
ну я вообще видел только про dns resolver. По-моему, только из-за него все проблемы. И он точно есть чисто гошный
Про него слышал, у меня как раз запрос апишки идёт по домену
whois
Друзья, скажите, а можно ли в mockery сгенерить мок для функции типа того:
type Foo(ctx context.Context) error
И вот на это дело нужно сгенерить мок
Alexander
хотя на другом серваке с центосом:
segmentation fault
kostyaBro
Ron Mount
Ну кстати у нас на работе орм юзают и в целом в этом есть свои плюсики
Ron Mount
Как минимум, меньше ошибок)
Dmitriy
Зачем учить API ORM если можно выучить SQL?
Зачем работать с объектами, если можно работать с записями из множества таблиц?
Alexander
но, конечно, можно обойтись без орм в зависимости от сложности структуры бд и степени общения с ней
kostyaBro
Таки перефразирую вопрос.
Зачем забивать голову ORM если знаешь SQL?
Вопрос скорее риторический тк аргументы за я знаю. Я думаю кроме как для простого CRUD вещь лишняя. А если надо агрегироыанные вьюшки создать да или просто соптимизировать запрос... Да и оверхед.
Кароч мне и без ORM норм дышется
Dmitriy
Не лучше. Это совершенно иной подход, для других целей. Если использовать ООП, то ОРМ - лучше подходит.
Alexander
чтобы быстро делать работу
kostyaBro
Зачем работать с объектами, если можно работать с записями из множества таблиц?
Ты и так работаешь с доменной сущностью, для которой есть репозиторий.
Какая у репозитория реализации не важно
Alexander
ну у тебя сейчас важнее в работе скорость работы приложения, а у кого-то баланс смещен в скорость разработки
Dmitriy
Вот и я говорю. Не лучше. Можно десяток лет программировать и не сталкиваться с реляционными базами данных. Зачем там нужен SQL? А учитывая то, что большинство разработчиков понятие не имеет что такое хранимые процедуры, триггеры, генераторы, ключи и индексы, то использование SQL будет идти во вред результату.
kostyaBro
Вот и я говорю. Не лучше. Можно десяток лет программировать и не сталкиваться с реляционными базами данных. Зачем там нужен SQL? А учитывая то, что большинство разработчиков понятие не имеет что такое хранимые процедуры, триггеры, генераторы, ключи и индексы, то использование SQL будет идти во вред результату.
Согласен с последним аргументом, но считаю, что лучше хотябы индексы знать. Это же правильный подход, смотреть под капот, не обязательно перебирать его даж.
Dmitriy
Ну вот можете по себе посудить: задумывались ли вы, что inner join взаимозаменяем на where? А если да, то что эффективнее? Работая с ОРМ об этом не приходится задумываться. И даже знать, являются ли данные реляционными вообще.
Андрей
Если рассмотреть сей вопрос с позиций изучения материала.
Если ещё не джун, то с чего начать изучение - с SQL или ORM ?
По итогу джун должен знать и то и другое ?
Мидлл ?
Herman
Какие-то интересные истории про разработчиков, которые sql не знают. Это кто под десктоп пишет или фронтенд?
Herman
А когда gorm валится, то надо понять, в чем проблема. По его сгенеренному запросу как раз
Alexander
Согласен с последним аргументом, но считаю, что лучше хотябы индексы знать. Это же правильный подход, смотреть под капот, не обязательно перебирать его даж.
а как без них? ничего работать не будет
Alexander
Alexander
Dmitry
Ну вот можете по себе посудить: задумывались ли вы, что inner join взаимозаменяем на where? А если да, то что эффективнее? Работая с ОРМ об этом не приходится задумываться. И даже знать, являются ли данные реляционными вообще.
А почему не приходится с орм задумываться? Если выстрелить себе в ногу этим, то что с sql, что с орм пойдешь копать
Evgeny
ну давайте по-чесноку
Evgeny
орм хотя бы опечатку покажет на этапе компиляции
kostyaBro
а как без них? ничего работать не будет
Выше имелось в виду понимать внутреннее устройство индексов. Многие даже не знают что ты можешь сделать индекс на B+tree например или хеш мапе. Или по незнанию подумать что индексы все ускоряют и поставить на каждый столбец по индексу.
Dmitriy
А почему не приходится с орм задумываться? Если выстрелить себе в ногу этим, то что с sql, что с орм пойдешь копать
Одна из причин - то что внутри вместо того чтоб джойнить таблицы, ОРМ делает серию запросов, причем с использованием плана запроса. Что на порядок эффективнее. Но это ж от ОРМ зависит.
Alexander
Dmitry
Одна из причин - то что внутри вместо того чтоб джойнить таблицы, ОРМ делает серию запросов, причем с использованием плана запроса. Что на порядок эффективнее. Но это ж от ОРМ зависит.
План запросов имеет св-во плавать в больших системах, покрайней мере из моего опыта его в принципе часто dba прибивают гвоздями