shadaj

You might enjoy my first ever blog post from ~10 years ago, when I first learned about distributed systems: https://www.shadaj.me/writing/romeo-juliet-and-reactive-prog...

You caught me! That's what my next post is about :)

Erlang (is great but) is still much closer to the static-location (Actors) paradigm than what I’m aspiring for. For example, if you have stateful calculations, they are typically implemented as isolated (static-location) loops that aren’t textually co-located with the message senders.

Stay tuned for the next blog post for one potential answer :) My PhD has been focused on this gap!

You caught us in our docs-writing week :) In the meantime, the Rustdoc for streams are fairly complete: https://hydro.run/rustdoc/hydro_lang/stream/struct.Stream

Flo lead-author here! This is spot on :) Flo aims to be a bit less opinionated than Timely in how the runtime should behave, so in particular we don't support the type of "time-traveling" computation that Timely needs when you have iterative computations on datasets with retractions.

This is also one of the core differences of Timely compared to DBSP, which uses a flat representation (z-sets) to store retractions rather than using versioned elements. This allows retractions to be propagated as just negative item counts which fits into the Flo model (and therefore Hydro).

Currently, Hydro is focused on networked applications, where most parallelism is across machines rather than within them. So there is some extra overhead if you want single-machine parallelism. It's something we definitely want to address in the future, via shared memory as you mentioned.

At POPL 2025 (last week!), an undergraduate working on Hydro presented a compiler that automatically compiles blocks of async-await code into Hydro dataflow. You can check out that (WIP, undocumented) compiler here: https://github.com/hydro-project/HydraulicLift

These code examples aren't fully documented yet (which is why we've not linked them in the documentation), but you can take a look at a (more-real) implementation of Paxos here: https://github.com/hydro-project/hydro/blob/main/hydro_test/.... We're also working on building more complex applications like a key-value store.

Hi, I'm one of the PhD students leading the work on Hydro!

DFIR is more of a middle-layer DSL that allows us (the high-level language developers) to re-structure your Rust code to make it more amenable to low-level optimizations like vectorization. Because DFIR operators (like map, filter, etc.) take in Rust closures, we can pass those through all the way from the high-level language to the final Rust binaries. So as a user, you never interact with DFIR.

PyO3 is the library that enables Python <-> Rust bindings, Maturin is a build tool for packaging PyO3 Rust libraries (which export Python APIs) as Python packages!

In principle, yes, you can use the `rust-sitter-tool` crate to generate the Tree Sitter JSON definition and then compile it to a standalone parser. The grammar is auto-generated though so it may be a bit trickier to integrate into other tooling? The general problem of exporting just the grammar is something that's been on my radar, but haven't had a chance to think through it too deeply yet.

Not yet, but this is something I've been investigating. The general plan is to have safe Rust bindings to the underlying Tree Sitter APIs used by custom scanners, and then have the Rust Sitter proc macro expose a Rust scanner as an `extern` function that the Tree Sitter runtime can call back to.

Yeah, definitely agree on WebAssembly! We have https://github.com/shadaj/tree-sitter-c2rust for running Tree Sitter on WASM via Rust, but definitely more potential in that direction. And very much agree on the error story needing work, right now it's mostly `panic`s everywhere and could definitely be improved with richer diagnostics.

We support optional elements by wrapping them in `Option<T>` (other annotations are applied to the contents of the option)! So you can define

  struct ... {
    ...
    #[rust_sitter::leaf(text = ",")
    _dangling_comma: Option<()>
  }

Yes! Right now, the main benefits are the ability to write grammar definitions that are quite close to the ideal AST structure (made possible by Tree Sitter's grammar format), and being able to embed the parser in many different applications (including WASM via https://github.com/shadaj/tree-sitter-c2rust). Rust Sitter also gives quite nice error diagnostics with spans thanks to Tree Sitter's recovery logic.

Fallible parsing is something I plan to implement in the very near future, by letting users wrap types in `Result` to mark them as an error boundary. Incremental parsing is a bit more difficult, since we'll need to add logic to know when an existing AST struct can be reused, but is on the roadmap.

Hi! Rust Sitter creator here, happy to answer any questions about the project and where it's going!

Katara author here, you're right! Katara is built on Metalift (https://github.com/metalift/metalift), which is a general purpose framework we've been building at Berkeley to abstract away the logic of analyzing the LLVM IR. The decision to use LLVM was exactly because it is the least-common-denominator for so so many languages, so we are excited to add official support for Rust and friends in the near future!

Hi there! ScalaPy is heavily influenced by Scala.js, especially features like static facades which have a similar purpose in both places. I'm hoping to bring even more features inspired by Scala.js, such as a py.native for facade method implementations that uses a macro to generate the underlying code.

I also just added an MIT license to the core and facade repositories.