你好，Hacker News — 来自韩国的问候
我是一名主要使用 Go 的后端工程师，想与大家分享我正在构建的一个框架，以解决我在生产系统中反复遇到的问题。
在我的日常工作中，我们的后端是基于 Echo 构建的。Echo 作为 HTTP 传输非常快速且可靠，但其高度的自由度几乎将架构决策完全留给了个别开发者。随着时间的推移，这导致了一个系统，其中执行流程和责任边界因最后修改某个功能的人而有所不同。维护变得困难，并不是因为代码不正确，而是请求的实际执行方式变得不再明显。
我寻找一个能够提供清晰执行模型和结构约束的 Go 框架，类似于 Spring 或 NestJS 提供的功能。但我没有找到合适的框架。转向 Spring 或 NestJS 也意味着放弃 Go 的一些优势——简单性、性能和明确控制——所以我决定自己构建一个。
Spine 是一个以执行为中心的 Go 后端框架。它旨在提供企业级的结构，同时故意避免隐藏的魔法。
Spine 提供的功能：
- 一个具有显式构造函数依赖注入的 IoC 容器
- 具有明确定义的执行阶段（前、后、完成）的拦截器
- 对 HTTP 请求和事件驱动执行的第一类支持
- 无注解、无隐式行为、无约定驱动的连接
核心理念：执行优先
关键区别在于 Spine 的执行模型。每个请求——无论是 HTTP 还是事件——都通过一个单一的、明确的管道（Pipeline）流动。管道是唯一决定执行顺序的组件。实际的方法调用由一个单独的调用器（Invoker）处理，严格分离执行控制和调用。
由于这种结构：
- 执行顺序可以通过阅读代码来解释
- 交叉关注点存在于执行流程中，而不是控制器内部
- 控制器仅表达用例，而不是编排逻辑
- 你可以通过查看 main.go 来理解请求处理
这种设计在清晰度上牺牲了一些便利性。作为回报，它在系统规模和复杂性增长时提供了更强的控制。
我创建 Spine 的目标不仅仅是为 Go 生态系统添加另一个框架，而是开启一场对话：现代 Web 框架隐藏了多少执行流程，这在何时会成为维护成本？
该框架目前是用韩语编写的。如果你对英语支持或国际化有需求，请随时提出问题——我计划根据社区的兴趣优先处理。
你可以在这里找到更多细节、一个基本的 HTTP 示例和一个简单的基于 Kafka 的 MSA 演示：
仓库：<a href="https://github.com/NARUBROWN/spine" rel="nofollow">https://github.com/NARUBROWN/spine</a>
感谢阅读。我非常期待你的反馈。
返回首页
最新
看到了这个仓库：<a href="https://github.com/tldev/posturr" rel="nofollow">https://github.com/tldev/posturr</a>，想分享我的解决方案，以避免紧张不安的心情 :)
嗨，HN，我创建了Beni（<a href="https://thebeni.ai" rel="nofollow">https://thebeni.ai</a>），这是一个用于实时视频通话的网页应用，配有AI伴侣。
这个想法起初源于一个相当简单的问题：文本聊天机器人无处不在，但它们很少给人一种真实存在的感觉。我想要一些更接近通话的东西，让角色能够实时反应（声音、时机、表情），而不仅仅是“输入、等待、回复”。
Beni基本上是：
- 一个在通话过程中会动画化的Live2D头像（表情 + 根据对话驱动的动作）
- 实时语音对话（流式响应，而不是“等待10秒再说”）
- 长期记忆，以便角色能够在不同会话中保持上下文
最难的部分不是生成文本，而是让整个循环感觉同步：麦克风输入、模型响应、文本转语音音频和Live2D动画都需要协调，否则会立即感觉不连贯。我花了更多时间在状态管理、延迟和缓冲上，而不是在提示上。
一些实现细节（如果有人感兴趣，我很乐意分享更多）：
- 基于浏览器的实时通话，带有音频流和客户端播放控制
- 前端的Live2D渲染，动画钩子与语音/状态相关联
- 一个存储轻量级用户信息/偏好和对话摘要的记忆层，以保持连续性
当前的限制：今天需要登录（以保持记忆并防止滥用）。我很快会添加一个访客模式，以便更快试用，并且目前正在开发移动视图。
我希望得到的反馈：
- “实时通话”循环的响应性是否足够，还是仍然太延迟？
- 关于浏览器中2D/3D头像的更好唇动同步/表情时机的任何想法？
谢谢，我会在评论区待着。
这是我几年前开始的一个爱好项目，目的是学习编程语言的实现。这个项目95%是手动编写的，虽然最近的一些提交中包含了来自Gemini CLI的代码。<p>我最开始是按照《Crafting Interpreters》这本书进行学习的，但逐渐偏离了原来的方向，直到几乎没有什么共同点。<p>技术栈：Rust、Cranelift（即时编译）、LALRPOP（解析器）。
嗨，HN，我在过去几周里构建了一个名为Meru OS的实验性人工智能操作系统，基于一个理念：智能应该是可验证的，而不是概率性的。
大多数大型语言模型（LLM）都是“黑箱”。我想构建一个“玻璃箱”，使每个输出都能追溯到一个经过认证的来源。
架构：
内核：状态不是用向量表示，而是用整数表示。我们使用算术基本定理（唯一质因数分解）来编码概念。
例子：如果时间 = 3，空间 = 5，那么时空 = 15。这允许通过简单地对整数进行除法来实现可逆的“时间旅行调试”。
虚拟机（Bija）：它不仅仅是运行周期；它运行“频率调制”。
内核本身是用特定的质频（赫兹）编码的。
执行实际上是指令与数据之间的“共振”状态，而不是传统的取指-解码-执行流水线。
数据（< 2MB）：我们将整个印度宪法、印度刑法典和一个印欧词源词典压缩成一个<2MB的包，使用自定义的基于模式的压缩（Pingala）。
为什么？
主权：逻辑和数据是本地拥有的。没有API调用。
绿色人工智能：它在我的MacBook的CPU上运行，几乎不产生热量/功耗。
吠陀逻辑：它将帕尼尼的语法规则（Ashtadhyayi）实现为图遍历算法，而不仅仅是统计注意力。
这绝对是实验性的，但它质疑“规模就是一切”的教条。希望能得到关于可逆质状态机逻辑的反馈。
链接：
代码： [https://github.com/akulasairohit/meru-os](https://github.com/akulasairohit/meru-os)
在线演示： [https://huggingface.co/spaces/akulasairohit/panini-demo](https://huggingface.co/spaces/akulasairohit/panini-demo)
宣言： [https://www.linkedin.com/pulse/introducing-meru-os-worlds-first-sovereign-ai-stack-akula-pf68e](https://www.linkedin.com/pulse/introducing-meru-os-worlds-first-sovereign-ai-stack-akula-pf68e)
谢谢，Rohit
嘿，HN社区，
我是一名来自尼日利亚的独立开发者。我开发了Quran Unlock——一款在你完成每日阅读《古兰经》之前，阻止你使用干扰性应用（如TikTok、Instagram等）的应用。
这个想法源于我自己对手机成瘾的挣扎。我想每天阅读《古兰经》，但总是被各种干扰分心。因此，我为自己开发了这个应用，然后决定分享给大家。
经过两个月的一些统计数据：
- 超过123,000名用户
- 64.9%的回访用户率
- 31百万个事件被追踪
技术栈：
- React Native
- Firebase（身份验证、Firestore、分析、云消息）
- RevenueCat用于订阅
- iOS屏幕时间API + Android使用统计
应用商店链接： [App Store](https://apps.apple.com/app/quran-unlock/id6754449406)
谷歌商店链接： [Play Store](https://play.google.com/store/apps/details?id=com.app.quranu)
期待HN社区的反馈！
我对当前的档案格式感到失望，要么它们过于复杂，要么是杂七杂八的，要么不支持随机访问（如磁带格式），或者有奇怪的限制（如ar档案）。因此，我自己设计了一个简单的随机访问档案格式。
我一直认为，DDD在当时是一个令人惊讶的优秀调试工具。它让程序执行变得可视化：堆栈、数据和控制流都能同时呈现。你可以真正“看到”程序在做什么。
与此同时，它显然是一个不同年代的产物：
- 单进程
- 主要是同步代码
- 没有真正的并发或异步概念
- 过时的用户界面和交互模型
今天我们调试的系统截然不同：多线程代码、异步运行时、长时间运行的服务、分布式组件。然而，大多数调试器在概念上仍然与GDB + 单步调试相似，只是包装在一个更美观的用户界面中。
我很好奇其他人对此的看法：
- DDD（或类似旧工具）中有哪些理念仍然有价值？
- “现代DDD”需要如何处理今天的软件？
- 你认为交互式调试仍然是正确的抽象方式吗？
我主要是从设计的角度提问——我自己也在尝试一些调试器的想法，但我更感兴趣的是听听经验丰富的工程师们今天如何看待这个问题。