как работать все свободное время не отвлекаясь?

Телеграм закрой, для начала.

надо стартапы пилить свои

но мне лень

если лень, значит - не надо

надо стартапы пилить свои

Пили мои, уж я-то желание создавать умею.

Братья гоферы, хороша ли официальная документация? И если нет - что лучше прочитать? Увидел это ”reply.([]byte)” и понял, что нужно почитать доку...

Хороша

Братья гоферы, хороша ли официальная документация? И если нет - что лучше прочитать? Увидел это ”reply.([]byte)” и понял, что нужно почитать доку...

Хороша Почитать нужно

Официальная документация - суперская!

слышь ты, ты че гонишь на нашу оф документацию

Спасибо!

да я тебя

Братья гоферы, хороша ли официальная документация? И если нет - что лучше прочитать? Увидел это ”reply.([]byte)” и понял, что нужно почитать доку...

Это просто приведение типов, если что

Братья гоферы, хороша ли официальная документация? И если нет - что лучше прочитать? Увидел это ”reply.([]byte)” и понял, что нужно почитать доку...

Обычное приведение типов же.

Это просто приведение типов, если что

Но я так понимаю это приводит к byte array’у?

Но я так понимаю это приводит к byte array’у?

Ну да, к слайсу байтов

Возвращает ошибку и что-то ещё, на случай невозможности приведения.

Ну да, к слайсу байтов

Но тогда что храниться в редисе?

Обычное приведение типов же.

Учитывая, что у нас два приведения типов - доку почитать не вредно

а вы говорите, параметрический полиморфизм в Go надо. Чтобы еще все усложнить, когда народ и так-то уже не все понимает...

Подозреваю, что c.Do() возвращает тебе interface{}

Почему не просто как в плюсах, а через точку?

Но тогда что храниться в редисе?

Ворос не в том, что там хранится, а в том, что либа отдала. А отдала она interface{}

и ты предполагаешь, что положил туда []byte, и конвертируешь в []byte

в общем, похоже, что если выйдет Go 2, то его уже так не осилишь за пару дней с нуля... :(

Почему не просто как в плюсах, а через точку?

А почему надо как в плюсах?

в плюсах неудобный префиксный оператор

У нас, повторю, есть и как в плюсах тоже

и ты предполагаешь, что положил туда []byte, и конвертируешь в []byte

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

У нас, повторю, есть и как в плюсах тоже

Кажется, имелась в виду форма (Type)value, такой вроде нет

Такой - нет

а вы говорите, параметрический полиморфизм в Go надо. Чтобы еще все усложнить, когда народ и так-то уже не все понимает...

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

а кто-то еще оборачивал в респонз вызовы в хендлерах?

в отдельную структуру

(для тех, кто не понял, превожу вопрос гна нормальный язык: кто-то еще врапил респонс-колы в хендлерах?)

*оборачивал в структуры, вызовы респонз в хендлерах ?

в тестах просто странно смотриться

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

и там уже вызывать ошибки теста

но это "не прозрачно"

наверно придется тестировать уже "результат хендлера" в виде json

Корригирую документ, описываю implicit casting и возникает вопрос, а нужен ли в таком случае вообще explicit casting?! func ReturnConst() const []int { return []int {1, 2, 3} // Implicit cast } var variable const []int = []int {1, 2, 3} // Implicit cast func TakeConst(v const []int) { /*…*/ } TakeConst([]int {1, 2, 3}) // Implicit cast единственная ситуация где explicit cast может пригодиться это short variable declaration: immutVec := const([]int {1, 2, 3}) // Or: immutVec2 := const * const T (&T{}) но стоит ли это учитывать?

бНОПНЯ апперед :)

или проще сказать: „хочешь иммутабелый? используй var declaration syntax“

Корригирую документ, описываю implicit casting и возникает вопрос, а нужен ли в таком случае вообще explicit casting?! func ReturnConst() const []int { return []int {1, 2, 3} // Implicit cast } var variable const []int = []int {1, 2, 3} // Implicit cast func TakeConst(v const []int) { /*…*/ } TakeConst([]int {1, 2, 3}) // Implicit cast единственная ситуация где explicit cast может пригодиться это short variable declaration: immutVec := const([]int {1, 2, 3}) // Or: immutVec2 := const * const T (&T{}) но стоит ли это учитывать?

У меня уже давно какае-то чувство, что ты хочешь все усложнить... Это же все потом будет понять и забить в мозг так же сложно, как и плюсы... Не?

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

:)

У меня уже давно какае-то чувство, что ты хочешь все усложнить... Это же все потом будет понять и забить в мозг так же сложно, как и плюсы... Не?

нет, и я уже сотню раз наверное объяснил почему это не так ? например, C как язык ещё проще чем Go, от этого на нём становится легче писать? Нет, потому-что он предоставляет разработчику или команде возможность очень легко выстрелить себе в ногу. Immutable types это инструмент защиты от случайных выстрелов в ногу, которые даже сложно заметить, поскольку такие выстрели в основном проходят бесболезнено, пока не заметишь что нога вся в крови… Mutable shared state is the root of all evil, especially in concurrent environments!

НЕ становится!

Я не против декларирования иммутабельности! Я просто за девушек будущего переживаю!

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

иии? Чем язык от иммутабельных типов станет для студентки первокурсницы сложнее? он наоборот станет легче, ибо первокурсница не сможет сделать то, что делать нельзя

первокурсница все сможет! :)

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

Корригирую документ, описываю implicit casting и возникает вопрос, а нужен ли в таком случае вообще explicit casting?! func ReturnConst() const []int { return []int {1, 2, 3} // Implicit cast } var variable const []int = []int {1, 2, 3} // Implicit cast func TakeConst(v const []int) { /*…*/ } TakeConst([]int {1, 2, 3}) // Implicit cast единственная ситуация где explicit cast может пригодиться это short variable declaration: immutVec := const([]int {1, 2, 3}) // Or: immutVec2 := const * const T (&T{}) но стоит ли это учитывать?

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

насколько я знаю Go, везде, кроме работы с безтиповым констами, все касты explicit

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

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

Скоро это будет второе слово, которое нельзя будет называть. Оба то, чего нельзя называть - нужно, но в го их не будет

Скоро это будет второе слово, которое нельзя будет называть. Оба то, чего нельзя называть - нужно, но в го их не будет

в этом чате нет слов, которые нельзя называть. За шутки на эту тему очень сильно хочу банить.

ну, вроде, одно из того, что нельзя наывать, уже, кажется, будет :)

Скоро это будет второе слово, которое нельзя будет называть. Оба то, чего нельзя называть - нужно, но в го их не будет

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

в этом чате нет слов, которые нельзя называть. За шутки на эту тему очень сильно хочу банить.

ты вобще очень сильно хочешь банить. Легче надо читать, с юмором! :)

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

ERROR: S client not available

я вроде в FAQ описал что иммут это одна из тех фич которые безболезненно реализовать в Go 1.x - реально, относительно других затей типа error handling и generics

я вроде в FAQ описал что иммут это одна из тех фич которые безболезненно реализовать в Go 1.x - реально, относительно других затей типа error handling и generics

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

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

Потому их и не будет

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

линтеры работают с выхлопом ast, если как-то это завезут, линтерам пофиг

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

хорошее замечание. С линтерами всё зависит от того как они парсят Go код, если они парсят его через AST тогда всё будет в порядке и продолжит работать безменений.

хорошее замечание. С линтерами всё зависит от того как они парсят Go код, если они парсят его через AST тогда всё будет в порядке и продолжит работать безменений.

Трудно себе представить, как можно реализовать линтер без аст, на регекспах, что ли?

линтеры работают с выхлопом ast, если как-то это завезут, линтерам пофиг

ну выхлопом то да, но там то типы есть конкретные в go/ast в которых придется включить эту иммутабельность

Трудно себе представить, как можно реализовать линтер без аст, на регекспах, что ли?

да как угодно ? но толковый линтер, однако, конечно будет использовать AST

и какие-нибудь линтеры могут просто не ожидать, что там придет что-то кроме ast.Ident

ну выхлопом то да, но там то типы есть конкретные в go/ast в которых придется включить эту иммутабельность

это не должно поломать обратную совместимость

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

без АлгТД эта проблема на 100% не решается

я плохо представляю, как именно это будет завезено (и может ли в принципе) скорее всего, флаг в type, для линтеров без явной поддержки вообще ничего не должно меняться

и какие-нибудь линтеры могут просто не ожидать, что там придет что-то кроме ast.Ident

https://golang.org/pkg/go/ast/#GenDecl

эт ты к чему?

так const декларации уже завезли, просто +1 кейс

ну вот именно что +1

а линтеры то много лет назад написаны

я не думаю, что линтеры будут падать, но фолс реакции на const, конечно, будут

В рамках противодействия свободному времени и желанию улучшить материал, дайте критику по https://habr.com/post/425025/ , заранее спасибо

В рамках противодействия свободному времени и желанию улучшить материал, дайте критику по https://habr.com/post/425025/ , заранее спасибо

Я не буду кририковать, потому что у меня юмор не смешной.

Добрый день, подскажите пожалуйста. Изучаю beego и возник вопрос, можно ли его использовать без использования orm, а писать чистый sql ?

можно

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

Ок спасибо

А использование всяких фреймворков в go это не «подпорка»?

подпорка

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

Ок спасибо

Тут Алексей Палащенко бывает, у него есть ORM общего пользования. Поговори с ним, кстати

Тут Алексей Палащенко бывает, у него есть ORM общего пользования. Поговори с ним, кстати

хорошо

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

расскажи это автоматическим миграциям

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

атоматические миграции - это такое добро, что никакого зла не надо