Hacker News Digest

Тактильность — это не просто физическое ощущение, а сложный феномен, влияющий на восприятие, эмоции и взаимодействие с миром. Она играет ключевую роль в пользовательском опыте: от сенсорных экранов до дизайна продуктов, где текстура и вес создают ощущение качества. Исследования показывают, что тактильные сигналы могут усиливать доверие и запоминаемость, например, в розничной торговле или цифровых интерфейсах.

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

• Обсуждение возможностей и ограничений ESP32-устройств, включая поддержку загружаемых нативных приложений (ELF apps) в проекте Tactility.
• Рассмотрение альтернативных языков и сред для ESP32, таких как Toit, Nim, BASIC (Picomite) и Java, а также поддержка RISC-V архитектуры.
• Исследование практических применений: от IoT до портативных менеджеров паролей, клиентов для мессенджеров (IRC) и устройств с сотовой связью.
• Критика и скептицизм относительно ограниченных ресурсов ESP32 (памяти) для выполнения сложных задач, таких как динамическая линковка.
• Сравнение Tactility с другими проектами (Flipper, Zephyr) и обсуждение его статуса как операционной системы.

Zig предлагает более простой подход к созданию CLI-инструментов по сравнению с Rust, особенно когда речь идёт о работе с памятью. В Rust строгий borrow checker предотвращает ошибки на этапе компиляции, но часто вынуждает переписывать код под его требования, усложняя разработку. Например, при попытке добавить новую запись в список, одновременно удерживая ссылки на существующие, компилятор Rust блокирует действие из-за конфликта владения и заимствования.

В Zig же разработчик напрямую управляет памятью через аллокаторы, используя указатели и мутацию без сложных правил времён жизни. Это требует дисциплины, но даёт больше гибкости и скорости написания кода. Для CLI-инструментов, где производительность и простота часто важнее абсолютной безопасности памяти, Zig оказывается практичнее. Безопасность — это не только отсутствие ошибок памяти, но и читаемость, скорость разработки и соответствие задаче.

• Обсуждение затрагивает проблемы безопасности в C, связанные с ручным управлением памятью, и ироничные комментарии по этому поводу.
• Пользователи делятся мнениями о современных языках (Nim, Odin, V, D, Zig), отмечая их преимущества, такие как интероперабельность с C и гибкость в управлении памятью.
• Уточняется функциональность Zig: он не компилируется в C, но имеет инструмент для трансляции C-кода в Zig, при этом компилируясь напрямую в машинный код.
• В обсуждении присутствует юмористический тон относительно утверждения, что разработчики не являются идиотами.

Плюсы Nim 2

• Память: по умолчанию ORC/ARC (RAII, деструкторы, move/copy), а не трассирующий GC. Можно --mm:none или --mm:atomicArc.
• Компилируется в C/C++/Obj-C/JS; выбираем компилятор (gcc, nvcc, …).
• Лёгкая интеграция: {.importc.}, {.importcpp.}, {.importjs.}, {.compile.} для сторонних файлов.
• Метапрограммирование: макросы, static исполнение кода на этапе компиляции, генерация CUDA.
• Краткость: мало шаблонного кода (чат на 70 строк).
• Производительность ≈ C/C++/Rust; поддержка SIMD, CUDA.

Минусы и подводные камни

• Генерируемый C/C++ код нечитаем — не цель проекта.
• Нет атомарных счётчиков в ORC по умолчанию (требуется флаг).
• Некоторые старые статьи/комментарии описывают Nim 1.x (GC по умолчанию).
• Синтаксис чувствителен к отступам и регистру (но это субъективно).

Мини-пример: простой key/value формат

import std/[tables, strutils]

type Config = object
  host*: string
  port*: int

proc loadConfig(path: string, T: typedesc): T =
  let data = readFile(path).splitLines()
  var kv = initTable[string, string]()
  for line in data:
    let parts = line.split('=')
    if parts.len == 2:
      kv[parts[0].strip()] = parts[1].strip()

  result.host = kv.getOrDefault("host", "localhost")
  result.port = parseInt(kv.getOrDefault("port", "8080"))

let cfg = loadConfig("app.conf", Config)
echo cfg.host, ":", cfg.port

Файл app.conf:

host = 0.0.0.0
port = 9000

Всё компилируется в один бинарник без GC-задержек.

• Пользователи отмечают редкую, но полезную возможность Nim — определять собственные операторы.
• Хвалят макросы, интегрированные в систему типов и перегрузку, сравнивая язык с «статически типизированным Lisp».
• Критика: сложности с Windows (Nimble-зависимости тянут GCC, Defender блокирует бинарники) и неоднозначная «фантастическая» интеграция с C++.
• Обсуждают объём JS-артефактов: для мелких примеров — десятки килобайт, но без оптимизации могут быть мегабайты.
• Для WASM рекомендуют компилировать в C и прогонять через Emscripten, но стандартные JS-биндинги не работают.
• Вопросы IDE: есть nimsuggest и быстрая настройка для Neovim, но плагинов для JetBrains почти нет.

fenster — сверхкомпактная кроссплатформенная GUI-библиотека.

• Особенности:

  • Окно, пиксельный буфер, ввод с клавиатуры/мыши.
  • Один .h файл, ~400 LOC, зависимости: X11 (Linux), Cocoa (macOS), Win32 (Windows).
  • Поддержка C/C++, Zig, Odin, Rust, Go, JS (WASM), C#, Swift, Pascal, Nim, Lua, Python, Ruby, OCaml, Fortran.

• Быстрый старт (C):

#define FENSTER_IMPL
#include "fenster.h"
int main() {
  struct fenster f = {.width = 320, .height = 240, .title = "demo"};
  uint32_t buf[320*240];
  for (fenster_open(&f); fenster_loop(&f) == 0; ) {
    // рисуем
    fenster_sync(&f, buf);
  }
  return 0;
}

• Сборка: cc demo.c -o demo (Linux: -lX11, macOS: -framework Cocoa, Windows: без флагов).

• API (C):

  • fenster_open, fenster_close, fenster_loop, fenster_sync.
  • Поля: width, height, title, keys[64], mouse.

• Лицензия: MIT.

• Fenster — это минимальная C-библиотека, создающая окно с пиксельным буфером, а не полноценный GUI с кнопками и меню.
• Участники отмечают отсутствие скриншотов и просят добавить их в README.
• Название «Fenster» переводится как «окно» на немецком, африкаанс, шведском и других языках.
• Некоторые считают polling-цикл ошибкой, другие считают его допустимым для такой простой задачи.
• В блог-посте нашли опечатку в sizeof и ограничение кода 8-битными цветами.
• Проект вызывает интерес для визуализации данных и как лёгкая альтернатива raylib.

• Участники жалеют, что выразительные языки с нативной компиляцией и автоматическим управлением памятью (Nim, D) не стали массовыми.
• Любители Nim хвалят его скорость, надёжность компилятора и эргономику, но жалуются на малую экосистему, устаревшую документацию и сложность кросс-компиляции.
• Скептики считают, что «выразительность» и макросы делают язык нишевым, требуют больше знаний и усложняют чтение чужого кода.
• Многие отметили, что успех языка определяют не фичи, а деньги, стандартная библиотека, тулинг и сообщество; Rust выиграл именно этим.
• Часть разработчиков ушла из Nim в Rust, Go или Zig из-за зрелости инструментов и богатой экосистемы, но продолжают следить за Nim и надеются на его рост.