E
Size: a a a
2020 June 18
IK
В чем проблемк? Кому шашечки, а кому ехать
ЛА
Не особенно нода и проигрывает, если писать нормально. Точнее, не так, единственная область, где она однозначно проигрывает - это многопоточность, но такое, чтобы самому писать какие-то многопоточные алгоритмы, встречается в работе довольно редко. А в дроблении чисел и посылании туда-сюда json'чиков они действуют практически одинаково. Го более удачен из коробки, за счёт типизации, но у ноды есть typescript, которые побогаче, как язык.
Так что тут исключительно вкусовщина.
На лично мой вкус, тайпскрипт прикольная штука, но джаваскриптовая экосистема - это такой ад, что лучше никогда этого не видеть и не трогать.
Так что тут исключительно вкусовщина.
На лично мой вкус, тайпскрипт прикольная штука, но джаваскриптовая экосистема - это такой ад, что лучше никогда этого не видеть и не трогать.
Выше написал, что сравнил экспрессный эндпоинт и аналогичный на стандартной либе го. Код приложения фактически отсутствует, сравниваются 2 библиотеки. Что надо было "писать нормально"?
По поводу алгоритмов и многопоточности, я постоянно использую эту фишку го - воркер пулы, еррор группы. Ради нее и влез в язык.
По поводу алгоритмов и многопоточности, я постоянно использую эту фишку го - воркер пулы, еррор группы. Ради нее и влез в язык.
IK
Не будет никогда фреймворка и производительного, и быстрого в использовании
DK
Ты имеешь ввиду кодогенерацию? Они всё-таки довольно ограничены в своём применении (удачи собрать на них, скажем, параметрический полиморфизм) и не очень удобны в использовании. В го нет удобных аннотаций и кодогенерировать вы будете магией, через "магические" комментарии, хардкод имён классов и так далее.
Ну все знают про эти недостатки языка. Каждый день что ли говорить о них?
DP
Так RoR и не ради производительности придуман, а для хуяк-хуяк и вебсайт
а теперь нам нужны средства делать это для больших нагрузок
DP
Не будет никогда фреймворка и производительного, и быстрого в использовании
spring? только память давай, и будет и хорошо, и быстро
DD
Богатая доменная модель подразумевает, что бизнес-логика заключена в классах и их поведении/отношениях. Анемичная подразумевает, что бизнес-логика пишется процедурно (в сервисах или даже plain-функциях), а классы - это просто структуры для передачи данных. (читай, например, https://habr.com/ru/company/jugru/blog/503868/)
Соответственно, в го, без дженериков и прочего мета-программирования очень сложно делать всякие хитрые паттерны, основанные на отношениях объектов. Есть интерфейсы и утиная типизация, но этого недостаточно. А в php ты изи можешь описать, скажем, десять классов подтипа "заказ" и написать универсальную функцию, которая единообразно обрабатывает любой класс из вышеперечисленных.
Соответственно, в го, без дженериков и прочего мета-программирования очень сложно делать всякие хитрые паттерны, основанные на отношениях объектов. Есть интерфейсы и утиная типизация, но этого недостаточно. А в php ты изи можешь описать, скажем, десять классов подтипа "заказ" и написать универсальную функцию, которая единообразно обрабатывает любой класс из вышеперечисленных.
> Богатая доменная модель подразумевает, что бизнес-логика заключена в классах и их поведении/отношениях. Анемичная подразумевает, что бизнес-логика пишется процедурно (в сервисах или даже plain-функциях), а классы - это просто структуры для передачи данных
В go же аналог класса - это структура. Что мешает засунуть бизнес логику в структуру?
> Соответственно, в го, без дженериков и прочего мета-программирования очень сложно делать всякие хитрые паттерны, основанные на отношениях объектов.
Каккие паттерны, например? В php же тоже нет дженериков, но паттерны вполне себе реализуемы.
> А в php ты изи можешь описать, скажем, десять классов подтипа "заказ" и написать универсальную функцию, которая единообразно обрабатывает любой класс из вышеперечисленных.
Что мешает использовать композицию вместо наследования? Я где-то читал (возможно ошибаюсь) что создатели go и решили не включать в язык наследование потому, что можно использовать композицию
В go же аналог класса - это структура. Что мешает засунуть бизнес логику в структуру?
> Соответственно, в го, без дженериков и прочего мета-программирования очень сложно делать всякие хитрые паттерны, основанные на отношениях объектов.
Каккие паттерны, например? В php же тоже нет дженериков, но паттерны вполне себе реализуемы.
> А в php ты изи можешь описать, скажем, десять классов подтипа "заказ" и написать универсальную функцию, которая единообразно обрабатывает любой класс из вышеперечисленных.
Что мешает использовать композицию вместо наследования? Я где-то читал (возможно ошибаюсь) что создатели go и решили не включать в язык наследование потому, что можно использовать композицию
E
В чем проблемк? Кому шашечки, а кому ехать
В том, что сложные проекты необходимо правильно структурировать и правильно моделировать предметную область, а то ты утонешь в регрессиях. Представь проект хотя бы на 100к строк кода на го (скажем) и на руби. С чем тебе было бы проще работать?
IK
spring? только память давай, и будет и хорошо, и быстро
Так про что угодно можно сказать
ЛА
Рефлексия - это то, что не стоит произносить вслух, в приличном обществе :) С ней вы много чего делаете в рантайме вместо того, чтобы быть уверенным, что ваш код рабочий, ещё на стадии компиляции. Ну и ещё это очень, очень медленно.
Рефлексия используется в самом го, в template пакетах к примеру, которые в свою очередь используются в таких тулзах как docker и helm, так что не очень это однозначно
IK
В том, что сложные проекты необходимо правильно структурировать и правильно моделировать предметную область, а то ты утонешь в регрессиях. Представь проект хотя бы на 100к строк кода на го (скажем) и на руби. С чем тебе было бы проще работать?
Ни с чем из двух
E
Ну все знают про эти недостатки языка. Каждый день что ли говорить о них?
Я объяснял, почему в го плохо с обобщенным программированием и богатой моделью. Ты спросил - я ответил. Это не делает го сильно хуже, это просто особенность.
DP
Так про что угодно можно сказать
ror упирается в проц, а проц у нас типа все, уперся в физику
IK
ror упирается в проц, а проц у нас типа все, уперся в физику
Есть же более идеоматическая замена рору - феникс
E
Рефлексия используется в самом го, в template пакетах к примеру, которые в свою очередь используются в таких тулзах как docker и helm, так что не очень это однозначно
Это не означает, что это нужно использовать повсеместно. Каждому инструменту - своё применение. И рефлексии следует избегать настолько, насколько это вообще возможно.
JC
А он не упирается в проц?
ЛА
Den D
> Богатая доменная модель подразумевает, что бизнес-логика заключена в классах и их поведении/отношениях. Анемичная подразумевает, что бизнес-логика пишется процедурно (в сервисах или даже plain-функциях), а классы - это просто структуры для передачи данных
В go же аналог класса - это структура. Что мешает засунуть бизнес логику в структуру?
> Соответственно, в го, без дженериков и прочего мета-программирования очень сложно делать всякие хитрые паттерны, основанные на отношениях объектов.
Каккие паттерны, например? В php же тоже нет дженериков, но паттерны вполне себе реализуемы.
> А в php ты изи можешь описать, скажем, десять классов подтипа "заказ" и написать универсальную функцию, которая единообразно обрабатывает любой класс из вышеперечисленных.
Что мешает использовать композицию вместо наследования? Я где-то читал (возможно ошибаюсь) что создатели go и решили не включать в язык наследование потому, что можно использовать композицию
В go же аналог класса - это структура. Что мешает засунуть бизнес логику в структуру?
> Соответственно, в го, без дженериков и прочего мета-программирования очень сложно делать всякие хитрые паттерны, основанные на отношениях объектов.
Каккие паттерны, например? В php же тоже нет дженериков, но паттерны вполне себе реализуемы.
> А в php ты изи можешь описать, скажем, десять классов подтипа "заказ" и написать универсальную функцию, которая единообразно обрабатывает любой класс из вышеперечисленных.
Что мешает использовать композицию вместо наследования? Я где-то читал (возможно ошибаюсь) что создатели go и решили не включать в язык наследование потому, что можно использовать композицию
В пхп нет строгой типизации, поэтому и дженерики не нужны.
DK
Я объяснял, почему в го плохо с обобщенным программированием и богатой моделью. Ты спросил - я ответил. Это не делает го сильно хуже, это просто особенность.
Я ничего и не спрашивал на самом деле