Hacker News Digest

Проектирование языка программирования — это итеративный процесс, включающий четыре фазы, которые необходимо повторять многократно. При реализации компилятора часто обнаруживается, что некоторые части языка спроектированы некорректно, что требует возврата к предыдущим этапам. Успех в создании языка зависит от глубоких знаний в трех ключевых областях: программных парадигмах (императивной, декларативной, объектно-ориентированной и др.), концепциях языков (последовательность выполнения, типизация, параллелизм и др.) и знакомстве с существующими языками. Автор рекомендует изучить десятки языков — от Python и Smalltalk до Haskell и Rust, а также ознакомиться с классическими работами по проектированию языков.

• Предложение включить Raku в список языков из-за встроенных грамматик для парсинга и объектно-ориентированной природы.
• Вопросы о компиляции целевых языков, их пайплайне сборки и контексте выполнения.
• Размышления о создании нового языка: необходимость, наличие ресурсов/команды, сроки выпуска MVP.
• Критика исходного материала как "AI slop", рекомендация использовать "programming language checklist".
• Споры об AI-происхождении текста (находки 2017 года) и упоминание забавного элемента (SnekQL).

Представлен шрифт Myna — моноширинный типографский шрифт, специально разработанный для программирования с обилием символов. Авторы создали его с фокусом на улучшении читаемости кода за счет оптимального распределения пространства между символами и четкого отображения специальных знаков.

Шрифт поддерживает широкий набор символов, включая математические обозначения, операторы и диакритические знаки, что делает его универсальным инструментом для разработчиков. Проект открыт на GitHub, где доступны файлы шрифта и документация по его использованию.

• Обсуждение началось с обсуждения шрифта Iosevka и его особенностей, включая то, что он не поддерживает лигатуры, что вызвало обсуждение о том, что такое лигатуры и как они влияют на читаемость кода.
• Участники обсуждали, что такое "язык, насыщенный символами", и какие языки программирования могут быть отнесены к этой категории, включая Perl и Haskell.
• Обсуждались проблемы с отсутствием поддержки Unicode в шрифтах, и как это влияет на работу с различными языками программирования.
• Участники обсуждали, что такое "моношириный" и "пропорциональный" шрифт, и как они влияют на читаемость кода.
• В конце обсуждение перешло к тому, что выбор шрифта для кода - это вопрос личных предпочтений, и что важно найти баланс между эстетикой и функциональностью.

Автор делится своим опытом работы с различными языками программирования, объясняя, почему OCaml стал его любимым языком. Он начал с Haskell, который оценил за функциональное программирование и статическую типизацию, но столкнулся с его сложностью и медленной компиляцией. Позже он попробовал Go, который понравился своей простотой, скоростью компиляции и хорошими инструментами, но разочаровал многословностью обработки ошибок и отсутствием функциональных возможностей. OCaml, по мнению автора, сочетает в себе лучшее из обоих миров: функциональные конструкции, статические гарантии, быструю компиляцию, простую семантику выполнения и отличную документацию. Особо отмечается, что OCaml компилируется в один статический бинарный файл, как Go, но при этом имеет более мощную систему типов и REPL. Автор считает, что создатели OCaml обладают хорошим вкусом, а язык представляет собой идеальный баланс между простотой и выразительностью.

• OCaml не стал мейнстримом из-за синтаксиса, отсутствия нативных библиотек и слабой экосистемы, но его идеи (pattern-matching, type inference, algebraic data types) уже давно живут в Rust, Swift, TypeScript и даже Go.
• Фактически OCaml — это «нативный» вариант F#, но без .NET-экосистемы, а F# — это OCaml без его синтаксиса и с .NET вместо OCaml-стандартной библиотеки.
• Попытка ReasonML привнести более C-подобный синтаксис вместо ужасающего синтаксиса OCaml закончилась тем, что Facebook забросил проект, а вся индустрия JS-инструментов осталась без единого стандарта.
• Попытка Facebook-а внедрить Reason вместо TypeScript внутри Facebook показала, что даже если синтаксис и не является проблемой, то отсутствие единого стандарта для сборки и пакетов в JS-мире оставляет язык без шанса.
• Несмотря на то, что OCaml — это язык с 25-летней историей, он не имеет ни мультиплатформенной сборки, ни нормального менеджера пакетов, ни нормального REPL, что делает его неподготовленным к работе вне Unix-подобных систем.

GHC теперь может работать полностью на стороне клиента в браузере через WebAssembly, демонстрируя значительный прогресс в разработке GHC WASM бэкенда. Это позволяет создавать интерактивные Haskell playground прямо в браузере без необходимости серверной части. Однако реализация имеет ограничения: используется байткод интерпретатор вместо компиляции в WASM, а cabal не поддерживается из-за отсутствия поддержки процессов. Для использования сторонних пакетов требуется предварительная компиляция через wasm32-wasi-cabal.

Проект сталкивается с некоторыми техническими вызовами, включая необходимость загрузки и извлечения около 50MB корневой файловой системы, что может вызывать временные зависания интерфейса. В некоторых браузерах, таких как Brave и Safari, возникают дополнительные проблемы с работой веб-воркеров. Тем не менее, эта технология открывает возможности для создания полностью интерактивных онлайн-курсов по Haskell и других веб-приложений, написанных на Haskell, работающих непосредственно в браузере пользователя.

• Обсуждение началось с вопроса о том, что WASM-версия GHC действительно запускает код в браузере, но не решает проблемы «бутстрапа» и воспроизводимых сборок, что делает Haskell невозможным для включения в дистрибутивы.
• Участники обсудили, что язык всё ещё жив, но отсутствие возможности полностью собрать его из исходников делает его «мертвым» с точки зрения дистрибутивов.
• Появились сомнения в том, что Haskell всё ещё актуален, и обсуждались ресурсы для изучения языка и практического применения.
• Также обсудили, что WASM-порт GHC демонстрирует прогресс бэкэнда, но не затрагивает проблему полного порта компилятора на новую архитектуру.
• В конце обсуждение сошлось на то, что язык всё ещё используется в продакшене и имеет практическое применение, а также что WASM может быть полезен не только в браузере, но и в других сценариях.

Rust повышает производительность разработки, несмотря на сложность.
Ключевые факторы:

• Жёсткий компилятор ловит ошибки до запуска, уменьшая время отладки.
• Модель владения устраняет гонки и утечки памяти, снижая количество багов.
• Инструменты: Cargo, Clippy, rustfmt и rust-analyzer ускоряют цикл «написание → проверка → запуск».
• Сообщество предлагает качественные крейты и быструю помощь.
• Производительность кода сравнима с C/C++, но без segfault и UB.

В итоге меньше времени тратится на отладку, больше — на новые функции.

• Автор статьи рассказал, как Rust позволяет безболезненно рефакторить большие кодовые базы благодаря строгой типизации и проверкам компилятора.
• Многие участники согласились, что статическая типизация (Rust, Haskell, OCaml-подобные языки) повышает уверенность при изменениях, особенно в многолюдных проектах.
• Часть комментаторов считает сравнение с TypeScript «нечестным»: TS компилируется в JS и наследует его недостатки, а приведённый баг с window.location.href — это особенность DOM, а не языка.
• Некоторые отметили, что Rust тоже не идеален: async/синхронные блокировки, медленная компиляция и «множество способов сделать одно и то же» могут снижать удобство.
• Общий вывод: преимущество Rust в безопасности и рефакторинге особенно заметно на больших проектах, но язык требует времени на изучение и не всегда лучше «классических» статически типизированных альтернатив.

Почему наём — боль

Компании теряют время: 9 раундов, охота за «трендовыми» разрабами, не могут отличить программиста от LLM. Кандидаты страдают: лучшие разрабы (Rust, Haskell) проваливают стресс-интервью, рекрутеры называют их «не-технарями», а потом пропадают на месяцы.

Каким должен быть хороший процесс

1. Различать сеньора и маркетолога с ChatGPT.
2. Применимо к работе: код, архитектура, ревью, документация.
3. Долгосрочно: люди не взаимозаменяемы, уход дорого, специализация под стек выучивается за месяц.
4. Экономно: инженерное время дорого.
5. Уважительно: неуважение отпугивает лучших.
6. Вкус: быстрое, но грязное решение — долгий долг команде; «клей» (поддержка коллег) множит продуктивность.

Почему популярные форматы не работают

• Live-coding / LeetCode
  Не различают, не про работу, уничтожают уважение и вкус, дорогие при многократных раундах.

• Take-home
  Легко сгенерировать ChatGPT, неуважительны к времени кандидата, отпугивают сильных.

• Проектирование архитектуры
  Лучше: ChatGPT не пройдёт, близко к реальной работе, можно оценить вкус и командное влияние.

• Современные «интервью» больше похожи на серию экзаменов, чем на профессиональный разговор.
• Многие считают, что достаточно 1-2 коротких встреч или пробы через контракт «temp-to-perm», чтобы понять, подходит ли человек.
• Популярные live-coding и leetcode почти не отражают реальную работу и отбирают не тех специалистов.
• Лучше обсуждать реальные задачи, ревьюить существующий код или решать мелкий баг в паре — это ближе к ежедневным обязанностям.
• Кандидаты теряют время и энергию на домашние задания и 9-часовые циклы, поэтому всё чаще «интервьюируют» и сами компании.