go-collections: структуры данных для Go с поддержкой дженериков

[dopusteam]

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

[idsulik]

свою библиотеку (написанную вчера)

idsulik released this Jul 12 - если 12 июль - это вчера, то вы правы

И не раскрыта тема 'эффективности', упомянутая в заголовке

справедливое замечание, пойду исправлю

[dopusteam]

Ну, судя по коммитам, skip list и graph вы добавили только вчера

[idsulik]

библиотеку (написанную вчера)

но вы писали про библиотеку.

даже если эти структуры добавлены вчера, то что в этом такого? я может сегодня тоже добавлю еще структуры, к примеру - bloom filter

[dopusteam]

Согласен, выразился некорректно.

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

[idsulik]

вводите читателя в заблуждение,

каким образом? и как вы предлагаете сделать?

[idsulik]

Готово, обновил статью и написал в начале, что это моя библиотека

[Sly_tom_cat]

А в юнит-тестах использовать if-ы вместо requeire/assert - это принципиально/религиозные соображения?

[idsulik]

Если вам кажется, что require/assert лучше, то можете тут объяснить или же создать pull request, гляну и буду рад принять или сам поменять и запушить)

[Sly_tom_cat]

Честно говоря немного лень делать все это...
Просто покажу пример
if s == nil { t.Error("Expected new set to be non-nil") }
заменяется на
require.NotNil(t, s) - провалит тест сразу
или
assert.NotNil(t, s) - позволит тесту продолжиться дальше но тест уже будет считаться провалившимся.

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

[idsulik]

Спасибо, я думал, что будет более веская причина поменять одно на другое)
Но да, согласен, лаконично, как дойдут руки поменяю

[Sly_tom_cat]

И кстати не совсем понял по какой причине очередь и стек сделаны на слайсах?

По мне имея linkedList - стек и очередь делаются просто алиасами на методы linkedList.

Но тут конечно зависит от задач - где-то и слайс под капотом будет хорош, а где-то лучше бы все-таки linkedList.

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

[idsulik]

пока на слайсах, в планах добавить еще и на linkedin, чтобы можно было выбрать нужный подход под задачу, как это сделано в Java.

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

[starwalkn]

Мало чем похоже на статью, это больше документация к вашей библиотеке. И какие преимущества перед проверенным https://github.com/emirpasic/gods с 16к звездами?

[idsulik]

Не знал про gods, у того и другого есть свои плюсы и минусы, к примеру, в go-collections есть Trie, есть SkipList, в планах добавить Bloom filter

[Sly_tom_cat]

Ну вот только там не модно-молодежно на дженириках. Там все по хадкору: на настоящих пустых интерфейсах. ;)

[starwalkn]

Коммит 8 месяцев назад был по переводу на дженерики.

[idsulik]

А это что-то меняет?) ощущение, что целенаправленно ищете к чему-бы придраться

[starwalkn]

Нет, никак не придраться, я хотел понять, в чем же преимущества вашего пакета перед gods, и вы ответили. А коммент про дженерики это ответ для @Sly_tom_cat

[Dreddsa]

Звезду поставил - автор молодец, так держать.
Но go - это про горутины там, многопоточность... А структуры в библиотеке без защиты от гонок.
Будет время/желание - можно проработать.
Удачи

[idsulik]

Спасибо большое. Да, в планах сделать отдельный пакет sync и поместить туда thread safe реализацию структур