Все есть тут: https://dub.pm/package-format-json

Спс

https://dlang.org/blog/2017/02/13/a-new-import-idiom/ о это работает что ли?

> Вообще на гошке всю жизнь было обобщенное программирование. Просто подход отличается от С++ или D. Делается все через рефлексию (богомерзко и хорошо бы выпилили вовсе)

https://t.me/dlangru/201306https://t.me/dlangru/201306
> что конечно не мешало гошникам рассказывать про проблемы дженериков, оправдывая отсутствие в их идеальном ЯП обобщенного программирования, приемлемого в системной разработке.

Если что, я в курсе про интерфейсы.

> или через кодогенерацию

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

> Но даже и тут скоро завезут дженерики как у всех

https://t.me/dlangru/201303
> Если сейчас спросить гошника что там с обобщенным программированием, то он скорее-всего ответит, что решение вовсю разрабатывают, т.к. оно, внезапно, для его задач весьма пригодилось бы

Дженерики в гошке не вводились не потому что они "не нужны" или "и без них хорошо", а потому что не хотелось вводить фичу ради фичи абы как. Да, 10 лет обсуждали как бы это сделать лучше. Чтобы не закончить как С++ с очень крутыми и выразительными темплейтами. Которые правда уронили время компиляции в дно, сделали сообщения об ошибках в компиляторе и дебаг нечитаемыми и сам код превратили местами в дикое месиво. Вот всего этого хотелось бы избежать. Одновременно с этим делать как в D, превращая компилятор в космолет и ловить потом десятилетиями ошибки компилятора на миксине внутри шаблона внутри миксина - тоже так себе перспектива. В итоге спустя десятков экспериментов в стол, таки нащупали компромис и приняли пропоузал (до этого было отклонено в районе 10 пропоузалов, часть с реализациями даже).

Да, можно написать на D код порождающий го-код. Только вот в гошке для этого уже сделана удобная инфраструктура, в стандартную библиотеку выведен интерфейс компилятора и можно удобно парсить ast. И получаются правда приятные и простые тулзы на го, которые генерируют тебе го-код.

Про это я и пишу - нести любую чушь, лишь бы не признавать проблем.

Какой-то беспредметный хейт. Критика должна быть по делу, а не "у вас нет дженериков, да как вы вообще живете?!"

Ты вообще читал то, что я писал? Я не критиковал ни один из ЯП. Или ты хочешь обмануть здесь кого-то?

Похоже, что ты критиковал всех гошников, типа они все хором одно и то же мнение высказывали

Не всех, да и речь про людей вообще, а не именно про гошников.

так никто не делает) особенно в компаниях говоря про свои продукты, особенно во вселенной где победил капитализм... как говорится, пластмассовый мир победил :)

Не хотели как в С++ и D, это можно понять. Но ведь куча языков с генериками было и других вот уже лет 40, не то чтобы это была прям супер новая задача.

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

Я хотел рассказать чем руководствовались разработчики го, когда не вводили дженерики (на докладе Фицпатрика был - он хорошо рассказывал стратегию развития языка). Ну и го - не универсальный язык (таких вообще нет и на попытки использовать тот же С++ для всего на свете - без слез не взглянешь). В тех задачах где он традиционно используется необходимости в дженериках особо не чувствуется. Кодогенерация вполне справлялась. Когда их завезут - станет ли лучше? Думаю да, сразу на ум приходят обобщенные библиотеки паттернов конкуретного кода. Но это явно не "минус языка на который все закрывают глаза", а просто фича, которая по приоритетам стояла не так высоко, как что-то что было нужно. Например, человеческий вендоринг - вот с ним дров наломали знатно, благо вроде с введением модулей устаканивается ситуация (да и то авторы отдельных библиотек бузят по поводу семвершна).

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

По-моему без генериков не сделать нормально базовые операции типа xs.map(...).map(...).filter(...).reduce(...). А без них современный язык невозможен. Ручные императивные циклы с добавлением в мутабельные массивы это каменный век.

Просто по философии языка - они очень не хотят повторять ситуацию с питоном 2/3 и ломать обратную совместимость, дробить комьюнити (прямо из доклада Фицпатрика пример). Одновременно с этим превращаться в сборник костылей на все случаи жизни как С++ - уйти от этого - вообще была изначальная мотивация сделать Go. Поэтому введение новых фичей в язык стараются делать очень аккуратно.

> на попытки использовать тот же С++ для всего на свете - без слез не взглянешь

а где с++ не подходит?

Ща распишу подробно. Есть пакет прямо за авторством Роба Пайка с обобщенной реализацией и map и filter и reduce. Очень простой, такое и самому написать не сложно, десяток строчек кода + тесты. Сделан на рефлексии, но к использованию в продакшене не рекомендуется (как раз из-за рефлексии). Про каменный век - искать какие-то радикально новые подходы в гошке - это не туда. Язык на самом деле максимально консервативен и правильней его воспринимать как С, но максимально заточенный под написание сетевых демонов. Циклы - в го есть for, который для коллекций работает как foreach, причем с копированием. То есть условно for _, val := range arr { в теле работаем в val, который копия элемента из массива } - по сути тоже самое, что map. Можно ли внутри такого for мутабельно работать с массивом - да, можно for i := range arr { arr[i] - используем уже сам элемент массива }. Ну то есть язык позаботился о том, чтобы программист явно контроллировал как он по коллекции ходит и вариант по-умолчанию иммутабелен для коллекции.