👣 Extractous-Go - быстрая библиотека для извлечения текста и данных из документов в Go

Коротко:
- множество форматов: удобно вытаскивать текст из реальных файлов в одном API
- потоковая обработка больших файлов через streaming API
- OCR для сканов с помощью Tesseract
- минимальные зависимости и простой старт

Пример:

package main

import (
 "fmt"
 "os"

 extract "github.com/rahulpoonia29/extractous-go"
)

func main() {
 f, _ := os.Open("report.pdf")
 defer f.Close()

 // Потоковое извлечение без загрузки всего файла в память
 text, err := extract.FromReader(f, extract.Options{
  EnableOCR: true,      // использовать OCR для сканов
  Language:  "eng+rus", // языки для Tesseract
 })
 if err != nil {
  panic(err)
 }
 fmt.Println(text)
}

🚀Github: https://github.com/rahulpoonia29/extractous-go

@Golang_google

#go #golang

🖥 Мнение: Gin - очень плохая программная библиотека,
и у автора есть много аргументов, почему.

В статье автор разбирает, почему популярный Go-фреймворк Gin может создавать скрытые проблемы в продакшене.

Главные идеи:

• ✋ Простота Gin обманчива, он прячет логику, которую разработчики не контролируют.
• ⚠️ Middleware-цепочки легко становятся неявными и сложными для отладки.
• 🧩 Встроенная магия (binding, context, handlers) делает код удобным, но снижает прозрачность.
• ⚡ Производительность на реальных нагрузках может страдать, особенно при интенсивной сериализации и работе с JSON.
• 🔍 Автор продвигает мысль: чем легче фреймворк кажется, тем труднее понять, как он ломается.

Gin хорош для старта и прототипов, но в крупных системах нужно либо тщательно контролировать то, что он делает “за вас”, либо рассматривать более прозрачные подходы.

https://eblog.fly.dev/ginbad.html

@Golang_google

#golang #go #gin

👣 Implementing Tail at Scale in Go - как строить высоконагруженный tail-сервис

Любопытная статья, в которой показано, как реализовать масштабируемый tail-механизм на Go для чтения и обработки данных в реальном времени. Речь не про «прочитать файл до конца», а про системы, которые постоянно слушают источники и реагируют на новые события.

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

Ключевые проблемы, которые нужно решить:
- непрерывное чтение данных без блокировок
- обработка тысяч событий параллельно
- устойчивость к ошибкам и сбоям источников
- масштабирование без сложной синхронизации

Почему Go хорошо подходит:
- легкие goroutine
- каналы вместо shared state
- простая модель конкурентности
- удобный graceful shutdown через context

Базовая архитектура tail-сервиса:
- reader читает данные из источника и кладет в канал
- parser превращает сырые строки в структуру
- filter отбрасывает ненужные события
- dispatcher рассылает данные дальше (метрики, алерты, стримы)

Важный принцип - никакой тяжелой логики в одном месте. Каждый этап независим и общается через каналы.

Ключевые паттерны:
- неблокирующий select вместо бесконечных циклов
- ограниченные по размеру каналы для backpressure
- worker-пулы для обработки нагрузки
- context для остановки всех горутин без утечек

Масштабирование достигается не сложной магией, а:
- разделением ответственности
- параллельной обработкой
- отсутствием глобальных mutex
- четким контролем потока данных

Tail at scale - это не про файлы, а про потоковую архитектуру. Если правильно выстроить пайплайн из goroutine и каналов, Go позволяет строить надежные realtime-системы, которые легко масштабируются и остаются понятными в поддержке.

Это отличный пример того, как идиоматичный Go решает задачи стриминга и realtime-обработки без лишней сложности.

https://jitesh117.github.io/blog/implementing-tail-at-scale-in-golang/

#golang #go

@Golang_google