My Bona fides: I've written my own Mathematica clone at least twice, maybe three times. Each time I get it parsing expressions and doing basic math, getting to basic calculus. Then I look up the sheer cliff face in front of me and think better of the whole thing.
There is an architectural flaw in Woxi that will sink it hard. Looking through the codebase things like polynomials are implemented in the rust code, not in woxilang. This will kill you long term.
The right approach is to have a tiny core interpreter, maybe go to JIT at some point if you can figure that out. Then implement all the functionality in woxilang itself. That means addition and subtraction, calculus, etc are term rewriting rules written in woxilang, not rust code.
This frees you up in the interpreter. Any improvements you make there will immediately show up over the entire language. It's also a better language to implement symbolic math in than rust.
It also means contributors only need to know one language: woxilang. No need to split between rust and woxilang.
I noticed the same thing, having also written an interpreter for the Wolfram language that focused on the core rule/rewriting/pattern language. At its heart it’s more or less a Lisp-like language where the core can be quite small and a lot of the functionality built via pattern matching and rewriting atop that. Aside from the sheer scale of WL, I ended up setting aside my experiments replicating it when I did performance comparisons and realized how challenging it would be to not just match WL in functionality but performance.
Woxi reminds me of some experiments I did to see how far vibe coding could get me on similar math and symbolic reasoning tools. It seems like unless you explicitly and very actively force a design with a small core, the models tend towards building out a lot of complex, hard-coded logic that ultimately is hard to tune, maintain, or reason about in terms of correctness.
Interesting exercise with woxi in terms of what vibe coding can produce. Not sure about the WL implementation though.
(For context, I write compiler/interpreter tools for a living - have been for a couple decades)
Mh, I thought about this a little and came actually to exactly the opposite conclusion: Implement as much as possible in Rust to get the fastest code possible. Do you have any more insights why this should not be possible / unsustainable?
You have two distinct products 1) An interpreter 2) a math language. Don't write your math in some funny imperative computer language.
Keep the interpreters surface area as small as possible. Do some work to make sure you can accelerate numeric, and JIT/compile functions down to something as close to native as you can.
Wolfram, and Taliesin Beynon have both said Wolfram were working internally to get a JIT working in the interpreter loop. Keep the core small, and do that now while it's easy.
Also, it's just easier to write in Mathematica. It's probably 10x smaller than the rust code:
EDIT: Another important thing to note is the people who really deeply know specific subjects in math won't be the best, or even good rust programmers. So letting them program in woxilang will give the an opportunity to contribute which they wouldn't have had otherwise.f[x_Integer]:=13*x; f::help:="Multiplies x by 13, in case you needed an easy function for that."
implementing addition in woxilang itself?? this gotta be terribly slow. am i missing something?
Switching out to an interpreted language has got to be anathema to a rewrite-it-in-Rust project