Comments 11
А на основе чего у вас сложилось такое впечатление?
На Go вообще что-нибудь пишут кроме линтеров и металинтеров?
Конечно, пишут. Библиотеки для написания линтеров и металинтеров, например:
https://go-toolsmith.github.io/
не понял вопроса. Пишут много чего. Вся продукция небезызвестной HashiCorp на go написана.
И это не относится к категории «линтеров и металинтеров»
И это не относится к категории «линтеров и металинтеров»
Docker, Kubernetes, приложения из HashiCorp и много-много сервисов для микросервисной архитектуры для компаний по всему миру.
Это очень круто.
Выше вот удивляются, почему в Go обилие линтеров и металинтеров – и это как раз потому, что их чертовски легко писать (в сравнении с другими языками). Немного опыта работы с AST плюс фантазия и можно автоматизировать нахождение и исправление очень много чего – вплоть до линтеров специфичных для конкретного проекта. Проблема как раз в diminished returns – чем больше линтеров, тем больше оверхед на каждый из них, и тем больше время линтинга в целом. То есть, если я хочу добавить 15 линтеров, каждый из них будет парсить исходный код и колдовать над ним, и затраты на это могу превысить порог, когда это вообще оправданно. Я так, понимаю, линтер собранный lintpack-ом берет задачу парсинга и прохода по коду на себя, а линтеры ответственны только за саму проверку и ничего больше. Это сильно уменьшает затраты на написание (и включение в pipeline) нового линтера.
Буду пробовать, спасибо!
Выше вот удивляются, почему в Go обилие линтеров и металинтеров – и это как раз потому, что их чертовски легко писать (в сравнении с другими языками). Немного опыта работы с AST плюс фантазия и можно автоматизировать нахождение и исправление очень много чего – вплоть до линтеров специфичных для конкретного проекта. Проблема как раз в diminished returns – чем больше линтеров, тем больше оверхед на каждый из них, и тем больше время линтинга в целом. То есть, если я хочу добавить 15 линтеров, каждый из них будет парсить исходный код и колдовать над ним, и затраты на это могу превысить порог, когда это вообще оправданно. Я так, понимаю, линтер собранный lintpack-ом берет задачу парсинга и прохода по коду на себя, а линтеры ответственны только за саму проверку и ничего больше. Это сильно уменьшает затраты на написание (и включение в pipeline) нового линтера.
Буду пробовать, спасибо!
Я так, понимаю, линтер собранный lintpack-ом берет задачу парсинга и прохода по коду на себя, а линтеры ответственны только за саму проверку и ничего больше. Это сильно уменьшает затраты на написание (и включение в pipeline) нового линтера.
Да, всё так.
Плюс из коробки всё для тестирования (работает с coverage) и интеграционного тестирования.
Логично, что более выразительные (или сложные) языки анализировать не так просто.
Одна из причин, почему мне Go нравится и почему я пробую работать над статическим анализом для него — мне это по силам.
Одна из причин, почему мне Go нравится и почему я пробую работать над статическим анализом для него — мне это по силам.
Вы правы, мой аргумент был не о том, что анализаторы проще писать для Go, а не на Go. Но простота Go (которая делает его удобной мишенью для статических анализаторов) она не только в грамматике, но и в тулинге, скорости, опыте использования, вероятности контрибьютинга, стабильности языка и т.д. Я знаю, что если я напишу анализатор на Go, то через 4 года он будет всё так же работать, код будет всё так же читабелен, и с ним будет так же удобно работать.
Sign up to leave a comment.
Go lintpack: менеджер компонуемых линтеров