Hacker News Digest

Тег: #gofmt

Постов: 2

Go's Sweet 16 (go.dev) 🔥 Горячее 💬 Длинная дискуссия

by 0xedb • 14 ноября 2025 г. в 22:33 • 277 points

ОригиналHN

#go#python#java#goroutines#gofmt#golangci-lint#google

Комментарии (210)

  • Go хвалят за простоту обучения и быструю продуктивность, особенно разработчикам, переходящим с Python или Java.
  • Стандартизированные инструменты (gofmt, golangci-lint) и модули обеспечивают единообразие кодовых баз и удобство работы.
  • Ключевые преимущества: производительность, конкурентность (goroutines), быстрая компиляция и портативные бинарные файлы.
  • Основные пожелания к улучшению: встроенная проверка на nil, sum types с исчерпывающими проверками и функциональные возможности (иммутабельность, итераторы).
  • Исторический казус: язык Go! существовал раньше, но был вытеснен Google, что вызвало споры в сообществе.

Formatting code should be unnecessary (maxleiter.com) 🔥 Горячее 💬 Длинная дискуссия

Форматирование кода должно быть лишним

В 80-х это уже знали.
Мой школьный учитель информатики, мистер Пейдж, участвовал в разработке компилятора Ada. Когда я в 2016-м жаловался на линтеры, он напомнил: проблему решили 40 лет назад. В Ada исходники не хранили — использовали IR-дерево DIANA. Каждый смотрел его в своём стиле: отступы, пробелы — всё равно.

Сейчас, в 2025-м, мы всё ещё спорим о запятых.

Как это работало
Рабочая станция Rational R1000 (1985) хранила не текст, а DIANA. IDE позволял редактировать дерево напрямую — проекционное редактирование. Компиляция была инкрементной, рефакторинг мгновенным, а «исходник» — просто красивой печатью дерева.

Плюсы: никаких holy-war’ов о табах, быстрая интеграция, встроенный VCS и отладка.
Минус: требовалась железная станция и знание Ada.

Вывод
Не нужно возвращаться к проекционным редакторам, но можно ли встроить идею «храним структуру, а не текст» в современные языки и IDE? Тогда форматирование станет личным вкусом, а не командным законом.

by MaxLeiter • 07 сентября 2025 г. в 23:08 • 316 points

ОригиналHN

#ada#dia#unison#ast#ide#git#gofmt#prettier#black#code-formatting

Комментарии (422)

  • Одни считают форматирование важным каналом коммуникации и показателем вкуса/опыта разработчика, другие — пустым байкшедом, который должен решаться автоматическим линтером без обсуждений.
  • Хранение кода не как текста, а как IR/AST (пример — Ada/DIANA, Unison) позволяет каждому видеть свой вариант форматирования, но ломает привычные grep, diff, git и другие текстовые инструменты.
  • Проекционное редактирование (JetBrains MPS, Chrome DevTools «pretty») демонстрирует «один IR — много представлений», но требует специальных IDE и пока не стало массовым.
  • Проблема смешанных языков, legacy, необходимости универсального стандарта IR и инерции экосистемы тормозит переход от plain-text.
  • Автоформатеры (gofmt, Prettier, Black) уже закрывают 90 % вопросов: на сохранении/коммите единый стиль, локально можно настроить git-фильтры smudge/clean.