Live data from Hacker News

Woxi: Wolfram Mathematica Reimplementation in Rust

github.com

71–80 of 141 posts

Re: Woxi: Wolfram Mathematica Reimplementation in Rust

#71
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.

Re: Woxi: Wolfram Mathematica Reimplementation in Rust

#72

Earlier quoted context omitted.

are all the tests hand written or are some agent-contributed? curious

What’s the difference if you review the code getting merged?

The difference is we can't tell if you reviewed the code.

Re: Woxi: Wolfram Mathematica Reimplementation in Rust

#73

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…

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?

Re: Woxi: Wolfram Mathematica Reimplementation in Rust

#74

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…

Switching out to an interpreted language has got to be anathema to a rewrite-it-in-Rust project

Re: Woxi: Wolfram Mathematica Reimplementation in Rust

#75

I love Rust for mathematical and scientific tasks (I am building the structural bio crate infrastructure), and I love Mathematica and have a personal sub. I should be the audience, but... What makes Mathematica great, IMO, is the polish and overall experience created by consistent work with applications in mind over decades. So, I look at this project with skepticism regarding its utility.

Half-assed reimplementations of existing software (often in the name of "memory safety") is what the Rust community is best known for.

Re: Woxi: Wolfram Mathematica Reimplementation in Rust

#76
post #75

I love Rust for mathematical and scientific tasks (I am building the structural bio crate infrastructure), and I love Mathematica and have a personal sub. I should be the audience, but... What makes Mathematica great, IMO, is the polish and overall experience created by consistent work with applications in mind over decades. So, I look at this project with skepticism regarding its utility.

Half-assed reimplementations of existing software (often in the name of "memory safety") is what the Rust community is best known for.

I find rust to be the best language and tool set in most categories. I still agree with this characterization.

Re: Woxi: Wolfram Mathematica Reimplementation in Rust

#77
post #73

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…

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.

Re: Woxi: Wolfram Mathematica Reimplementation in Rust

#78
post #50

Earlier quoted context omitted.

Yeah, I've already looked into it, but decided to keep developing it "example driven" for now. Aka I'm playing around with it, and whenever I find something that's broken I keep a note of it and then I pick those notes one by one and implement them. Once the most common things are implemented I will start writing property tests to catch all the edge cases of each feature.

I'm saying you can go even further and automate the entire thing using LLMs/agents, it is pretty much the ideal use case: you have a black-box reference implementation to test against; descriptive documentation for what the functions should do; some explicitly supplied examples in the documentation; and the ability to automatically create an arbitrary number of tests. So not only do you have a closed loop system that…

You accidentally raise an interesting point: good, thorough public documentation, once considered a great selling point for your system, now invites automated reimplementation by competition. It would be a shame to see public docs vanish because it turns out they are literally machine readable specs.

Re: Woxi: Wolfram Mathematica Reimplementation in Rust

#79
post #12

Earlier quoted context omitted.

Yeah, the Mathematica language is the least interesting aspect of the Mathematica system. Closely followed by the interactive notebooks.

> Closely followed by the interactive notebooks. Mathematica's notebooks are the only environment where I can do some computation to arrive at a symbolic expression. Copy the expression from the output cell into a new input cell. Then manipulate it by hand into the form I want. Then continue processing it further. Also, symbolic expressions can be written nicely with actual superscripts and subscripts, and with non-l…

Have a look at TeXmacs! (https://texmacs.org)

(AFAIK, you can run Mathematica sessions in TeXmacs, get proper typesetting, and can copy/paste expressions for simplification by hand or using other CAS sessions in the same TeXmacs document).

Re: Woxi: Wolfram Mathematica Reimplementation in Rust

#80
post #56

Earlier quoted context omitted.

MathWorks offers a huge list of "toolboxes", domain specific extensions that cover a lot of features in each domain. Replacing Matlab isn't about the core language alone.

Which often means that e.g. loading an image for displaying it increases cost by a few thousands

The price tags are wild for sure. But the sheer number of supported features is what makes them attractive. Cloning that completely is practically infeasable.
Post reply on HN