Comments 15
Если писать сразу с учётом всех этих «краевых» эффектов, то можно, как правило, создать программу, которая будет в 5-10 раз быстрее, но оно вам надо? Как правило ответ — «нет, не надо», возможность быстро менять программу при изменении требований важнее.
Но, собственно, Go на выжимание «всех соков» из процессора и не претендует — для этого C++ есть (хотя, в последнее время, rust начал на ту же нишу претендовать).
ЗЫ: не очень понятна постановка вопроса вообще, почему именно функциональные аргументы? Как же простота?
Для каждой задачи свой инструмент. Второй способ (функциональные аргументы) подразумевает что будет инициализироваться "сложный" со множеством параметров или "тяжелый" на ресурсы объект, который будет существовать на протяжении всей жизни программы или библиотеки. Тот же метод Dial упомянутый вами, обычно вызывается один раз. Также обычно функциональные аргументы используются только в Публичных методах/функциях. Если у вас внутренний апи, который вы вызываете тысячу раз, то применять там функциональные аргументы всегда плохая идея.
Кто-то выше писал что "Синтаксический сахар вроде должен уменьшать количество кода и делать его проще". Так и есть с точки зрения пользователя библиотеки, т.е. автору библиотеки таки да, надо написать чуть-чуть больше, в отличие от первого способа, чтобы конечному пользователю было легче жить.
Интересная статья одного из "столпов" Go — Dave Cheney https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis где он приводит третий вариант и подробно все разбирает с плюсами и минусами.
PS: а что, если передавать в такой конструктор функцию от (*класс, ...int) или в крайнем случае ...string? Ещё гибче получается, причем второй аргумент функции оказывается опциональным списком — надо тебе, чтобы у фичи было много параметров, все запихиваешь в строки и передаешь, надо ноль — пишешь функцию от одного аргумента *класс, и хватит.
Необязательные аргументы в функциях Go