hackslash dot org

Nova: A JavaScript and WebAssembly engine written in Rust

Posted: 2025-05-29 14:05:27

Nova is a new JavaScript and WebAssembly engine built in Rust, focusing on performance, reliability, and embedability. It aims to provide a fast and secure runtime for server-side JavaScript applications, including serverless functions and edge computing, as well as non-browser environments like game development or IoT devices. Nova supports JavaScript modules, asynchronous programming, and standard Web APIs. It also boasts a small footprint, making it suitable for resource-constrained environments. The project is open-source and still under active development, with a focus on expanding its feature set and improving compatibility with existing JavaScript ecosystems.

The blog post introduces Nova, a new JavaScript and WebAssembly engine built using the Rust programming language. It aims to be a modern, high-performance engine suitable for a variety of use cases, from server-side scripting and embedding in other applications to potentially powering web browsers in the future. The project is motivated by the desire to leverage Rust's memory safety and performance characteristics to create a robust and efficient JavaScript execution environment.

Nova prioritizes standards compliance with recent ECMAScript specifications (specifically mentioning ES2024), ensuring compatibility with modern JavaScript code. It also supports the WebAssembly standard, allowing execution of compiled WebAssembly modules. This dual support allows developers to utilize both JavaScript and WebAssembly within the same environment.

The post highlights Nova's architecture, emphasizing the use of a bytecode compiler and interpreter. Source code is first compiled into bytecode, an intermediate representation, which is then either interpreted or further compiled to machine code using a Just-in-Time (JIT) compiler. This two-tiered approach allows for a balance between fast startup times (achieved through interpretation) and optimal performance (through JIT compilation). Currently, the JIT compiler is under development, with the interpreter being the primary execution method.

A key aspect of Nova's design is its memory management. The engine utilizes a garbage collector to automatically manage memory allocation and deallocation, relieving developers from manual memory management responsibilities and preventing memory leaks and related errors.

The post demonstrates Nova’s capabilities by showcasing a simple example of running JavaScript code. It also outlines the project’s roadmap for future development, which includes implementing the JIT compiler, expanding standards compliance, and improving garbage collection performance. The developers express their ambition for Nova to eventually become a viable alternative to existing JavaScript engines, both in terms of performance and features. The overall tone is optimistic and enthusiastic about the potential of Nova in the JavaScript and WebAssembly ecosystem. The post encourages community involvement and contributions to the project, suggesting it's an open-source endeavor. Finally, the post emphasizes that Nova is still in its early stages of development, implying that while functional, it’s not yet production-ready and further development and optimization are expected.

Summary of Comments ( 19 )
https://news.ycombinator.com/item?id=44126264

HN commenters generally expressed interest in Nova, particularly its Rust implementation and potential performance benefits. Some questioned the practical need for yet another JavaScript engine, especially given the maturity of existing options like V8. Others were curious about specific implementation details, like garbage collection and WebAssembly support. A few pointed out the inherent challenges in competing with established engines, but acknowledged the value of exploring alternative approaches and the potential for niche applications where Nova's unique features might be advantageous. Several users expressed excitement about its potential for integration into other Rust projects. The potential for smaller binary sizes and faster startup times compared to V8 was also highlighted as a potential advantage.

The Hacker News post for "Nova: A JavaScript and WebAssembly engine written in Rust" has several comments discussing various aspects of the project.

Some users express excitement about a new JavaScript engine written in Rust, seeing it as a positive development. They praise the potential performance benefits and memory safety that Rust can bring to such a project. One user specifically mentions being interested in the potential for Servo’s concurrency model to be implemented, potentially leading to impressive parallelization capabilities.

There's a discussion regarding the feasibility and challenges of creating a JavaScript engine from scratch. Several users point out the immense undertaking involved in fully supporting the JavaScript specification and achieving competitive performance with established engines like V8. Concerns about garbage collection implementation and the potential for subtle bugs also surface. However, some counter that starting anew allows for leveraging modern design principles and potentially avoiding legacy baggage.

The conversation also delves into the motivations behind building a new engine, with speculation about whether it aims to address specific niches or explore novel architectural ideas. Some suggest potential use cases like embedded systems, server-side JavaScript, or specialized applications where existing engines might not be ideal.

Performance comparisons with existing engines are a recurring theme. Users express curiosity about benchmarks and real-world performance metrics. While acknowledging it's early days for the project, they emphasize the importance of demonstrating tangible performance advantages to justify adopting a new engine.

There's a brief discussion on the project's licensing, specifically the use of the MIT license, which is seen as permissive and conducive to wider adoption.

A few comments touch upon the broader landscape of JavaScript engines, mentioning other projects like QuickJS and highlighting the challenges faced by alternative engines in gaining widespread traction.

Finally, some users share their personal experiences with Rust and WebAssembly, expressing optimism about the project's prospects given the strengths of these technologies.

Overall, the comments reflect a cautious but optimistic outlook on Nova. While acknowledging the significant challenges involved in building a successful JavaScript engine, commenters are intrigued by the potential of a Rust-based implementation and eager to see how the project evolves.

Running GPT-2 in WebGL: Rediscovering the Lost Art of GPU Shader Programming

permalink

Posted: 2025-05-27 18:02:51

Nathan Reed successfully ran a scaled-down version of the GPT-2 language model entirely within a web browser using WebGL shaders. By leveraging the parallel processing power of the GPU, he achieved impressive performance, generating text at a reasonable speed without any server-side computation. This involved creatively encoding model parameters as textures and implementing the transformer architecture's intricate operations using custom shader code, demonstrating the potential of WebGL for complex computations beyond traditional graphics rendering. The project highlights the power and flexibility of shader programming for tasks beyond its typical domain, offering a fascinating glimpse into using readily available hardware for machine learning inference.

Nathan Ross's blog post, "Running GPT-2 in WebGL: Rediscovering the Lost Art of GPU Shader Programming," details his ambitious project of implementing the GPT-2 language model entirely within a web browser, leveraging the power of WebGL for computation. Motivated by a desire to explore the limits of browser-based machine learning and rediscover the underlying principles of GPU programming, Ross embarked on this challenging endeavor.

The post begins by outlining the rationale behind choosing GPT-2, citing its manageable size and established position in the natural language processing landscape. Recognizing the computational intensity of running such a model, especially within the confines of a browser, Ross opted for WebGL, a JavaScript API providing access to the GPU. This choice necessitated a deep dive into shader programming, a domain he describes as somewhat obscured by higher-level abstractions in modern GPU programming practices.

Ross then meticulously describes the process of translating the GPT-2 architecture into a series of shader programs. He elaborates on the challenges involved in adapting the matrix multiplications, crucial for transformer models like GPT-2, to the constraints of WebGL. This included meticulously managing data layout and transfer between CPU and GPU, a crucial aspect for performance optimization. The post highlights the intricate details of how tensors, the fundamental data structures in deep learning, are represented and manipulated within the shader environment. Ross explains the necessity of flattening and packing these multi-dimensional arrays into textures, the primary data structure used by GPUs, and the subsequent unpacking within the shaders.

The narrative continues with a discussion of the limitations and workarounds encountered. Due to the constraints of WebGL 1.0, which lacks direct support for integer operations within shaders, Ross devised innovative solutions using floating-point arithmetic to mimic integer behavior. He also emphasizes the iterative development process, constantly profiling and optimizing the shader code to maximize performance within the browser's limited resources.

Further, the blog post showcases the practical application of this WebGL implementation by demonstrating text generation within a browser. Users can input a starting prompt, and the browser-based GPT-2 generates subsequent text, all powered by the GPU. Ross also provides insights into the performance characteristics, comparing inference speeds achieved with this WebGL implementation to those of CPU-based execution. While acknowledging that the WebGL version isn't as fast as optimized CPU implementations, he emphasizes the significant speedup achieved compared to a naive JavaScript implementation.

Finally, Ross reflects on the project's broader significance, emphasizing the renewed appreciation for the underlying mechanics of GPU programming gained through this experience. He suggests that understanding these low-level details can be valuable even when working with higher-level frameworks, providing a deeper insight into performance bottlenecks and optimization strategies. The post concludes with a call to further exploration of browser-based machine learning, highlighting its potential for accessibility and broader applications.

Summary of Comments ( 20 )
https://news.ycombinator.com/item?id=44109257

HN commenters largely praised the author's approach to running GPT-2 in WebGL shaders, admiring the ingenuity and "hacky" nature of the project. Several highlighted the clever use of texture memory for storing model weights and intermediate activations. Some questioned the practical applications, given performance limitations, but acknowledged the educational value and potential for other, less demanding models. A few commenters discussed WebGL's suitability for this type of computation, with some suggesting WebGPU as a more appropriate future direction. There was also discussion around optimizing the implementation further, including using half-precision floats and different texture formats. A few users shared their own experiences and resources related to shader programming and on-device inference.

The Hacker News post discussing running GPT-2 in WebGL and GPU shader programming has generated a moderate number of comments, focusing primarily on the technical aspects and implications of the approach.

Several commenters express fascination with the author's ability to implement such a complex model within the constraints of WebGL shaders. They commend the author's ingenuity and deep understanding of both GPT-2 and the nuances of shader programming. One commenter highlights the historical context, recalling a time when shaders were used for more general-purpose computation due to limited access to compute shaders. This reinforces the idea that the author is reviving a "lost art."

There's a discussion around the performance characteristics of this approach. While acknowledging the technical achievement, some commenters question the practical efficiency of running GPT-2 in a browser environment using WebGL. They point out the potential bottlenecks, such as data transfer between the CPU and GPU, and the inherent limitations of JavaScript and browser APIs compared to native implementations. A specific concern raised is the overhead of converting model weights to half-precision floating-point numbers, a requirement for WebGL 1.0. However, another commenter suggests potential optimizations, such as using WebGL 2.0 which supports 32-bit floats.

The topic of precision and its impact on model accuracy is also addressed. Some express skepticism about maintaining the model's performance with reduced precision. They posit that the quantization necessary for WebGL could significantly degrade the quality of the generated text.

A few commenters delve into the technical details of the implementation, discussing topics like memory management within shaders, the challenges of data representation, and the use of textures for storing model parameters. This provides additional insight into the complexity of the project.

Finally, there's a brief discussion about the potential applications of this approach. While acknowledging the current performance limitations, some see promise in using browser-based GPT-2 for specific use cases where client-side inference is desirable, such as privacy-sensitive applications.

In summary, the comments on Hacker News show appreciation for the technical feat of running GPT-2 in WebGL shaders, while also raising pragmatic concerns about performance and accuracy. The discussion provides valuable insights into the challenges and potential of this unconventional approach to deploying machine learning models.

Show HN: Porting Terraria and Celeste to WebAssembly

permalink

Posted: 2025-05-26 20:06:25

The blog post details the author's successful porting of both Terraria and Celeste to WebAssembly using a custom C# runtime built upon Mono. This allows both games to run directly within a web browser without plugins or installation. The author highlights the challenges encountered, particularly with handling graphics and input, and explains the solutions implemented, such as utilizing SDL2 and Emscripten. While performance isn't yet perfect, particularly with Terraria's more complex world generation, both games are demonstrably playable in the browser, showcasing the potential of WebAssembly for running demanding applications.

This blog post by Velzie chronicles their ambitious project of porting two popular indie games, Terraria and Celeste, to WebAssembly (Wasm) using the Emscripten compiler. The ultimate goal is to enable these games to run natively in a web browser without requiring plugins or external software. The post focuses primarily on the challenges and successes experienced while porting Celeste, highlighting the complexities involved in adapting a game designed for a desktop environment to the constraints and capabilities of the web.

Velzie begins by outlining their motivation, driven by a desire to experiment with Wasm and explore the potential of web-based gaming. They then detail the technical hurdles they faced. One major obstacle was managing the game's file system, which required emulation within the browser environment. This involved creating a virtual file system within Wasm that could mimic the game's original file access patterns. Another significant challenge was handling the game's audio output, which required careful integration with the browser's audio APIs. Velzie explains how they tackled this by utilizing the SDL2 library and leveraging its audio capabilities within the Wasm context.

The post further elaborates on the performance considerations of running a computationally intensive game like Celeste within a browser. Velzie discusses the optimization techniques employed to improve performance, including memory management strategies and code optimizations specific to the Wasm compilation process. They describe the iterative process of identifying performance bottlenecks and implementing targeted solutions to ensure smooth gameplay.

The author also delves into the nuances of handling user input, requiring mapping keyboard and mouse events to the game's input system within the Wasm environment. They explain how they achieved this mapping using Emscripten’s input handling functionalities, enabling players to control the game seamlessly within the browser.

Throughout the post, Velzie shares code snippets and technical insights into the porting process. While acknowledging that the project is still a work in progress, the demonstrable results showcase the feasibility and potential of running complex games like Celeste within a web browser using WebAssembly. The post concludes with reflections on the lessons learned and future directions for the project, hinting at the possibility of expanding the Wasm port to encompass other games as well. It emphasizes the exciting potential of Wasm as a powerful technology for bringing demanding applications, particularly games, to the web platform.

Summary of Comments ( 38 )
https://news.ycombinator.com/item?id=44101175

HN users discussed the technical challenges and successes of porting games to WebAssembly. Several commenters praised the developer's work, particularly the performance achieved with Celeste, noting it felt native. Some discussed the complexities of handling game inputs, audio, and file system access within the browser environment. A few users expressed interest in the potential of WASM for game development, seeing it as a viable platform for distributing and playing games without installations. Others shared their experiences with similar projects and offered suggestions for optimization. The legality of distributing ROMs online was also briefly touched upon.

The Hacker News post discussing the porting of Terraria and Celeste to WebAssembly generated several interesting comments. Many users praised the technical achievement, particularly the performance of the Celeste port. One user, "velzie" (presumably the author of the original blog post), clarified some details about the project, such as the use of Emscripten and the fact that the ports weren't fully completed but rather tech demos. They also mentioned the challenges they faced, like audio latency and the lack of proper gamepad support in the browser.

Several comments focused on the performance aspects. Some users expressed surprise at how well these complex games ran in a browser environment. Others discussed the potential of WebAssembly for gaming, with some arguing that it could eventually rival native performance. There was some debate about the overhead of garbage collection and the limitations of the browser's sandbox environment.

A recurring theme was the potential legal implications of these ports, specifically regarding copyright infringement. Users discussed the complexities of distributing copyrighted game assets and the potential responses from game developers.

Some users shared their own experiences with WebAssembly, mentioning other games or applications that had been successfully ported. They also discussed the tools and techniques used for WebAssembly development, including Emscripten and various JavaScript frameworks.

One commenter pointed out the irony of running computationally intensive games in a browser tab alongside other tabs, potentially impacting overall system performance. Another user suggested potential improvements to the project, such as implementing virtual gamepad controls.

Several commenters requested information about the porting process and expressed interest in learning more about WebAssembly development. They inquired about specific technical details, such as the handling of game assets and the implementation of input controls. The author, "velzie," provided some helpful responses to these questions, sharing insights into their development process and the challenges they faced.

Roto: A Compiled Scripting Language for Rust

permalink

Posted: 2025-05-21 11:10:29

NLnet Labs introduces Roto, a compiled scripting language designed specifically for extending Rust applications. Aiming to bridge the gap between embedded scripting (with languages like Lua) and native Rust extensions, Roto offers performance closer to native code while maintaining the flexibility and rapid iteration of a scripting language. It compiles to native code via LLVM, leverages Rust's type system and memory safety, and allows seamless interoperability with existing Rust code. Roto is still under active development but shows promise as a performant and safe way to script and extend Rust programs.

NLnet Labs has introduced Roto, a novel compiled scripting language specifically designed for integrating with Rust. Roto aims to bridge the gap between the performance of compiled languages and the flexibility of scripting languages, offering a powerful tool for extending Rust applications without sacrificing speed. The blog post details the motivations behind Roto's development and its core features.

A key motivation for creating Roto was the need for a scripting language that could seamlessly interact with Rust data structures and functions. Existing scripting solutions often require complex bridging mechanisms and data marshalling, which can negatively impact performance. Roto addresses this issue by leveraging Rust's type system and memory management, enabling direct access to Rust code with minimal overhead.

Roto achieves its performance through ahead-of-time (AOT) compilation. Unlike interpreted scripting languages, Roto scripts are compiled into native code before execution, resulting in significantly faster performance. This compilation process leverages the LLVM infrastructure, the same robust compiler technology used by Rust itself.

The language's syntax is inspired by Lua, known for its simplicity and ease of use. This design choice aims to make Roto accessible to a wide range of developers. Additionally, Roto features optional static typing, offering developers the choice between the flexibility of dynamic typing for rapid prototyping and the safety and performance benefits of static typing for production-ready code.

Roto's integration with Rust is further enhanced by its ability to define custom data types and functions directly within Rust code, making them readily available to Roto scripts. This deep integration allows developers to extend the functionality of their Rust applications in a highly efficient and maintainable manner.

The blog post highlights a practical use case for Roto within the context of the RPKI (Resource Public Key Infrastructure), demonstrating its ability to streamline complex validation tasks. In this scenario, Roto scripts are utilized to define and execute validation rules, showcasing the language's potential for network security applications.

While still in its early stages of development, Roto demonstrates considerable promise as a powerful and efficient scripting solution for Rust. The project's focus on performance, seamless integration with Rust, and ease of use positions it as a valuable tool for developers looking to enhance the flexibility and extensibility of their Rust projects. The creators encourage community involvement and contributions to help shape the future of the language.

Summary of Comments ( 82 )
https://news.ycombinator.com/item?id=44050222

HN commenters discuss Roto's potential, particularly for embedded systems and scenarios requiring quick iteration. Some express interest in its ability to potentially replace Lua while offering better performance and tighter Rust integration. Concerns arise about Roto's early stage of development and limited documentation. Several commenters question its practical advantages over existing scripting solutions or using Rust directly, particularly given the existence of similar projects. Others raise points about garbage collection, debugging, and the trade-offs between scripting and compiled languages. Finally, some discuss the difficulty of achieving the "holy grail" of a truly performant, easy-to-use scripting language embedded within a systems language.

The Hacker News post for "Roto: A Compiled Scripting Language for Rust" generated a moderate amount of discussion, with a number of commenters exploring various aspects of the language and its potential use cases.

Several commenters expressed interest in Roto's ability to address the complexities of build scripts and configuration management in Rust. They saw it as a potential solution to the awkwardness of using existing tools like build.rs scripts, which often require dropping down to a lower level of abstraction and dealing with environment variables and process management. Roto's compiled nature and Rust integration were seen as advantageous in this context.

There was a discussion around the tradeoffs between interpreted and compiled scripting languages. Some questioned whether a compiled scripting language truly offered significant advantages over an interpreted one, especially given the overhead of compilation. However, proponents of Roto countered that the performance benefits and tighter integration with Rust's type system outweighed the compilation costs, particularly in scenarios where the script is executed repeatedly.

A few commenters drew parallels between Roto and other scripting or extension languages like Lua and Dyon. They discussed the potential for Roto to fill a similar niche within the Rust ecosystem, enabling developers to extend Rust applications with dynamic scripting capabilities.

Some users also raised questions about Roto's specific features and implementation details, such as its garbage collection mechanism, error handling strategy, and the extent of its integration with existing Rust crates. These questions highlighted the desire for more information about the language's practical aspects and how it compares to alternative approaches.

A recurring theme was the desire for a more streamlined and ergonomic developer experience within the Rust ecosystem. Roto was viewed by some as a potential step in this direction, offering a more convenient way to handle tasks that are currently cumbersome or require workarounds.

Finally, there was some skepticism expressed about the long-term viability of Roto. Some commenters questioned whether it would gain sufficient traction and community support to become a widely adopted tool. However, others expressed optimism, noting the potential for Roto to address real pain points in the Rust development workflow.

Reports of Deno's Demise Have Been Greatly Exaggerated

permalink

Posted: 2025-05-20 11:33:14

Deno, the JavaScript/TypeScript runtime, is actively addressing recent community concerns regarding its perceived decline. The blog post refutes the narrative of Deno's "demise," highlighting continued development, a growing user base, and successful integration in production environments at companies like Slack and Netlify. While acknowledging a shift in focus away from the Deno Deploy serverless platform towards improving the core runtime, the team emphasizes their commitment to the long-term vision of Deno and its potential for simplifying JavaScript development. They are actively working on performance enhancements, improved documentation, and expanding compatibility, demonstrating their ongoing dedication to the project's growth and stability.

The blog post, titled "Reports of Deno's Demise Have Been Greatly Exaggerated," emphatically refutes recent online discussions suggesting a decline in Deno's popularity and relevance within the JavaScript and TypeScript ecosystem. The authors acknowledge the perception of diminished activity, particularly concerning social media engagement and perceived stagnation in the growth of Deno Deploy, their serverless cloud offering. However, they argue this perception is a misinterpretation of Deno's current strategic focus and does not accurately reflect the platform's overall health and trajectory.

The post meticulously dismantles the narrative of decline by presenting a multifaceted counter-argument. Firstly, it highlights substantial, albeit less publicly visible, growth in Deno's usage. Specifically, it cites a significant increase in monthly downloads of the Deno runtime, demonstrating continued adoption and integration into developer workflows. Secondly, it emphasizes the robust financial standing of the Deno company, securing substantial funding that ensures long-term stability and capacity for ongoing development. This financial security, they argue, allows Deno to prioritize foundational improvements and strategic initiatives rather than chasing short-term metrics like social media buzz.

Further addressing the perceived stagnation of Deno Deploy, the post clarifies that the initial explosive growth, fueled by early adopters and novelty, has naturally leveled off into a more sustainable, albeit less dramatic, expansion. This, they explain, is characteristic of any technology's adoption lifecycle and should not be misinterpreted as a sign of failure. Furthermore, the post underscores Deno Deploy's ongoing evolution and improvement, with a renewed focus on enterprise-grade features and infrastructure enhancements to solidify its position as a robust and reliable serverless platform.

Finally, the post reiterates Deno's commitment to its core principles of providing a secure, modern, and productive runtime environment for JavaScript and TypeScript. It emphasizes the ongoing dedication to refining the developer experience, enhancing performance, and expanding the ecosystem of tools and libraries available to Deno developers. The authors conclude by expressing confidence in Deno's future, asserting that the project is not only alive and well but poised for continued growth and impact on the future of web development. They attribute the perceived decline to a shift in focus towards less visible but ultimately more crucial aspects of the project, reassuring the community of their long-term vision and commitment to Deno's success.

Summary of Comments ( 117 )
https://news.ycombinator.com/item?id=44040332

Hacker News users discuss Deno's blog post addressing concerns about its perceived decline. Several commenters express skepticism about Deno's claimed growth, questioning the metrics used and highlighting the lack of significant real-world adoption. Some users point to the continued dominance of Node.js and the difficulty of displacing an established ecosystem. Others mention Deno's fresh approach to security and its potential for specific use cases, but acknowledge it hasn't achieved mainstream success. A few users express interest in trying Deno for smaller projects, but overall the sentiment leans towards cautious observation rather than enthusiastic endorsement. The discussion reflects a wait-and-see attitude regarding Deno's future.

The Hacker News post titled "Reports of Deno's Demise Have Been Greatly Exaggerated" (linking to a Deno blog post) sparked a lively discussion with a variety of viewpoints on Deno's current state and future prospects.

Several commenters expressed skepticism about Deno's long-term viability. One user questioned the blog post's metrics, pointing out that download numbers don't necessarily equate to actual usage or successful projects. They also highlighted the challenge Deno faces in competing against established ecosystems like Node.js, arguing that Deno needs a "killer feature" to truly differentiate itself and attract a larger user base. Another commenter echoed this sentiment, suggesting that Deno's initial promise of security and simplicity has been overshadowed by the complexities introduced by features like npm compatibility. This commenter also expressed concern about the lack of a clear roadmap and the potential for Deno to become yet another "compile-to-JS" language that struggles to gain traction.

Others defended Deno, praising its improvements and expressing optimism for its future. One user highlighted Deno's fresh approach to package management and its focus on web standards. They argued that while Deno might not have a single "killer feature," its cumulative improvements offer a more streamlined and modern developer experience. Another commenter pointed out Deno's success in specific niches, such as edge computing and serverless functions, suggesting that Deno might find its true strength in specialized applications. They also appreciated Deno's commitment to stability and its well-defined release process. Some users also mentioned their positive experiences with Deno Deploy and Fresh, showcasing specific examples of Deno's practicality and ease of use.

A recurring theme in the comments was the comparison between Deno and Node.js. Several users debated the merits of each platform, with some arguing that Deno offers a cleaner and more secure alternative to Node.js, while others maintained that Node.js's mature ecosystem and vast community make it the superior choice. Some commenters acknowledged the strengths of both platforms and suggested that they could coexist and serve different needs.

The discussion also touched upon the challenges of building and maintaining open-source projects. One commenter expressed sympathy for the Deno team, acknowledging the difficulty of responding to community feedback and balancing competing priorities. They emphasized the importance of patience and understanding in the open-source development process.

Overall, the comments reflect a mixed sentiment towards Deno. While some remain skeptical about its future, others see its potential and appreciate its ongoing development. The discussion highlights the ongoing competition in the JavaScript ecosystem and the challenges faced by newer projects trying to gain traction against established players.

WASM 2.0

permalink

Posted: 2025-05-09 08:01:06

WebAssembly 2.0 is a significant upgrade to the WebAssembly platform, enhancing its capabilities while maintaining backwards compatibility. This version introduces several key features like fixed-width SIMD for improved performance in multimedia and computational tasks, bulk memory operations for efficient data manipulation, and relaxed SIMD to offer portability across diverse hardware. Additionally, reference types enable direct manipulation of JavaScript objects and other WebAssembly modules, fostering better integration with existing web technologies. These advancements, along with improved exception handling and enhanced thread control, further solidify WebAssembly's position as a powerful and versatile technology for web development and beyond.

The WebAssembly Core Specification 2.0 details a significant evolution of the WebAssembly (Wasm) platform, building upon the foundational concepts of version 1.0. This document meticulously outlines the core components of the Wasm system, including its abstract syntax, validation rules, and execution semantics. It serves as the definitive guide for implementers building Wasm engines, toolchains, and related technologies.

A primary focus of Wasm 2.0 is enhanced expressiveness and performance. The specification introduces new features designed to improve developer productivity and broaden the range of applications that can effectively leverage Wasm. These enhancements include improved support for bulk memory operations, richer control flow mechanisms, and refined type handling. The specification also addresses the growing need for interoperability with other web technologies and external systems.

The core of the Wasm system revolves around modules, which are portable units of code containing functions, data segments, and other related elements. The specification painstakingly defines the structure and validation rules for these modules, ensuring that Wasm code can be reliably and securely executed across different environments. The binary format of these modules is also carefully defined, promoting efficient parsing and loading.

The execution semantics of Wasm are described in detail, covering aspects such as memory management, function calls, and control flow. The specification defines the operational semantics of Wasm instructions, providing a precise and unambiguous model of how Wasm code behaves at runtime. This detailed definition allows for predictable and consistent execution across different Wasm implementations.

The specification also covers the integration of Wasm with host environments, such as web browsers. It defines the interface through which Wasm modules can interact with the host, enabling access to system resources and functionality. This interoperability is crucial for allowing Wasm modules to participate fully within larger applications and systems.

Furthermore, Wasm 2.0 emphasizes modularity and extensibility. The specification lays the groundwork for future extensions and customizations of the Wasm platform, allowing the ecosystem to evolve and adapt to emerging needs and use cases. This forward-thinking approach ensures that Wasm remains a relevant and powerful technology in the evolving landscape of web development and beyond. Finally, the document emphasizes the importance of security and provides guidance on how to mitigate potential vulnerabilities. It underscores the need for robust implementations that adhere to the specification's guidelines to ensure the safe and reliable execution of Wasm code.

Summary of Comments ( 80 )
https://news.ycombinator.com/item?id=43934711

Hacker News users discussed the potential impact and features of WASM 2.0. Several commenters expressed excitement about improved performance, particularly regarding garbage collection and interface types, hoping it would pave the way for wider adoption, including GUI applications and better integration with existing languages. Some discussed the complexity of the specification and the challenges of implementation. A recurring theme was the desire for simplified integration with JavaScript and the browser DOM, a key factor in WASM's broader usability. There were also inquiries and discussions about specific technical aspects like tail calls, exceptions, and memory management. Some users expressed caution, wanting to see real-world performance improvements before getting too enthusiastic.

The Hacker News post titled "WASM 2.0" linking to the W3C's WebAssembly Core Specification 2.0 draft has generated a moderate amount of discussion. Several commenters express excitement about the future of WebAssembly and the improvements proposed in version 2.0.

A key theme in the comments is the maturation of WebAssembly. Commenters observe that the 2.0 specification signifies a move towards stability and standardization, solidifying WebAssembly's place as a key technology for web development and beyond. The addition of features like garbage collection and improved threading support are frequently mentioned as positive developments, expanding the potential use cases for WebAssembly.

Some commenters delve into specific features of the 2.0 draft. Discussion around garbage collection touches on its potential benefits for languages like Java, Python, and JavaScript that rely on garbage collection. The improved threading model is also highlighted as a significant improvement, enabling better performance for multi-threaded applications.

Performance is another recurring topic, with commenters speculating about the potential performance improvements offered by WebAssembly 2.0. While acknowledging that benchmarks are needed, there's general optimism that the new features will contribute to faster and more efficient web applications.

A few commenters discuss the broader implications of WebAssembly's evolution. Some see it as a potential game-changer for web development, enabling more complex and performant web applications. Others discuss its potential applications beyond the browser, such as in serverless computing and other cloud-native environments.

While there's a general sense of enthusiasm, some commenters express caution. They note that WebAssembly 2.0 is still a draft and that the final specification might differ. Others raise concerns about the complexity of some of the new features and their potential impact on browser compatibility.

Overall, the comments reflect a positive outlook on the future of WebAssembly. The 2.0 draft is seen as a significant step forward, promising improved performance, expanded capabilities, and greater maturity for the technology. While some cautionary notes are present, the overall sentiment is one of anticipation and excitement for the potential of WebAssembly 2.0.

Running Clojure in WASM with GraalVM

permalink

Posted: 2025-04-27 07:50:07

This blog post details the author's successful experiment running Clojure code in a web browser using WebAssembly (WASM) compiled via GraalVM Native Image. The process involves using SCI, the self-hosted Clojure interpreter, to create a native image ahead-of-time (AOT) that can be further compiled to WASM. The post highlights several key steps, including preparing a minimal Clojure project, utilizing GraalVM's native-image tool with necessary configuration for WASM, and finally embedding the resulting WASM file in a simple HTML page for browser execution. The author showcases a basic "Hello, World!" example and briefly touches on potential benefits like performance improvements, albeit acknowledging the current limitations and experimental nature of the approach.

Roman Liutikov's blog post, "Running Clojure in WASM with GraalVM," details the process and considerations involved in compiling Clojure code into WebAssembly (WASM) using GraalVM Native Image. The primary motivation is to leverage WASM's portability and performance benefits for running Clojure applications in web browsers and other WASM-compatible environments.

The post begins by acknowledging existing tools like clj-kondo and babashka for compiling ClojureScript, a dialect of Clojure designed for JavaScript interoperability, to WASM. However, it emphasizes the desire to compile Clojure directly, without resorting to ClojureScript. This is where GraalVM Native Image enters the picture.

Liutikov explains that GraalVM's ability to compile Java applications ahead-of-time (AOT) extends to other JVM languages like Clojure. This AOT compilation produces a native executable, which can then be further processed into a WASM binary. The blog post outlines a specific workflow involving several key steps:

Preparing a simple Clojure project: This involves creating a basic deps.edn file to manage project dependencies, including the org.clojure/clojure dependency itself. A straightforward Clojure function, greet, is defined for demonstration.
Utilizing the native-image tool: GraalVM's native-image tool is the core component for AOT compilation. The post highlights the importance of including the --language:clojure flag to enable Clojure support and specifies the entry point using --main. Crucially, the --wasm flag instructs the compiler to generate a WASM output instead of a native executable.
Handling Clojure's runtime dependencies: A significant challenge is ensuring all necessary Clojure runtime libraries are included in the WASM binary. The blog post addresses this by adding a reflect-config.json file which lists classes requiring reflection during runtime. This file is then passed to native-image using the -H:ReflectionConfigurationFiles option.
Executing the WASM binary: Once the compilation process is complete, the resulting WASM file can be executed within a WASM runtime environment like wasmtime. The post showcases a basic example of running the compiled greet function using wasmtime.

Liutikov further discusses some of the complexities and nuances encountered during the process. Specifically, the post details the challenges of managing Clojure's dynamic nature and reliance on reflection within the context of AOT compilation. The reflect-config.json file becomes crucial for mitigating these challenges by explicitly specifying classes that need reflection support.

The post concludes by acknowledging the experimental nature of compiling Clojure directly to WASM with GraalVM and highlighting the potential for future advancements in this area. The successful execution of a simple Clojure function demonstrates the feasibility of this approach, paving the way for exploring more complex Clojure applications in WASM environments. The author expresses optimism about the potential for improved performance and portability for Clojure applications using this technique.

Summary of Comments ( 29 )
https://news.ycombinator.com/item?id=43810211

Hacker News users discussed the challenges and potential benefits of running Clojure in WASM using GraalVM. Several commenters pointed out the substantial resulting file sizes, questioning the practicality for web applications. Performance concerns were also raised, particularly regarding startup time. Some suggested exploring alternative approaches like using smaller ClojureScript compilers or different WASM runtimes. Others expressed excitement about the possibilities, mentioning potential applications in serverless functions and plugin systems. One commenter highlighted the contrast between the "write once, run anywhere" promise of Java (which GraalVM leverages) and the current state of browser compatibility issues. The overall sentiment leaned towards cautious optimism, acknowledging the technical hurdles while recognizing the potential of Clojure in the WASM ecosystem.

The Hacker News post "Running Clojure in WASM with GraalVM" (https://news.ycombinator.com/item?id=43810211) has several comments discussing the challenges and potential of compiling Clojure to WebAssembly (Wasm).

One commenter highlights the inherent difficulties in making Clojure, a language heavily reliant on the Java Virtual Machine (JVM), work efficiently in a Wasm environment. They point out that the JVM's dynamic nature and garbage collection present significant obstacles to achieving optimal performance in a browser context. This leads to concerns about larger Wasm output sizes compared to other languages better suited for Wasm compilation, like Rust.

The discussion delves into potential solutions and workarounds for these challenges. The use of GraalVM Native Image is mentioned as a way to ahead-of-time compile Java code, potentially reducing the runtime overhead associated with the JVM. However, the effectiveness of this approach with Clojure's dynamic features is questioned. Another commenter mentions that fully leveraging GraalVM Native Image with Clojure requires carefully considering and potentially restricting certain aspects of the language's dynamism.

There's also a comment about the practicalities of debugging Clojure running in Wasm, suggesting it's a more complex process than debugging JavaScript. This contributes to the overall theme of the challenges involved in bridging the gap between Clojure's JVM-centric design and the Wasm environment.

Further discussion involves the limitations of running mutable data structures in a multi-threaded context within Wasm. While Wasm offers threading capabilities, the intricacies of shared memory management and the avoidance of data races become important considerations when porting languages like Clojure that typically handle these complexities within the JVM.

Finally, there's speculation about the future of Wasm and its potential to evolve into a more robust platform capable of efficiently hosting languages like Clojure. This touches upon the hope that advancements in Wasm technology might eventually alleviate the currently identified challenges.

Show HN: Faasta – A self-hosted Serverless platform for WASM-wasi-HTTP in Rust

permalink

Posted: 2025-04-25 00:31:05

Faasta is a self-hosted serverless platform written in Rust that allows you to run WebAssembly (WASM) functions compiled with the wasi-http ABI. It aims to provide a lightweight and efficient way to deploy serverless functions locally or on your own infrastructure. Faasta manages the lifecycle of these WASM modules, handling scaling and routing requests. It offers a simple CLI for managing functions and integrates with tools like HashiCorp Nomad for orchestration. Essentially, Faasta lets you run WASM as serverless functions similarly to cloud providers, but within your own controlled environment.

This Hacker News post introduces Faasta, a self-hosted, open-source serverless platform specifically designed for WebAssembly (Wasm) modules compiled with the wasi-http interface. Written in Rust, Faasta aims to provide a lightweight and efficient runtime environment for executing Wasm functions as serverless functions. The platform leverages the capabilities of Wasm's sandboxed execution environment to offer enhanced security and portability, allowing developers to deploy their functions across different operating systems and architectures without modification.

Faasta emphasizes simplicity and ease of use. Developers write their functions in languages that compile to Wasm and support the wasi-http standard. These functions can then be easily deployed to a Faasta instance. The platform handles the complexities of managing the Wasm runtime, including instantiation, execution, and resource allocation. Faasta also likely manages the HTTP request routing to the appropriate Wasm functions based on configured routes.

The project leverages Rust's performance characteristics and memory safety to create a robust and efficient execution environment for serverless functions. The post highlights Faasta as a potential solution for developers looking to build and deploy serverless applications without relying on cloud providers or complex container orchestration systems. The self-hosted nature of Faasta grants users full control over their infrastructure and data, which can be particularly appealing for sensitive applications or those requiring specific compliance requirements. While the post does not delve into specifics, it suggests a streamlined workflow for deploying Wasm functions, likely involving minimal configuration and potentially automated scaling based on demand. The underlying Wasm technology enables rapid cold starts and low overhead, contributing to efficient resource utilization and cost savings. The use of the wasi-http interface further simplifies development by providing a standardized way for Wasm functions to interact with HTTP requests and responses.

Summary of Comments ( 20 )
https://news.ycombinator.com/item?id=43789010

Hacker News users generally expressed interest in Faasta, praising its use of Rust and WASM/WASI for serverless functions. Several commenters appreciated its self-hosted nature and the potential cost savings compared to cloud providers. Some questioned the performance characteristics and cold start times, particularly in comparison to existing serverless offerings. Others pointed out the relative complexity compared to simpler container-based solutions, and the need for more robust observability features. A few commenters offered suggestions for improvements, including integrating with existing service meshes and providing examples for different use cases. The overall sentiment was positive, with many eager to see how the project evolves.

The Hacker News post discussing Faasta, a self-hosted serverless platform for WASM-wasi-HTTP in Rust, generated a moderate amount of discussion with a mix of praise, curiosity, and constructive criticism.

Several commenters expressed excitement about the project, praising its use of Rust and WASM, and seeing it as a promising approach to serverless computing. They appreciated the potential for improved performance and security compared to traditional serverless platforms, particularly highlighting the isolation provided by WASM. The self-hosting aspect was also seen as a significant advantage, offering greater control and flexibility.

Some commenters focused on the developer experience. They inquired about the ease of use and the learning curve associated with deploying and managing functions on Faasta. There were questions about specific features, like cold starts and scaling capabilities. One commenter specifically asked about the process of adding new WASM modules, expressing a desire for a straightforward and intuitive deployment mechanism.

A recurring theme in the comments was a comparison to other similar projects and technologies. Commenters mentioned existing serverless platforms and WASM runtimes, discussing the advantages and disadvantages of each. Some suggested alternative approaches or technologies that could be integrated into Faasta, such as using different WASM runtimes or exploring different networking models.

A few commenters raised technical points, including discussions around security considerations and the performance implications of using WASM. One commenter specifically questioned the overhead associated with WASM, particularly in the context of I/O operations.

Finally, some commenters expressed interest in contributing to the project or using it for their own applications. They requested more information about the project's roadmap and future development plans. Overall, the comments reflect a positive reception for Faasta, with a keen interest in its potential and a desire for more information about its practical application.

Abusing DuckDB-WASM by making SQL draw 3D graphics (Sort Of)

permalink

Posted: 2025-04-22 13:35:47

The blog post details a creative misuse of DuckDB-WASM, compiling SQL queries within a web browser to generate 3D-like graphics. By leveraging DuckDB's ability to generate large datasets and then encoding coordinate and color information into a custom string format, the author renders these strings as voxels within a JavaScript-based 3D viewer. While not true 3D graphics rendering in the traditional sense, the approach demonstrates the surprising flexibility of DuckDB and its potential for unconventional applications beyond standard data analysis. Essentially, the SQL queries define the shape and colors of the "voxels," which are then assembled and displayed by the JavaScript frontend.

The blog post "Abusing DuckDB-WASM by making SQL draw 3D graphics (Sort Of)" by Frank McSherry details an unconventional and experimental approach to generating 3D graphics using the in-browser version of the DuckDB analytical database, specifically its WebAssembly (WASM) implementation. The author's primary motivation stems from a fascination with pushing the boundaries of what DuckDB can achieve beyond its intended purpose of data analysis. The core idea revolves around exploiting DuckDB's ability to perform relational algebra operations on large datasets to manipulate and render a 3D model.

Instead of traditional graphics APIs and shaders, McSherry leverages SQL queries to process the vertex and face data of a 3D model. The model itself is represented as relational tables within DuckDB, where each vertex and each triangular face are stored as rows with their respective coordinates and connectivity information. The "rendering" process is accomplished by using SQL queries to project the 3D vertices onto a 2D plane, simulating a perspective projection. This projection is achieved through mathematical operations within the SQL query itself, calculating the screen coordinates of each vertex based on a simplified camera model.

The post highlights the limitations of this approach. It's not a true real-time rendering pipeline, nor is it efficient. Rather, it's a proof-of-concept demonstration. The output is not a textured or shaded 3D model in the traditional sense. Instead, the generated 2D projection is visualized by drawing lines connecting the projected vertices, resulting in a wireframe representation of the 3D model. The wireframe is then drawn onto a HTML5 canvas element using JavaScript, with DuckDB providing the calculated 2D coordinates.

McSherry describes the process of importing the 3D model data into DuckDB and constructing the SQL queries necessary for the projection. He also addresses challenges encountered, including the lack of built-in trigonometric functions in the WASM version of DuckDB at the time, which necessitated a workaround involving pre-calculated sine and cosine tables. The author emphasizes the experimental and somewhat "hacky" nature of the project, acknowledging that it's not intended for practical 3D graphics applications. The post concludes with a reflection on the potential of exploring unconventional uses of database systems and the unexpected capabilities that can be unlocked through creative experimentation. The overall tone is one of playful exploration and a desire to push the boundaries of what’s possible with existing tools.

Summary of Comments ( 26 )
https://news.ycombinator.com/item?id=43761998

Hacker News users generally found the DuckDB-WASM 3D rendering hack clever and amusing. Several commenters praised the ingenuity and highlighted the unexpected versatility of DuckDB. Some expressed skepticism about practical applications, questioning performance and limitations compared to dedicated graphics libraries. A few users discussed potential optimizations, including leveraging SIMD and Web Workers. There was also a short thread discussing the broader implications of using databases for unconventional tasks, with some arguing it showcased the power of declarative programming. Finally, some commenters shared similar "hacks" they'd performed with SQL in the past, reinforcing the idea that SQL can be used in surprisingly flexible ways.

WebAssembly: How to Allocate Your Allocator

permalink

Posted: 2025-04-19 07:02:43

This blog post explores different strategies for memory allocation within WebAssembly modules, particularly focusing on the trade-offs between using the built-in malloc (provided by wasm-libc) and implementing a custom allocator. It highlights the performance overhead of wasm-libc's malloc due to its generality and thread safety features. The author presents a leaner, custom bump allocator as a more performant alternative for single-threaded scenarios, showcasing its implementation and integration with a linear memory. Finally, it discusses the option of delegating allocation to JavaScript and the potential complexities involved in managing memory across the WebAssembly/JavaScript boundary.

This blog post, titled "WebAssembly: How to Allocate Your Allocator," delves into the intricacies of memory management within the WebAssembly (Wasm) environment, specifically focusing on the challenge of bootstrapping a dynamic memory allocator. The author meticulously outlines the problem: Wasm modules, by design, initially lack access to a system allocator like malloc. Therefore, before any dynamic memory allocation can occur within a Wasm module, an allocator itself must be initialized and established. This presents a chicken-and-egg scenario: you need memory to set up the system that gives you memory.

The post then explores several strategies to overcome this initial hurdle. The first approach involves statically allocating a fixed-size block of memory within the Wasm module during compilation. This pre-allocated block serves as the initial heap, from which the dynamic allocator can then carve out smaller chunks of memory as needed. While simple, this method suffers from a significant limitation: the maximum allocatable memory is predetermined and cannot be expanded at runtime, restricting the application's flexibility.

A more sophisticated solution leverages Wasm's ability to import functions. By importing allocation and deallocation functions (e.g., malloc and free) from the host environment (like a JavaScript engine), the Wasm module gains access to a dynamic memory pool managed externally. This approach avoids the fixed-size limitation of the static allocation method and allows for more flexible memory management. However, it introduces a dependency on the host environment and may incur performance overhead due to the cross-environment function calls.

The post further elaborates on a hybrid approach, combining the benefits of both static and imported allocation. Initially, a small, statically allocated block is used to bootstrap a minimal allocator. This minimal allocator can then utilize the imported allocation functions to request larger chunks of memory from the host, effectively expanding the available heap dynamically as required. This strategy mitigates the limitations of purely static allocation while minimizing the initial reliance on external calls.

Finally, the author introduces a nuanced technique involving linear memory growth requests within Wasm. By incrementally requesting additional memory pages from the host, the Wasm module can organically expand its heap as needed. This approach provides fine-grained control over memory expansion and avoids the overhead of frequent calls to external allocation functions for small memory requests. The article then proceeds to explain the mechanism of using the memory.grow instruction within the Wasm module to interact with the host and request these expansions, thus providing a flexible and efficient way to manage dynamic memory allocation within the Wasm environment. The author provides concise C code examples to illustrate each of these techniques, offering practical guidance on implementing them in real-world Wasm modules.

Summary of Comments ( 1 )
https://news.ycombinator.com/item?id=43734751

Hacker News users discussed the implications of WebAssembly's lack of built-in allocator, focusing on the challenges and opportunities it presents. Several commenters highlighted the performance benefits of using a custom allocator tailored to the specific application, rather than relying on a general-purpose one. The discussion touched on various allocation strategies, including linear allocation, arena allocation, and using allocators from the host environment. Some users expressed concern about the added complexity for developers, while others saw it as a positive feature allowing for greater control and optimization. The possibility of standardizing certain allocator interfaces within WebAssembly was also brought up, though acknowledged as a complex undertaking. Some commenters shared their experiences with custom allocators in WebAssembly, mentioning reduced binary sizes and improved performance as key advantages.

The Hacker News post "WebAssembly: How to Allocate Your Allocator" sparked a discussion with several insightful comments revolving around memory management within WebAssembly.

One commenter highlighted the challenges of using C++ exceptions within WebAssembly, specifically noting the complexities of stack unwinding. They mentioned that simply catching exceptions at the top level isn't enough; one must also consider the implications of unwinding through WebAssembly code that may not have been compiled with exception support. This poses a problem when linking with system libraries, which might indeed throw exceptions.

Another commenter discussed the intricacies of WebAssembly's linear memory model and how it complicates memory management. They contrasted it with native code where addresses are virtual, allowing for more sophisticated memory handling techniques. Within WebAssembly's more restrictive environment, implementing features like virtual memory requires substantial manual effort. They also pointed out that while the blog post focuses on allocation, the deallocation aspects within WebAssembly pose their own unique set of challenges.

A subsequent comment delved deeper into the performance implications of different allocation strategies. The commenter questioned whether the "bump allocation" method discussed in the blog post is truly suitable for high-performance applications, suggesting that techniques involving free lists might be more efficient in long-running programs.

Further discussion centered around the specific challenges faced by different programming languages when targeting WebAssembly. Commenters mentioned languages like Zig and Rust, which offer more control over memory management, contrasting them with languages like C++ where the complexities of exception handling and name mangling can introduce further difficulties. The need for careful consideration when choosing a language for WebAssembly development was emphasized.

Finally, a commenter offered an interesting perspective on the security implications of memory management within WebAssembly. They suggested that the simplified, more constrained memory model of WebAssembly, while presenting challenges for developers, might actually contribute to improved security. The rationale being that the reduced complexity could potentially minimize the surface area for memory-related vulnerabilities.

JSLinux

permalink

Posted: 2025-04-14 06:27:48

JSLinux is a PC emulator written in JavaScript. It allows you to run a Linux distribution, or other operating systems like Windows 2000, entirely within a web browser. Fabrice Bellard, the creator, has implemented several different emulated architectures including x86, ARM, and RISC-V, showcasing the versatility of the project. The site provides several pre-built virtual machines to try, offering various Linux distributions with different desktop environments and even a minimal version of Windows 2000. It demonstrates a remarkable feat of engineering, bringing relatively complex operating systems to the web without the need for plugins or extensions.

Fabrice Bellard's "JSLinux" project showcases a remarkable feat of engineering: a fully functional x86-based PC emulator written entirely in JavaScript. This means that, leveraging the power of a web browser alone, users can experience a simulated computer system, complete with a Linux operating system, directly within their browser window. The emulator itself is incredibly versatile, supporting various Linux distributions including a buildroot-based minimal system, a version of Debian, and even a port of Arch Linux.

The core technology underpinning this emulator is a carefully crafted x86 CPU emulator, meticulously implemented in JavaScript. This allows the execution of compiled x86 machine code directly within the browser's JavaScript engine. Furthermore, the project features a PC hardware emulation layer, providing virtualized hardware components such as a hard disk, network card, and graphical display, all interacting seamlessly within the JavaScript environment.

The website provides several pre-configured virtual machine images, ready to be launched directly in the browser. These range from a barebones Linux system suitable for demonstrating the emulator's core capabilities to more complete distributions offering a familiar Linux desktop environment. Users can interact with these emulated systems as they would with a physical machine, using the provided virtual keyboard and mouse or optionally mapping them to their physical peripherals.

The performance of the emulator is surprisingly robust, given its execution within the constraints of a web browser. While not comparable to native hardware execution speeds, it's sufficient for basic tasks and highlights the efficiency of Bellard's implementation. The project demonstrates the potential of JavaScript as a platform for complex computations, pushing the boundaries of what's achievable within a browser environment. Moreover, the project is a testament to the power of emulation in providing accessible and readily available platforms for exploration and experimentation, removing the need for specialized hardware or software installations.

Summary of Comments ( 99 )
https://news.ycombinator.com/item?id=43678590

Hacker News users discuss Fabrice Bellard's JSLinux, mostly praising its technical brilliance. Several commenters express amazement at running Linux in a browser, highlighting its use of a compiled-to-JavaScript PC emulator. Some discuss potential applications, including education and preserving older software. A few point out limitations, like performance and the inability to access local filesystems easily, and some reminisce about similar projects like v86. The conversation also touches on the legality of distributing copyrighted BIOS images within such an emulator.

The Hacker News post titled "JSLinux" (https://news.ycombinator.com/item?id=43678590) has several comments discussing Fabrice Bellard's impressive work emulating a PC in JavaScript. Many commenters express awe and admiration for the technical achievement.

One recurring theme is the sheer ingenuity and difficulty of emulating a complex system like x86 in a browser environment. Several commenters point out the performance limitations inherent in JavaScript, making the project's speed even more remarkable. They discuss the various optimizations Bellard likely employed to achieve such performance, including techniques like Just-In-Time compilation (JIT) within the JavaScript engine. Some speculate on the specific strategies used to overcome performance bottlenecks, and the cleverness required to translate x86 instructions into something a browser can handle efficiently.

Another key discussion point centers around the practical implications of such technology. Some commenters envision potential applications in online education, allowing students to access and experiment with different operating systems without needing dedicated hardware. Others highlight the potential for preserving older software and making it accessible through a web browser. The ability to run legacy applications directly in the browser, without the need for emulation software or virtual machines, is seen as a significant advantage.

There's also a conversation around the security aspects of running an emulated system within a browser. Commenters acknowledge the potential risks involved and discuss the importance of sandboxing the emulated environment to prevent malicious code from escaping and affecting the host system. The inherent security model of web browsers and how it interacts with the emulated environment is a point of interest.

Several commenters share their own experiences with JSLinux and similar projects, discussing its utility and limitations. Some mention using it for specific tasks like testing websites on older browsers or experimenting with vintage software. Others recall encountering performance issues with more demanding applications, acknowledging the inherent limitations of browser-based emulation.

Finally, some comments delve into the historical context of Bellard's work, highlighting his other significant contributions to the open-source community, like FFmpeg and QEMU. His reputation as a highly skilled and innovative developer adds to the overall appreciation for the JSLinux project. Commenters express respect for his consistent ability to push the boundaries of what's possible with software.

Rust to C compiler – 95.9% test pass rate, odd platforms

permalink

Posted: 2025-04-12 04:21:15

The cg_clif project has made significant progress in compiling Rust to C, achieving a 95.9% pass rate on the Rust test suite. This compiler leverages Cranelift as a backend and utilizes a custom ABI for passing Rust data structures. Notably, it's now functional on more unusual platforms like wasm32-wasi and thumbv6m-none-eabi (for embedded ARM devices). While performance isn't a primary focus currently, basic functionality and compatibility are progressing rapidly, demonstrating the potential for compiling Rust to a portable C representation.

This blog post by Fractal Fir details the ongoing development of cg_clif (now clif-util), a tool designed to compile Rust code into C code. The author focuses on recent progress and challenges encountered while targeting "odd platforms"—specifically, WebAssembly (Wasm) and embedded systems like the AVR microcontroller family.

A significant milestone is reaching a 95.9% pass rate on the Rust compiler's extensive test suite when compiling to C and subsequently to Wasm. This achievement highlights the project's increasing maturity and ability to handle complex Rust constructs even when targeting non-traditional environments. The author attributes this success partly to the use of Cranelift, a code generation library that facilitates targeting diverse architectures.

However, the journey isn't without hurdles. The post explains that supporting inline assembly, a feature frequently used for low-level optimization and hardware interaction, presents significant difficulties. The disparity between the assembly syntax understood by the Rust compiler's LLVM backend and the syntax expected by the Wasm target requires intricate translation, a problem not yet fully solved. The author acknowledges this as a major area of ongoing work.

Furthermore, the post discusses the challenges in targeting the AVR microcontroller architecture. AVR, a popular choice for resource-constrained embedded systems, poses unique constraints due to its limited instruction set and memory capacity. The author describes working on implementing calling conventions compatible with AVR and tackling the intricacies of handling data types and memory management specific to this platform. While significant progress has been made, targeting AVR remains a work in progress, with complete support still on the horizon.

The overarching goal of cg_clif is to expand the reach of Rust code by enabling compilation to C, thereby unlocking the ability to target platforms not directly supported by the standard Rust compiler. The project leverages the Cranelift code generation library and the clif intermediate representation to achieve this cross-compilation. While challenges remain, particularly regarding inline assembly and support for resource-constrained environments like AVR, the project demonstrates promising progress towards enabling broader platform compatibility for Rust code. The author expresses optimism about future developments and invites contributions from the community.

Summary of Comments ( 164 )
https://news.ycombinator.com/item?id=43661329

Hacker News users discussed the impressive 95.9% test pass rate of the Rust-to-C compiler, particularly its ability to target unusual platforms like the Sega Saturn and Sony PlayStation. Some expressed skepticism about the practical applications, questioning the performance implications and debugging challenges of such a complex transpilation process. Others highlighted the potential benefits for code reuse and portability, enabling Rust code to run on legacy or resource-constrained systems. The project's novelty and ambition were generally praised, with several commenters expressing interest in the developer's approach and future developments. Some also debated the suitability of "compiler" versus "transpiler" to describe the project. There was also discussion around specific technical aspects, like memory management and the handling of Rust's borrow checker within the C output.

The Hacker News post titled "Rust to C compiler – 95.9% test pass rate, odd platforms" sparked a discussion with several interesting comments. Many commenters focused on the complexities and nuances of compiling Rust to C, particularly given Rust's unique memory management features.

One commenter highlighted the challenges inherent in translating Rust's borrow checker and ownership model into C, which lacks these built-in mechanisms. They questioned how the compiler handled these crucial aspects of Rust, expressing skepticism about achieving true compatibility without significant runtime overhead or limitations. This comment resonated with others who also expressed concern about the potential performance implications and the difficulty of replicating Rust's safety guarantees in C.

Another commenter pointed out the inherent difficulty in targeting "odd platforms," as mentioned in the title. They elaborated on the potential issues with varying C standard library implementations and the complexities of ensuring compatibility across diverse architectures and operating systems. This prompted a discussion about the trade-offs between portability and performance when attempting such a compilation process.

Several comments also touched on the potential use cases of such a compiler. Some suggested it could be valuable for embedded systems or environments where Rust isn't directly supported. Others questioned the practicality, arguing that if the target platform supports a C compiler, it might also be feasible to support a Rust compiler directly, potentially negating the need for a transpilation step.

The discussion also explored alternative approaches, such as compiling Rust to LLVM bitcode and then using LLVM to generate C code. This was presented as a potentially more robust approach that could leverage LLVM's optimizations and platform support.

Finally, some comments expressed interest in the specific platforms targeted by the project and requested more details about the remaining 4.1% of failing tests. They were curious about the nature of these failures and whether they represented fundamental limitations or solvable issues. Overall, the comments reflected a mixture of curiosity, skepticism, and cautious optimism about the potential of a Rust-to-C compiler.

SpacetimeDB

permalink

Posted: 2025-04-09 13:27:30

SpacetimeDB is a globally distributed, relational database designed for building massively multiplayer online (MMO) games and other real-time, collaborative applications. It leverages a deterministic state machine replicated across all connected clients, ensuring consistent data across all users. The database uses WebAssembly modules for stored procedures and application logic, providing a sandboxed and performant execution environment. Developers can interact with SpacetimeDB using familiar SQL queries and transactions, simplifying the development process. The platform aims to eliminate the need for separate databases, application servers, and networking solutions, streamlining backend infrastructure for real-time applications.

SpacetimeDB, according to its website, presents itself as a globally distributed, relational database designed for building massively multiplayer online (MMO) games and other real-time, interactive applications. It distinguishes itself by tightly integrating a WebAssembly (Wasm) runtime within the database itself. This unique architecture allows developers to write application logic in languages that compile to Wasm, like Rust, and execute that logic directly within the database, close to the data. This, they claim, minimizes latency and simplifies development by eliminating the need for separate application servers and complex client-server communication patterns.

The platform boasts strong consistency and ACID properties, guaranteeing data integrity even in a distributed environment. Transactions are serialized globally, ensuring all connected clients see a consistent view of the data. This predictable behavior is crucial for applications requiring real-time synchronization, like online games.

SpacetimeDB emphasizes scalability and fault tolerance. The distributed nature of the database allows it to handle a large number of concurrent users and provides resilience against individual node failures. The system automatically manages data replication and distribution across its network.

Security is also a highlighted feature. Data is encrypted both in transit and at rest, providing protection against unauthorized access. Furthermore, the Wasm sandbox environment within the database isolates user-defined logic, mitigating potential security risks arising from malicious or buggy code.

Developers interact with SpacetimeDB using a client library and the spacetime command-line interface (CLI) tool. The CLI facilitates schema management, data manipulation, and deployment of Wasm modules. The client libraries provide convenient APIs for integrating SpacetimeDB into applications written in various languages.

The website promotes several key benefits of using SpacetimeDB, including simplified development due to the integrated Wasm runtime, reduced operational overhead due to the managed infrastructure, improved performance through minimized latency, and enhanced security through encryption and sandboxing. The platform aims to provide a comprehensive solution for developers looking to build scalable, secure, and real-time interactive applications, particularly in the gaming space. They offer a free tier for developers to explore and experiment with the technology.

Summary of Comments ( 4 )
https://news.ycombinator.com/item?id=43631822

Hacker News users discussed SpacetimeDB, a globally distributed, relational database with strong consistency and built-in WebAssembly smart contracts. Several commenters expressed excitement about the project, praising its novel approach and potential for various applications, particularly gaming. Some questioned the practicality of strong consistency in a distributed database and raised concerns about performance, scalability, and the complexity introduced by WebAssembly. Others were skeptical of the claimed ease of use and the maturity of the technology, emphasizing the difficulty of achieving genuine strong consistency. There was a discussion around the choice of WebAssembly, with some suggesting alternatives like Lua. A few commenters requested clarification on specific technical aspects, like data modeling and conflict resolution, and how SpacetimeDB compares to existing solutions. Overall, the comments reflected a mixture of intrigue and cautious optimism, with many acknowledging the ambitious nature of the project.

The Hacker News post titled "SpacetimeDB" generated several comments discussing the distributed database solution offered by SpacetimeDB. Many of the comments focus on the project's use of WebAssembly (Wasm) and its potential benefits and drawbacks.

One commenter expressed skepticism about the practicality of using Wasm for database logic, questioning whether the performance benefits outweigh the limitations. They specifically raised concerns about the I/O performance within a Wasm environment and the potential difficulties in managing complex database operations within such a constrained runtime.

Another commenter brought up the comparison to FoundationDB, a well-established distributed database, and inquired about how SpacetimeDB differentiates itself and addresses similar challenges related to fault tolerance and scalability. This prompted a response from a user claiming to be associated with SpacetimeDB, who highlighted features such as built-in networking and permissioning as key differentiators. They also clarified that SpacetimeDB utilizes a "multi-region active-active setup," suggesting a focus on high availability and data consistency across geographically distributed locations.

Further discussion revolved around the choice of programming language for Wasm modules within SpacetimeDB. Commenters discussed the merits of using Rust, given its focus on safety and performance, and touched on the potential for using other languages like JavaScript or TypeScript.

The implications of storing data in a centralized manner, as seemingly implied by SpacetimeDB's architecture, were also debated. Concerns were raised about data ownership, control, and the potential for vendor lock-in. A commenter countered this by highlighting the possibility of running a SpacetimeDB cluster independently, which would alleviate some of these concerns.

Security aspects of SpacetimeDB also garnered attention, with commenters inquiring about the robustness of the system against malicious code execution within the Wasm environment.

Finally, the feasibility of using SpacetimeDB for specific use cases like game development was discussed, with some commenters expressing enthusiasm for its potential in real-time, multiplayer game scenarios. This sparked further debate about the suitability of the database for handling rapidly changing game state data.

Overall, the comments on the Hacker News post reflect a mix of curiosity, skepticism, and cautious optimism regarding SpacetimeDB. The discussion centers primarily on the technical implications of using Wasm for database operations, the potential benefits and drawbacks of the proposed architecture, and the suitability of SpacetimeDB for various application domains.

Show HN: I built a Rust crate for running unsafe code safely

permalink

Posted: 2025-04-06 13:28:48

mem-isolate is a Rust crate designed to execute potentially unsafe code within isolated memory compartments. It leverages Linux's memfd_create system call to create anonymous memory mappings, allowing developers to run untrusted code within these confined regions, limiting the potential damage from vulnerabilities or exploits. This sandboxing approach helps mitigate security risks by restricting access to the main process's memory, effectively preventing malicious code from affecting the wider system. The crate offers a simple API for setting up and managing these isolated execution environments, providing a more secure way to interact with external or potentially compromised code.

The Hacker News post titled "Show HN: I built a Rust crate for running unsafe code safely" introduces mem-isolate, a new Rust library designed to mitigate the risks associated with executing potentially unsafe code. The core concept behind mem-isolate is compartmentalization. It achieves this by leveraging Rust's ownership system and memory safety guarantees to create isolated memory regions, effectively sandboxing the execution of untrusted or volatile code.

This sandboxing prevents potential memory corruption or other undefined behavior from affecting the primary application. If the isolated code attempts an illegal memory access or performs another unsafe operation that would typically lead to a crash or vulnerability, the effects are confined within the isolated memory region. The main application remains unaffected, enhancing overall system stability and security.

The crate provides a mechanism to execute a given function within this confined environment. It works by forking the current process and establishing the isolated memory space within the child process. The target function then runs solely within this isolated child process. Any memory violations or crashes are isolated to the child process, preventing them from propagating to the parent and compromising the main application. The parent process can then continue operating normally.

The developer highlights that while mem-isolate focuses on memory safety, it doesn't address all potential security concerns. For example, it doesn't inherently protect against issues like infinite loops or excessive resource consumption within the isolated code. These aspects would require additional monitoring and control mechanisms.

Essentially, mem-isolate offers a way to run potentially dangerous code within a controlled environment, significantly reducing the risks associated with executing untrusted code within a Rust application, particularly focusing on preventing memory-related vulnerabilities from impacting the core application's integrity.

Summary of Comments ( 5 )
https://news.ycombinator.com/item?id=43601301

Hacker News users discussed the practicality and security implications of the mem-isolate crate. Several commenters expressed skepticism about its ability to truly isolate unsafe code, particularly in complex scenarios involving system calls and shared resources. Concerns were raised about the performance overhead and the potential for subtle bugs in the isolation mechanism itself. The discussion also touched on the challenges of securely managing memory in Rust and the trade-offs between safety and performance. Some users suggested alternative approaches, such as using WebAssembly or language-level sandboxing. Overall, the comments reflected a cautious optimism about the project but acknowledged the difficulty of achieving complete isolation in a practical and efficient manner.

The Hacker News post "Show HN: I built a Rust crate for running unsafe code safely" (linking to the mem-isolate crate) generated a moderate amount of discussion, mostly focused on the complexities and nuances of memory safety in Rust, and whether the crate truly offers a "safe" solution for running unsafe code.

Several commenters express skepticism about the claim of "safely" running unsafe code. One points out the inherent contradiction, suggesting the term is an oxymoron. Another argues that true safety requires formal verification, and anything short of that is merely reducing the attack surface rather than eliminating it. This sentiment is echoed by another commenter who highlights the difficulty in proving the soundness of the approach and the potential for subtle bugs to undermine the isolation.

A few comments delve into the specifics of mem-isolate's implementation. One user questions its practicality for real-world scenarios, suggesting that the overhead of serialization and deserialization, coupled with the limitations on system call access, could severely limit its usefulness. They also mention the potential performance impact and the challenge of managing data dependencies between isolated processes.

The discussion also touches upon alternative approaches to isolating unsafe code, such as WebAssembly. One commenter mentions Wasmtime as a more mature and robust solution, although they acknowledge that Wasmtime might not be suitable for all use cases. Another suggests using language-level sandboxing features provided by some languages.

Some users discuss the trade-offs between security and performance. One commenter notes that while complete memory safety is desirable, it often comes at a cost to performance. They suggest that in certain situations, a calculated risk with less strict isolation might be acceptable if performance is a critical factor.

Finally, a few comments express general interest in the project and commend the author for tackling a challenging problem. They acknowledge the difficulty of achieving true memory safety in systems programming and appreciate the effort to improve the security of Rust code. However, even these positive comments maintain a cautious tone, reflecting the overall skepticism towards the claim of absolute safety.

My Browser WASM't Prepared for This. Using DuckDB, Apache Arrow and Web Workers

permalink

Posted: 2025-04-06 07:31:27

This blog post details the author's experience building a fast, in-browser analytics tool using DuckDB compiled to WebAssembly (Wasm), Apache Arrow for data transfer, and web workers for parallel processing. The post highlights the performance benefits of this combination, allowing for efficient querying of large datasets directly within the browser without server-side processing. By leveraging DuckDB's analytical capabilities within the browser, the application provides a responsive and interactive user experience for data exploration. The author also discusses the challenges encountered and solutions implemented, such as handling large data transfers between the main thread and the web worker using Arrow, ultimately achieving significant performance gains compared to traditional JavaScript-based solutions.

This Medium post, titled "My Browser WASM't Prepared for This. Using DuckDB, Apache Arrow, and Web Workers in Real Life," explores the author's journey of leveraging powerful data processing tools directly within a web browser environment to analyze substantial datasets, specifically focusing on Major League Baseball (MLB) statistics. The author sets the stage by highlighting the increasing demand for complex data analysis within web applications and the limitations of traditional client-side JavaScript solutions for handling larger datasets. This leads to the introduction of WebAssembly (Wasm), a technology that allows for the compilation of performance-intensive codebases, written in languages like C++, to run efficiently within browsers.

The core of the post revolves around the integration of three key technologies: DuckDB, Apache Arrow, and Web Workers. DuckDB, an in-process analytical database management system, is lauded for its speed and efficiency, especially when dealing with analytical queries on columnar data. The author emphasizes DuckDB's Wasm compatibility, allowing it to be utilized directly within the browser, bringing the power of a relational database to the client-side.

Apache Arrow, a columnar memory format, serves as the bridge for seamless data transfer between different systems and languages. Its inclusion in this workflow is crucial for efficiently moving data between JavaScript and DuckDB within the browser environment. The author highlights how Arrow's zero-copy data sharing capabilities minimize overhead and maximize performance, particularly beneficial when dealing with large datasets.

To prevent blocking the main browser thread and maintain a responsive user interface during these intensive data processing operations, the author introduces the use of Web Workers. Web Workers enable the execution of JavaScript code in background threads, allowing the main thread to remain free for handling user interactions. By offloading the DuckDB operations and data processing to a Web Worker, the application can analyze large datasets without impacting the user experience.

The post details the practical implementation of this architecture, showcasing code snippets and explanations of how to configure DuckDB within a Web Worker, establish communication between the main thread and the worker, and utilize Arrow for data transfer. The MLB statistics dataset serves as a real-world example to demonstrate the performance and capabilities of this approach. The author walks through querying the data using SQL within the browser and visualizing the results, highlighting the advantages of bringing such powerful analytical tools directly to the client-side.

Finally, the post concludes by summarizing the benefits of this approach, emphasizing the enhanced performance, improved user experience through responsive interfaces, and the potential for empowering web applications with more complex data analysis capabilities. The author suggests that this combination of technologies represents a significant step forward in enabling data-intensive applications within the browser, opening up new possibilities for interactive data exploration and analysis.

Summary of Comments ( 14 )
https://news.ycombinator.com/item?id=43599613

HN commenters generally praised the approach of using DuckDB, Arrow, and web workers for in-browser analytics. Several highlighted the potential of this combination for powerful client-side data processing and visualization, particularly for large datasets. Some pointed out that this method shifts the burden of computation to the client, potentially saving server costs and improving privacy. A few commenters offered alternative solutions or discussed the limitations of the current implementation, including browser compatibility and memory management. The performance benefits and ease of use compared to JavaScript solutions were recurring themes, with one commenter specifically mentioning its usefulness for interactive dashboards.

The Hacker News post titled "My Browser WASM't Prepared for This. Using DuckDB, Apache Arrow and Web Workers" has generated several comments discussing the use of DuckDB in the browser through WebAssembly (Wasm).

Several commenters express enthusiasm for the potential of DuckDB in the browser, enabling complex data analysis without server-side processing. One commenter highlights the significance of being able to use familiar SQL syntax within the browser environment, removing the need for specialized JavaScript libraries for data manipulation. They further emphasize the potential for performance improvements by leveraging multi-threading via Web Workers.

Another commenter raises the point of data security and privacy, noting that processing sensitive data client-side offers advantages in certain scenarios where uploading data to a server isn't feasible or desirable. This comment sparks a brief discussion about the nuances of security, with others acknowledging the benefits while cautioning about the importance of proper client-side security measures.

The performance of DuckDB compiled to Wasm is a recurring theme. Some users share their experiences with performance bottlenecks, particularly with larger datasets. A commenter suggests that the current implementation might be limited by the browser's garbage collection, potentially affecting performance in certain cases. This leads to speculation about future optimizations and improvements in Wasm and browser technologies that could address these limitations.

One comment thread delves into the technical details of how DuckDB utilizes Apache Arrow for data interchange within the browser. Commenters discuss the advantages of Arrow's columnar format for efficient data processing and the role it plays in bridging the gap between DuckDB and JavaScript.

Finally, some comments touch upon the broader implications of this technology, envisioning applications such as interactive data exploration tools, offline data analysis capabilities, and improved performance for web applications dealing with large datasets. One commenter even speculates on the potential for "serverless" analytics, where complex data processing happens entirely within the user's browser.

A Vision for WebAssembly Support in Swift

permalink

Posted: 2025-04-05 13:58:18

This post outlines a vision for first-class WebAssembly support in Swift, enabling developers to compile Swift code directly to Wasm for use in web browsers and other Wasm environments. The proposal emphasizes seamless integration with existing JavaScript ecosystems, allowing bidirectional communication between Swift and JavaScript code. It also aims for near-native performance by leveraging Wasm's capabilities, and proposes tools and workflows to simplify the development process, such as automatic generation of JavaScript bindings for Swift code. The ultimate goal is to empower Swift developers to build high-performance web applications and leverage the growing Wasm ecosystem, while maintaining Swift's core values of safety, performance, and expressiveness.

This forum post outlines a comprehensive vision for integrating WebAssembly (Wasm) support into the Swift programming language, aiming to enable Swift developers to target the web and other Wasm-compatible environments seamlessly. The author emphasizes that this integration should prioritize ergonomics, performance, and interoperability, ensuring a smooth and efficient developer experience.

The proposal suggests a two-pronged approach: "Swift-in-Wasm" and "Wasm-in-Swift." Swift-in-Wasm focuses on compiling Swift code directly into WebAssembly, allowing developers to write web applications and other Wasm-targeted software using familiar Swift syntax and libraries. This approach entails significant modifications to the Swift compiler and runtime to support the Wasm target. Key aspects include efficient memory management within the Wasm environment, handling Swift's runtime features like automatic reference counting (ARC), and ensuring compatibility with JavaScript and the Web API through well-defined interoperability mechanisms. Performance is a crucial consideration, and the proposal emphasizes generating optimized Wasm code that leverages the capabilities of modern web browsers and other Wasm runtimes.

Conversely, Wasm-in-Swift aims to enable the embedding and execution of pre-existing Wasm modules within Swift applications. This functionality would allow developers to leverage existing Wasm libraries and components within their Swift projects, expanding the ecosystem available to them. This aspect involves designing robust APIs within Swift to load, interact with, and manage Wasm modules. It also requires addressing issues such as type mapping between Swift and Wasm types, and ensuring safe and efficient communication between the Swift and Wasm environments.

The long-term vision described in the post envisions Swift becoming a first-class language for Wasm development, empowering developers to build high-performance web applications, serverless functions, and other Wasm-based software. The proposal also highlights the potential for leveraging Wasm to distribute Swift code to various platforms beyond the web, extending the reach and applicability of the language. The author anticipates that this integration will benefit both the Swift and Wasm communities, fostering collaboration and growth in both ecosystems. Finally, the post acknowledges that realizing this vision requires significant effort and invites community feedback and contributions to shape the future of Wasm support in Swift.

Summary of Comments ( 97 )
https://news.ycombinator.com/item?id=43593596

Hacker News users discussed the potential and challenges of Swift for WebAssembly. Some expressed excitement about the prospect of using Swift for frontend development, highlighting its performance and type safety as advantages over JavaScript. Others were more cautious, pointing to the existing maturity of JavaScript and its ecosystem, and questioning whether Swift could gain significant traction. Concerns were raised about the size of Swift compiled output and the integration with existing JavaScript libraries and frameworks. The potential for full-stack Swift development and server-side applications with WebAssembly was also mentioned as a motivating factor. Several users suggested that prioritizing the developer experience and tooling would be crucial for adoption.

The Hacker News post "A Vision for WebAssembly Support in Swift," linking to a Swift forums discussion about bringing WebAssembly support to the Swift programming language, generated a moderate amount of discussion. Several commenters expressed enthusiasm and interest in the possibilities.

A significant thread focused on the potential benefits and drawbacks compared to existing solutions like JavaScript and TypeScript. One commenter questioned whether Swift offered enough advantages over TypeScript to justify the effort, pointing out that TypeScript already enjoys wide adoption and robust tooling for web development. Counterarguments highlighted Swift's performance potential, strong typing, and modern language features as reasons why it could be a compelling alternative. This back-and-forth explored the trade-offs between a potentially faster, more robust language like Swift and the established ecosystem of JavaScript/TypeScript.

Several commenters discussed the potential impact of WebAssembly support on Swift's overall adoption. Some speculated that it could broaden Swift's reach significantly, allowing it to break free from its primary association with Apple platforms and become a more general-purpose language. Others expressed skepticism, suggesting that the web development landscape is already crowded and that Swift might struggle to gain traction against established players.

Another recurring theme was the practical considerations of implementing WebAssembly support in Swift. Commenters discussed the challenges of garbage collection and interoperability with existing JavaScript code. The intricacies of efficiently bridging Swift's runtime environment with the browser's WebAssembly implementation were also touched upon.

Some commenters brought up specific use cases where Swift in the browser could be particularly advantageous, including computationally intensive tasks and porting existing Swift code to the web. The potential for improved performance in web applications was a recurring point of interest.

While there was general excitement about the prospect, many comments acknowledged the significant work involved and the need for careful consideration of the technical challenges. The overall sentiment leaned towards cautious optimism, with commenters expressing interest in seeing how the project evolves and whether it can deliver on its potential.

Show HN: Transputer emulator in JavaScript (fast enough to be useful)

permalink

Posted: 2025-04-04 03:59:44

A JavaScript-based Transputer emulator has been developed and is performant enough for practical use. It emulates a T425 Transputer, including its 32-bit processor, on-chip RAM, and link interfaces for connecting multiple virtual Transputers. The emulator aims for accuracy and speed, leveraging WebAssembly and other optimizations. While still under development, it can already run various programs, offering a readily accessible way to explore and experiment with this parallel computing architecture within a web browser. The project's website provides interactive demos and source code.

This Hacker News post introduces a newly developed emulator for the Transputer, a pioneering parallel processing architecture from the late 1980s, implemented entirely in JavaScript. The author emphasizes that the emulator's performance is sufficiently high to be practically useful, a notable achievement given the complexities of emulating a parallel architecture within a single-threaded environment like a web browser.

The emulator, showcased on a dedicated webpage, allows users to experience and experiment with Transputer code directly within their browsers. The post highlights the inclusion of several demonstration programs, including a Mandelbrot set fractal generator, illustrating the emulator's capability to handle computationally intensive tasks. The author provides background information on the Transputer architecture, emphasizing its innovative use of on-chip communication channels for inter-process communication, a feature central to its parallel processing capabilities. This core concept of channel communication is faithfully replicated within the JavaScript emulator.

The implementation utilizes a technique of compiling the Transputer's Occam programming language, specifically a subset targeting the IMS T800 model, into WebAssembly. This compilation process facilitates the emulator's speed and efficiency by leveraging the performance benefits of WebAssembly. The post details the process of generating the necessary WebAssembly code from Occam source code, including using a custom toolchain involving the Kent Retargetable Occam Compiler (KROC) and the LLVM compiler infrastructure. It also mentions the integration of a rudimentary filing system, crucial for loading programs and data into the emulated environment.

The author expresses enthusiasm for the potential of this project to revive interest in the Transputer architecture and its unique approach to parallel computing, making it accessible to a wider audience through the ubiquity of web browsers. They also invite exploration and feedback from the community, suggesting possibilities for future development and improvements. The provided demonstration programs, particularly the Mandelbrot example, serve as a tangible demonstration of the emulator's capabilities and a starting point for users to explore the world of Transputer programming.

Summary of Comments ( 2 )
https://news.ycombinator.com/item?id=43578190

Hacker News users discussed the surprising speed and cleverness of a JavaScript-based Transputer emulator. Several praised the author's ingenuity in optimizing the emulator, making it performant enough for practical uses like running old Transputer demos. Some commenters reminisced about their past experiences with Transputers, highlighting their unique architecture and the challenges of parallel programming. Others expressed interest in exploring the emulator further, with suggestions for potential applications like running old games or educational purposes. A few users discussed the technical aspects of the emulator, including the use of Web Workers and the limitations of JavaScript for emulating parallel architectures. The overall sentiment was positive, with many impressed by the project's technical achievement and nostalgic value.

The Hacker News post titled "Show HN: Transputer emulator in JavaScript (fast enough to be useful)" linking to a Transputer emulator written in JavaScript generated several comments discussing various aspects of the emulator and Transputers in general.

Several commenters expressed fascination with Transputers and their unique architecture, reminiscing about their past experiences with the technology. One commenter recalled using Transputers for parallel processing in university and praised their elegant design. Another highlighted the innovative nature of the Transputer's inter-process communication channels. The general sentiment was one of nostalgia and appreciation for the Transputer's historical significance in parallel computing.

Performance was a key topic of discussion. Some users questioned the "fast enough to be useful" claim in the title, prompting the original poster (OP) to clarify that the emulator achieves about 1/10th the speed of a real Transputer. While not as fast as native hardware, this speed was deemed sufficient for certain tasks, such as running old demos and exploring Transputer programming. The OP further explained that the emulator's performance is bottlenecked by JavaScript's garbage collection, particularly when dealing with the emulated memory operations.

The choice of JavaScript for the emulator was also discussed. While acknowledging the performance limitations, the OP explained that JavaScript's accessibility and ease of sharing through a web browser made it a suitable choice for this project. This allowed for wider reach and easier experimentation for those interested in Transputers without requiring complex setup or specialized hardware.

Several commenters expressed interest in the potential applications of the emulator, including educational purposes and preserving historical software. One user suggested exploring WebAssembly as a potential avenue for performance improvement. Others discussed the possibility of integrating the emulator with existing Transputer development tools.

There was also discussion about the differences between emulation and simulation. One commenter pointed out that the project is an emulator, mimicking the hardware, rather than a simulator, which would model the behavior at a higher level.

Finally, some commenters shared links to related projects and resources, including other Transputer emulators and archival material. This contributed to a broader discussion about retrocomputing and the preservation of older technologies.

Java Minecraft in the Browser

permalink

Posted: 2025-03-31 14:56:35

BrowserCraft allows you to play a near-complete version of Minecraft Classic (specifically version 0.0.23a_01) directly in your web browser, thanks to the CheerpJ Java to JavaScript/WebAssembly compiler. It requires no installation or plugins, boasting full multiplayer support and even the ability to connect to existing Java Minecraft Classic servers. While aiming for feature parity with the original client, some differences exist, notably enhanced performance in certain areas and potential discrepancies in rendering. The project is open-source and actively being developed, welcoming community contributions.

This blog post details a remarkable feat of software engineering: running a modified version of Minecraft, the popular voxel-based sandbox game, entirely within a web browser, without requiring any client-side installations or plugins. The project, dubbed "Browsercraft," leverages the CheerpJ Java to JavaScript/WebAssembly compiler to achieve this. Originally, Minecraft was written in Java, a language not natively supported by web browsers. CheerpJ overcomes this limitation by converting the Java bytecode of the Minecraft client into a format executable by browsers, specifically JavaScript and, for enhanced performance, WebAssembly.

The post explains that Browsercraft is not simply a proof of concept but a functional, albeit modified, version of Minecraft Classic. Players can join multiplayer servers and experience core gameplay elements, including block breaking, placement, and basic crafting. It emphasizes that the entire game logic, originally implemented in Java, is now executing within the browser environment thanks to the CheerpJ conversion process.

The author delves into some of the technical challenges encountered and solutions implemented during the project. A key challenge was handling Minecraft's reliance on native libraries, code specifically designed for the operating system Minecraft typically runs on. The solution involved utilizing a custom implementation of the LWJGL (Lightweight Java Game Library) rewritten specifically to be compatible with CheerpJ and the browser environment. This custom LWJGL implementation provides the necessary abstractions for graphics rendering, audio output, and input handling within the browser context.

Furthermore, the post highlights the performance improvements observed when leveraging WebAssembly as the compilation target for CheerpJ. WebAssembly, a binary instruction format designed for web browsers, offers significant performance gains compared to JavaScript, resulting in a smoother and more responsive gameplay experience within Browsercraft.

Finally, the author concludes by showcasing the potential of CheerpJ and WebAssembly to enable the execution of complex Java applications, like Minecraft Classic, entirely within web browsers, opening up new possibilities for accessibility and distribution of Java-based software. The post provides a link to a live demonstration of Browsercraft, allowing readers to experience the project firsthand.

Summary of Comments ( 9 )
https://news.ycombinator.com/item?id=43535769

HN commenters express excitement and curiosity about the technical implementation of a Java Minecraft clone running in the browser. Several discuss the clever use of CheerpJ, a Java-to-WebAssembly compiler, noting its surprisingly good performance and suitability for CPU-bound tasks like Minecraft's game logic. Some commenters raise concerns about performance bottlenecks, particularly related to rendering and garbage collection, while others offer potential optimizations. The project's open-source nature and availability on GitHub are praised, with some expressing interest in contributing. A few commenters reminisce about similar projects in the past, comparing their performance and approaches. The overall sentiment is positive, with the project viewed as an impressive technical feat and a promising demonstration of WebAssembly's capabilities.

The Hacker News post titled "Java Minecraft in the Browser" (linking to https://browsercraft.cheerpj.com/) generated a moderate amount of discussion, with several commenters expressing interest and sharing their perspectives.

A recurring theme is the impressive technical feat of running Minecraft, a Java application, within a web browser. Several comments highlight the use of CheerpJ, a Java to WebAssembly/JavaScript compiler, as the key enabling technology. Commenters marvel at how far web technology has come, allowing for such complex applications to run smoothly within the browser environment. Some express surprise and even disbelief, prompting further explanations from others familiar with CheerpJ and similar technologies.

Some commenters discuss the performance of Browsercraft, with general agreement that it runs surprisingly well given the circumstances. While acknowledging it's not perfect, the consensus seems to be that the performance is impressive for a Java application running within a browser. One commenter even reports a positive experience playing on a low-powered Chromebook.

A few comments delve into the technical details of CheerpJ and how it achieves this. One user mentions the ability of CheerpJ to provide access to the underlying operating system through a virtualized DOM, which allows the Java application to interact with browser APIs. Another commenter clarifies that while CheerpJ doesn't interpret Java bytecode directly, it effectively re-implements the Java runtime environment using WebAssembly, enabling execution within the browser.

The discussion also touches on the potential implications of this technology. Some commenters speculate about the possibility of running other Java applications, or even entire operating systems, within the browser. Others discuss the benefits of using Java for game development, such as portability, while acknowledging its performance limitations compared to native code.

Several commenters express concerns related to security and the potential for abuse of this technology. They raise the possibility of malicious actors using this to distribute malware disguised as seemingly harmless Java applications running within the browser.

Finally, some comments simply share amusement or express general enthusiasm for the project, often expressing nostalgia for Minecraft. One commenter jokingly requests a version of RuneScape running in the browser.

Overall, the comments reflect a positive reception to the project, with many expressing amazement at the technical achievement and speculating on the potential future applications of such technology, while also acknowledging potential downsides like security risks.

Retro Boy: simple Game Boy emulator written in Rust, can be played on the web

permalink

Posted: 2025-03-20 21:54:17

Retro Boy is a simple Game Boy emulator written in Rust and compiled to WebAssembly, allowing it to run directly in a web browser. It features a basic but functional graphical user interface and supports sound, offering a playable experience for a selection of ROMs. While not aiming for perfect accuracy or advanced features, it focuses on clean code and serves as a learning project showcasing Rust and WebAssembly for emulation.

Summary of Comments ( 79 )
https://news.ycombinator.com/item?id=43429417

Hacker News users generally praised the Retro Boy emulator for its clean Rust implementation and WebAssembly deployment. Several commenters appreciated the project's simplicity and educational value, seeing it as a good starting point for learning emulator development or Rust. Some discussed performance aspects of WebAssembly and the challenges of accurate emulation. A few users compared it favorably to other Game Boy emulators and highlighted the benefits of Rust's safety features for this type of project. Others pointed out the clever use of a single match statement in the CPU emulation code. The developer's engagement in the comments, answering questions and acknowledging feedback, was also positively received.

The Hacker News post about Retro Boy, a simple Game Boy emulator written in Rust, has generated a moderate amount of discussion, with a number of commenters expressing interest and sharing their perspectives on the project and emulation in general.

Several commenters discuss the choice of Rust for emulator development. One notes that Rust's safety features make it well-suited for this kind of project, where memory management and precise bit manipulation are crucial. They highlight how these features help prevent common emulation bugs and crashes. Another commenter concurs, adding that Rust's performance characteristics are also beneficial for achieving good emulation speed.

The WebAssembly (Wasm) aspect of the project also garnered attention. A commenter expresses enthusiasm for Wasm's ability to bring emulators and other computationally intensive applications to the web browser. They discuss the potential for increased accessibility and the convenience of not requiring users to download and install separate applications. Another user chimed in mentioning they appreciate the project being written in Rust and compiled to Wasm, highlighting the performance benefits of such an approach and how it allows users to simply open a URL and instantly play games.

A few commenters delve into the technical details of Game Boy emulation. One commenter discusses the complexities of accurately emulating the Game Boy's hardware quirks, including its timing and memory access patterns. They express appreciation for the project's simplicity, suggesting it could serve as a good learning resource for aspiring emulator developers. Another commenter inquires about the emulator's accuracy, asking about its compatibility with various Game Boy games and any known limitations.

Some commenters share their own experiences with emulation and retro gaming, reminiscing about playing classic Game Boy titles. One recounts fond memories of playing specific games, triggering nostalgic discussions among other users.

Finally, there are a few comments offering suggestions and feedback for the project. One commenter suggests adding support for save states, a feature that would allow users to save and resume their game progress. Another suggests adding support for different Game Boy color palettes.

Overall, the comments section reflects a positive reception for the Retro Boy project, praising its use of Rust, its WebAssembly implementation, and its potential as both a functional emulator and a learning tool. The comments also showcase the enduring appeal of retro gaming and the community's interest in preserving and experiencing classic games through emulation.

Checkers written in Rust and exported to WASM

permalink

Posted: 2025-03-14 17:17:50

This blog post details the author's process of creating a Checkers game using Rust and compiling it to WebAssembly (WASM) for play in a web browser. The author highlights the benefits of using Rust, such as performance and memory safety, and the relative ease of targeting WASM. They describe key implementation aspects, including game logic, board representation, and user interface interaction using the Yew framework. The post also covers setting up the Rust and WASM build environment, and optimizing the WASM module size for faster loading. The final result is a playable checkers game embedded directly in the webpage, demonstrating the practicality of Rust and WASM for web development.

Summary of Comments ( 30 )
https://news.ycombinator.com/item?id=43364776

HN commenters generally praised the clean and performant implementation of Checkers in Rust and WASM. Several lauded the clear code and the educational value of the project, finding it a good example of Rust and WASM usage. Some discussed performance considerations, including the choice of using a 1D array for the board representation, suggesting a 2D array might offer better readability despite potentially slightly reduced performance. A few comments touched on potential enhancements, like adding an AI opponent or allowing undo/redo functionality. There was also minor discussion around alternative approaches to game development with Rust/WASM and other languages.

The Hacker News post titled "Checkers written in Rust and exported to WASM" (https://news.ycombinator.com/item?id=43364776) has a moderate number of comments discussing various aspects of the project and related technologies.

Several commenters praise the clean and simple implementation of the game, appreciating the author's focus on a straightforward approach rather than over-engineering. One user specifically highlights the value of this as a learning resource for those interested in Rust and WASM, noting it's more accessible than more complex examples.

A significant portion of the discussion revolves around the choice of Rust and WASM. Some users express enthusiasm for Rust's performance characteristics and memory safety features, seeing them as ideal for web-based game development. Others discuss the benefits of WASM for portability and performance. One commenter points out that WASM's ability to be run in various environments makes it a good choice for projects like this.

The use of the Yew framework is also a topic of conversation. Commenters familiar with Yew express their positive experiences with it. One user mentions its similarity to React, making it easier to learn for those coming from a JavaScript background.

Performance is touched on in several comments. One commenter questions the necessity of WASM for a simple game like checkers, suggesting that JavaScript might be sufficient. Another counters this, arguing that WASM offers performance advantages even for simpler games, particularly in scenarios with more complex logic or AI. There's also some discussion around the size of the WASM binary and potential optimizations.

Beyond the technical aspects, some comments focus on the user experience. One commenter suggests improvements to the UI, such as highlighting possible moves. Another appreciates the minimalist design.

In summary, the comments generally express positive sentiment towards the project, praising its simplicity, the technology choices, and its potential as a learning resource. The discussion covers various technical details related to Rust, WASM, and Yew, as well as aspects of performance and user experience.

Show HN: In-Browser Graph RAG with Kuzu-WASM and WebLLM

permalink

Posted: 2025-03-10 15:12:57

This blog post demonstrates a Retrieval Augmented Generation (RAG) pipeline running entirely within a web browser. It uses Kuzu-WASM, a WebAssembly build of the Kuzu graph database, to store and query a knowledge graph, and WebLLM, a library for running large language models (LLMs) client-side. The demo allows users to query the graph using natural language, with Kuzu translating the query into its native query language and retrieving relevant information. This retrieved context is then fed to a local LLM (currently, a quantized version of Flan-T5), which generates a natural language response. This in-browser approach offers potential benefits in terms of privacy, reduced latency, and offline functionality, enabling new possibilities for interactive and personalized AI applications.

This blog post introduces a novel approach to implementing Retrieval Augmented Generation (RAG) entirely within a web browser, leveraging the power of Kuzu-WASM, a WebAssembly port of the Kuzu graph database, and WebLLM, a library for running large language models (LLMs) client-side. The post demonstrates how these technologies can be combined to create a powerful and privacy-preserving question-answering system that operates without server-side components.

The core concept revolves around using Kuzu-WASM to store and query a knowledge graph directly in the browser. This eliminates the need for a remote database server and keeps sensitive data localized to the user's machine. The post uses a movie dataset as an example, showcasing how relationships between actors, movies, and genres can be represented within the graph. Queries written in Cypher, KuzuDB's query language, retrieve relevant information from this local graph based on user questions.

WebLLM then enters the scene, taking the results retrieved by Kuzu-WASM and feeding them to a locally running LLM. This LLM uses the retrieved information as context to generate a comprehensive and accurate answer to the user's query. The post highlights the use of a smaller, quantized LLM model optimized for browser execution, emphasizing the potential for performance and efficiency in this client-side architecture.

The post details the technical steps involved in setting up this in-browser RAG pipeline. It covers loading Kuzu-WASM and the chosen LLM model, populating the graph database with the movie dataset, and constructing the logic that connects user queries, graph traversal with Cypher, and LLM-powered answer generation. Code snippets are provided to illustrate the implementation.

The authors emphasize the benefits of this approach, particularly its privacy implications. By keeping data and processing local, user information is never transmitted to a server, offering a significantly more private user experience. Furthermore, the post hints at the potential for offline functionality, suggesting that this architecture could enable powerful knowledge-based applications even without an internet connection. Finally, the post encourages readers to explore and experiment with this technology, positioning it as an exciting development in the evolution of web-based applications and AI.

Summary of Comments ( 4 )
https://news.ycombinator.com/item?id=43321523

HN commenters generally expressed excitement about the potential of in-browser graph RAG, praising the demo's responsiveness and the possibilities it opens up for privacy-preserving, local AI applications. Several users questioned the performance and scalability with larger datasets, highlighting the current limitations of WASM and browser storage. Some suggested potential applications, like analyzing personal knowledge graphs or interacting with codebases. Concerns were raised about the security implications of running LLMs client-side, and the challenge of keeping WASM binaries up-to-date. The closed-source nature of KuzuDB also prompted discussion, with some advocating for open-source alternatives. Several commenters expressed interest in trying the demo and exploring its capabilities further.

The Hacker News post discussing in-browser graph RAG with Kuzu-WASM and WebLLM has generated several comments, offering a range of perspectives on the project.

One commenter expresses excitement about the potential of WebAssembly for database applications, specifically highlighting the possibility of running complex queries client-side without server dependencies. They see this as a significant step toward enabling powerful and responsive web applications. They also inquire about the feasibility of using this technology with larger datasets, acknowledging the current limitations of browser storage.

Another commenter raises a practical concern about the performance implications of handling large graph datasets within the browser. They question whether the current implementation can efficiently manage substantial graphs and suggest that server-side processing might be more suitable for complex graph operations on large datasets. This comment highlights a common trade-off between client-side convenience and server-side performance when dealing with data-intensive applications.

A further comment delves into the specifics of the technology, mentioning the use of Apache Arrow for data serialization. They posit that this choice could be contributing to performance bottlenecks, particularly when transferring data between JavaScript and WebAssembly. They suggest exploring alternative serialization methods or optimizing the data transfer process to improve overall efficiency.

Another individual inquires about the licensing of the project, expressing interest in its potential applications. This highlights the importance of clear licensing information for open-source projects to encourage adoption and collaboration.

The discussion also touches upon the security implications of running database queries within the browser environment. One comment raises the concern of potential vulnerabilities arising from client-side execution and suggests that careful consideration should be given to security best practices.

Finally, a commenter expresses enthusiasm for the project's potential to democratize access to graph databases, making them more accessible to developers and users without requiring specialized server infrastructure. They see this as a positive step towards empowering individuals and smaller organizations to leverage the power of graph technology.

In summary, the comments on the Hacker News post reflect a general interest in the project while also raising important questions and concerns regarding performance, scalability, security, and licensing. The discussion highlights the potential benefits and challenges of bringing graph database technology to the browser environment.

Online Embedded Rust Simulator

permalink

Posted: 2025-03-09 03:40:51

Wokwi now offers a web-based simulator for developing and debugging embedded Rust programs. This online tool allows users to write, build, and run Rust code targeted for various microcontrollers, including the AVR ATmega328P (like the Arduino Uno) and RP2040 (Raspberry Pi Pico), directly in the browser. The simulator features peripherals like LEDs, buttons, serial output, and an integrated logic analyzer, enabling interactive hardware simulation without requiring physical hardware. Code can be compiled and flashed to the virtual microcontroller, and the simulator provides a debugging environment for stepping through code and inspecting variables. This simplifies the embedded Rust development process, making it more accessible for learning and experimentation.

The Wokwi website introduces a novel online simulator specifically designed for developing and debugging embedded Rust programs. This simulator eliminates the need for physical hardware, offering a convenient and accessible environment for experimentation and learning. The platform provides a simulated representation of a microcontroller, encompassing peripherals such as LEDs, buttons, and a serial monitor, all accessible directly within the user's web browser. This allows developers to write, build, flash, and debug their Rust code in a streamlined workflow without leaving the browser interface.

The simulation environment replicates the behavior of an actual microcontroller, emulating the execution of Rust code as if it were running on a physical device. This includes support for core embedded Rust features, such as interacting with hardware registers and managing peripherals. The integrated development environment (IDE) within Wokwi boasts several helpful tools, including a built-in debugger that facilitates stepping through code, inspecting variables, and identifying potential issues. Additionally, the simulator offers a visual representation of the simulated hardware, allowing developers to observe the effects of their code on the virtual components in real-time, such as LEDs blinking or button presses being registered.

Furthermore, Wokwi's online Rust simulator supports a variety of target microcontrollers, offering flexibility in choosing the appropriate hardware platform for a specific project. The website also features documentation and tutorials, providing guidance and examples to assist users in getting started and exploring the capabilities of the simulator. This makes the platform a valuable resource for both experienced embedded systems developers seeking a rapid prototyping environment and newcomers looking to learn embedded Rust programming in a practical and interactive manner. The cloud-based nature of Wokwi further enhances its accessibility, enabling users to access and utilize the simulator from any device with a web browser, eliminating the need for complex local setup and configuration.

Summary of Comments ( 7 )
https://news.ycombinator.com/item?id=43305973

HN commenters generally expressed enthusiasm for Wokwi's online embedded Rust simulator. Several praised its ease of use and accessibility, noting it lowers the barrier to entry for embedded development. Some highlighted the educational benefits, particularly for those new to Rust or embedded systems. A few pointed out the limitations of simulation compared to real hardware, but acknowledged the simulator's value for initial development and testing. The discussion also touched on potential improvements, including support for more microcontrollers and peripherals, as well as integration with other tools. Some users shared their positive experiences using Wokwi for specific projects, further reinforcing its practical usefulness.

The Hacker News post titled "Online Embedded Rust Simulator" (linking to https://wokwi.com/rust) generated a modest amount of discussion, with several commenters expressing enthusiasm for the project and exploring its potential applications and limitations.

One commenter highlighted the educational value of the simulator, suggesting it could be a fantastic tool for beginners learning embedded Rust. They praised the interactive nature of the platform, allowing users to experiment and gain practical experience without needing physical hardware. This sentiment was echoed by another user who envisioned using the simulator in workshops or introductory courses.

Several commenters delved into technical aspects, discussing the underlying technology and its limitations. One user inquired about the simulator's handling of peripherals, specifically mentioning the absence of support for specific features like DMA. The creator of Wokwi responded, acknowledging the current limitations and outlining plans for future development, including potential support for DMA and other advanced peripherals. This exchange showcased the collaborative nature of the platform and the developer's responsiveness to community feedback.

Another technical discussion revolved around the simulator's performance and its suitability for larger, more complex projects. One user questioned whether the simulator could handle real-world applications with significant processing demands. While acknowledging that the simulator might not be ideal for highly complex projects, the creator pointed out that it was designed for educational purposes and smaller-scale projects, emphasizing its strength in rapid prototyping and experimentation.

Beyond technical discussions, several commenters expressed their general appreciation for the project, viewing it as a valuable contribution to the embedded Rust ecosystem. Some users shared their personal experiences with the simulator, highlighting its ease of use and effectiveness in learning embedded concepts.

Overall, the comments reflected a positive reception to the online embedded Rust simulator. The discussion centered around the simulator's educational benefits, technical capabilities and limitations, and its potential as a valuable tool for learning and experimentation within the embedded Rust community.

OpenGL to WASM, learning from my mistakes

permalink

Posted: 2025-03-01 13:24:30

Porting an OpenGL game to WebAssembly using Emscripten, while theoretically straightforward, presented several unexpected challenges. The author encountered issues with texture formats, particularly compressed textures like DXT, necessitating conversion to browser-compatible formats. Shader code required adjustments due to WebGL's stricter validation and lack of certain extensions. Performance bottlenecks emerged from excessive JavaScript calls and inefficient data transfer between JavaScript and WASM. The author ultimately achieved acceptable performance by minimizing JavaScript interaction, utilizing efficient memory management techniques like shared array buffers, and employing WebGL-specific optimizations. Key takeaways include thoroughly testing across browsers, understanding WebGL's limitations compared to OpenGL, and prioritizing efficient data handling between JavaScript and WASM.

The blog post "OpenGL to WASM, learning from my mistakes" details the author's journey and challenges encountered while porting a C++ OpenGL application to WebAssembly (WASM) using Emscripten. The author's initial goal was seemingly straightforward: compile the existing codebase to WASM and utilize WebGL within a browser environment. However, the process proved more complex than anticipated.

The author's first significant hurdle involved memory management. OpenGL relies on client-side memory management, allowing direct manipulation of memory buffers by the application. WebGL, in contrast, leverages JavaScript's garbage collection and restricts direct memory access. This difference necessitated rewriting sections of the codebase to interface with WebGL's memory management model. The author implemented a strategy of mapping and unmapping memory to ensure data consistency between C++ and JavaScript, essentially creating a bridge to manage data transfer between the two environments.

Another major challenge arose from differing shader compilation processes. OpenGL allows runtime compilation of shaders, whereas WebGL mandates pre-compilation. This disparity compelled the author to modify the shader pipeline significantly, converting shaders to a string representation and embedding them directly into the C++ source code for pre-compilation before WASM compilation. This pre-compilation stage, while solving the immediate compatibility issue, introduced an added layer of complexity to the build process.

Further complications emerged due to the asynchronous nature of JavaScript. The author's OpenGL application, designed for a synchronous execution environment, encountered issues when interfacing with JavaScript's asynchronous callbacks. This necessitated careful synchronization to avoid race conditions and ensure the proper execution order of operations, particularly related to texture loading and rendering. The solution involved adapting the C++ code to handle asynchronous operations and ensuring proper sequencing.

The author also discusses the need for a JavaScript "glue" layer to facilitate communication between the WASM module and the browser environment. This layer handled tasks like canvas resizing, input event handling, and general interaction between the WASM-compiled C++ code and the JavaScript runtime.

Finally, the post touches on performance considerations. While WASM offered good performance overall, the author notes that the overhead associated with memory mapping and the JavaScript glue code introduced some performance penalties. The author acknowledges the need for ongoing optimization to achieve optimal performance in the browser environment.

In essence, the post provides a detailed account of the challenges and solutions encountered during the porting process, highlighting the key differences between OpenGL and WebGL, the complexities of memory management in a WASM context, the intricacies of shader compilation, the importance of handling asynchronous operations, and the role of a JavaScript interface layer. The author emphasizes the non-trivial nature of porting OpenGL applications to WASM, offering valuable insights for developers undertaking similar endeavors.

Summary of Comments ( 15 )
https://news.ycombinator.com/item?id=43218998

Commenters on Hacker News largely praised the author's clear writing and the helpfulness of the article for those considering similar WebGL/WebAssembly projects. Several pointed out the challenges inherent in porting OpenGL code, especially around shader precision differences and the complexities of memory management between JavaScript and C++. One commenter highlighted the benefit of using Emscripten's WebGL bindings for easier texture handling. Others discussed the performance implications of various approaches, including using WebGPU instead of WebGL, and the potential advantages of libraries like glium for abstracting away some of the lower-level details. A few users also shared their own experiences with similar porting projects, offering additional tips and insights. Overall, the comments section provides a valuable supplement to the article, reinforcing its key points and expanding on the practical considerations for OpenGL to WebAssembly porting.

The Hacker News post "OpenGL to WASM, learning from my mistakes" (linking to an article about porting OpenGL to WebGL) has a moderate number of comments, sparking a discussion around various aspects of WASM, WebGL, and graphics programming. Several commenters offer their own experiences and insights related to the author's journey.

One compelling thread focuses on the complexities and nuances of WebGL. One commenter points out the challenges in handling WebGL contexts, especially in multi-threaded environments, highlighting how seemingly simple actions like clearing the screen can become problematic due to context switching. This spurred further discussion about the asynchronous nature of WebGL and the difficulties it presents. Another commenter discusses the limitations of WebGL, particularly regarding compute shaders and other advanced features that are available in native OpenGL, emphasizing the trade-offs involved in targeting the web.

Another key area of discussion revolves around the performance characteristics of WASM and JavaScript for graphics-intensive tasks. One commenter questions the performance benefits of using WASM for this specific use case, suggesting that JavaScript might be sufficiently optimized for many 2D or simpler 3D applications. This prompted a counter-argument referencing the potential for WASM to leverage SIMD instructions and other low-level optimizations that can provide substantial speedups, especially for complex computations and algorithms commonly found in 3D graphics.

A few commenters share their own experiences and alternative approaches to web-based graphics programming. One mentions using libraries like Emscripten and its OpenGL support, emphasizing the ease of porting existing C/C++ codebases. Another suggests exploring WebGPU as a more modern and performant alternative to WebGL, highlighting its advantages in terms of features and access to modern hardware capabilities.

Finally, several comments directly address the author's experiences and choices detailed in the linked article. Some offer specific advice related to memory management and data transfer between JavaScript and WASM, while others commend the author for sharing their learning process and the valuable insights gained from the porting effort.

MichiganTypeScript: A WebAssembly runtime implemented in TypeScript types

permalink

Posted: 2025-02-26 16:26:18

MichiganTypeScript is a proof-of-concept project demonstrating a WebAssembly runtime implemented entirely within TypeScript's type system. It doesn't actually execute WebAssembly code, but instead uses advanced type-level programming techniques to simulate its execution. By representing WebAssembly instructions and memory as types, and leveraging TypeScript's type inference and checking capabilities, the project can statically verify the behavior of a given WebAssembly program. This effectively transforms TypeScript's type checker into an interpreter, showcasing the power and flexibility of its type system, albeit in a non-practical, purely theoretical manner.

The GitHub repository "MichiganTypeScript/typescript-types-only-wasm-runtime," also known as MichiganTypeScript, presents a novel approach to WebAssembly (Wasm) runtime implementation. Instead of using traditional programming languages like C++, Rust, or JavaScript, this project leverages the TypeScript type system itself to emulate a Wasm runtime environment entirely within the type checker. This means no actual JavaScript code is generated or executed; the entire runtime logic, including loading Wasm modules, executing instructions, managing memory, and handling system calls, is encoded and enforced through complex type definitions and manipulations.

MichiganTypeScript achieves this by representing Wasm concepts as TypeScript types. For example, Wasm instructions are modeled as type-level functions, memory is represented using tuples, and the stack is simulated using recursive type definitions. The execution of a Wasm program within this system involves a series of intricate type transformations, where the TypeScript compiler effectively "steps through" the program by applying type-level functions that correspond to Wasm instructions. The compiler's type checking mechanism verifies that these transformations are valid according to the defined Wasm semantics.

The primary objective of this project is not to create a practical, performant Wasm runtime for real-world applications. Instead, it serves as an exploration of the boundaries of TypeScript's type system and a demonstration of its expressive power. By implementing a complex system like a Wasm runtime purely within the type system, the project showcases the potential of using types for advanced static analysis, program verification, and potentially even code generation in the future. While currently limited in terms of the Wasm features it supports and the size of programs it can handle, MichiganTypeScript represents a compelling experiment in pushing the limits of type-driven development. The project highlights the increasing sophistication of type systems in modern programming languages and opens up new avenues for research into leveraging them for tasks traditionally performed by runtime environments.

Summary of Comments ( 5 )
https://news.ycombinator.com/item?id=43185174

Hacker News users discussed the cleverness of using TypeScript's type system for computation, with several expressing fascination and calling it "amazing" or "brilliant." Some debated the practical applications, acknowledging its limitations while appreciating it as a demonstration of the type system's power. Concerns were raised about debugging complexity and the impracticality for larger programs. Others drew parallels to other Turing-complete type systems and pondered the potential for generating optimized WASM code from such TypeScript code. A few commenters pointed out the project's connection to the "ts-sql" project and speculated about leveraging similar techniques for compile-time query validation and optimization. Several users also highlighted the educational value of the project, showcasing the unexpected capabilities of TypeScript's type system.

The Hacker News post titled "MichiganTypeScript: A WebAssembly runtime implemented in TypeScript types" sparked a discussion with several interesting comments.

Many users expressed fascination and amusement at the project, highlighting the ingenuity and absurdity of implementing a Wasm runtime purely within TypeScript's type system. Some saw it as a clever demonstration of the power and flexibility of TypeScript's type system, pushing its boundaries beyond what might be considered practical. Others viewed it more as a playful experiment or a form of esoteric programming.

One commenter questioned the practical implications of the project, wondering about its potential use cases beyond being a proof of concept. This sparked a small thread discussing the potential for verifying Wasm modules at compile time or exploring new possibilities in type-level computation. However, the general consensus seemed to be that the project's primary value lies in its demonstration of the theoretical possibilities, rather than immediate practical applications.

Several users pointed out the similarities to other projects that explore the computational capabilities of type systems, particularly within languages like Idris and Haskell. This highlighted the connection between TypeScript's advanced type features and the concepts found in dependently-typed languages.

There was also some discussion regarding the performance and scalability of such an approach. Some commenters expressed skepticism about the feasibility of using this for real-world Wasm execution, anticipating potential performance bottlenecks.

A few users highlighted the educational value of the project, suggesting that it could be a useful tool for learning about both TypeScript's type system and the inner workings of Wasm.

Finally, some comments simply expressed amazement and appreciation for the creativity and technical skill demonstrated by the project's creators. Phrases like "mind-blowing," "absolutely bonkers," and "amazingly pointless" were used to capture the general sentiment of bewildered admiration.

TypeScript types can run DOOM [video]

permalink

Posted: 2025-02-26 15:05:02

This YouTube video demonstrates running a playable version of DOOM within a TypeScript type definition. By cleverly exploiting the TypeScript compiler's type system, particularly recursive types and conditional type inference, the creator encodes the game's logic and data, including map layout, enemy behavior, and rendering. The "game" runs entirely within the type checker, with output rendered as a string that visually represents the game state. This showcases the surprising computational power and complexity achievable within TypeScript's type system, though it's obviously not a practical way to develop games. Instead, it serves as a fascinating exploration of the boundaries of what can be accomplished with type-level programming.

The YouTube video "TypeScript types can run DOOM [video]" demonstrates a highly unconventional and computationally intensive approach to implementing game logic. Instead of using traditional runtime code, the creator leverages the TypeScript type system to effectively emulate a simplified version of the classic game DOOM. This is achieved by encoding game state, map data, and game logic rules within complex, nested type definitions.

The video showcases how TypeScript's type checker, during compilation, evaluates these intricate types. This evaluation process mimics the execution of the game logic. For instance, the type system determines the player's position, checks for collisions with walls based on the map data encoded within the types, and even simulates projectile movement and enemy interactions, all at compile time.

Due to the inherent limitations of the type system, the resulting "game" is not visually rendered in a traditional sense. Instead, the output of this compile-time computation is represented abstractly through type errors. These carefully crafted type errors are designed to convey information about the game's state. For example, a specific type error might indicate that the player has encountered a wall, picked up an item, or defeated an enemy.

The creator demonstrates the process of constructing these types, explaining the underlying principles and the logic behind their design. They show how different aspects of the game, such as movement, collision detection, and even basic enemy AI, are translated into type-level computations. This involves using advanced TypeScript features, like conditional types, mapped types, and recursive types, to represent game logic within the confines of the type system.

The overall project serves as an impressive, albeit impractical, demonstration of the power and flexibility of the TypeScript type system. It highlights the Turing completeness of TypeScript's type system, albeit in a highly constrained and unconventional manner. The video is not meant to advocate for this approach in real-world game development but rather showcases the unexpected capabilities and potential of type systems for complex computations, pushing the boundaries of what's typically considered possible with a type checker.

Summary of Comments ( 138 )
https://news.ycombinator.com/item?id=43184291

HN users were generally impressed with the technical feat of running DOOM in a TypeScript type. Several pointed out the absurdity and impracticality of the project, with one user calling it "peak type abuse." Discussion touched on the Turing completeness of TypeScript's type system, its potential misuse, and the implications for performance. Some wondered about practical applications, while others simply appreciated it as a clever demonstration of the language's capabilities. A few users questioned the definition of "running" in this context, arguing that it was more of a simulation than actual execution. There was some debate about the video's explanation clarity and a call for a blog post with a more thorough breakdown.

The Hacker News post titled "TypeScript types can run DOOM [video]" (linking to a YouTube video demonstrating a TypeScript type system complex enough to encode and "run" a simplified version of DOOM) generated a variety of comments, predominantly focused on the cleverness of the implementation and the implications for type systems.

Several commenters expressed amazement and admiration for the technical feat. Phrases like "absolutely insane," "mind-blowing," and "this is wild" were common. This sentiment reflects the unexpected power and complexity demonstrated by manipulating TypeScript's type system to perform computations typically handled by runtime code.

A significant thread of discussion revolved around the practical implications (or lack thereof) of this demonstration. Many acknowledged the impracticality of this approach for actual game development or any performance-sensitive task. Commenters pointed out the significant performance overhead and the unwieldy nature of encoding logic within a type system. However, some suggested that the underlying principles could potentially have applications in areas like formal verification and compile-time computation, even if encoding a game within types remains a novelty.

Some commenters explored the theoretical boundaries of this approach. They questioned how far such a system could be pushed and speculated about the computational completeness of sufficiently advanced type systems. The discussion touched upon topics like Turing completeness and the theoretical limits of computation within type systems.

A few comments focused on the educational value of the demonstration. They highlighted the project's ability to illustrate the power and flexibility of type systems, even if the specific application is impractical. This suggests the video could be a valuable tool for learning about type systems and their potential.

Some technical details of the implementation were also discussed, including the use of recursive types and the limitations imposed by the TypeScript type system. Commenters debated the elegance and readability of the code, with some expressing concerns about the complexity and maintainability of such an approach.

Finally, some comments injected humor into the thread, making lighthearted remarks about the absurdity of running DOOM in a type system and the potential for future "type-driven" applications.

Overall, the comments on Hacker News reflected a mix of awe, skepticism, and curiosity about the implications of running DOOM within TypeScript's type system. While acknowledging the impracticality of the specific application, many appreciated the technical ingenuity and the potential for future explorations of type system capabilities.

Chicory: A JVM native WebAssembly runtime

permalink

Posted: 2025-02-25 11:22:06

Chicory is a new WebAssembly runtime built specifically for the Java Virtual Machine (JVM). It aims to bring the performance and portability benefits of Wasm to JVM environments by allowing developers to seamlessly execute Wasm modules directly within their Java applications. Chicory achieves this through a combination of ahead-of-time (AOT) compilation to native code via GraalVM Native Image and a runtime library implemented in Java. This approach allows for efficient interoperability between Java code and Wasm modules, potentially opening up new possibilities for leveraging Wasm's growing ecosystem within established Java systems.

The blog post introduces Chicory, a novel runtime environment designed specifically for executing WebAssembly (Wasm) code directly on the Java Virtual Machine (JVM). Chicory aims to bridge the gap between the Wasm ecosystem and the vast world of Java libraries and frameworks, enabling developers to seamlessly integrate Wasm modules into existing Java applications. This integration allows leveraging the performance benefits of Wasm while capitalizing on the maturity and richness of the Java ecosystem.

Chicory achieves this integration through a two-pronged approach. Firstly, it compiles Wasm modules into Java bytecode, allowing the JVM to execute them natively. This compilation process leverages the existing capabilities of the JVM, ensuring efficient execution and optimization of the Wasm code. Secondly, Chicory provides a meticulously crafted interoperability layer that facilitates smooth communication between Java code and Wasm modules. This interoperability layer handles data marshalling and conversion between Java types and Wasm types, enabling seamless data exchange and function calls between the two environments.

One of the primary advantages of using Chicory is performance. By compiling Wasm to JVM bytecode, Chicory can harness the JVM's just-in-time (JIT) compilation and optimization capabilities, leading to potentially significant performance improvements compared to interpreted Wasm runtimes. This performance advantage is particularly important for computationally intensive tasks or applications requiring low latency.

Another key benefit is access to the extensive Java ecosystem. Chicory allows Wasm modules to directly utilize existing Java libraries and frameworks, unlocking a wealth of functionality for Wasm developers. This access eliminates the need to reimplement common functionalities within the Wasm environment, accelerating development and reducing code duplication.

Furthermore, Chicory simplifies the deployment of Wasm modules. By running Wasm directly on the JVM, developers can leverage existing Java deployment infrastructure and tools, streamlining the deployment process and reducing operational overhead.

The blog post highlights Chicory's current status as an early-stage project, emphasizing the potential for future development and improvements. It also mentions ongoing work on refining the interoperability layer and expanding support for various Wasm features. The ultimate goal is to provide a robust and performant runtime environment that fully integrates Wasm into the JVM, empowering developers to build high-performance applications that combine the best of both worlds. The post encourages community involvement and contributions to help shape the future of Chicory and its integration with the Wasm ecosystem.

Summary of Comments ( 86 )
https://news.ycombinator.com/item?id=43170545

Hacker News users discussed Chicory's potential, limitations, and context within the WebAssembly ecosystem. Some expressed excitement about its JVM integration, seeing it as a valuable tool for leveraging existing Java libraries and infrastructure within WebAssembly applications. Others raised concerns about performance, particularly regarding garbage collection and its suitability for computationally intensive tasks. Comparisons were made to other WebAssembly runtimes like Wasmtime and Wasmer, with discussion around the trade-offs between performance, portability, and features. Several comments questioned the practical benefits of running WebAssembly within the JVM, particularly given the existing rich Java ecosystem. There was also skepticism about WebAssembly's overall adoption and its role in the broader software landscape.

The Hacker News post titled "Chicory: A JVM native WebAssembly runtime" sparked a discussion thread with several insightful comments. Many commenters focused on the potential benefits and drawbacks of using WebAssembly (Wasm) within the JVM ecosystem.

One recurring theme was the exploration of use cases for Chicory. Some commenters questioned the advantages of using Wasm within the JVM compared to existing JVM languages like Kotlin or Scala. They pondered whether Wasm offered significant performance gains or other benefits that would justify the added complexity of integrating another runtime environment. Others suggested potential niches, such as running code from other languages compiled to Wasm, or leveraging Wasm's sandboxing capabilities for security-sensitive operations.

Performance was another key area of discussion. Some commenters expressed skepticism about Wasm's performance within the JVM, particularly concerning garbage collection and interoperability with JVM objects. They highlighted the potential overhead of bridging the gap between the Wasm and JVM environments.

Several commenters drew comparisons between Chicory and GraalVM's native image functionality. They debated whether using Wasm within the JVM offered any advantages over compiling JVM languages to native code directly. The discussion touched upon topics such as startup time, memory footprint, and overall execution speed.

Some commenters expressed interest in the technical details of Chicory's implementation, such as its garbage collection strategy and its approach to handling Wasm system calls. They inquired about the project's maturity and its roadmap for future development.

A few commenters mentioned alternative approaches to running Wasm in the JVM, such as using Wasmer or Wasmtime. They compared these existing solutions with Chicory, discussing their respective strengths and weaknesses.

Overall, the comments on the Hacker News post reflected a cautious optimism about Chicory. While acknowledging the potential of Wasm within the JVM, commenters raised important questions about its practical benefits and technical challenges. The discussion highlighted the need for further exploration and benchmarking to determine Chicory's viability in real-world scenarios.

Why I'm writing a Scheme implementation in 2025: Async Rust

permalink

Posted: 2025-02-17 20:30:26

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.

In a blog post titled "Why I'm Writing a Scheme Implementation in 2025: Async Rust," author Matthew Plant explains his motivations for embarking on a new Scheme implementation, emphasizing the advantages offered by utilizing asynchronous Rust. Plant, acknowledging the plethora of existing Scheme implementations, articulates that his primary drive isn't solely to create another Scheme, but rather to explore the intersection of Scheme's elegant design and the powerful features of asynchronous Rust. He believes this combination offers a unique opportunity to build a high-performance, concurrent Scheme system tailored for modern computing needs.

Plant elaborates on the specific benefits of using async Rust. He highlights the language's memory safety features, eliminating concerns about data races and other memory-related bugs that can plague implementations in languages like C. This inherent safety allows for greater focus on the core logic of the Scheme interpreter and runtime, rather than tedious debugging of memory issues. Furthermore, async Rust provides powerful tools for concurrency and parallelism, allowing for efficient handling of asynchronous operations, which are increasingly prevalent in modern applications. This aligns perfectly with Plant's vision of a modern, high-performance Scheme system. He specifically mentions the desire to experiment with concurrent garbage collection, facilitated by async Rust, potentially leading to a more responsive and efficient runtime environment.

The author discusses previous attempts at achieving similar goals with other languages, acknowledging that projects like CHICKEN Scheme have achieved a high level of performance. However, he argues that leveraging async Rust offers a unique blend of performance, safety, and concurrency features that makes it a particularly compelling choice for this project. He expresses excitement about the prospect of combining Scheme's simplicity and elegance with the robustness and modern capabilities of async Rust. Plant further details his intention to integrate modern tooling, specifically mentioning Language Server Protocol (LSP) support, to enhance the developer experience. This focus on tooling reflects a commitment to creating not only a performant implementation but also a user-friendly development environment.

Finally, the post concludes with a look towards the future of the project. Plant states his intentions to release the code open-source, encouraging community involvement and contributions. He acknowledges that the project is in its early stages, but expresses optimism about its potential and invites others to join him in exploring the possibilities of a Scheme implementation powered by async Rust. He sees this project as an exciting opportunity to push the boundaries of Scheme implementations and leverage the best of what modern language design has to offer.

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.

Now you can run Ruby on Rails in the browser using WebAssembly

permalink

Posted: 2025-02-17 15:15:14

Ruby on Rails applications can now run directly in web browsers thanks to WebAssembly. This is achieved using a new project called "Spreetail/wunderbar-wasm", which compiles Ruby and Rails to WASM using a custom-built toolchain. This allows developers to build full-stack Rails apps that execute client-side, offering potential performance benefits for certain applications by reducing server roundtrips. The WASM approach allows for offline functionality and removes the need for separate frontend and backend deployments. While still experimental, this technology opens up new possibilities for building web applications with Ruby on Rails.

The blog post "Now you can run Ruby on Rails on WebAssembly" on web.dev details a significant advancement in web development: the ability to execute the popular Ruby on Rails framework entirely within a web browser, leveraging the power of WebAssembly (Wasm). This achievement opens up new possibilities for richer, more interactive web applications and simplifies the development process in several key ways.

Traditionally, Ruby on Rails applications have resided on server-side infrastructure, handling data processing and dynamic content generation before sending the rendered HTML to the user's browser. This client-server architecture necessitates managing server resources, dealing with network latency, and potentially sacrificing interactivity. With the advent of Rails running on Wasm, the entire application, including the Ruby interpreter, the Rails framework, and application code, can be downloaded and executed directly within the client's browser.

The blog post highlights the collaboration between the Wasmer team and the Shopify team, who spearheaded this effort. Shopify, a major e-commerce platform with a substantial Ruby on Rails codebase, recognized the potential benefits of Wasm for improving developer experience and application performance. By compiling a version of Ruby specifically designed for Wasm, using the Wasmer runtime, they demonstrated the feasibility of running a full Rails application client-side.

This shift to client-side execution offers several advantages. Firstly, it improves the developer experience by simplifying the development workflow. Developers no longer need to constantly switch between frontend and backend development environments, streamlining the debugging and testing process. Secondly, it opens doors for improved application performance and interactivity. Complex calculations and data manipulations can occur instantly within the browser, eliminating network round trips and enhancing the user experience. Thirdly, it presents an opportunity to reimagine traditional web application architecture. The post hints at the potential for hybrid architectures where certain components run client-side while others remain server-side, offering greater flexibility and scalability.

The post showcases a proof-of-concept demonstrating a simplified Rails application running entirely within the browser, handling user input and dynamically updating the content without any server interaction. This example, while basic, illustrates the potential of this technology. The post emphasizes that this is still an early-stage development, but the progress achieved signals a promising future for Ruby on Rails in the browser, potentially revolutionizing web development workflows and paving the way for more sophisticated and responsive web experiences. While challenges remain, including the initial download size of the Wasm module and the performance of certain Ruby operations within Wasm, the advancements outlined in the blog post represent a significant step towards a future where server-side logic can seamlessly migrate to the client's browser, empowering developers and enriching user experiences.

Summary of Comments ( 17 )
https://news.ycombinator.com/item?id=43079791

Hacker News commenters expressed skepticism about the practicality of running Ruby on Rails in the browser via WebAssembly. Concerns focused on performance, particularly startup time and overall speed, doubting it would be suitable for production applications. Some suggested alternative approaches for achieving similar functionality, like using a server-rendered backend with a JavaScript frontend framework. Others questioned the use cases, wondering if the complexity was worth the effort compared to established approaches. Several commenters pointed to the large size of the Wasm bundle as a major drawback. A few expressed cautious optimism, acknowledging the technical achievement while remaining unsure of its real-world applicability. Finally, some highlighted the potential benefits for specific niches, such as online code editors or interactive tutorials.

The Hacker News post titled "Now you can run Ruby on Rails in the browser using WebAssembly" (linking to a web.dev article about the same) generated a moderate amount of discussion, with a mixture of excitement, skepticism, and practical considerations.

Several commenters expressed enthusiasm about the potential of running Rails entirely in the browser, highlighting benefits like simplified deployment, offline capabilities, and improved collaboration. One user envisioned a future where complex web applications could be shared seamlessly via URL, much like sharing a document, with the entire application logic and data bundled within the browser. Another commenter pointed out the potential for streamlined development workflows, eliminating the need for separate backend and frontend deployments.

However, many comments also raised concerns and limitations. Performance was a recurring theme, with some users questioning whether WebAssembly could truly deliver a smooth experience for a complex framework like Rails. The size of the compiled Wasm bundle was also mentioned as a potential obstacle, especially for larger applications. One commenter humorously pointed out the irony of returning to the "download the entire internet" model of early web pages.

Several users discussed the practical implications of running Rails in the browser, particularly regarding database access. Questions arose about how data persistence would be handled, with suggestions including using IndexedDB or relying on a separate backend server for data storage. The security implications of running server-side code within the client's browser were also raised, with concerns about potential vulnerabilities and the need for robust security measures.

Some comments focused on specific technical details, such as the use of the WASI (WebAssembly System Interface) and its implications for portability. One commenter questioned the choice of Ruby as the initial target language for this technology, suggesting that other languages might be better suited for WebAssembly due to their smaller runtime size.

Finally, several commenters shared their own experiences with similar technologies, such as using Python in the browser via WebAssembly. These comments provided valuable context and insights into the challenges and opportunities of bringing server-side frameworks to the client-side. Overall, the comments reflected a cautious optimism about the potential of running Rails in the browser, acknowledging the exciting possibilities while also recognizing the significant hurdles that need to be overcome.

We were wrong about GPUs

permalink

Posted: 2025-02-14 22:36:31

The Fly.io blog post "We Were Wrong About GPUs" admits their initial prediction that smaller, cheaper GPUs would dominate the serverless GPU market was incorrect. Demand has overwhelmingly shifted towards larger, more powerful GPUs, driven by increasingly complex AI workloads like large language models and generative AI. Customers prioritize performance and fast iteration over cost savings, willing to pay a premium for the ability to train and run these models efficiently. This has led Fly.io to adjust their strategy, focusing on providing access to higher-end GPUs and optimizing their platform for these demanding use cases.

The Fly.io blog post, "We Were Wrong About GPUs," details the company's evolving perspective on the role of Graphics Processing Units (GPUs) in their infrastructure and service offerings. Initially, Fly.io held a somewhat skeptical view of GPUs, believing that their primary utility lay within niche domains like machine learning and high-performance computing, and that the complexities and costs associated with their deployment outweighed their benefits for a broader audience. This perspective stemmed from the perceived challenges of GPU provisioning, the specialized hardware requirements, and the comparatively limited software ecosystem tailored for general-purpose GPU utilization outside of these specific fields.

However, the rapid advancement of both hardware and software related to GPUs has compelled Fly.io to re-evaluate their initial stance. They now recognize a significant shift in the landscape, where GPUs are becoming increasingly relevant and accessible for a wider range of applications beyond their traditional strongholds. This change is driven by several factors, including the growing maturity and affordability of GPU technology itself, the emergence of more streamlined and efficient provisioning mechanisms, and the expansion of software frameworks and tools that facilitate broader GPU utilization.

Specifically, the blog post highlights the rising popularity and capability of WebGPU, a new standard for web-based graphics and compute. This standard enables developers to leverage the power of GPUs directly within web browsers, opening up numerous possibilities for richer and more performant web applications. This development significantly lowers the barrier to entry for GPU usage, making it easier for developers to integrate GPU acceleration into their projects without needing deep expertise in specialized GPU programming paradigms.

Furthermore, the post acknowledges the evolving landscape of AI and the increasing demand for GPU resources to support AI workloads. The surge in generative AI applications and the growing reliance on machine learning models across various industries have underscored the critical role GPUs play in enabling these computationally intensive tasks. This realization has further reinforced Fly.io's revised perspective on the importance of GPUs in their future infrastructure plans.

Consequently, Fly.io now recognizes the strategic importance of incorporating GPUs into their platform. They acknowledge that their earlier assumptions about the limited applicability of GPUs were incorrect in light of these advancements, and are now actively working to integrate GPU support into their service offerings to cater to the expanding demand for GPU-accelerated applications across a broader spectrum of use cases, encompassing not only traditional high-performance computing and machine learning, but also emerging areas like web-based graphics and generative AI. They are committed to providing their users with access to the powerful capabilities of GPUs, enabling them to build and deploy more performant and resource-intensive applications within the Fly.io ecosystem.

Summary of Comments ( 421 )
https://news.ycombinator.com/item?id=43053844

HN commenters largely agreed with the author's premise that the difficulty of utilizing GPUs effectively often outweighs their potential benefits for many applications. Several shared personal experiences echoing the article's points about complex tooling, debugging challenges, and ultimately reverting to CPU-based solutions for simplicity and cost-effectiveness. Some pointed out that specific niches, like machine learning and scientific computing, heavily benefit from GPUs, while others highlighted the potential of simpler GPU programming models like CUDA and WebGPU to improve accessibility. A few commenters offered alternative perspectives, suggesting that managed services or serverless GPU offerings could mitigate some of the complexity issues raised. Others noted the importance of right-sizing GPU instances and warned against prematurely optimizing for GPUs. Finally, there was some discussion around the rising popularity of ARM-based processors and their potential to offer a competitive alternative for certain workloads.

The Hacker News post "We were wrong about GPUs" (linking to a fly.io blog post) generated a moderate amount of discussion, with several commenters offering interesting perspectives on the original article's claims.

A recurring theme is the nuance of GPU suitability for different tasks. Several comments challenge the blanket statement of being "wrong" about GPUs, highlighting their continued dominance in specific areas like machine learning training and scientific computing. One commenter pointed out that GPUs excel when data parallelism is high and control flow is relatively simple, which is often the case in these domains. Another echoes this, stating that GPUs are still the best choice for highly parallelizable tasks where the overhead of transferring data to the GPU is outweighed by the speed gains.

Some commenters discuss the complexities of utilizing GPUs effectively. One individual mentions the challenges of managing GPU memory and the difficulties in programming for them, contrasting this with the relative ease of using CPUs for more general-purpose tasks. This reinforces the idea that GPUs are not a universal solution and require careful consideration of the specific workload.

Another thread of discussion revolves around the rising prominence of alternative hardware, specifically mentioning TPUs and FPGAs. One commenter suggests that the article might be better titled "GPUs aren't the only future" acknowledging their ongoing relevance while highlighting the potential of other specialized hardware for specific tasks. Another points out that while GPUs are good at what they do, certain workloads, like database queries, might benefit more from specialized hardware or even optimized CPU implementations.

Several commenters provide anecdotal experiences. One shares their experience of struggling with GPUs for a specific image processing task, ultimately finding a CPU-based solution to be more efficient. This further emphasizes the importance of evaluating hardware choices based on individual project needs.

Finally, some comments focus on the cost aspect of GPUs, especially within the context of smaller companies or individual developers. The high cost of entry can be a significant barrier, making alternative solutions like CPUs or cloud-based GPU instances more appealing depending on the project's scale and budget.

Overall, the comments paint a picture of nuanced agreement and disagreement with the original article. While acknowledging the limitations and complexities of GPU usage, they generally agree that GPUs are not a panacea but remain a powerful tool for specific workloads. The discussion highlights the importance of careful hardware selection based on individual project requirements and the exciting potential of alternative hardware solutions.

Extensible WASM Applications with Go

permalink

Posted: 2025-02-14 07:08:53

Go 1.21 introduces a new mechanism for building more modular and extensible WebAssembly applications. Previously, interacting with JavaScript from Go WASM required compiling all the code into a single, large WASM module. Now, developers can compile Go functions as individual WASM modules and dynamically import and export them using JavaScript's standard module loading system. This allows for creating smaller initial downloads, lazy-loading functionalities, and sharing Go-defined APIs with JavaScript, facilitating the development of more complex and dynamic web applications. This also enables developers to build extensions for existing WASM applications written in other languages, fostering a more interconnected and collaborative WASM ecosystem.

This Go blog post, titled "Extensible WASM Applications with Go," explores a novel approach to building WebAssembly (WASM) applications using Go that emphasizes extensibility and modularity. Traditional WASM development often involves compiling an entire application into a single WASM module. This approach, while functional, can lead to large file sizes and makes it difficult to update or extend the application without recompiling the entire codebase. This blog post introduces a new strategy where Go developers can compile smaller, independent WASM modules that can be dynamically loaded and integrated into a larger application at runtime.

The post details how this dynamic linking and loading mechanism works within the context of WASM and Go. It explains that this capability is enabled by the wasmexport prototype tool, a new command-line utility designed specifically for generating extensible WASM modules. wasmexport facilitates the process of exporting Go functions for use within a WASM environment and enables these functions to be called from other WASM modules or even JavaScript. This cross-module communication is a key aspect of achieving extensibility.

The blog post walks through a concrete example of building a simple drawing application. It demonstrates how to create separate WASM modules for different drawing shapes, like circles and triangles. Each shape module exports functions to draw the respective shape on a canvas. These modules are then loaded dynamically by a main WASM module, which acts as the orchestrator of the application. The main module can then call the drawing functions exposed by the individual shape modules, effectively combining them into a cohesive application.

The post emphasizes the benefits of this approach, highlighting the reduced initial download size as only the core application needs to be loaded initially. Additional modules, providing extra functionalities, can be downloaded and integrated on demand. This lazy-loading capability contributes to a more responsive user experience. The post further emphasizes the improved maintainability and update process, as modifications to individual modules do not necessitate a recompilation of the entire application. Only the updated module needs to be rebuilt and re-downloaded.

Finally, the post acknowledges that wasmexport is still a prototype and under active development. It encourages community feedback and contributions to further refine and solidify this promising approach to building extensible and modular WASM applications with Go. The overall message is that this new method offers a significant improvement over existing WASM development workflows, paving the way for more complex and dynamic web applications built with Go.

Summary of Comments ( 81 )
https://news.ycombinator.com/item?id=43045698

HN commenters generally expressed excitement about Go's new Wasm capabilities, particularly the ability to import and export functions, enabling more dynamic and extensible Wasm applications. Several highlighted the potential for creating plugins and modules with Go, simplifying development and deployment compared to current WebAssembly workflows. Some discussed the implications for server-side Wasm and potential performance benefits. A few users raised questions about garbage collection and memory management with this new functionality, and another thread explored comparisons to JavaScript's module system and the potential for better tooling around Wasm. Some expressed concerns about whether it's better to use Go or Rust for Wasm development, and there was an insightful dialogue comparing wasmexport with previous approaches.

The Hacker News post "Extensible WASM Applications with Go" (https://news.ycombinator.com/item?id=43045698) has a moderate number of comments, discussing various aspects of using Go with WebAssembly (Wasm) and the implications of the wasmexport feature.

Several commenters express enthusiasm for the potential of Wasm and Go's role in it. One user highlights the benefit of Go's relatively small runtime size compared to other languages, making it attractive for Wasm applications. This small runtime contributes to faster loading times and reduced resource consumption, which are crucial for web-based applications.

Another commenter notes the "plugin" architecture enabled by wasmexport, where core Wasm modules can dynamically load and utilize extensions. They appreciate how this facilitates modularity and code reuse, envisioning scenarios where different teams can develop independent Wasm modules that seamlessly integrate with a central application. The commenter specifically mentions how this could be useful for developing extensions for software like image editors.

A discussion emerges around the security implications of this dynamic loading capability. Some users raise concerns about the potential for malicious extensions to compromise the security of the core Wasm module. While acknowledging these risks, others point out that similar security concerns exist with traditional plugin systems and suggest that established security best practices can be applied to mitigate these risks in the Wasm context as well.

The conversation also touches on the broader ecosystem surrounding Wasm and its future. One commenter expresses hope that wasmexport will contribute to a thriving ecosystem of reusable Wasm modules. Another commenter draws a parallel between wasmexport and the dynamic linking features of operating systems, suggesting that wasmexport could pave the way for a more modular and flexible web.

A few comments delve into the technical details of wasmexport, discussing aspects such as interface definitions and the mechanisms for interaction between the core module and its extensions.

Finally, some comments offer alternative perspectives. One user suggests exploring Web Workers as a potential solution for extensibility, arguing that this approach might offer certain advantages over wasmexport in specific use cases. Another user questions the need for dynamic linking in the browser environment, suggesting that static linking might be sufficient for many applications.

In summary, the comments on the Hacker News post reflect a generally positive outlook on the potential of wasmexport to enhance the capabilities of Wasm applications developed with Go. While acknowledging potential security challenges, commenters express excitement about the possibilities for modularity, code reuse, and a richer Wasm ecosystem. The discussion also includes technical insights and alternative viewpoints, providing a balanced perspective on the topic.

Stories with Tag WebAssembly

Summary of Comments ( 19 ) https://news.ycombinator.com/item?id=44126264

Summary of Comments ( 20 ) https://news.ycombinator.com/item?id=44109257

Summary of Comments ( 38 ) https://news.ycombinator.com/item?id=44101175

Summary of Comments ( 82 ) https://news.ycombinator.com/item?id=44050222

Summary of Comments ( 117 ) https://news.ycombinator.com/item?id=44040332

Summary of Comments ( 80 ) https://news.ycombinator.com/item?id=43934711

Summary of Comments ( 29 ) https://news.ycombinator.com/item?id=43810211

Summary of Comments ( 20 ) https://news.ycombinator.com/item?id=43789010

Summary of Comments ( 26 ) https://news.ycombinator.com/item?id=43761998

Summary of Comments ( 1 ) https://news.ycombinator.com/item?id=43734751

Summary of Comments ( 99 ) https://news.ycombinator.com/item?id=43678590

Summary of Comments ( 164 ) https://news.ycombinator.com/item?id=43661329

Summary of Comments ( 4 ) https://news.ycombinator.com/item?id=43631822

Summary of Comments ( 5 ) https://news.ycombinator.com/item?id=43601301

Summary of Comments ( 14 ) https://news.ycombinator.com/item?id=43599613

Summary of Comments ( 97 ) https://news.ycombinator.com/item?id=43593596

Summary of Comments ( 2 ) https://news.ycombinator.com/item?id=43578190

Summary of Comments ( 9 ) https://news.ycombinator.com/item?id=43535769

Summary of Comments ( 79 ) https://news.ycombinator.com/item?id=43429417

Summary of Comments ( 30 ) https://news.ycombinator.com/item?id=43364776

Summary of Comments ( 4 ) https://news.ycombinator.com/item?id=43321523

Summary of Comments ( 7 ) https://news.ycombinator.com/item?id=43305973

Summary of Comments ( 15 ) https://news.ycombinator.com/item?id=43218998

Summary of Comments ( 5 ) https://news.ycombinator.com/item?id=43185174

Summary of Comments ( 138 ) https://news.ycombinator.com/item?id=43184291

Summary of Comments ( 86 ) https://news.ycombinator.com/item?id=43170545

Summary of Comments ( 74 ) https://news.ycombinator.com/item?id=43083017

Summary of Comments ( 17 ) https://news.ycombinator.com/item?id=43079791

Summary of Comments ( 421 ) https://news.ycombinator.com/item?id=43053844

Summary of Comments ( 81 ) https://news.ycombinator.com/item?id=43045698

Summary of Comments ( 19 )
https://news.ycombinator.com/item?id=44126264

Summary of Comments ( 20 )
https://news.ycombinator.com/item?id=44109257

Summary of Comments ( 38 )
https://news.ycombinator.com/item?id=44101175

Summary of Comments ( 82 )
https://news.ycombinator.com/item?id=44050222

Summary of Comments ( 117 )
https://news.ycombinator.com/item?id=44040332

Summary of Comments ( 80 )
https://news.ycombinator.com/item?id=43934711

Summary of Comments ( 29 )
https://news.ycombinator.com/item?id=43810211

Summary of Comments ( 20 )
https://news.ycombinator.com/item?id=43789010

Summary of Comments ( 26 )
https://news.ycombinator.com/item?id=43761998

Summary of Comments ( 1 )
https://news.ycombinator.com/item?id=43734751

Summary of Comments ( 99 )
https://news.ycombinator.com/item?id=43678590

Summary of Comments ( 164 )
https://news.ycombinator.com/item?id=43661329

Summary of Comments ( 4 )
https://news.ycombinator.com/item?id=43631822

Summary of Comments ( 5 )
https://news.ycombinator.com/item?id=43601301

Summary of Comments ( 14 )
https://news.ycombinator.com/item?id=43599613

Summary of Comments ( 97 )
https://news.ycombinator.com/item?id=43593596

Summary of Comments ( 2 )
https://news.ycombinator.com/item?id=43578190

Summary of Comments ( 9 )
https://news.ycombinator.com/item?id=43535769

Summary of Comments ( 79 )
https://news.ycombinator.com/item?id=43429417

Summary of Comments ( 30 )
https://news.ycombinator.com/item?id=43364776

Summary of Comments ( 4 )
https://news.ycombinator.com/item?id=43321523

Summary of Comments ( 7 )
https://news.ycombinator.com/item?id=43305973

Summary of Comments ( 15 )
https://news.ycombinator.com/item?id=43218998

Summary of Comments ( 5 )
https://news.ycombinator.com/item?id=43185174

Summary of Comments ( 138 )
https://news.ycombinator.com/item?id=43184291

Summary of Comments ( 86 )
https://news.ycombinator.com/item?id=43170545

Summary of Comments ( 74 )
https://news.ycombinator.com/item?id=43083017

Summary of Comments ( 17 )
https://news.ycombinator.com/item?id=43079791

Summary of Comments ( 421 )
https://news.ycombinator.com/item?id=43053844

Summary of Comments ( 81 )
https://news.ycombinator.com/item?id=43045698