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.
Such a massive undertaking would be almost impossible without AI agents, so yeah, they help me. But with around 5000 tests, they are actually helping to improve the software quality!
Reviewing the correctness of code is a lot harder than writing correct code, in my experience. Especially when the code given looks correct on an initial glance, and leads you into faulty assumptions you would not have made otherwise.
I'm not claiming AI-written and human-reviewed code is necessarily bad, just that the claim that reviewing code is equivalent to writing it yourself does not match my experience at all.
Plus if you look at the commit cadence there is a lot of commits like 5-10 minutes a part in places that add new functionality (which I realize doesn't mean they were "written" in that time)
I find people do argue a lot about "if it is reviewed it is the same" which might be easy when you start but I think the allure of just glancing going "it makes sense" and hammering on is super high and hard to resist.
We are still early into the use of these tools so perhaps best practices will need to be adjusted with these tools in mind. At the moment it seems to be a bit of a crap shoot to me.
You wrote: “If they hand wrote the code we know they at least looked at it once.”
But that’s not true, because even if they did indeed hand-write the code, we as third parties wouldn’t have any reliable proof of that, and therefore still couldn’t draw the conclusion that they looked at the code.
Them claiming to have hand-written the code isn’t any better than them claiming to have thoroughly reviewed the code. We can’t know in either case.
> Them claiming to have hand-written the code isn’t any better than them claiming to have thoroughly reviewed the code. We can’t know in either case.
It is better, because most people aren't out-right liars. If he said "I hand-wrote the code", sure it doesn't prove it, but I would believe him. When he says "I thoroughly reviewed the code"... yeah maybe. That's the sort of thing people do lie about (even to themselves).
reply