А
в рефлексию
Size: a a a
2020 May 08
А
в копипасту
G
Когда команда большая, легко делить обязанности и писать свои компоненты для ещё несформированного кода, над которым работает другая команда, если абстракции языка это позволяют
Пример - пишем удобный для нас интерфейс к ещё ненаписанному классу (над которым работают другие разработчики), когда класс готов - пишем адаптор к нашему коду
А
тогда какая причина создания Go?
А тогда какая причина ведения работ над Go2?
ИЧ
Пример - пишем удобный для нас интерфейс к ещё ненаписанному классу (над которым работают другие разработчики), когда класс готов - пишем адаптор к нашему коду
этого же нет в микросервисах, абстракции на контейнерах держатся
ИЧ
А тогда какая причина ведения работ над Go2?
могу только предположить, что Go стал популярен и расширил свою изначальную нишу
А
Go на самом деле хорош, когда надо из одного сокета взять какие-то данные и положить в другой. А вот когда надо с данными проделать какую-то работу, да ещё и не тривиальную, то уже начинаются проблемы
ИЧ
Go на самом деле хорош, когда надо из одного сокета взять какие-то данные и положить в другой. А вот когда надо с данными проделать какую-то работу, да ещё и не тривиальную, то уже начинаются проблемы
вот, микросервисы как раз про перекладывание данных
А
могу только предположить, что Go стал популярен и расширил свою изначальную нишу
Да причина лишь в дефектах изначального дизайна, которые они сейчас пытаются исправить.
AZ
тогда какая причина создания Go?
Вообще э, насколько я помню, google изначально создавала его не для этого
G
вот, микросервисы как раз про перекладывание данных
ФП хорошо на отображение (перекладывание, если угодно) данных ложится)
АГ
Это старый раст больше походил на ML с «плюсами», в современном, на мой вкус, слишком много визуального мусора шума, а код выглядит менее читаемым, чем перловый.
Весь шум обусловлен тем, что нужно иметь возможность изъясняться с компилятором на языке лайфтаймов, и я, если честно, не вижу способа сделать это еще проще. Единственное, что мне не нравится в расте на уровне синтаксиса - это два способа указания trait bound: в заголовке (impl<T: Foo> …) vs where T: Foo, причем where строго мощнее. Не то, чтобы это мешало, просто кажется избыточным. Можете привести пример что вам кажется странным в синтаксисе раста, не хочу разводить холивар, просто сколько не встречал таких жалоб никогда не приводилось конкретных примеров
А
То что Go стал популярным не означает даже того, что он очень хорошо подходит бизнесу для написания микросервисов
DS
у абстракций есть своя цена, когда команда маленькая, легко делить экспертизу, когда большая, это уже невозможно
так-как Go ориентирован на большие команды, выбрали такой компромисс
большинство программистов не понимает такую страсть к простоте, потому что в жизни не сталкивается с проблемами крупных продуктов, когда кодобазу пишут 100+ разработчиков
так-как Go ориентирован на большие команды, выбрали такой компромисс
большинство программистов не понимает такую страсть к простоте, потому что в жизни не сталкивается с проблемами крупных продуктов, когда кодобазу пишут 100+ разработчиков
Вот очень в этом не уверен.
Невыразительность языка сильно поднимает размер кодовой базы на пустом месте.
То есть работал в больших и старых кодовых базах в относительно больших командах (не 100 человек, но 30+) и проблемой была именно невыразительность используемого языка и его системы типов.
Очень много гарантий, которые можно было бы закодировать на уровне типов в итоге оказываются на плечах команды с закономерным итогом
Невыразительность языка сильно поднимает размер кодовой базы на пустом месте.
То есть работал в больших и старых кодовых базах в относительно больших командах (не 100 человек, но 30+) и проблемой была именно невыразительность используемого языка и его системы типов.
Очень много гарантий, которые можно было бы закодировать на уровне типов в итоге оказываются на плечах команды с закономерным итогом
ИЧ
Вот очень в этом не уверен.
Невыразительность языка сильно поднимает размер кодовой базы на пустом месте.
То есть работал в больших и старых кодовых базах в относительно больших командах (не 100 человек, но 30+) и проблемой была именно невыразительность используемого языка и его системы типов.
Очень много гарантий, которые можно было бы закодировать на уровне типов в итоге оказываются на плечах команды с закономерным итогом
Невыразительность языка сильно поднимает размер кодовой базы на пустом месте.
То есть работал в больших и старых кодовых базах в относительно больших командах (не 100 человек, но 30+) и проблемой была именно невыразительность используемого языка и его системы типов.
Очень много гарантий, которые можно было бы закодировать на уровне типов в итоге оказываются на плечах команды с закономерным итогом
здесь важно работать с микросервисами, в которых абстракции не очень востребованы
А
здесь важно работать с микросервисами, в которых абстракции не очень востребованы
Востребованы
А
Они везде востребованы.
DS
здесь важно работать с микросервисами, в которых абстракции не очень востребованы
Работаю с микросервисами, потребность в абстракциях все равно остаётся.
А
Потому что тот пример который я приводил на самом деле весьма "низкоуровневая" операция
ИЧ
Востребованы
абстракции уходят на уровень выше, во взаимодействие между микросервисами