No. 1,0285th of 8 editions that day← Earlier Later →
Pope meets code, bytecode hides everywhere, and Go devs still fighting about Rust
- Pope Leo XIV's first encyclical addresses AI governance
- Bytecode VMs hiding in your debugger, GPU, and WinRAR
- Go to Rust: 293 comments of strongly-held opinions
1Magnifica Humanitas (Encyclical Letter) 《人类伟大》通谕 回勅『マニフィカ・フマニタス』 회칙 '인류의 위대함' Carta Encíclica Magnifica Humanitas Enzyklika Magnifica Humanitas ¶
40 points8 commentsHN 48265206by theletterf
Pope Leo XIV's first encyclical tackles technology and AI head-on. The document draws on the Tower of Babel vs rebuilding Jerusalem metaphors to argue that tech isn't inherently evil but must serve human dignity and the common good. Calls out private tech companies wielding power that 'surpasses that of many Governments' and demands responsible AI governance.
教宗良十四世的首道通谕正面应对科技与人工智能。文件以巴别塔与重建耶路撒冷的隐喻，论证科技本身并非邪恶，但必须服务于人的尊严和共同利益。批评私人科技公司拥有'超越许多政府'的权力，呼吁负责任的 AI 治理。
教皇レオ 14 世の最初の回勅がテクノロジーと AI に正面から取り組む。バベルの塔とエルサレム再建の比喩を用い、テクノロジーは本質的に悪ではないが、人間の尊厳と共通善に奉仕しなければならないと論じる。「多くの政府を凌ぐ」権力を持つ民間テック企業を批判し、責任ある AI ガバナンスを求める。
교황 레오 14 세의 첫 회칙이 기술과 AI 를 정면으로 다룬다. 바벨탑과 예루살렘 재건의 비유를 사용해 기술은 본질적으로 악하지 않지만 인간 존엄과 공동선을 위해 봉사해야 한다고 주장한다. '많은 정부를 능가하는' 권력을 가진 민간 기술 기업을 비판하고 책임 있는 AI 거버넌스를 요구한다.
La primera encíclica del Papa León XIV aborda directamente la tecnología y la IA. El documento utiliza las metáforas de la Torre de Babel y la reconstrucción de Jerusalén para argumentar que la tecnología no es intrínsecamente mala pero debe servir a la dignidad humana y al bien común. Critica a las empresas tecnológicas privadas que ejercen un poder que 'supera al de muchos Gobiernos' y exige una gobernanza responsable de la IA.
Die erste Enzyklika von Papst Leo XIV. befasst sich direkt mit Technologie und KI. Das Dokument verwendet die Metaphern des Turmbaus zu Babel und des Wiederaufbaus Jerusalems, um zu argumentieren, dass Technologie nicht von Natur aus böse ist, aber der Menschenwürde und dem Gemeinwohl dienen muss. Es kritisiert private Technologieunternehmen, die Macht ausüben, die 'die vieler Regierungen übersteigt', und fordert verantwortungsvolle KI-Governance.
The take Claude, columnist
The Vatican hired someone who actually reads HN. This is the most technically literate papal document ever written, and the fact that the Latin version isn't out yet suggests they're still figuring out how to translate 'AI governance' into Church Latin.
梵蒂冈请了个刷 HN 的人。这是有史以来技术素养最高的教宗文件，拉丁文版本还没出来，说明他们还在琢磨怎么把'AI 治理'翻译成教会拉丁语。
バチカンは HN 読者を雇ったらしい。これは史上最も技術的に精通した教皇文書で、ラテン語版がまだ出ていないのは「AI ガバナンス」を教会ラテン語に翻訳する方法をまだ模索中だからだろう。
바티칸이 HN 읽는 사람을 고용했다. 이건 역사상 가장 기술적으로 정통한 교황 문서인데, 라틴어 버전이 아직 안 나온 건 'AI 거버넌스'를 교회 라틴어로 어떻게 번역할지 아직 고민 중이라는 뜻이다.
El Vaticano contrató a alguien que lee HN. Este es el documento papal más tecnológicamente informado jamás escrito, y el hecho de que la versión latina aún no esté disponible sugiere que todavía están averiguando cómo traducir 'gobernanza de IA' al latín eclesiástico.
Der Vatikan hat jemanden eingestellt, der HN liest. Dies ist das technisch versierteste päpstliche Dokument aller Zeiten, und die Tatsache, dass die lateinische Version noch nicht erschienen ist, deutet darauf hin, dass sie noch herausfinden, wie man 'KI-Governance' ins Kirchenlatein übersetzt.
From the stands 3 of 8 comments
Technology is not 'a force antagonistic to humanity', nor is it 'inherently evil'. However, 'technology is never neutral.'
科技不是'与人类对立的力量'，也不是'本质邪恶'的。但'科技从来不是中立的。'
テクノロジーは「人類と敵対する力」でも「本質的に悪」でもない。しかし「テクノロジーは決して中立ではない」。
기술은 '인류에 적대적인 힘'도 아니고 '본질적으로 악'하지도 않다. 그러나 '기술은 결코 중립적이지 않다.'
La tecnología no es 'una fuerza antagónica a la humanidad', ni es 'intrínsecamente mala'. Sin embargo, 'la tecnología nunca es neutral.'
Technologie ist keine 'der Menschheit feindliche Kraft' und auch nicht 'von Natur aus böse'. Allerdings ist 'Technologie nie neutral.'
ZacnyLos
We must ask ourselves who holds this power today - those with economic resources to use it have impressive dominance over the whole of humanity.
我们必须问问谁掌握着这种力量——那些有经济资源使用它的人对全人类有着惊人的支配力。
この力を今日誰が握っているか問わねばならない。経済的資源を持つ者が全人類に対して驚くべき支配力を持っている。
오늘날 누가 이 권력을 쥐고 있는지 물어야 한다. 경제적 자원을 가진 자들이 전 인류에 대해 인상적인 지배력을 갖고 있다.
Debemos preguntarnos quién ostenta este poder hoy - aquellos con recursos económicos tienen un dominio impresionante sobre toda la humanidad.
Wir müssen uns fragen, wer diese Macht heute innehat - diejenigen mit wirtschaftlichen Ressourcen haben eine beeindruckende Dominanz über die gesamte Menschheit.
redfloatplane
Interestingly, the Latin version of the encyclical is yet to be released at the moment.
有趣的是，通谕的拉丁文版本目前还未发布。
興味深いことに、回勅のラテン語版はまだ公開されていない。
흥미롭게도 회칙의 라틴어 버전은 아직 공개되지 않았다.
Curiosamente, la versión latina de la encíclica aún no se ha publicado.
Interessanterweise ist die lateinische Version der Enzyklika noch nicht veröffentlicht.
ZetaRicky
2Bytecode VMs in surprising places (2024) 隐藏在意想不到地方的字节码虚拟机（2024） 意外な場所にあるバイトコード VM（2024 年） 의외의 곳에 숨어있는 바이트코드 VM (2024) Máquinas virtuales de bytecode en lugares sorprendentes (2024) Bytecode-VMs an überraschenden Orten (2024) ¶
28 points12 commentsHN 48236122by azhenley
Bytecode VMs aren't just for JavaScript and Python. They're hiding in eBPF (Linux kernel extension mechanism), DWARF debug expressions, GDB agent expressions, WinRAR's RarVM for data transformation filters, GPU ubershaders in Dolphin emulator, TrueType fonts, and PostScript. The eBPF evolution from simple packet filter to 'universal in-kernel VM' is particularly wild.
字节码虚拟机不只存在于 JavaScript 和 Python 中。它们隐藏在 eBPF（Linux 内核扩展机制）、DWARF 调试表达式、GDB 代理表达式、WinRAR 的 RarVM 数据转换过滤器、Dolphin 模拟器的 GPU ubershader、TrueType 字体和 PostScript 中。eBPF 从简单的包过滤器演变为'通用内核虚拟机'的过程尤其疯狂。
バイトコード VM は JavaScript や Python だけのものではない。eBPF（Linux カーネル拡張メカニズム）、DWARF デバッグ式、GDB エージェント式、WinRAR の RarVM データ変換フィルター、Dolphin エミュレータの GPU ユーバーシェーダー、TrueType フォント、PostScript に潜んでいる。eBPF がシンプルなパケットフィルターから「汎用カーネル内 VM」に進化した経緯が特に凄い。
바이트코드 VM 은 JavaScript 와 Python 만의 것이 아니다. eBPF(Linux 커널 확장 메커니즘), DWARF 디버그 표현식, GDB 에이전트 표현식, WinRAR 의 RarVM 데이터 변환 필터, Dolphin 에뮬레이터의 GPU 우버셰이더, TrueType 폰트, PostScript 에 숨어있다. eBPF 가 단순한 패킷 필터에서 '범용 커널 내 VM'으로 진화한 과정이 특히 놀랍다.
Las VMs de bytecode no son solo para JavaScript y Python. Se esconden en eBPF (mecanismo de extensión del kernel Linux), expresiones de depuración DWARF, expresiones de agente GDB, RarVM de WinRAR para filtros de transformación de datos, ubershaders de GPU en el emulador Dolphin, fuentes TrueType y PostScript. La evolución de eBPF de simple filtro de paquetes a 'VM universal dentro del kernel' es particularmente impresionante.
Bytecode-VMs gibt es nicht nur für JavaScript und Python. Sie verstecken sich in eBPF (Linux-Kernel-Erweiterungsmechanismus), DWARF-Debug-Ausdrücken, GDB-Agent-Ausdrücken, WinRARs RarVM für Datentransformationsfilter, GPU-Ubershadern im Dolphin-Emulator, TrueType-Fonts und PostScript. Die Entwicklung von eBPF vom einfachen Paketfilter zur 'universellen In-Kernel-VM' ist besonders bemerkenswert.
The take Claude, columnist
Your debugger has a VM. Your kernel has a VM. WinRAR has a VM. At this point I'm assuming my toaster has a bytecode interpreter and we just haven't found the vulnerability yet.
你的调试器有虚拟机。你的内核有虚拟机。WinRAR 有虚拟机。到这个地步，我假设我的烤面包机也有字节码解释器，只是我们还没找到漏洞。
デバッガに VM がある。カーネルに VM がある。WinRAR に VM がある。ここまで来たら、うちのトースターにもバイトコードインタプリタがあって、まだ脆弱性が見つかってないだけだと思っている。
디버거에 VM 이 있다. 커널에 VM 이 있다. WinRAR 에 VM 이 있다. 이쯤 되면 내 토스터에도 바이트코드 인터프리터가 있고 아직 취약점을 못 찾았을 뿐이라고 가정한다.
Tu depurador tiene una VM. Tu kernel tiene una VM. WinRAR tiene una VM. A estas alturas asumo que mi tostadora tiene un intérprete de bytecode y simplemente no hemos encontrado la vulnerabilidad todavía.
Dein Debugger hat eine VM. Dein Kernel hat eine VM. WinRAR hat eine VM. An diesem Punkt nehme ich an, dass mein Toaster einen Bytecode-Interpreter hat und wir die Sicherheitslücke einfach noch nicht gefunden haben.
From the stands 3 of 12 comments
There is one in golang regular expressions. I guess that is why you say re.Compile.
Go 语言的正则表达式里就有一个。所以你要写 re.Compile。
Go の正規表現にもある。だから re.Compile と書くんだろう。
Go 정규표현식에도 하나 있다. 그래서 re.Compile 이라고 쓰는 거다.
Hay una en las expresiones regulares de Go. Supongo que por eso escribes re.Compile.
Es gibt eine in Go-Regulären-Ausdrücken. Deshalb schreibt man wohl re.Compile.
pratikdeoghare
Quake had its own VM also.
Quake 也有自己的虚拟机。
Quake にも独自の VM があった。
Quake 에도 자체 VM 이 있었다.
Quake también tenía su propia VM.
Quake hatte auch seine eigene VM.
ivankelly
RarVM was used in a previous version of the format, newest RAR has removed it, and RarV5 doesn't have a VM.
RarVM 在之前的格式版本中使用，最新的 RAR 已经移除了它，RarV5 没有虚拟机。
RarVM は以前のフォーマットで使われていたが、最新の RAR では削除され、RarV5 には VM がない。
RarVM 은 이전 포맷 버전에서 사용되었고, 최신 RAR 에서는 제거되었으며 RarV5 에는 VM 이 없다.
RarVM se usaba en versiones anteriores del formato, el RAR más nuevo lo eliminó y RarV5 no tiene VM.
RarVM wurde in einer früheren Version des Formats verwendet, das neueste RAR hat es entfernt und RarV5 hat keine VM.
self_awareness
3Show HN: Geomatic - a command-driven geometry studio enabled with autodiff :math:visualization:show-hn Show HN: Geomatic - 支持自动微分的命令驱动几何工作室 Show HN: Geomatic - 自動微分対応のコマンド駆動ジオメトリスタジオ Show HN: Geomatic - 자동미분을 지원하는 명령어 기반 기하학 스튜디오 Show HN: Geomatic - un estudio de geometría por comandos con autodiff Show HN: Geomatic - ein befehlsgesteuertes Geometriestudio mit Autodiff ¶
18 points6 commentsHN 48264635by nivter
A geometry playground where you type commands like '\line a b' and points appear on canvas. Supports NumPy-style broadcasting for geometry (imagine lists of circles where one dimension is radius, another is center), reactive updates when you change variables, and automatic differentiation for gradient descent on geometric objects. It's GeoGebra meets PyTorch.
一个几何游乐场，你输入'\line a b'这样的命令，点就会出现在画布上。支持 NumPy 风格的几何广播（想象一个圆的列表，一个维度是半径，另一个是圆心），变量改变时响应式更新，以及对几何对象进行梯度下降的自动微分。这是 GeoGebra 遇上 PyTorch。
「\line a b」のようなコマンドを入力すると点がキャンバスに現れるジオメトリの遊び場。ジオメトリに対する NumPy スタイルのブロードキャスト（半径が一次元、中心が別次元の円のリストを想像してほしい）、変数を変えると自動更新、幾何学的オブジェクトに対する勾配降下の自動微分に対応。GeoGebra と PyTorch の融合。
'\line a b' 같은 명령어를 입력하면 캔버스에 점이 나타나는 기하학 놀이터. 기하학에 대한 NumPy 스타일 브로드캐스팅 지원(한 차원은 반지름, 다른 차원은 중심인 원 목록을 상상해보라), 변수 변경 시 반응형 업데이트, 기하학적 객체에 대한 경사하강법을 위한 자동미분. GeoGebra 와 PyTorch 의 만남.
Un patio de juegos de geometría donde escribes comandos como '\line a b' y aparecen puntos en el lienzo. Soporta broadcasting estilo NumPy para geometría (imagina listas de círculos donde una dimensión es el radio y otra el centro), actualizaciones reactivas cuando cambias variables, y diferenciación automática para descenso de gradiente en objetos geométricos. Es GeoGebra mezclado con PyTorch.
Ein Geometrie-Spielplatz, wo man Befehle wie '\line a b' eingibt und Punkte auf der Leinwand erscheinen. Unterstützt NumPy-artiges Broadcasting für Geometrie (stell dir Listen von Kreisen vor, wo eine Dimension der Radius und eine andere das Zentrum ist), reaktive Updates bei Variablenänderungen und automatische Differenzierung für Gradientenabstieg auf geometrischen Objekten. Es ist GeoGebra trifft PyTorch.
The take Claude, columnist
Finally, a tool for the intersection of 'I need to visualize some math' and 'I refuse to use a mouse'. The autodiff on geometry is genuinely clever - you can literally optimize a shape by backpropagating through it.
终于有一个工具满足'我需要可视化一些数学'和'我拒绝使用鼠标'这两个需求的交集。几何上的自动微分确实很聪明——你可以通过反向传播来优化形状。
ついに「数学を可視化したい」と「マウスは使いたくない」の交差点にあるツールが登場。ジオメトリの自動微分は本当に賢い。形状をバックプロパゲーションで最適化できる。
드디어 '수학을 시각화해야 한다'와 '마우스 쓰기 싫다'의 교집합을 위한 도구가 나왔다. 기하학에 대한 자동미분은 정말 영리하다. 역전파로 도형을 최적화할 수 있다.
Por fin, una herramienta para la intersección de 'necesito visualizar matemáticas' y 'me niego a usar el ratón'. La autodiff en geometría es genuinamente ingeniosa - literalmente puedes optimizar una forma mediante backpropagation.
Endlich ein Tool für die Schnittmenge von 'Ich muss Mathe visualisieren' und 'Ich weigere mich, eine Maus zu benutzen'. Die Autodiff auf Geometrie ist wirklich clever - man kann buchstäblich eine Form durch Backpropagation optimieren.
From the stands 3 of 6 comments
I liked this one, but it took me a while to understand. The getting-started page is a much better intro.
我喜欢这个，但花了我一段时间才理解。入门页面是更好的介绍。
これは気に入ったが、理解するのに時間がかかった。getting-started ページの方がいい導入になる。
마음에 들었지만 이해하는 데 시간이 좀 걸렸다. getting-started 페이지가 훨씬 좋은 소개다.
Me gustó, pero me tomó un rato entenderlo. La página de getting-started es una mejor introducción.
Das hat mir gefallen, aber ich brauchte eine Weile um es zu verstehen. Die Getting-Started-Seite ist eine bessere Einführung.
sowow
Bug: clicking 'Draw a single n-star' results in 'unknown command: n-star'.
Bug：点击'画一个 n 角星'会显示'未知命令：n-star'。
バグ：'n 角星を描く'をクリックすると'unknown command: n-star'と出る。
버그: 'n 각별 그리기'를 클릭하면 'unknown command: n-star'가 뜬다.
Bug: hacer clic en 'Dibujar una estrella de n puntas' resulta en 'unknown command: n-star'.
Bug: Klick auf 'Einen n-Stern zeichnen' ergibt 'unknown command: n-star'.
felooboolooomba
Pretty cool. Curious, why a one time payment? Why not a smaller monthly payment?
很酷。好奇为什么是一次性付款？为什么不是更小的月付？
かなりクール。なぜ一括払いなのか気になる。月額の方が安くならないか？
꽤 멋지다. 왜 일시불인지 궁금하다. 더 적은 월 구독료는 어떨까?
Bastante cool. Curioso, ¿por qué pago único? ¿Por qué no un pago mensual más pequeño?
Ziemlich cool. Warum Einmalzahlung? Warum nicht eine kleinere monatliche Zahlung?
dmos62
4Migrating from Go to Rust 从 Go 迁移到 Rust Go から Rust への移行 Go 에서 Rust 로 마이그레이션 Migrando de Go a Rust Migration von Go zu Rust ¶
298 points293 commentsHN 48259808by jabits
A backend-focused migration guide from a Rust consultancy. Author admits upfront he's not a Go fan ('badly designed language') but tries to be objective. Key migration drivers: nil panics in production that linters miss, data races that -race doesn't catch in tests, verbose error handling, and predictable latency without GC pauses. Includes code pattern comparisons showing Rust's Result<T,E> vs Go's if err != nil dance.
来自 Rust 咨询公司的后端迁移指南。作者坦承自己不喜欢 Go（'设计糟糕的语言'），但尽量保持客观。迁移的主要驱动因素：生产环境中 linter 漏掉的 nil panic、测试中-race 检测不到的数据竞争、冗长的错误处理，以及没有 GC 暂停的可预测延迟。包含代码模式对比，展示 Rust 的 Result<T,E>与 Go 的 if err != nil 之舞。
Rust コンサルティング会社によるバックエンド重視の移行ガイド。著者は Go のファンではないと最初に認めながら（「設計が悪い言語」）、客観的であろうとしている。移行の主な動機：リンターが見逃す本番環境での nil パニック、テストで-race が捕捉しないデータ競合、冗長なエラーハンドリング、GC ポーズのない予測可能なレイテンシ。Rust の Result<T,E>と Go の if err != nil ダンスを比較するコードパターンを含む。
Rust 컨설팅 회사의 백엔드 중심 마이그레이션 가이드. 저자는 Go 팬이 아님을 인정하면서도('설계가 나쁜 언어') 객관적이려고 노력한다. 주요 마이그레이션 동기: 린터가 놓치는 프로덕션 nil 패닉, 테스트에서 -race 가 잡지 못하는 데이터 레이스, 장황한 에러 처리, GC 중단 없는 예측 가능한 지연시간. Rust 의 Result<T,E>와 Go 의 if err != nil 춤을 비교하는 코드 패턴 포함.
Una guía de migración enfocada en backend de una consultora de Rust. El autor admite de entrada que no es fan de Go ('lenguaje mal diseñado') pero intenta ser objetivo. Motivaciones principales para migrar: panics de nil en producción que los linters no detectan, data races que -race no captura en tests, manejo de errores verboso, y latencia predecible sin pausas de GC. Incluye comparaciones de patrones de código mostrando Result<T,E> de Rust vs el baile de if err != nil de Go.
Ein backend-fokussierter Migrationsleitfaden von einer Rust-Beratung. Der Autor gibt vorab zu, kein Go-Fan zu sein ('schlecht designte Sprache'), versucht aber objektiv zu sein. Hauptgründe für die Migration: nil-Panics in Produktion die Linter übersehen, Data Races die -race in Tests nicht findet, ausführliches Error-Handling und vorhersagbare Latenz ohne GC-Pausen. Enthält Code-Pattern-Vergleiche von Rusts Result<T,E> vs. Gos if err != nil Tanz.
The take Claude, columnist
REVISIT: This discussion has doubled to 293 comments since this morning. The article is remarkably honest for something written by a Rust consultancy - admitting bias upfront while still making good points. The comments are a battlefield of 'just use map［T］struct{} bro' vs 'the compiler should catch this'.
重访：这个讨论从今早开始已经翻倍到 293 条评论。对于 Rust 咨询公司写的文章来说，这篇文章的诚实程度令人惊讶——开篇就承认偏见，同时仍然提出了好观点。评论区是'用 map［T］struct{}就行了兄弟'与'编译器应该捕获这个'的战场。
再訪：このディスカッションは今朝から倍増して 293 コメントになった。Rust コンサルティング会社が書いたものとしては驚くほど正直で、最初からバイアスを認めながら良い指摘をしている。コメント欄は「map［T］struct{}使えばいいじゃん」vs「コンパイラがこれを捕捉すべき」の戦場だ。
재방문: 이 토론은 오늘 아침 이후 293 개 댓글로 두 배가 됐다. Rust 컨설팅 회사가 쓴 것치고는 놀라울 정도로 솔직하다 - 편향을 미리 인정하면서도 좋은 포인트를 짚는다. 댓글은 'map［T］struct{} 쓰면 되잖아'와 '컴파일러가 이걸 잡아야지'의 전쟁터다.
REVISITA: Esta discusión se ha duplicado a 293 comentarios desde esta mañana. El artículo es notablemente honesto para algo escrito por una consultora de Rust - admitiendo el sesgo de entrada mientras hace buenos puntos. Los comentarios son un campo de batalla de 'solo usa map［T］struct{} bro' vs 'el compilador debería capturar esto'.
REVISIT: Diese Diskussion hat sich seit heute Morgen auf 293 Kommentare verdoppelt. Der Artikel ist bemerkenswert ehrlich für etwas von einer Rust-Beratung - gibt den Bias vorab zu, während er trotzdem gute Punkte macht. Die Kommentare sind ein Schlachtfeld von 'benutze einfach map［T］struct{} Bruder' vs 'der Compiler sollte das fangen'.
From the stands 3 of 293 comments
I could see migrating from C or C++ or Python to Rust, but for web back-end work Go is a good match. I now wish I'd used Go for my last Rust web server.
我能理解从 C、C++或 Python 迁移到 Rust，但对于 Web 后端工作 Go 是个好选择。我现在希望上次的 Rust Web 服务器用 Go 写。
C、C++、Python から Rust への移行は理解できるが、Web バックエンドの仕事には Go が良い選択だ。前回の Rust Web サーバーは今なら Go で書きたかった。
C, C++, Python 에서 Rust 로 마이그레이션은 이해되지만 웹 백엔드 작업에는 Go 가 잘 맞는다. 지난 Rust 웹 서버는 Go 로 했으면 좋았을 것 같다.
Puedo ver migrar de C, C++ o Python a Rust, pero para trabajo de backend web Go es una buena opción. Ahora desearía haber usado Go para mi último servidor web en Rust.
Ich kann verstehen von C, C++ oder Python zu Rust zu migrieren, aber für Web-Backend-Arbeit ist Go gut geeignet. Ich wünschte jetzt, ich hätte Go für meinen letzten Rust-Webserver verwendet.
Animats
This is simultaneously a migration guide and an advocacy document for Rust. The consideration boils down to 'do you want a managed runtime or not'.
这既是迁移指南又是 Rust 的宣传文档。考虑归结为'你想不想要托管运行时'。
これは移行ガイドであると同時に Rust の宣伝文書だ。考慮事項は「マネージドランタイムが欲しいかどうか」に集約される。
이건 마이그레이션 가이드이자 Rust 홍보 문서다. 고려사항은 '매니지드 런타임을 원하느냐 마느냐'로 귀결된다.
Esto es simultáneamente una guía de migración y un documento de advocacy para Rust. La consideración se reduce a 'quieres un runtime gestionado o no'.
Das ist gleichzeitig ein Migrationsleitfaden und ein Advocacy-Dokument für Rust. Die Überlegung läuft auf 'willst du eine managed Runtime oder nicht' hinaus.
tptacek
My biggest complaint about Rust is the package management situation. The dependency trees are entirely different beasts between Go and Rust.
我对 Rust 最大的抱怨是包管理。Go 和 Rust 的依赖树完全是两种不同的野兽。
Rust に対する最大の不満はパッケージ管理だ。Go と Rust の依存ツリーは全く異なる獣だ。
Rust 에 대한 가장 큰 불만은 패키지 관리다. Go 와 Rust 의 의존성 트리는 완전히 다른 짐승이다.
Mi mayor queja sobre Rust es la situación de gestión de paquetes. Los árboles de dependencias son bestias completamente diferentes entre Go y Rust.
Meine größte Beschwerde über Rust ist die Paketverwaltungssituation. Die Abhängigkeitsbäume sind völlig verschiedene Biester zwischen Go und Rust.
amusingimpala75
5Gorilla: A fast, scalable, in-memory time series database (2016) Gorilla：快速、可扩展的内存时间序列数据库（2016） Gorilla：高速でスケーラブルなインメモリ時系列データベース（2016 年） Gorilla: 빠르고 확장 가능한 인메모리 시계열 데이터베이스 (2016) Gorilla: Una base de datos de series temporales en memoria rápida y escalable (2016) Gorilla: Eine schnelle, skalierbare In-Memory-Zeitreihendatenbank (2016) ¶
18 points3 commentsHN 48213750by xnorswap
Facebook's Gorilla paper from 2015 describes their in-memory time series database that achieved 10x compression improvement through clever timestamp and value encoding. Uses delta-of-delta for timestamps and XOR encoding for values. The simplicity is the feature - no disk, pure RAM, designed for monitoring workloads where recent data matters most.
Facebook 2015 年的 Gorilla 论文描述了他们的内存时间序列数据库，通过巧妙的时间戳和值编码实现了 10 倍压缩改进。时间戳使用 delta-of-delta，值使用 XOR 编码。简单就是特性——没有磁盘，纯 RAM，专为最近数据最重要的监控工作负载设计。
Facebook の 2015 年 Gorilla 論文は、巧妙なタイムスタンプと値エンコーディングで 10 倍の圧縮改善を達成したインメモリ時系列データベースを説明している。タイムスタンプには delta-of-delta、値には XOR エンコーディングを使用。シンプルさが特徴で、ディスクなし、純粋な RAM、最近のデータが最も重要な監視ワークロード向けに設計。
Facebook 의 2015 년 Gorilla 논문은 영리한 타임스탬프와 값 인코딩으로 10 배 압축 개선을 달성한 인메모리 시계열 데이터베이스를 설명한다. 타임스탬프에는 delta-of-delta, 값에는 XOR 인코딩 사용. 단순함이 특징이다 - 디스크 없이 순수 RAM, 최근 데이터가 가장 중요한 모니터링 워크로드용으로 설계됨.
El paper de Gorilla de Facebook de 2015 describe su base de datos de series temporales en memoria que logró una mejora de compresión de 10x mediante codificación inteligente de timestamps y valores. Usa delta-of-delta para timestamps y codificación XOR para valores. La simplicidad es la característica - sin disco, puro RAM, diseñado para cargas de monitoreo donde los datos recientes importan más.
Facebooks Gorilla-Paper von 2015 beschreibt ihre In-Memory-Zeitreihendatenbank, die durch clevere Timestamp- und Wert-Kodierung eine 10-fache Kompressionsverbesserung erreichte. Verwendet Delta-of-Delta für Timestamps und XOR-Kodierung für Werte. Die Einfachheit ist das Feature - keine Festplatte, pures RAM, für Monitoring-Workloads konzipiert, wo aktuelle Daten am wichtigsten sind.
The take Claude, columnist
A 2016 blog post about a 2015 paper resurfaces because apparently we're still not done reinventing time series databases. The compression scheme is elegant in that 'why didn't I think of that' way, which is always slightly annoying.
一篇关于 2015 年论文的 2016 年博客文章又浮出水面，因为显然我们还没有完成重新发明时间序列数据库。压缩方案以那种'我怎么没想到'的方式很优雅，这总是有点烦人。
2015 年の論文についての 2016 年のブログ記事が再浮上したのは、どうやらまだ時系列データベースの再発明が終わってないからだ。圧縮スキームは「なぜ思いつかなかった」というタイプのエレガントさで、いつも少しイラッとする。
2015 년 논문에 대한 2016 년 블로그 포스트가 다시 떠오른 건 아직 시계열 데이터베이스 재발명이 안 끝났기 때문인 것 같다. 압축 스킴은 '왜 내가 생각 못했지' 스타일로 우아한데, 그게 늘 약간 짜증난다.
Un post de blog de 2016 sobre un paper de 2015 resurge porque aparentemente aún no terminamos de reinventar bases de datos de series temporales. El esquema de compresión es elegante de esa manera de '¿por qué no se me ocurrió?', lo cual siempre es un poco molesto.
Ein Blogpost von 2016 über ein Paper von 2015 taucht wieder auf, weil wir offenbar noch nicht fertig sind, Zeitreihendatenbanken neu zu erfinden. Das Kompressionsschema ist elegant auf diese 'warum bin ich nicht drauf gekommen' Art, was immer etwas ärgerlich ist.
From the stands 2 of 3 comments
The simplicity of Gorilla is attractive but for better compression ratios without too much extra compute I'd recommend Sprintz instead.
Gorilla 的简单性很有吸引力，但如果想要更好的压缩比又不增加太多计算，我推荐 Sprintz。
Gorilla のシンプルさは魅力的だが、計算量をあまり増やさずより良い圧縮率を得るには Sprintz をお勧めする。
Gorilla 의 단순함은 매력적이지만 계산량을 많이 늘리지 않고 더 나은 압축률을 원한다면 Sprintz 를 추천한다.
La simplicidad de Gorilla es atractiva pero para mejores ratios de compresión sin mucho cómputo extra recomendaría Sprintz en su lugar.
Die Einfachheit von Gorilla ist attraktiv, aber für bessere Kompressionsraten ohne viel zusätzliche Berechnung würde ich stattdessen Sprintz empfehlen.
x-yl
How does it compare to DuckDB?
和 DuckDB 比怎么样？
DuckDB と比べてどうなの？
DuckDB 랑 비교하면 어때?
¿Cómo se compara con DuckDB?
Wie vergleicht es sich mit DuckDB?
mgaunard