если уж на просьбу добавить в стандартную поставку го нормальный пакетный менеджер еще год назад был только один ответ - «это не нужно», у иммутабельности под любым соусом сейчас нет никаких шансов пройти в язык

если бы не было то я бы не писал proposal ? The proposed feature targets the current Go 1.x (> 1.11) language specification and doesn't violate the Go 1 compatibility promise. https://github.com/romshark/Go-2-Proposal---Immutability

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

и не поддерживаете предложение сделать его ещё более читабельным?

если что-то возращает указатель, можно мутировать ?

да здравствуют баги, о существовании которых мы узнаём тогда, когда уже слишком поздно!

и не поддерживаете предложение сделать его ещё более читабельным?

Поддерживаю, и поддерживаю иммутабельность, но не поддерживаю const в том виде как он реализован в с++

В инженерии все давно поняли, что людям доверять нельзя.

+

Да даже SQL можно писать абсолютно нечитаемо.

JOINs anyone?

Ну судя по черновику Go2, в гугле походу насобирали шишки, потанцевали на граблях и заставили менять язык, вводя фичи про которые раньше говорили, что "не нужны". Так что можно и иммутабельность запилить.

Откуда вот это "не нужны"? 13-й год, один иг го разработчиков предлагает пропозал про иммутабельности слайсы, это как пример позиции коретим Где вы находите утверждения "не нужны"?

Изменится в плане учебник от go 1.10 не даст понимания что это за херь и надо переучивать программиста

дайте мне по крайней мере возможность писать правильные библиотеки и правильно писать на Go проекты, без кодогенерации, boilerplate'а и лишних тормозов производительности)) меня учебники и тот факт что других надо переучивать мало волнует потому-что это необязательно, Go 1.x от этого не ломается, пиши как хочешь, но приятнее открывать для себя скорее новые возможности написания более качественного кода, нежели открывать для себя лимитации языка... вы со мной не согласны?)

Откуда вот это "не нужны"? 13-й год, один иг го разработчиков предлагает пропозал про иммутабельности слайсы, это как пример позиции коретим Где вы находите утверждения "не нужны"?

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

Тут кто то предлагала для начала линтер и мне кажется с позиции практической полезности сейчас был бы хороший ход зпилить линтер и возможности метить передаваемые в ыункцию/метод аргументы как имутабельные, хотя бы даже каким нибудь кривым комментом типа //go:immut

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

Я не о качестве идеи, а об утверждении что коретим считает иммутабельность ненужной

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

Я не о качестве идеи, а об утверждении что коретим считает иммутабельность ненужной

так это фантазии Андрея, не обращайте внимание

Тут кто то предлагала для начала линтер и мне кажется с позиции практической полезности сейчас был бы хороший ход зпилить линтер и возможности метить передаваемые в ыункцию/метод аргументы как имутабельные, хотя бы даже каким нибудь кривым комментом типа //go:immut

https://github.com/qbeon/go-immutability-linter#disadvantages-relative-to-compiler-enforced-immutability

дайте мне по крайней мере возможность писать правильные библиотеки и правильно писать на Go проекты, без кодогенерации, boilerplate'а и лишних тормозов производительности)) меня учебники и тот факт что других надо переучивать мало волнует потому-что это необязательно, Go 1.x от этого не ломается, пиши как хочешь, но приятнее открывать для себя скорее новые возможности написания более качественного кода, нежели открывать для себя лимитации языка... вы со мной не согласны?)

на сколько я понимаю, вот это считается сейчас качаственным кодом в го func efaceToInt(eface interface{}) int { return (*(*int)((*[2]unsafe.Pointer)(unsafe.Pointer(&eface))[1])) }

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

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

на сколько я понимаю, вот это считается сейчас качаственным кодом в го func efaceToInt(eface interface{}) int { return (*(*int)((*[2]unsafe.Pointer)(unsafe.Pointer(&eface))[1])) }

good one))

good one))

так что иммутабельность пока что дело десятое

на сколько я понимаю, вот это считается сейчас качаственным кодом в го func efaceToInt(eface interface{}) int { return (*(*int)((*[2]unsafe.Pointer)(unsafe.Pointer(&eface))[1])) }

Неправильно понимаете

Неправильно понимаете

а какого качества тогда этот код?

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

https://github.com/golang/go/issues/20443 проработан (но требует проверки) https://github.com/romshark/Go-2-Proposal---Immutability#51-proposal-spec-add-read-only-slices-and-maps-as-function-arguments-20443 —- https://github.com/golang/go/issues/22876 проработан (но требует проверки) https://github.com/romshark/Go-2-Proposal---Immutability#52-proposal-go-2-read-only-types-22876 —- https://github.com/golang/go/issues/23157 ещё не проработан (однако я уже сним ознакомился) —- https://groups.google.com/forum/#!topic/golang-nuts/BnjG3N77Ico это не оффициальный пропосал, но думаю его стоит рассмотреть и линкануть

Этот код нечитабелен, и про использование unsafe сказано достаточно

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

на сколько я понимаю, вот это считается сейчас качаственным кодом в го func efaceToInt(eface interface{}) int { return (*(*int)((*[2]unsafe.Pointer)(unsafe.Pointer(&eface))[1])) }

просто Кирилл любит, когда через штанину рукой :) и у него получается быстро, по крайней мере иногда :)

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

Поэтому утверждение "в го считается качественным" неверно А так то писать можешь как угодно

где связь то?

где связь то?

Качественный в го - говей и работает корректно

Данный код работает корректно но не говэй и нет гарантий что он не поломается при новой версии го

Вот и вся связь

ну первое, что такое go way? я знаю только про effective go, в котором только в 1 месте упоминается readable

Простота и читабельность

Есть ещё всякие факторы, но их немного

а можешь цитату скинуть или доклад какой-нибудь, мне интересно откуда все эти мысли пошли

Есть выступление пайка почему го взлетел, вот там он примерно описывает как они это видят

А вообще про говей и различные моменты почему в го так а не иначе много достаточно выступлений пайка

Есть другие умные мужи пытающинся донести идеи го, но я не вспомню сейчас по памяти ссылок на доклады

почему так или иначе это одно, а почему такой код (которого полно в стдлиб) не go way, это другой вопрос

почему так или иначе это одно, а почему такой код (которого полно в стдлиб) не go way, это другой вопрос

В го есть ансейф и его можно использовать если очень надо, но мы же говорим о "в го считается качественным кодом"

А на счёт стдлиб там есть нехороший код, сейчас меньше, было больше и был прям откровенный говнокод, но что это меняет?

это какая-то двуличность, топим за одно, а делаем другое

почему так или иначе это одно, а почему такой код (которого полно в стдлиб) не go way, это другой вопрос

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

это какая-то двуличность, топим за одно, а делаем другое

Нет. Я не видел идеально реализованных проектов, всегда в той или иной степени - компромиссы, но при этом стремиться к хорошему это правильно

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

Этот "обман" та еще хрень, bytes.Buffer уже наобманывался

Этот "обман" та еще хрень, bytes.Buffer уже наобманывался

в стд "обман" чаще всего работал, и его выпиливали, когда завозили оптимизации (string<->[]byte)

а то получается вот так

https://github.com/mailru/easyjson/blob/3fdea8d05856a0c8df22ed4bc71b3219245e4485/jlexer/bytestostr.go

Подскажите, пожалуйста, как работать с import’ами, если использую приватный репозиторий и разрабатываю в докере?

Подскажите, пожалуйста, как работать с import’ами, если использую приватный репозиторий и разрабатываю в докере?

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

dep

dep

https://github.com/golang/dep/blob/master/docs/FAQ.md#how-do-i-get-dep-to-consume-private-git-repos-using-a-github-token

https://github.com/golang/dep/blob/master/docs/FAQ.md#how-do-i-get-dep-to-consume-private-git-repos-using-a-github-token

Только с гитхабом работает такое?

с любым гит репозиторием

dep

я просто руками указывал [[override]] name = "my_private_repo" source = "ssh://git@my_private_repo.git" branch = "master"

в Gopkg.lock

или constraint

тогда можно без токенов жить

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

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

пулите репу, монтируете папку в докер, изменения пушите снаружи

Ну, полетели: https://github.com/gosh-lang/gosh

пулите репу, монтируете папку в докер, изменения пушите снаружи

То есть при каждом новом package мне нужно пушить в гит?

Го же сам по себе медленный, зачем на нем ещё интерпретатор другого языка писать?

ERROR: S client not available

в каком смысле go медленный?

Потому что скорость – не всё

То есть при каждом новом package мне нужно пушить в гит?

да, идея именно такая

То есть при каждом новом package мне нужно пушить в гит?

https://medium.com/statuscode/golang-docker-for-development-and-production-ce3ad4e69673

https://medium.com/statuscode/golang-docker-for-development-and-production-ce3ad4e69673

Я видел, не особо статья

вы чего хотите, собственно?

Я видел, не особо статья

тогда вам стоит просто почитать, что такое докер

вопросов по го я не вижу

тогда вам стоит просто почитать, что такое докер

https://github.com/enfipy/goodev

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

Неужели нельзя настроить absolute path на root проекта и подключать от туда пакеты?

просто не нужно кодить в докере

блин. а мб тот слитый код аэрофлота на самом деле чья-то иде, парень просто кодил в докере?

блин. а мб тот слитый код аэрофлота на самом деле чья-то иде, парень просто кодил в докере?

парень был альтернативно одаренный со всех сторон?

Я переписал пункт 1.1.1. для лучшего понимания проблемы: https://github.com/romshark/Go-2-Proposal---Immutability#111-ambiguous-code-and-dangerous-bugs

Неужели нельзя настроить absolute path на root проекта и подключать от туда пакеты?

конечно, можно. это GOPATH

Ребяты, есть return type у функции:*typeName, как мне конструкцию execParams := getSpecParams() return &execParams упростить?

ну типо в одну строку сделать без лишней переменной

вроде можно сделать return &(getSpecParams())

нельзя

можно сделать функцию обертку, которая вернт typeName

ну значит нельзя, это go way, страдай

Неужели нельзя настроить absolute path на root проекта и подключать от туда пакеты?

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

Подскажите, в чем проблема? Структура имплементирует интерфейс, но при передачи ее в функцию которая принимает параметром этот интерефейс, выдает что нельзя так

Если передать не просто db, а указатель &db, то все ок

Почему так?

Все верно, надо указатель передавать, если в сигнатуре интерфейс

Если передать не просто db, а указатель &db, то все ок

потому-что скорее всего не T у вас имплементирует интерфейс а *T, а это такие разные типы