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?
My issue is that Mathematica is essentially a term rewriting system. Reimplementing everything in Rust seems to go against the idea. The derivative computation is 400 lines of Rust and could be 20 lines of Mathematica code.
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.
I have not looked at the implementation but isn't the idea to write a Lispy language in Rust (in other words, Mathematica the language) and then write the differentiation and other routines in that.
I mean you can do autodiff with a regular library in Rust. Enzyme is just a very specific type of autodiff which transforms after some compilation has taken place.
I don't know that you can match something speedwise like a JIT or Expression Templates in rust though without using something like Enzyme.
AI has a tendency of "just make it pass!" (which to be fair you also sometimes see from junior human devs - maybe where it learnt from!). Remember that C compiler which didn't even do basic error checking because that wasn't checked by the test suite?
A very young project written by AI means you haven't reviewed the code and nobody has used it in anger. It might work perfectly, but my experience of AI so far says that it won't.
As an alternative, I’m working on reimplementing Wolfram Language/ Mathematica in Rust: https://woxi.ad-si.com/
A lot of Wolfram Language code just works already!
I saw this project before, nice work! What is your plan when it comes to the hard core algebra parts like multivariate polynomial factorization and cylindrical algebraic decomposition? These features require quite some complex mathematical code and it is tricky to get it correct, and to get it working fast. Do you want to use other libraries for this or do you want to implement this all yourself?
If you want to use Symbolica for some of these features, feel free to reach out!
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!
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.
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!
I tried out numerous audio tagging apps (Kid3, Picard, …) and wasn't happy with any of them. They all try to work with some kind of library system of have a really bad UX (single line input for Lyrics???).
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:
f[x_Integer]:=13*x;
f::help:="Multiplies x by 13, in case you needed an easy function for that."
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.
I'm not a PL expert but isn't building a decent JIT a massive undertaking? I guess you're saying that the JIT itself would be what makes a project like this worth using in the first place?
It's like most things in software, if you constrain the problem enough, focus on the problems you actually have and make some smart choices early on, it can be a very modest lift on the order of a week or two for a 90% solution, but on the other end of the spectrum, it's a lifetime of work for a team of hundreds...
Most humans like external validation. Having other people use what they've built is a common metric of validation in open source software. Economically, these metrics can be used as credentials for things like job applications or consideration in joining groups.
reply