Original paper: https://www.nature.com/articles/s41467-025-67657-w

What an incredible journey it's been.

It took almost 7 years, and sometimes I lost hope that I would make it to a successful exit.

But today I am pleased to announce that I finally achieved the ultimate Hacker News karma:

  31337

I'll now be pivoting away from day-to-day HN responsibilities, into more of an occasional advisory role.

The maximum available points for that role is 32767, so I'll try to spend it wisely.

If anyone needs to hire a founder type, I know one who has freed up a lot of discretionary time, to spend on work.

https://i.imgur.com/HnB30Ff.png

I built GroqBash, a single‑file Bash client for the Groq API (OpenAI‑compatible). I wanted something fully auditable, with no dependencies, and that worked reliably on Termux, where /tmp isn’t writable. Everything lives inside a self‑created groqbash.d directory, and the core script avoids eval, avoids /tmp, and keeps permissions strict.

The project now includes optional extras: additional providers (including Gemini), extended documentation, small security tools, and a tiny test suite. The core stays minimal and portable; extras are opt‑in.

I’d love to get: - feedback on the design and Bash choices - visibility to see if others find this useful - testing on different environments (Linux distros, macOS, WSL, Termux)

Repo: https://github.com/kamaludu/groqbash

Note: I’m not a native English speaker. I read English fairly well, but I usually rely on automatic translators (and sometimes GroqBash itself) when writing. Happy to clarify anything if needed.

Hello Hacker News — greetings from South Korea I’m a backend engineer working primarily with Go, and I’d like to share a framework I’ve been building to solve a problem I’ve repeatedly encountered in production systems.

In my day-to-day work, our backend is built on top of Echo. Echo is fast and reliable as an HTTP transport, but its high level of freedom leaves architectural decisions almost entirely to individual developers. Over time, this led to a system where execution flow and responsibility boundaries varied depending on who last touched a feature. Maintenance became difficult not because the code was incorrect, but because how requests actually executed was no longer obvious.

I looked for a Go framework that could provide a clear execution model and structural constraints, similar to what Spring or NestJS offer. I couldn’t find one that fit. Moving to Spring or NestJS would also mean giving up some of Go’s strengths—simplicity, performance, and explicit control—so I decided to build one instead.

Spine is an execution-centric backend framework for Go. It aims to provide enterprise-grade structure while deliberately avoiding hidden magic.

What Spine provides • An IoC container with explicit, constructor-based dependency injection • Interceptors with well-defined execution phases (before, after, completion) • First-class support for both HTTP requests and event-driven execution • No annotations, no implicit behavior, no convention-driven wiring

The core idea: execution first

The key difference is Spine’s execution model.

Every request—HTTP or event—flows through a single, explicit Pipeline. The Pipeline is the only component that determines execution order. Actual method calls are handled by a separate Invoker, keeping execution control and invocation strictly separated.

Because of this structure: • Execution order is explainable by reading the code • Cross-cutting concerns live in the execution flow, not inside controllers • Controllers express use cases only, not orchestration logic • You can understand request handling by looking at main.go

This design trades some convenience for clarity. In return, it offers stronger control as the system grows in size and complexity.

My goal with Spine isn’t just to add another framework to the Go ecosystem, but to start a conversation: How much execution flow do modern web frameworks hide, and when does that become a maintenance cost?

The framework itself is currently written in Korean. If English support or internationalization is important to you, feel free to open an issue—I plan to prioritize it based on community interest.

You can find more details, a basic HTTP example, and a simple Kafka-based MSA demo here: Repository: https://github.com/NARUBROWN/spine

Thanks for reading. I’d really appreciate your feedback.

PolyMCP now lets you expose Python MCP (Model Context Protocol) tools in two ways from the same code: 1. Server-based MCP deployments (HTTP endpoints) 2. WebAssembly bundles that run directly in the browser

This means you can reuse the same Python functions for server workflows or client-side experiments without any code changes.

⸻

Why it matters • Plug-and-play: one Python function, multiple deployment options. • Instant testing: run your tools locally in the browser or via HTTP. • Enterprise-ready: leverage internal libraries, scripts, and APIs immediately. • Unified interface: MCP agents call your tools the same way, regardless of server or WASM.

⸻

Example

# Python function def calculate_stats(numbers): """Return basic statistics for a list of numbers""" return { "count": len(numbers), "sum": sum(numbers), "mean": sum(numbers)/len(numbers) }

# === WebAssembly MCP === from polymcp import expose_tools_wasm compiler = expose_tools_wasm([calculate_stats]) compiler.compile("./wasm_output")

The same function can also be exposed via HTTP MCP endpoints without modification.

# === HTTP MCP === from polymcp.polymcp_toolkit import expose_tools app = expose_tools([calculate_stats], title="Stats Tools") # Run with: uvicorn server_mcp:app --reload

⸻

Repo: https://github.com/poly-mcp/Polymcp

We’d love to hear how you’re using PolyMCP and feature ideas for future releases.