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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
LibreOffice, the open-source office suite, is celebrating its 14th anniversary (not 40th) with new features aimed at boosting online collaboration. A key development is the experimental browser-based version using WebAssembly, allowing users to run LibreOffice directly in their browser without installation. This version, dubbed "Zetaoffice," is currently limited but demonstrates the potential for enhanced accessibility and collaborative editing. Further developments include improved real-time collaboration within the desktop suite, progress towards a single, consistent codebase across different platforms, and enhanced interoperability with Microsoft Office formats.
HN commenters are generally positive about LibreOffice's continued development and the potential of WebAssembly. Several express excitement about running LibreOffice in the browser, particularly for simplified deployment and access. Some raise concerns about performance and resource usage, especially with complex documents. Others question the practicality of real-time collaboration within a browser-based office suite, comparing it to existing solutions like Google Docs/Sheets. A few commenters delve into technical details, discussing the WASM compilation process and the challenges of porting a large codebase like LibreOffice. There's also discussion about licensing, with some pointing out the limitations of the MPL license in certain commercial scenarios.
wasmCloud is a platform designed for building and deploying distributed applications using WebAssembly (Wasm) components. It uses a "actor model" and capabilities-based security to orchestrate these Wasm modules across any host environment, from cloud providers to edge devices. The platform handles complex operations like service discovery, networking, and logging, allowing developers to focus solely on their application logic. wasmCloud aims to simplify the process of building portable, secure, and scalable distributed applications with Wasm's lightweight and efficient runtime.
Hacker News users discussed the complexity of WasmCloud's lattice and its potential performance impact. Some questioned the need for such a complex system, suggesting simpler alternatives like a message queue and a registry. Concerns were raised about the overhead of the lattice and its potential to become a bottleneck. Others defended WasmCloud, pointing to its focus on security, actor model, and the benefits of its distributed nature for specific use cases. The use of Smithy IDL also generated discussion, with some finding it overly complex for simple interfaces. Finally, the project's reliance on Rust was noted, with some expressing concern about potential memory management issues and the learning curve associated with the language.
Zeroperl leverages WebAssembly (Wasm) to create a secure sandbox for executing Perl code. It compiles a subset of Perl 5 to Wasm, allowing scripts to run in a browser or server environment with restricted capabilities. This approach enhances security by limiting access to the host system's resources, preventing malicious code from wreaking havoc. Zeroperl utilizes a custom runtime environment built on Wasmer, a Wasm runtime, and focuses on supporting commonly used Perl modules for tasks like text processing and bioinformatics. While not aiming for full Perl compatibility, Zeroperl offers a secure and efficient way to execute specific Perl workloads in constrained environments.
Hacker News commenters generally expressed interest in Zeroperl, praising its innovative approach to sandboxing Perl using WebAssembly. Some questioned the performance implications of this method, wondering if it would introduce significant overhead. Others discussed alternative sandboxing techniques, like using containers or VMs, comparing their strengths and weaknesses to WebAssembly. Several users highlighted potential use cases, particularly for serverless functions and other cloud-native environments. A few expressed skepticism about the viability of fully securing Perl code within WebAssembly given Perl's dynamic nature and CPAN module dependencies. One commenter offered a detailed technical explanation of why certain system calls remain accessible despite the sandbox, emphasizing the ongoing challenges inherent in securing dynamic languages.
The author details their process of creating a WebAssembly (Wasm) virtual machine (VM) written entirely in C. Driven by a desire for a lightweight, embeddable Wasm runtime for resource-constrained environments, they built the VM from scratch, implementing core features like the stack-based execution model, linear memory, and basic WebAssembly System Interface (WASI) support. The project focused on simplicity and understandability over performance, serving primarily as a learning exercise and a platform for experimentation with Wasm. The post walks through key aspects of the VM's design and implementation, including parsing the Wasm binary format, handling function calls, and managing memory. It also highlights the challenges faced and lessons learned during the development process.
Hacker News users generally praised the author's clear writing style and the educational value of the post. Several commenters discussed the project's performance, noting that it's not optimized for speed and suggesting potential improvements like just-in-time compilation. Some shared their own experiences with WASM interpreters and related projects, including comparisons to other implementations and alternative approaches like using a stack machine. Others appreciated the detailed explanation of the parsing and execution process, finding it helpful for understanding WASM internals. A few users pointed out minor corrections or areas for potential enhancement in the code, demonstrating active engagement with the technical details.
Maxima, a powerful computer algebra system (CAS), is now accessible directly in web browsers thanks to a project leveraging Embedded Common Lisp (ECL) compiled to WebAssembly (WasM). This allows users to perform complex symbolic computations, including algebra, calculus, and numerical analysis, without any local installation. The browser-based interface provides a REPL (read-eval-print loop) for interactive calculations and utilizes MathJax for displaying formatted mathematical expressions. This project makes Maxima's capabilities more readily available, eliminating the need for dedicated software or server-side setups.
Commenters on Hacker News express excitement about Maxima running in the browser via WASM and ECL. Several highlight the potential for educational uses and interactive symbolic computation in web environments. Some discuss the performance overhead of WASM and suggest improvements, like pre-compilation for faster startup. The ability to share computational documents easily and integrate with other web technologies is praised. A few users mention other similar projects, including one using ClojureScript and another involving a Python CAS in the browser. The general sentiment is positive, with commenters intrigued by the possibilities this opens up for accessibility and collaborative mathematical work. One commenter expresses interest in building symbolic computation directly into a browser rather than running it as a VM.
The blog post showcases an incredibly compact WebAssembly compiler written in just a single tweet's worth of JavaScript code. This compiler takes a simplified subset of C code as input and directly outputs the corresponding WebAssembly binary format. It leverages JavaScript's ability to create typed arrays representing the binary structure of a .wasm file. While extremely limited in functionality (only supporting basic integer arithmetic and a handful of operations), it demonstrates the core principles of converting higher-level code to WebAssembly, offering a concise and educational example of how a compiler operates at its most fundamental level. The author emphasizes this isn't a practical compiler, but rather a fun exploration of code golfing and a digestible introduction to WebAssembly concepts.
Hacker News users generally expressed appreciation for the conciseness and elegance of the WebAssembly compiler presented in the tweet. Several commenters pointed out that while impressive, the compiler is limited and handles only a small subset of WebAssembly. Some discussed the potential educational value of such a minimal example, while others debated the practicality and performance implications. A few users delved into technical details, analyzing the specific instructions and optimizations used. The overall sentiment leaned towards admiration for the technical achievement, tempered with an understanding of its inherent limitations.
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.
The Hacker News post titled "Abusing DuckDB-WASM by making SQL draw 3D graphics (Sort Of)" generated a moderate amount of discussion, with a number of commenters expressing their amusement and fascination with the project.
Several commenters focused on the cleverness and unexpectedness of using SQL for graphical rendering, even if it's not practical. One described it as a "fun hack" and "peak software absurdity," highlighting the enjoyable, albeit unconventional, nature of the project. Another appreciated the technical ingenuity involved, calling it "madness" in a positive light. This sentiment was echoed by others who found the project amusing and appreciated the author's creativity.
Some commenters delved into the technical aspects, discussing the performance implications and limitations of such an approach. One commenter questioned the efficiency and wondered about the practical applications, while acknowledging the project's entertainment value. Another pointed out the inherent limitations of using SQL for graphics processing, suggesting that specialized tools are better suited for such tasks.
The potential educational value of the project was also highlighted. One commenter mentioned that it serves as a good example of how to transfer binary data to and from WebAssembly, a valuable skill for web developers.
A few commenters drew comparisons to other unconventional uses of SQL, such as generating music or solving complex mathematical problems. This reinforces the idea that SQL, while primarily designed for data management, can be used in surprisingly creative ways.
Overall, the comments reflect a general appreciation for the project's novelty and ingenuity, even if its practical applications are limited. The commenters acknowledge the impracticality of using SQL for 3D graphics but celebrate the creative exploration and technical demonstration involved.