Опять вы оптимизируете производительность до замеров

в общем я предвижу reject пропозола с формулировкой «это не нужно», в общем, как и всегда

смотрите у нас есть rust и go. оба языка новые. на go у нас есть несколько больших сложных проектов. на rust у нас есть какой-то фейспалм. мне кажется, уже можно сказать, что rust не выстрелил.

Можно кстати сравнить. Есть parity , а есть go-eth. Два проекта реализуют одинаковую логику и спекуу.

Оба достаточно большие

Можно

нет в JS иммутабельности, там только shallow immutability, я её называю fake & useless immutability. можно изменить поле const объекта и рантайм даже не пикнет 😀 а freeze это не решение, ибо, опять-же, shallow... deepfreeze сильно бьёт по производительности

В JS у const обычная семантика const *T

в общем я предвижу reject пропозола с формулировкой «это не нужно», в общем, как и всегда

Скорее всего

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

да, давайте плюнем на производительность, нагородим кодогенерации, и сделаем всё всё всё ЛИШЬ БЫ не облегчать себе работу иммутабельными типами))

в общем я предвижу reject пропозола с формулировкой «это не нужно», в общем, как и всегда

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

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

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

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

У вас странное представление о говэй

Опять вы оптимизируете производительность до замеров

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

У вас странное представление о говэй

ну да, ведь иметь нормальный пакетный менеджер из коробки это то же go way, хотя подождите ка….

ну да, ведь иметь нормальный пакетный менеджер из коробки это то же go way, хотя подождите ка….

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

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

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

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

Нет, скорее чужеродная реализация нужной фичи

Про иммутабельность в том или ином виде разговоры идут давно, никто не говорит что это не нужно

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

Простота лишь в плане изучения, а вот читабельность - это вряд-ли. Го-код очень плохо передает намерения программиста, а ещё его много.

Его много но он очень легко читается, когда тыс каждый день ревьювишь тонны кода это становится очень ценным

Простота лишь в плане изучения, а вот читабельность - это вряд-ли. Го-код очень плохо передает намерения программиста, а ещё его много.

Возможно есть более читаемые, но я не сталкивался

Его много но он очень легко читается, когда тыс каждый день ревьювишь тонны кода это становится очень ценным

Легко читается только когда точно знаешь, что код должен делать. Иначе приходится гадать на кофейной гуще.

Возможно есть более читаемые, но я не сталкивался

А с какими языками вы вообще работали?

А с какими языками вы вообще работали?

C,C++, java, js, Python, ruby, php

Чето ещё наверняка но меньше

Ну есть конечно SQL. Тот тоже хорошо читается

Раст например гораздо более сложен и замысел автора гораздо менее очевиден

Но там может нехватка знания языка

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

Но там может нехватка знания языка

Какой смысл говорить о читабельности языка, который ты даже не знаешь?

Ну я пытался освоить, написал пару простеньких хелловордов на базе libp2p но упёрся как раз в то что очень тяжело читать чужой код и забросил

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

если const не примут тогда не видать нам в Go 1.x иммутабельности совсем

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

читайте пропосал, поймёте что getter'ы / setter'ы тут совершенно не при чём и не решают перечисленные проблемы и вообще кодогенерация это никак не Go way, иначе бы она была встроена в язык (generics anybody?) а не просто в toolchain

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

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

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

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

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

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

да за живое вас задело

прямо бомбит

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

Изменится чтение чужого кода

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

вы зачем то объясняете мне то, что я сам прекрасно знаю, выше я озвучил не свою позицию, а позицию разработчиков языка и с 99% вероятностью предсказал результат работы над этим пропозолом

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

Переменные функции нормально именовать надо

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

Ну вот в го с этим нет проблем

Его много но он очень легко читается, когда тыс каждый день ревьювишь тонны кода это становится очень ценным

когда из определения функции не понятно: 1. мутирует ли она переданные ей объекты 2. можно ли мутировать то что она возвращает 3. имеет ли она side-effect'ы на объект если это метод это вы называете читабельным? Обычно это называют неоднозначным кодом и он нечитабелен и опасен (ambiguous code)

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

когда из определения функции не понятно: 1. мутирует ли она переданные ей объекты 2. можно ли мутировать то что она возвращает 3. имеет ли она side-effect'ы на объект если это метод это вы называете читабельным? Обычно это называют неоднозначным кодом и он нечитабелен и опасен (ambiguous code)

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

когда из определения функции не понятно: 1. мутирует ли она переданные ей объекты 2. можно ли мутировать то что она возвращает 3. имеет ли она side-effect'ы на объект если это метод это вы называете читабельным? Обычно это называют неоднозначным кодом и он нечитабелен и опасен (ambiguous code)

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

Переменные функции нормально именовать надо

Ага, а ещё доку писать и обновлять вовремя. Говорю же, детсад, а не инженерная область.

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

Ага, а ещё доку писать и обновлять вовремя. Говорю же, детсад, а не инженерная область.

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

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

Можно. Но его хотя-бы можно писать читаемо, с го же такого не прокатит.

Именуй все таблицы и переменные как a, b, c, d

Можно. Но его хотя-бы можно писать читаемо, с го же такого не прокатит.

Почему? С го можно писать читаемо

Изменится чтение чужого кода

да, изменится, в лучшую сторну, станет яснее что автор имел ввиду

да, изменится, в лучшую сторну, станет яснее что автор имел ввиду

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

Я не говорю что это критично

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

если бы не было то я бы не писал 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])) }

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

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

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