The author is developing a Scheme implementation in async Rust to explore the synergy between the two. They believe Rust's robust tooling, performance, and memory safety, combined with its burgeoning async ecosystem, provide an ideal foundation for a modern Lisp dialect. Async capabilities offer exciting potential for concurrent Scheme programming, especially with features like lightweight tasks and channels. The project aims to leverage Rust's strengths while preserving the elegance and flexibility of Scheme, potentially offering a compelling alternative for both Lisp enthusiasts and Rust developers interested in functional programming.
Kreuzberg is a new Python library designed for efficient and modern asynchronous document text extraction. It leverages asyncio and supports various file formats including PDF, DOCX, and various image types through integration with OCR engines like Tesseract. The library aims for a clean and straightforward API, enabling developers to easily extract text from multiple documents concurrently, thereby significantly improving processing speed. It also offers features like automatic OCR language detection and integrates seamlessly with existing async Python codebases.
Hacker News users discussed Kreuzberg's potential, praising its modern, async approach and clean API. Several questioned its advantages over existing libraries like unstructured and langchain, prompting the author to clarify Kreuzberg's focus on smaller documents and ease of use for specific tasks like title and metadata extraction. Some expressed interest in benchmarks and broader language support, while others appreciated its minimalist design and MIT license. The small size of the library and its reliance on readily available packages like beautifulsoup4 and selectolax were also highlighted as positive aspects. A few commenters pointed to the lack of support for complex layouts and OCR, suggesting areas for future development.
Summary of Comments ( 74 )
https://news.ycombinator.com/item?id=43083017
HN commenters generally expressed interest in the project, finding the combination of Scheme and async Rust intriguing. Several questioned the choice of Rust for performance reasons, arguing that garbage collection makes it a poor fit for truly high-performance async workloads, and suggesting alternatives like C, C++, or even Zig. Some suggested exploring other approaches within the Rust ecosystem, like using a different garbage collector or a stack-allocated scheme. Others praised the project's focus on developer experience and the potential of combining Scheme's expressiveness with Rust's safety features. A few commenters also discussed the challenges of integrating garbage collection with async runtimes and the potential trade-offs involved. The author's responses clarified some of the design choices and acknowledged the performance concerns, indicating they're open to exploring different strategies.
The Hacker News post discussing the blog post "Why I'm writing a Scheme implementation in 2025: Async Rust" has generated a moderate number of comments, mostly focusing on the author's chosen technology stack and motivations.
Several commenters express curiosity and interest in the project. One asks about the specific type of Scheme being implemented, questioning whether it's a "full R7RS Scheme" or a smaller subset. This commenter also mentions their own fondness for Scheme's "powerful macro system." Another commenter questions the choice of Rust for garbage collection, citing potential performance challenges. They suggest exploring other languages like Go or Zig, which might offer better performance for this specific task. However, another user counters this point by suggesting that the author likely chose Rust for its memory safety guarantees, even if it means potentially more complex garbage collection implementation.
A recurring theme in the comments is the perceived complexity of implementing a garbage collector in Rust. Multiple users highlight this as a potentially significant hurdle. One commenter proposes using a tracing garbage collector as a potentially suitable approach. They further elaborate by suggesting that the author could leverage Rust's ownership system to enhance the efficiency of the garbage collector.
Some commenters delve into more technical aspects of the project. One discusses the possibilities of integration with WebAssembly, specifically using WASI. They propose that such integration could allow the Scheme implementation to run in various environments, widening its potential use cases.
There's also discussion about the practical applications of this new Scheme implementation. One commenter suggests potential use cases in game development, highlighting Scheme's suitability for scripting and embedded logic.
Finally, a few comments offer alternative perspectives. One commenter suggests that the author's goal of combining Scheme and async Rust could be achieved by embedding a Lua interpreter instead, arguing that this might be a simpler and more efficient route. Another commenter wonders about the practical benefits of this project, questioning whether the combination of Scheme and async Rust offers significant advantages over existing solutions.
Overall, the comments reflect a mixture of intrigue, skepticism, and practical advice regarding the author's endeavor. While some express enthusiasm for the project, others raise concerns about the chosen technologies and the project's overall practicality. The discussion revolves primarily around the technical challenges of garbage collection in Rust, the potential benefits and drawbacks of the technology stack, and the possible applications of the resulting Scheme implementation.