#golang #linq #дизайн_языка
Закрыт. На этот вопрос невозможно дать объективный ответ.
Ответы на него в данный момент не принимаются.
Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы на него можно было дать ответ, основанный на фактах и цитатах, отредактировав его.
Закрыт 8 месяцев назад.
У меня есть вопрос про linq. Почему в Go до сих пор нет в стандарте этой чудесной
штуки. Всё, что я слышал до сих пор по эту технологию от гоферов, так это то, что это
не по-гоферному. К сожалению, этот аргумент меркнет, когда тебе нужно сделать пару
группировок, а потом ещё пару проекций. В итоге, 3-4 строки трансформируются 3-4 экрана.
По-моему выбор очевиден. Да, есть проблемы. Например, для реализации LINQ, скорее всего
потребуется reflect, что приведёт к просаживанию производительности. Но при этом, не
стоит забывать, что с таким же успехом, можно сказать, что и сам reflect приводит к
тому, что производительность просаживается. Так давайте от него откажемся. Конечно,
этого никто не сделает. Вопрос в том, где корректно использовать ту или иную технологию.
Кстати говоря, аналог reflect есть. Это статическая генерация кода. Например, так
реализованы некоторые не стандартные пакеты в Go для работы с JSON.
Для ознакомления с технологией LINQ в го, привожу ссылку.
Я завёл issue в основной репе golang. Требуется достаточно весомое обоснование для
открытие такого issue.
Продолжая моё исследования linq для golang, я нашёл следующее. Здесь человек производит
сравнение koazee и обычных циклов. Легко заметить, что он приходит к выводу, что koazee
не сильно уступает нативному golang. Обсуждение здесь. К слову, скажу, koazee -- лучшая
реализация linq для golang. Лучшая == самая быстрая и функциональная на момент 09.07.2019.
Одна из неудобных вещей в golang и linq -- это способ обращения к лямбдам. Так как
в golang нет шаблонов, придётся писать конструкции, которые похожи на эти:
From(cars).Where(func(c interface{}) bool {
return c.(Car).year >= 2015
}).Select(func(c interface{}) interface{} {
return c.(Car).owner
})
Всем очевидно, что данная конструкция громоздкая и неудобно читается. Более того,
здесь происходит приведение интерфейса к типу, что также не является хорошим тоном.
В оправдание скажем, что отказ от такого рода конструкций, приводит к ещё более неудобным
вещам: нескольким функциям, которые могут оказаться ещё менее читаемые, особенно, если
разработчик не аккуратен. Спещу заметить, с большой вероятностью, эти функции будут
возвращать ошибки в качестве возвращаемых значений, что только увеличит объём кода.
В go-linq создателям удалось добиться эмуляции шаблонов:
From(cars).Where(func(c Car) bool {
return c.year >= 2015
}).Select(func(c Car) string {
return c.owner
})
При этом, скорее всего (если ничего не изменилось), go-linq много медленнее, koazee.
Взято отсюда. 09.07.2019
Ещё одна библиотека, которая ничего не упоминает про linq, но реализует похожий
функционал. Не поддерживается, к сожалению. 09.07.2019
Ответы
Ответ 1
На этот вопрос вам точно ответят только в Go Team, но ответ скорее всего будет около следующего. Во-первых, для LINQ à la C# нужны обобщённые коллекции типа IEnumerable, которые если и появятся, то только в Go 2.0. На интерфейсах это всё пойдёт через отражение, что медленно, и местами небезопасно. Во-вторых, само название «Language Integrated Query» говорит, что нужна поддержка со стороны языка. Это означает новые ключевые слова, причём не одно. Учитывая, что Go Team крайне неохотно добавляет ключевые слова, их добавление крайне маловероятно. Не говоря уже о том, что это синтаксический сахар. В-третьих, даже если опустить синтаксис, для LINQ понадобятся анонимные функции с выведением типов, что является ещё одним расширением языка, и что вряд ли появится даже в Go 2.0.
Комментариев нет:
Отправить комментарий