marker
evcxr
Our great sponsors
marker | evcxr | |
---|---|---|
2 | 75 | |
136 | 5,131 | |
5.9% | 2.2% | |
9.4 | 8.7 | |
3 months ago | 22 days ago | |
Rust | Rust | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
marker
-
Blog Post: Next Rust Compiler
Check out this, which aims to implement said stable interface!
-
1Password releases Typeshare, the "ultimate tool for synchronizing your type definitions between Rust and other languages for seamless FFI"
Hey, I might be able to give some input how I deal with it in [rust-linting](https://github.com/rust-linting/rust-linting). For some context, the project needs to load several dynamic libraries and provide each of them with an abstract syntax tree. Serializing and deserializing the types for every step would most likely be too expensive. That's why I opted for a Rust <-> Rust FFI. There are two parts of this: 1. The loaded libraries needed to accept data from a driver. For this, I generate functions in the library crates which are marked as `extern "C"` and only use FFI safe types. Passing information to the loaded crates then always calls the generated functions, which intern call access a thread local struct instance in the dynamic crate. It's important that the instance implement a specific trait. For the library creation, it seems like magic. 2. Callbacks. The loaded libraries need to pass information back to the driver. For this, I use a struct with function pointers. These are also marked as `extern "C"` and need to only use FFI safe types. The definition of FFI safe, is a bit difficult. Slices, `str`, `Option<>` and most of the rusts STD types don't have a stable layout to the point, that it can change between compilations with the same compiler. Therefore, it's required that each passed type is `#[repr(C)]`. Options are wrapped in an enum, which has `#[repr(C)]`, slices and strings are dismantled into a data pointer and a length. On the receiving and they're reconstructed again. A small warning. I'm not an expert on FFI interfaces. My implementation would probably have some problems with lifetimes, if I'd use a slightly different memory model. So far, this has worked well (Besides the required boilerplate). The project is currently sadly lacking documentation, as it's still under heavy development. If you want, feel free to lock around the code base. The stable types and most of the interface is inside the `linter_api` crate.
evcxr
-
Scriptisto: "Shebang interpreter" that enables writing scripts in compiled langs
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.
-
Go: What We Got Right, What We Got Wrong
https://github.com/evcxr/evcxr can run Rust in a Jupyter notebook. It's not Golang but close enough.
-
The Hallucinated Rows Incident
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:
- TermiC: Terminal C, Interactive C/C++ REPL shell created with BASH
- Exploring Options for Dynamic Code Changes in Rust without Recompilation (hot reloading)
- Go 1.21 will (likely) have a static toolchain on Linux
-
What’s an actual use case for Rust
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).
-
would you use rust for scripting?
You should check out evcxr
- Nannou – An open-source creative-coding framework for Rust
-
A Case for Rust in Deep Learning
I think you might like this project: https://github.com/google/evcxr . It brings the REPL workflow to Rust, so having fast iteration should not be an issue.
What are some alternatives?
vscode-jupyter - VS Code Jupyter extension
polars - Dataframes powered by a multithreaded, vectorized query engine, written in Rust
jupyter-rust - a docker container for jupyter notebooks for rust
rust-script - Run Rust files and expressions as scripts without any setup or compilation step.
bincode - A binary encoder / decoder implementation in Rust.
cargo-script - Cargo script subcommand
iron.nvim - Interactive Repl Over Neovim
vim-slime - A vim plugin to give you some slime. (Emacs)
ipython - Official repository for IPython itself. Other repos in the IPython organization contain things like the website, documentation builds, etc.
nsi - High level Rust bindings for Illumination Research’s Nodal Scene Interface – ɴsɪ.
rust-csv - A CSV parser for Rust, with Serde support.
rutie - “The Tie Between Ruby and Rust.”