Go to Rust calls with Apache Arrow datatypes.

Last update: Nov 14, 2023

Related tags

Overview

🔎 Overview

alloy is a standalone Go module that enables calls to Rust code with Apache Arrow datatypes through its defined C data interface.

The overarching goal is to enable calls between languages through an underlying C interface, in this case utilizing cgo and the Rust ffi. This implementation comes with no overhead due to using the Apache Arrow data format.

The only data sent between the language binaries are raw pointers referencing the allocated memory and associated schemas. This allows for fast, (somewhat) robust, and colorful use cases in data engineering scenarios.

📦 Installation

To use the Go module, simply include it in your import with path name github.com/firelink-data/alloy/alloy-go. If you want to install any Go binary utilizing alloy, you need to enable cgo compilation by setting CGO_ENABLED=0.

To add the static Rust crate to your own Rust code, you can use the cargo package manager:

$ cargo add alloy-rs

🚀 Example usage

The example file examples/main.go should envision how your Go application could utilize alloy to call Rust code with Apache Arrow parameters.

Show example code

package main

import (
    "fmt"
    "github.com/firelink-data/alloy/alloy-go"
)

func main() {
    fmt.Println("Hello from Go!");

    alloy.InitLogging();
    alloy.TestLogging("Hello Rust, sent from Golang!");

    ...

    fmt.Println("Goodbye from Go!");
}

📋 License

All code written by Firelink Data is to be held under a general MIT license, please see LICENSE for specific information.

Any other code included in this repository is to be held under its respective license(s).

The new, performant, and simplified version of Holochain on Rust (sometimes called Holochain RSM for Refactored State Model)

Holochain License: This repository contains the core Holochain libraries and binaries. This is the most recent and well maintained version of Holochai

741 Jan 5, 2023

Comments

Setup Rust and Golang CI, and Golang tests

Currently we have only unit testing workflow for alloy-rs, we should have full CI (format, lint, testing) for both alloy-go and alloy-rs.

These can be implemented in separate workflow files, based on language? Or just create on huge CI file which takes care of both alloy-go and alloy-rs? @Ignalina thoughts?

I think separating is easier implementation wise, but will spawn a lot of github actions jobs when using different os and toolchain strategies!
enhancement devops discussion

opened by wilhelmagren 1