Фича языка описывается так, словно в шарпах/жабе нельзя строить API на основе функций, что не так. «Вместо иерархии объектов в Go используется композиция функций» — то есть такого паттерна не существует в Go, но это не означает, что он единственно верный в C#.
2. Интерфейсы
По поводу структурной типизации: она выигрывает в гибкости, но теряет в строгости семантики — один метод обслуживает все интерфейсы сразу, и Go, например, не имеет инструментов для разделения. Так что, думаю, это просто трейдофф между явным и неявным, то есть не хорошо и не плохо.
В Go есть ещё одна интересная особенность — Zero Value
Особенностью это не является. Так как я не гошник, механизм «внешне» особо неотличим относительно «оппонентов», из-за чего весь раздел звучит странно. Единственное, про «опасное состояние» в рамках C#/Java можно назвать «ошибку на миллиард», но современный язык предлагает использование nullable reference types/Optional types, что, признаю, только частично закрывает проблему. Но это замечание справедливо только для reference types, и, как я знаю, Go в части этих же типов делает совершенно ничего, что сводит всё к тому, о чём я писал выше.
5. Concurrency-примитивы.
«Всё это рождает огромное количество конкурентных паттернов, характерных именно для Go» — что говорит лишь о том, что создатели языка решили сделать ставку на эти примитивы, сделав их частью языка, а не о том, что они невыразимы на других языках.
Пример 1. Интерфейсы.
«Не напоминает ли это паттерн "Стратегия"?» — напоминает функцию, требующую выполнения определённого контракта у передаваемого объекта, а не паттерн, смысл которого заключается в рантайм-переопределении поведения у сущности.
Пример 2. HTTP-хендлеры.
Относительно паттерна здесь я уже не могу быть так категоричен, но в аргументации прослеживается тот же спич о функциях и объектах. Да, например, в ASP.NET единицей маршрута, обычно, является метод у объекта-контроллера, но это не значит, что в шарпах паттерн «урл-функция» невыразим.
Пример 4. Functional Options.
Специфичный паттерн в лице... массива функций, посыпанный сахарком?
«Какие паттерны отлично реализуются в Go?»
Те, в которых явно не используется наследование.
С самим выводом в статье можно согласиться, но вступительный текст и само содержание способствуют не ассимиляции языковых мигрантов, а представляют лишь кривое сравнение идиоматичных паттернов разных языков в лоб.
Я, конечно, не "минусатор", номне, человеку, который знаком с внутренностями мейнстримных хеш-таблиц лишь поверхностно, кажется статья как рваной, так и неполной.
Может за то что публично усомнился в общепринятой догме
Думаю, что "догмой" это является для тех, кто не имеет представление о самом приниципе работы хеш-функции - преобразование данных неограниченной длины в данные с длиной фиксированной и из чего следует при таком сужении, что автор и написал, - коллизия. А дальше он начал реализовывать свой велосипед, выбрал простой метод борьбы с ней и... всё? Статья закончилась, ни сравнении с меинстримными реализациями, ни борьбы с деградацией скорости доступа к хеш-таблице при добавлении в ней огромного количества элементов, ни наглядных схем работы, т.к мне как читателю не сильно интересно склеивать в уме реализацию по сниппетам неизвестного мне ЯП. Прочитав всё это я могу лишь сказать: "Доступ к хеш-таблице не за константное время происходит. Круто, и чё?"
Раздел про "NonNull и PhantomData" просто неверен, в виду того, что raw pointer по дефолту является !Send + !Sync и лучше уж следовало написать про то, как реализуется Sync и как бороться с !Send.
Фича языка описывается так, словно в шарпах/жабе нельзя строить API на основе функций, что не так. «Вместо иерархии объектов в Go используется композиция функций» — то есть такого паттерна не существует в Go, но это не означает, что он единственно верный в C#.
По поводу структурной типизации: она выигрывает в гибкости, но теряет в строгости семантики — один метод обслуживает все интерфейсы сразу, и Go, например, не имеет инструментов для разделения. Так что, думаю, это просто трейдофф между явным и неявным, то есть не хорошо и не плохо.
Особенностью это не является. Так как я не гошник, механизм «внешне» особо неотличим относительно «оппонентов», из-за чего весь раздел звучит странно. Единственное, про «опасное состояние» в рамках C#/Java можно назвать «ошибку на миллиард», но современный язык предлагает использование nullable reference types/Optional types, что, признаю, только частично закрывает проблему. Но это замечание справедливо только для reference types, и, как я знаю, Go в части этих же типов делает совершенно ничего, что сводит всё к тому, о чём я писал выше.
«Всё это рождает огромное количество конкурентных паттернов, характерных именно для Go» — что говорит лишь о том, что создатели языка решили сделать ставку на эти примитивы, сделав их частью языка, а не о том, что они невыразимы на других языках.
«Не напоминает ли это паттерн "Стратегия"?» — напоминает функцию, требующую выполнения определённого контракта у передаваемого объекта, а не паттерн, смысл которого заключается в рантайм-переопределении поведения у сущности.
Относительно паттерна здесь я уже не могу быть так категоричен, но в аргументации прослеживается тот же спич о функциях и объектах. Да, например, в ASP.NET единицей маршрута, обычно, является метод у объекта-контроллера, но это не значит, что в шарпах паттерн «урл-функция» невыразим.
Специфичный паттерн в лице... массива функций, посыпанный сахарком?
Те, в которых явно не используется наследование.
С самим выводом в статье можно согласиться, но вступительный текст и само содержание способствуют не ассимиляции языковых мигрантов, а представляют лишь кривое сравнение идиоматичных паттернов разных языков в лоб.
Вот видите, не работает этот ваш раст!
Я, конечно, не "минусатор", но мне, человеку, который знаком с внутренностями мейнстримных хеш-таблиц лишь поверхностно, кажется статья как рваной, так и неполной.
Думаю, что "догмой" это является для тех, кто не имеет представление о самом приниципе работы хеш-функции - преобразование данных неограниченной длины в данные с длиной фиксированной и из чего следует при таком сужении, что автор и написал, - коллизия. А дальше он начал реализовывать свой велосипед, выбрал простой метод борьбы с ней и... всё? Статья закончилась, ни сравнении с меинстримными реализациями, ни борьбы с деградацией скорости доступа к хеш-таблице при добавлении в ней огромного количества элементов, ни наглядных схем работы, т.к мне как читателю не сильно интересно склеивать в уме реализацию по сниппетам неизвестного мне ЯП.
Прочитав всё это я могу лишь сказать: "Доступ к хеш-таблице не за константное время происходит. Круто, и чё?"
Раздел про "NonNull и PhantomData" просто неверен, в виду того, что raw pointer по дефолту является !Send + !Sync и лучше уж следовало написать про то, как реализуется Sync и как бороться с !Send.