adius
adius on Hacker News
Cuis Smalltalk (
https://cuis.st) uses vector graphics for its rendering engine!
I would recommend Cuis Smalltalk (
https://cuis.st) as a more idiomatic solution that also looks much better due to it's vector graphic based rendering engine.
I've tried to get into Solidworks, Fusion, and FreeCAD several times, but every time I come back to programmatic CAD. It just better matches how I think about 3D design I guess. Also, I love that there can't be any hidden state or constraints -everything is fully defined by your code and fully visible.
Just give it a try, I guess, and see if it works for your use cases!
I was actually able to get a first version released just now:
https://luacad.ad-si.com/playground
It's still rather bare bones and won't work well for large models, but otherwise it should be fully functional!
I'm pretty sure it's Turing complete by now. If it was conceptualized as a limited language and only became a full fledged programming language over time, it would certainly explain all its weird warts. (Here is some more details:
https://github.com/ad-si/LuaCAD#why-lua) I guess 3D modeling is just too complex for a simple, but limited DSL.
Lua is easier to use, faster, and more feature-rich. It's one of those rare occasions when a new solution is actually better in every single way.
Agreed! I’m already working on it, but it’s not quite ready yet. ETA is 1-2 weeks.
Yes, it executes in a full fledged Lua environment. So you can do all the things you expect do be able to do with Lua!
I’d pick Lua over Python any day, but maybe that’s just me. ;-)
Posted by
adius on Friday August 14, 2026 @12:43PM
from the show-hn dept.
https://luacad.ad-si.com
LuaCAD models solids in Lua rather than the OpenSCAD language, with operator
overloading for CSG (`a + b`, `a - b`, `a * b`).It ships with a CLI and a desktop app, including a preview area and a text editor.I've always been a big fan of OpenSCAD, but the SCAD language itself is unfortunately quite cobbled-together and is a very poorly designed programming language.LuaCAD takes all the good...
No, none of them are implemented yet. I'll bump the priority to implement this!
Interesting - I would never use it as I find entering math with plain ASCII much faster and more intuitive, but if there is interest in this, I'll increase its priority!
Thanks! I’m interested as well … I’ll check it out and report back!
Performance is pretty good for most stuff by now. However, there are functions which not optimized yet or implemented in a very basic way and if you use them in non-trivial ways the performance might be quite slow. We're happy about any reports of such issues at
https://github.com/ad-si/Woxi/issues!
Yes, Rubi mostly works by now! Performance is still a concern, but we're working on improving it. I'll add some information on how to best use Rubi to the documentation soon. I already have a draft, but didn't find the time to finish it, yet.
I think the Wolfram Language got 80–90% of it right, and that's why I want to reimplement and use it in the first place. It bothers me that I have to use inferior solutions, such as those implemented in Python and Julia, just because the better solution is prohibitively expensive.
Of course, there are a few things I think we can do better than the Wolfram Language, but given all the available legacy code, there's really no point in making it slightly different and losing the ability to use that code. However, we might build an alternative syntax and frontend in the future that surfaces the capabilities of the Wolfram Language with a better UX.
Since then, we've made more than 7,000 commits and massively expanded Woxi's feature set. So it's well worth another try for anyone who tried it back then!
Posted by
adius on Wednesday August 12, 2026 @06:06AM
from the show-hn dept.
https://woxi.ad-si.com
Woxi is an interpreter for the Wolfram Language written in Rust.It comes with Woxi Studio, a Mathematica-like GUI built with iced, but you can also use Woxi through a CLI, Jupyter kernel, Python package, npm package, or WASM module.Compared with wolframscript / Mathematica, the main differences are:- Free and open source
- Very fast startup - Typically milliseconds rather than seconds for the...
Cuis Smalltalk has full high-DPI support as its GUI is based on vector graphics:
https://cuis.st/
The "Initial Motivation" section in the article explains why existing mobile apps aren't good enough.
Thanks for the report. I'm looking into it!
After 9 years of on-and-off development, I'm happy to announce the 1.0 release of Perspec, a desktop app for correcting the perspective of photos of documents, receipts, and whiteboards.
The headline feature of 1.0 is automatic corner detection: Instead of the usual edge-detection + Hough transform pipeline, it segments the document via watershed segmentation and finds corners, which handles wrinkled receipts and curved book pages much better. And if the detection is off, you can just drag the selection polygon to fix it.
Posted by
adius on Wednesday July 29, 2026 @04:58PM
from the adriansieber.com dept.
My theory is that writing as much as possible in Rust will improve performance and produce higher-quality code due to Rust's static typing. So far, it's been working well, but the final verdict is still out.
Author here: I absolutely do not understand this mindset.
It has almost 20K unit tests by now and hundreds of full end-to-end tests of complicated scripts to ensure it works and matches the output of Wolframscript. Why does it matter that I was using Claude to help me implement it?
Mathics (
https://mathics.org/) has been working on a Mathematica clone for years and hasn't had any problems so far. There have been many legal cases establishing that APIs are't copyrightable, and since Woxi shares zero code with Mathematica, it should be fine.
No support for intermediate steps yet, but if there is interest in it, I'd be happy to prioritize it.
Thanks! I'm hoping to use libraries for this, but unfortunately there aren't many available in Rust yet for those kinds of problems.
Integrating Symbolica would be awesome, but our licenses are incompatible at the moment. If you're willing to relicense parts for Woxi, I'd be happy to work on this together!
For short scripts, it’s often faster because there’s less initialization overhead. In general, though, it largely depends on whether the functions you’re using already have optimized implementations in Woxi. That’s what I’m currently working on, so I’d appreciate any feedback on what doesn’t work for you yet!