Ты просто на C++ лично не писал :)

А зачем мне писать на C++?

Removed msg from Ross. Reason: new user + external link

чо? охренели линк на пеп удалять?

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

А сигнатурами-то и не хотят типы (классы) выражать. Прикинь? Не тот язык

gorm - вобще не надо юзать

Я буду рад если посоветуете другую ORM. Правда вы возможно скажете что ORM вовсе не нужно использовать. Но я бы хотел делать миграции на основе описанных структур и операции над БД совершать тоже через модели

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

И это плохо

и не тот компилятор, и не те цели

И это плохо

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

Я буду рад если посоветуете другую ORM. Правда вы возможно скажете что ORM вовсе не нужно использовать. Но я бы хотел делать миграции на основе описанных структур и операции над БД совершать тоже через модели

Не будешь! Просто учи SQL

К тому же компилятор не может проверить код на то, что все контракты исполнены

Не будешь! Просто учи SQL

Это потому что все ORM в Go не очень? Или вы фанат голого SQL. Мне как-то не очень хочется отказываться от уровня абстракции

Не будешь! Просто учи SQL

орм не нужны?)

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

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

Это потому что все ORM в Go не очень? Или вы фанат голого SQL. Мне как-то не очень хочется отказываться от уровня абстракции

все ORM в Go не очень. Если ты не искусственный интеллект. И все эти ORM написаны не искусственым интеллектом. :(

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

все ORM в Go не очень. Если ты не искусственный интеллект. И все эти ORM написаны не искусственым интеллектом. :(

какой-то пунктик на ИИ?

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

Читаемость кода снижают текучие абстракции и оверинжиниринг

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

Большинство, но далеко не все. Тот же хаскель к примеру, насколько я знаю, не проверяет выполнение всяких монадических и функторных законов.

Да и не только в Go

Я буду рад если посоветуете другую ORM. Правда вы возможно скажете что ORM вовсе не нужно использовать. Но я бы хотел делать миграции на основе описанных структур и операции над БД совершать тоже через модели

орм норм, но в го советую искать орм на кодогенерации, рефлексия под капотом зло, или использовать билдеры запросов типа https://github.com/Masterminds/squirrel

орм норм, но в го советую искать орм на кодогенерации, рефлексия под капотом зло, или использовать билдеры запросов типа https://github.com/Masterminds/squirrel

Спасибо!)

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

Субъективное, люди испокон веков используют абстракции для борьбы со сложностью. Читаемость снижают только те не текущие абстракции, которые вы не понимаете

Иначе бы вы писали на ассемблере, ибо там нет абстракций

Когда смотришь, какие запросы генерит тот же Django ORM - просто стыднор становится. Django ORM на Python тоже не роботы делали :)

Субъективное, люди испокон веков используют абстракции для борьбы со сложностью. Читаемость снижают только те не текущие абстракции, которые вы не понимаете

А вот тут согласен на все сто.

Причём у многих используемых языков не так уж и много абстракций.

Без абстракций мы бы так и сидели в пещерах, а еду бы добыли охотой

Большинство, но далеко не все. Тот же хаскель к примеру, насколько я знаю, не проверяет выполнение всяких монадических и функторных законов.

Это да, но можно валидировать внешней системой доказательств типа Coq + написать property для quickcheck тестов

Субъективное, люди испокон веков используют абстракции для борьбы со сложностью. Читаемость снижают только те не текущие абстракции, которые вы не понимаете

испоконно люди стремятся тратить меньше энергии на подумать головой. К добру это не приведет :(

испоконно люди стремятся тратить меньше энергии на подумать головой. К добру это не приведет :(

Топ кек. Вы знаете о термине технологической сингулярности?

А ещё знаете ли вы, что она достигнута уже очень давно

да, Сингулярность - это в мозгу, когда читаешь Манускрипт мертвой птицы. А в жизнь из это й сингулярности ничего не выходит.

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

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

+1

А уже пятница?

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

нет, не пятница, а то я бы и не то сказал :)

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

Очевидно, что нет. Более того, в го практически невозможна композиция абстракций

Хотя и в ООП с ней сложно ибо неконтролируемая мутабельность

А программирование это не "композиция абстракций"?

А программирование это не "композиция абстракций"?

В том числе. В го программирование - это по большей части описание конкретных алгоритмов

Используя встроенные абстракции

вот и хорошо!

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

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

"Вообще не понимая" и "понимая достаточно, чтобы пользоваться" - разные вещи

"Вообще не понимая" и "понимая достаточно, чтобы пользоваться" - разные вещи

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

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

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

причём тут хаскель?

хаскель слишком отличается от Go чтобы нормально сравнивать

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

+1

я вообще в плане дженериков люблю сравнивать Go и Java, потому что Go тупо повторяет путь Java

причём тут хаскель?

Без хаскеля сложно понять что такое нормальные дженерики, ADT, абстракции

там тоже изначально не было дженериков и был Object (аналог interface{} из Go)

Без хаскеля сложно понять что такое нормальные дженерики, ADT, абстракции

лолвут

Без хаскеля сложно понять что такое нормальные дженерики, ADT, абстракции

Зачем ADT тащить в императивный язык?

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

Без хаскеля сложно понять что такое нормальные дженерики, ADT, абстракции

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

я про путь в плане дженериков сейчас

в джаве была такая же ситуация с их отсутствием как сейчас в Go

а появятся же, не? мне казалось что в 2.0 анонсировали

Зачем ADT тащить в императивный язык?

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

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

Ну ок, можно любой ML взять

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

Так у меня ща бомбить начинает. Такой вопрос на адекватность: на кой хер превращать Go в хаскель?

Причём я не против дженериков, а всеми руками за.

Так у меня ща бомбить начинает. Такой вопрос на адекватность: на кой хер превращать Go в хаскель?

не ну паттерн матчинг еще никому нигде не мешал так-то

ERROR: S client not available

Так у меня ща бомбить начинает. Такой вопрос на адекватность: на кой хер превращать Go в хаскель?

Если добавить адт и дженерики го превратится в хачкель? Лолвут

я вот что-то сильно сомневаюсь в пользе адт для go

очень сильно сомневаюсь

и удастся ли их вообще нормально впихнуть

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

я вот что-то сильно сомневаюсь в пользе адт для go

Да хотя бы нормально ошибки можно будет возвращать

будет Go++ )))))

Да что там дженерики, если не прдиётся больше писать каждый раз if err != nil { return err }, то это уже будет прогресс огромный.

и удастся ли их вообще нормально впихнуть

А что там впихивать то?

Добавить нормальные кортежи и типы суммы

И все

О! Кстати Go++ это будет хороший вариант при условии хорошего пиара

Добавить нормальные кортежи и типы суммы

можно пример кода?

куча народу на Go++ заработает кучу денежек :)

О Боже, неужели хипишь про дженерики до сих пор идёт

Сегодня с утра читал рекламный прост на хабре, про некий цветок Linux, где нет ничего лишнего. Даже systemd нет. Лишнее - это работа! Но статья хорошая

О Боже, неужели хипишь про дженерики до сих пор идёт

Да, и будет дальше идти

можно пример кода?

(a, b, c) - кортеж type SType enum { Int int String string Nothing } s := SType.Int(5) switch s { case SType.Int(i): ... case SType.String(str): ... case SType.Nothing: ... }

жяль, что не все понимают, что лишнее (не нужное) - это тоже тяжелая работа :(

жяль, что не все понимают, что лишнее (не нужное) - это тоже тяжелая работа :(

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

(a, b, c) - кортеж type SType enum { Int int String string Nothing } s := SType.Int(5) switch s { case SType.Int(i): ... case SType.String(str): ... case SType.Nothing: ... }

ааа, то есть если мы сейчас пишем if err != nil { return err }, то с adt мы сможем писать здоровый switch вместо этого

прям отлично

ааа, то есть если мы сейчас пишем if err != nil { return err }, то с adt мы сможем писать здоровый switch вместо этого

С адт не проблема добавить оператор ?

С адт не проблема добавить оператор ?

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

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

Большая на самом деле

Большая на самом деле

почему?

почему?

Что делать, если возвращаемых значений несколько? А если ошибку надо преобразовать?

И ещё какие-то корнер кейсы были, из кстати тут же обсуждали

ну вообще да, есть корнер кейсы, но их не так уж и много

но был где-то даже issue на гитхабе

который как раз предлагал ввести оператор позволяющий преобразовать ошибку перед возвратом