да как как

всё так же, всё то же

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

(про go-gen) пишешь коммент, он его парсит и генерит несколько функций для разных типов

Минус чтения - это охрененный минус

Ну и чтение кодогенерации минус

Я про пример ситуации

func fact(n int8) int8 { .... } func fact(n int64) int64 { }

Я как то не могу придумать ситуации когда такое возникает

1. open up your browser 2. navigato to "www.google.com" 3. in the search-bar type in: "why do we need generics. programming." 4. click the "search" button 5. select either of the first 5 (non-ad) results and.. 6. voila!

Ну и чтение кодогенерации минус

В большинстве случаев, можно просто так написать

А более жизненные примеры, которые не связаны с матаном?)

func fact(n int8) int8 { .... } func fact(n int64) int64 { }

а для int8 n! не выйдет за int8?

а для int8 n! не выйдет за int8?

С потолка взял

А более жизненные примеры, которые не связаны с матаном?)

Обработка строк и байтовых массивов

1. open up your browser 2. navigato to "www.google.com" 3. in the search-bar type in: "why do we need generics. programming." 4. click the "search" button 5. select either of the first 5 (non-ad) results and.. 6. voila!

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

ой да гонит он всё

нет никаких кейсов у дженериков

так, поумничать захотелось

Кстати, почему мы просто не можем свести к необходимому типу данных и передать его в функцию?

вон, даже пример с факториалами не подошёл для дженериковости

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

спонтанно приходит в голову случай когда пишешь контейнер-класс, сортировку и т.д.

спонтанно приходит в голову случай когда пишешь контейнер-класс, сортировку и т.д.

Ну да, в этом случае действительно печально

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

плюс compilation time можно дженериками загубить

Останется по очевидным причинам

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

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

Неудобно. Ну и людям хочется repl, которого в go нет и быть не может

почему не может?!

https://www.google.ru/search?newwindow=1&safe=off&ei=XtUJW5KIM4bt6AS7zoeIDA&q=golang+repl&oq=golang+repl&gs_l=psy-ab.3..0i67k1l2j0l8.48266.49492.0.49756.7.7.0.0.0.0.61.366.7.7.0....0...1c.1.64.psy-ab..0.7.361...0i7i30k1j0i10k1j0i8i7i30k1j0i13k1.0.w0ey7CtLpw0

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

C и C++ языки слаботипизированные

Я как то не могу придумать ситуации когда такое возникает

int vs int32 vs int64. Тебе на вход в функцию прилетает параметр и его надо скастить в int, например

В int64 все кастится. Гиде пираблема?

Кстати, почему мы просто не можем свести к необходимому типу данных и передать его в функцию?

Можем. Просто надо будет писать кучу боилерплейта

Не кучу

В int64 все кастится. Гиде пираблема?

Проблема в написании однообразного кода

Разнообразный код плохо читается...

В int64 все кастится. Гиде пираблема?

Давай чуть сложнее: на вход 2 параметра, каждый может быть int/int32/int64, на выходе - 1 и тоже int/int32/int64

И уже 27 вариантов

27 вариантов вызова, да. Не вижу проблемы

Объясню, откуда такая боль: где-то в api мы имеем int, где-то uintptr, где-то int64, где-то uint32

Нет, это не я так сделал, а такая ситуация в go

Вот тот же PollFD

Который uint32

Ну скасти параметр при вызове, и возврат тоже скасти

Ну скасти параметр при вызове, и возврат тоже скасти

Там не вызовы, а поля структуры :(

Напиши конвертер :)

Не, я понимаю, о чем ты

Но в реальности это проблемой не станет никогда

Я не понимаю, почему я должен это делать за машину

Но в реальности это проблемой не станет никогда

Бха! Да я уже в это встал.

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

Бха! Да я уже в это встал.

Гиде?

Гиде?

unsafe

Сделают жинерики на рефлекте, будет то чего стараемся избегать

Сделают жинерики на рефлекте, будет то чего стараемся избегать

И будут тормоза

Если самому писать функцию рефлектами для джинерика

Генерики - это кодогенерация, так-то. На рефлексах сделанное надо иначе называть

unsafe

И что там?

Так так же можно свой тип делать с функциями преобразования

Не дженерики, конечно, но...

Так так же можно свой тип делать с функциями преобразования

Медленно

Медленно

Дженерики быстрей не будут

Не, будут, при компиляции вызов нужного метода преобразования... но это автоматизация кодогенерации

Дженерики быстрей не будут

static dispatch vs "dynamic dispatch"

И что там?

Постоянный явный кастинг :(

(под "dynamic dispatch" будем понимать конвертацию, хотя это и не так)

Постоянный явный кастинг :(

но это же и есть строгая типизация

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

ну, в общем, это синтаксический сахар, который бы не помешал

myintvalue.(int64) простейший джинерик

ERROR: S client not available

не

генерик - это параметрический тип.

Ну я шутя

производительность в движке это приоритет #1

Ты прав

фактически, при создании конкретного типа на основе параметрического генерится соответствующий код и прописываются соответствующие вызовы

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

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

Метод .String()

Какое-то начало

а?!

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

Читая чужое я часто на дженериках в слип вхожу..

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

а?!

В го много где, если есть этот метод у типа, например в fmt используется, если нужна строка для вывода этого типа

Яву не трогал, кроме jira confluence и других вещей где нужны были костыли или понимание что там ваще ей надо

А, ну книжку по андроид приложениям листал

ну вот PHP это уже издевательство над современным железом. Гоняем на тачках с 12 ядерными 4 гигагерцовыми процами, а высераем 300 мс и 200req/s

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

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

+100500

Все просят генерики и мне интересно, чем они могут помочь

Например можно будет реализовать итераторы. А если добавить типы суммы, то и нормальную обработку ошибок без исключений. Будет проще работа с мьютексами всякими, можно будет делать кастомные каналы (с логированием, например). Будет возможность написать нормальную библиотеку с контейнером и нормально её использовать.

При этом всё это будет type safety

Слишком сложно

Дженерики для слабаков

Так слишком сложно или для слабаков?

Так слишком сложно или для слабаков?

Мне как пхпшнику дженерики не нужны

Мне как пхпшнику дженерики не нужны

Так вам там и статическая типизация не нужна

Типизация заебись

Мне как пхпшнику дженерики не нужны

Смотри запилят ведь) https://wiki.php.net/rfc/generics

Дженерики - ересь от жавистов

Мне как пхпшнику дженерики не нужны

и где не нужны? уточни пожалуйста

и где не нужны? уточни пожалуйста

А где они нужны?

А где они нужны?

в rust, go и т.д. например)

Дженерики - ересь от жавистов

Кек. А при чём тут жависты?

в том же рфц пхпшном вполне разумная аргументация