Поэтому и говорю - имхо. Видеть Rec и всегда держать в голове, что в определенных контекстах это на самом деле генерик, а параметр берется из другого места - сложнее. И это ради возможности не писать три символа? Тогда уж вводить аналог this, но для типов

Ну... Может и забыл, а может и не знал. Но вопрос же был об интерфейсах на микросервисах. Вот это оно самое.

P.S. Там же написано об A-Frame прямо в следующем предложении :)

В тайпскрипте кстати есть тип this

Это может быть далеко и не 3 символа. И да с дженериками набо многое помнить. Ведь параметр может прийти как от класса так и от функции. Вообще language server в этом помощник

Именно поэтому явное лучше неявного

Во первых это опчионально, так же как и любой другой вывод типов

может лучше уж
class Rec<T> {
  prev: Self
  next: Self
}
?

с такой позицией Хаскель вообще жуткий ЯП ведь там неявный параметрический полиморфизм)

Не лучше, потому что можно сделать еще и так:

class Foo<K,V> extends Base<K,V> {
  clone(): Base {
  }
}

Конечно можно ввесли Super на равне с Self. Но не знаю

В некотором смысле это так и есть - я за локальный вывод типов типа var x = ..., но против глобального, тк считаю наличие единого source of truth в сигнатуре важнее возможности сэкономить несколько нажатий

Фишка мелких утилиток, на которые Go и рассчитан, в том, что, ну, не нужно там 20 вариантов min на все случаи жизни. Обычно, парочки хватает. И обычно, они, всё-равно специализированные какие-нибудь под нужды конкретной утилиты, и их, всё равно, необходимо писать. Что проще: написать специализированный min или же реализовать класс Ord для того, чтобы воспользоваться полиморфным, поимев с этого все проблемы с неявной передачей словарей? Я вот не знаю.

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

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

ну и на го пишут достаточно большие аппы, всякие докеры.

Вот в дотнете была такая же история. Там есть 16 вариантов Func, Action, Tuple и тэдэ - по количеству аргументов. Когда предложили ввести variadic generics, чтобы сделать это как следует, мейнтейнеры сказали «ну это дофига пилить придется, а так оно костыльненько но работает»

> P.S. Там же написано об A-Frame прямо в следующем предложении 🙂

Да я об этом тоже написал) То есть как бы уже противоречие. С одной стороны единственный, а в следующем же предложении перечислены альтернативы)

Как переиспользовать? Вот есть у меня, условно, grep - она строки молотит в файлах. А есть какая-нибудь xinetd, которая соединения пробрасывает. Функциональность очень разная. Всё разное. Не понятно, что можно переиспользовать.

Это концепция unix. Система специально так проектировалась, чтобы можно было изолировать домены ответственности и домены ошибок в небольших независимых, ортогональных по функциональности, процессах, чтобы в целом всё работало стабильнее.

Противоположностью к unix, кстати, были lisp-машины, в которых всё было монолитно, один image на всё, общий код и т.д. и т.п. Ну и где сейчас lisp-машины?

ну,
1. если у вас функция на 16 параметров, вы делаете явно что-то не так.
2. лучше это чем отсутсвие обобщенных типов в принципе.

1. Функция вида printf может и должна иметь сколько хочешь аргументов, а не только 16
2. Это факт, просто аналогичная ситуация на другом уровне )