Wow! Do my eyes deceive me? What kind of ‘sunset’ are we talking of here?!
Woxi: Wolfram Mathematica Reimplementation in Rust
131–140 of 141 posts
Re: Woxi: Wolfram Mathematica Reimplementation in Rust
#132Earlier quoted context omitted.
Interesting, thanks for sharing. Naive question as I'm not familiar with Mathematica much (but aware of it and Wolfram Alpha and related tools), how does it compare to e.g. Jupyter or Julia or maybe another language (with its framework) that might be even closer?
I think Wolfram Language is just so much more ergonomic. No need to import dependencies - everything's included and consistent, very readable - yet compact - syntax, less gotchas than Python, R, etc., sensible default, …
I'd add the pattern matching syntax. it's so natural for a mathematician.
Re: Woxi: Wolfram Mathematica Reimplementation in Rust
#133Earlier quoted context omitted.
Well it would get vastly more popular if it was officially endorsed. Do you want lots of people using it?
Why is that important?
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.
Re: Woxi: Wolfram Mathematica Reimplementation in Rust
#134Earlier quoted context omitted.
You are missing the term "JIT", which would enable a host of runtime optimizations which include generating calls to some static piece of native code which performs addition.
But surely you can have a "fast path" that is implemented in the host language, right?
I am confused for the same reason you are. Isn't the rust code just "pre-jitted" code essentially? i.e. hand optimized. You are going to want to hand-optimize some functions in cases where the jit cannot do a good job in its current form. You probably also want a benchmarking system where you compare the jitted code to the hand optimized code, to prove to yourself that the hand optimized code is still worth keeping, after any automatic jit improvements you make. And if you don't want the runtime overhead of the jit then you can pre-jit certain functions and distribute them as part of the binary's executable code
Re: Woxi: Wolfram Mathematica Reimplementation in Rust
#135Earlier quoted context omitted.
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…
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?
Re: Woxi: Wolfram Mathematica Reimplementation in Rust
#136Earlier quoted context omitted.
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…
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...
Re: Woxi: Wolfram Mathematica Reimplementation in Rust
#137Hi, I'm the main developer. We're steadily getting closer to the next release which will support most features of Mathematica 1.0 plus some of the most popular newer functions (> 900 overall!). AMA!
There's a mystique around Mathematica's math engine. Is this groundless, or will you eventually run into problems getting correct, identical answers -- especially for answers that Mathematic derives symbolically? The capabilities and results of the computer algebra systems that I've used varied widely.
Mathematica gets incorrect answers quite frequently.
Re: Woxi: Wolfram Mathematica Reimplementation in Rust
#138Earlier quoted context omitted.
No I don’t, review your code
If I go by the contributor numbers on Github, I see Claude has committed something on the order of 300,000 lines of code. I don't think it's reasonable to review that much code, even in weeks worth of time.
I haven’t needed to do such a thing in a while, but my “rule” for explaining how unreasonable is to say “if I only glanced at each line of code for 1 second, without bothering to understand the details, it would take me 3 and a half full 24hr days non stop to simply look at”. So it’s definitely more than 1 work week because presumably other stuff is going to need to get done in that time too. Actually understanding it is going to be at least a multiple of that, and probably the multiple is ~30x.
Re: Woxi: Wolfram Mathematica Reimplementation in Rust
#139Earlier quoted context omitted.
What’s the difference if you review the code getting merged?
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.
eh with plenty of tests that I can easily read and are well documented I haven't actually ever found this to be a problem in practice