Почему все фреймворки Golang сосредоточены на производительности?

Мне нравится язык Go, и я представил его в Arduino более года назад. Это действительно изменило наш способ создания и развертывания приложений, вот основные преимущества для нас:

  • Компилируется на каждой используемой нами архитектуре
  • Молниеносно
  • Очень легко развернуть, мы используем двоичный файл + файл конфигурации json
  • Крепкий
  • Хорошо задокументированы
  • Библиотеки высокого качества

Большая часть нашей серверной части нового проекта Arduino Create построена на Go.

Мы начали использовать Revel (из-за некоторого сходства с Django), затем Gin Gonic, теперь Echo с некоторым экскурсом на других фреймворках. Очень легко переписать ваши приложения микросервисов в других фреймворках, если ваше приложение достаточно мало, а мы сохранили их очень маленькими.

Сегодня я услышал про Iris, если сравнить некоторые из этих фреймворков, все они говорят о скорости как о главной особенности:

Самый быстрый серверный веб-фреймворк для Go. - Ирис

Самый быстрый полнофункциональный веб-фреймворк для Golang. Кристально чистый. - Джин Гоник

Быстрый и необычный фреймворк HTTP-сервера для Go (Golang). До 10 раз быстрее остальных. - Эхо

Все новые интересные микро-веб-фреймворки почти одинаковы с точки зрения архитектуры, и у них могут быть свои плюсы / минусы в отношении своего метода маршрутизации. Это правда, что все они быстрые, но это напоминает мне, что они соревнуются не по той причине.

Некоторое время назад в области Linux шла аналогичная битва за лучший формат пакетов или менеджер пакетов: apt, yum, nix, pac и т. Д., И снова движение упустило возможность создать однородную эхосистему для большинства дистрибутивов (это заняло при этом иметь .deb и .rpm на совершенно разных рынках).

Почему бы им не посоревноваться в скорости? Скорость важна, это факт, но хорошо написанное приложение Go уже будет намного быстрее, чем такое же приложение, написанное на одном из самых известных интерпретируемых языков.

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

Я действительно считаю, что будет лучше, если различные фреймворки попытаются конкурировать или объединить некоторые проекты вокруг набора определенных функций. В этом направлении, вероятно, лучшая работа была проделана Gorilla Web Toolkit, предоставляющим множество небольших библиотек, которые разработчик может выбрать и легко интегрировать в свой проект.

Вот в чем должны соревноваться новые фреймворки:

  • Предоставьте простой способ создать архитектуру плагина
  • Подключите собственный языковой шаблон (большинство фреймворков теперь используют только Go Templating)
  • Простой способ добавить промежуточное ПО
  • Хорошие варианты переплета
  • Легко подключаемые библиотеки ORM или БД (мне не нравится ORM, но это моя проблема, к вашему сведению, мы используем RethinkDB)
  • Хорошая пользовательская и архитектурная документация (не ориентированная только на разработчиков)
  • Интернационализация
  • Служба поддержки

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

Я действительно надеюсь, что разработчики Go (которые великолепны) попытаются создать более поддерживаемую и более крупную (с точки зрения принятия) структуру, чтобы выбрать всего несколько функций и сделать их лучше. Пожалуйста, прекратите иметь множество микрофреймворков, которые делают почти одно и то же и соревнуются в скорости. По моему опыту, проблемы со скоростью 99,98% связаны не с самими инструментами, а с тем, как люди их используют, неправильными алгоритмами или связанными с неоптимизированными запросами к БД или управлением сеансом / ОЗУ.

Хорошо то, что теперь Go стабилен и поддерживается в достаточной степени, я уверен, что очень скоро появится новый фреймворк, который будет конкурировать с самыми популярными на рынке, язык Go великолепен, разработчики Go исключительны, сообщество достаточно большое, это время действовать эффективно, а не быстро!