OffsetArrays.jl VS evcxr

Well, there is OffsetArrays in Julia, but it has acquired a reputation as a poison pill because most code assumes the 1-based indexing and it's easy to forget to convert the indexing and screw up the code.

Similar correctness issues are a big part of the reason that, several years ago, I submitted a series of pull requests to Julia so that its entire test suite would run without memory errors under Valgrind, save for a few that either (i) we understood and wrote suppressions for, or (ii) we did not understand and had open issues for. Unfortunately, no one ever integrated Valgrind into the CI system, so the test suite no longer fully runs under it, last time I checked. (The test suite took nearly a day to run under Valgrind on a fast desktop machine when it worked, so is infeasible for every pull request, but could be done periodically, e.g. once every few days.)

Even a revived effort on getting core Julia tests to pass under Valgrind would not do much to help catch correctness bugs due to composing different packages in the ecosystem. For that, running in testing with `--check-bounds=yes` is probably a better solution, and much quicker to execute as well. (see e.g. https://github.com/JuliaArrays/OffsetArrays.jl/issues/282)

You might be interested in OffsetArrays.jl.

Counting starts at one, as do most vector/matrix/tensor indices. If it bothers you too much, see OffsetArrays.jl and Arrays with custom indices.

No need for another version, Julia supports custom indices by default. Check out https://docs.julialang.org/en/v1/devdocs/offset-arrays/ and https://github.com/JuliaArrays/OffsetArrays.jl

Emacs didn't invent REPL, and it's common everywhere. For Rust: https://github.com/evcxr/evcxr/blob/main/evcxr_repl/README.m.... But heck, the compiler is reasonably fast enough that any IDE can REPL by compiling the code.

The value here is more in being able to read a script before you run it, then have it run fast, maybe tweaking something here and there. And a compiled script will run 10,000 times faster than LISP, which can be important.

https://github.com/evcxr/evcxr can run Rust in a Jupyter notebook. It's not Golang but close enough.

The engine uses rust_decimal::Decimal to represent high precision decimal numbers, like the weight property. Serialization of RocksDB keys is done by the storekey crate. To know how Yumi's machine stores diffs, we can now ask- How does storekey serialize rust_decimal? Well, using evcxr to run Rust in Jupyter, the answer is as a null-terminated string:

In theory you should be able to create Rust notebooks (Jupyter notebook) using evcxr so maybe some AI, data analysis, prototyping make sense if you aim for good performance in final application (protype in evcxr and use notebook as reference to implement final application in Rust for speed and safety).

You should check out evcxr

There is also implementations of rust REPLs, like the beautifully named evcxr.