В статье я не сомнивался в решаемости проблем, вопрос был один - насколько дженерики повысят производительность в конкретном случае. Более того в статье так-же сказано, что дженерики позволяют писать более лаконичный и понятный код, о чем и сказано в вашем коментарии, насколько я вижу.
Разверните свою мысль, пожалуйста, зачем переписывание на exists?
После получения результата из стека нам в любом случае надо преобразовать значение, чтобы смочь его использовать. Значит убирать его в текущих тестах смысла нет - тогда не понятно, что тестируется.
Моя статья не про устройство дженериков, и не про устройство interface{} с преобразование типов (это две достаточно большие темы, которые тянуть на статью каждая), а только про сравнение производительности. Поэтому и глубоких теоретических материалов в ней нет.
В случае с дженериками у нас есть необходимость объявлять переменные возврата только ради значения по умолчанию для переменной типа дженерика. На текущий момент я не нашел как вернуть такое значение без указанного механизма. Т.е. использование происходит в момент, когда стек у нас пустой, в 3й строчке функции (хоть и неявное). Так что на текущий момент я не вижу других способов реализации.
Я только в начале пути golang, поэтому мне сложно сейчас будет сформулировать свои ожидания. На текущий момент исследую возможности языка. Но как только за плечами будет больше проектов, то мне действительно будет интересно обдумать ответ на данный вопрос. (Просто еще мало шишек набил на golang, чтобы понимать какие еще боли можно решить с помощью дженериков, а для каких лучше придумать другой механизм)
Очень интересная тема исследования. В статьях говорят, что дженерики компилируют несколько версий кода с нужными типами (т.е. копипаста, но в бинарном виде). Такое поведение с рефлексией действительно неожиданное.
Вопрос как обычно в нагруженности сервиса. Давайте представим, что у нас есть небольшой домашний проект. Скажем на 100-150 человек (начальная аудитория). Код в процессе активного переписывания, допиливания и внедрения фич. И вот если тут на одну чашу весов положить производительность, а на другю читаемость, то в этом случае я выберу читабельность. Моя статья была с позиции домашенго пет-проекта на небольшое количество пользователей. Когда мы приходим в мир enterprise, то там совершенно другой расклад. И иногда читабельностью жертвуют даже ради 2-3%, поскольку от общего потребления получается достаточно большая величина. Мой вывод не панацея (это надо поправить в статье) и направлен он на небольшие советы. А для более серьёзных проектов - приведены цифры, и по ним будет возможно уже иметь картину для принятия решения на конкретном проекте.
Не могу уловить взаимосвязь, раскройте суть вашей претензии подробнее, пожалуйста.
В статье я не сомнивался в решаемости проблем, вопрос был один - насколько дженерики повысят производительность в конкретном случае. Более того в статье так-же сказано, что дженерики позволяют писать более лаконичный и понятный код, о чем и сказано в вашем коментарии, насколько я вижу.
Разверните свою мысль, пожалуйста, зачем переписывание на exists?
После получения результата из стека нам в любом случае надо преобразовать значение, чтобы смочь его использовать. Значит убирать его в текущих тестах смысла нет - тогда не понятно, что тестируется.
Моя статья не про устройство дженериков, и не про устройство interface{} с преобразование типов (это две достаточно большие темы, которые тянуть на статью каждая), а только про сравнение производительности. Поэтому и глубоких теоретических материалов в ней нет.
В случае с дженериками у нас есть необходимость объявлять переменные возврата только ради значения по умолчанию для переменной типа дженерика. На текущий момент я не нашел как вернуть такое значение без указанного механизма. Т.е. использование происходит в момент, когда стек у нас пустой, в 3й строчке функции (хоть и неявное). Так что на текущий момент я не вижу других способов реализации.
Я только в начале пути golang, поэтому мне сложно сейчас будет сформулировать свои ожидания. На текущий момент исследую возможности языка. Но как только за плечами будет больше проектов, то мне действительно будет интересно обдумать ответ на данный вопрос. (Просто еще мало шишек набил на golang, чтобы понимать какие еще боли можно решить с помощью дженериков, а для каких лучше придумать другой механизм)
Нет, а что вас именно смутило в статье?
Очень интересная тема исследования. В статьях говорят, что дженерики компилируют несколько версий кода с нужными типами (т.е. копипаста, но в бинарном виде). Такое поведение с рефлексией действительно неожиданное.
Вопрос как обычно в нагруженности сервиса.
Давайте представим, что у нас есть небольшой домашний проект. Скажем на 100-150 человек (начальная аудитория). Код в процессе активного переписывания, допиливания и внедрения фич.
И вот если тут на одну чашу весов положить производительность, а на другю читаемость, то в этом случае я выберу читабельность.
Моя статья была с позиции домашенго пет-проекта на небольшое количество пользователей.
Когда мы приходим в мир enterprise, то там совершенно другой расклад. И иногда читабельностью жертвуют даже ради 2-3%, поскольку от общего потребления получается достаточно большая величина.
Мой вывод не панацея (это надо поправить в статье) и направлен он на небольшие советы. А для более серьёзных проектов - приведены цифры, и по ним будет возможно уже иметь картину для принятия решения на конкретном проекте.