Ferret is a declarative data automation language and embeddable Go runtime for structured extraction workflows, built for Go developers who need to query, transform, and synchronize structured data across browsers, APIs, databases, and documents from inside their own applications.

What it is

Ferret is a declarative-first, expression-oriented embedded language called FQL, paired with a runtime written in Go. FQL combines querying, transformation, synchronization, and structured results with host-defined values and capabilities, so an application can embed the runtime and decide exactly which functions, modules, data, and external operations a program is allowed to use. The language keeps a declarative core and adds domain-oriented orchestration plus constrained mutable state for automation that cannot be expressed as a pure data transformation. It is deliberately focused rather than a general-purpose scripting language. The project lives in the Go ecosystem as an importable module under github.com/MontFerret/ferret/v2, is licensed Apache-2.0, and is categorised under Data & Analytics / Data Extraction & Web Scraping. The branch described here carries the upcoming Ferret v2, currently in alpha; the stable v1 release lives on the v1 branch.

The concrete problem it solves is the pile of imperative glue that Go services accumulate when they need to pull structured data out of heterogeneous sources. Ferret replaces a general-purpose embedded scripting language plus hand-written orchestration with one unified query model covering browsers, APIs, databases, documents, and custom data sources. Capability-based host values let the embedding application expose its own objects, resources, and external systems to FQL directly, while managed resource lifecycle handles files, connections, cursors, and streams. The result is that extraction logic becomes a declarative program the host compiles once and runs many times, rather than a scatter of ad-hoc calls.

Key capabilities

• Declarative FQL language for querying, transforming, synchronizing, and automating structured data, with a constrained mutable state model for automation that is not a pure transformation.
• Embeddable Go runtime used through ferret.New(opts...), with a flow of compile query, create session, then run: eng.Compile(ctx, ferret.NewAnonymousSource(...)), plan.NewSession(ctx), session.Run(ctx).
• Reusable compiled plans and isolated execution sessions, so a program can be compiled once and executed repeatedly.
• Capability-based host values that expose application objects, resources, and external systems to FQL, with the host deciding which functions, modules, and operations a program may reach.
• Unified query model spanning browsers, APIs, databases, documents, and custom data sources, reflected in topics such as chrome-devtools-protocol, browser-automation, html, and data-extraction.
• Extensible runtime through namespaced functions, modules, hooks, and custom value types.
• Event-driven synchronization and dispatch for asynchronous and stateful resources, plus a bytecode VM and portable programs supporting precompiled artifacts.

Who uses it and how

• Go teams embedding an automation or extraction engine inside an existing service, where the host must control which host values and external operations each program can use.
• Existing Ferret v1 integrations migrating in two stages: first to the v2 compatibility API via the compat module, then incrementally to the native v2 API.
• Applications built on github.com/MontFerret/api, which use the official adapter package github.com/MontFerret/ferret/v2/uapi; uapi.New(opts...) creates and owns a native engine, while uapi.Wrap(native) borrows an existing one and its Close is a no-op.
• Workloads that benefit from precompiled artifacts and repeated execution through the bytecode VM rather than recompiling queries per run.
• Browser and HTML extraction workflows, given the project's browser-automation and Chrome DevTools Protocol topics.

Getting started

Install the module with go get github.com/MontFerret/ferret/v2@latest. New projects should use the native v2 API, while existing v1 integrations should start with the compat module, and the language can be tried in the browser playground linked from the README.

How it compares

No list of paid or proprietary products that Ferret replaces is provided in the available facts. Among similar tools, no directly comparable project is named either, so on the evidence here Ferret stands alone in this registry.

When to use it — and when not to

Ferret v2 is in alpha, so teams needing a stable target should stay on the v1 branch or plan a two-stage migration through the compat module before adopting the native API. Embedding it means operating a Go dependency and respecting a lifecycle contract: sessions and plans must be settled and closed before their owning runtime or borrowed engine. It is a poor fit for anyone wanting a general-purpose scripting language or a non-Go host, since it is intentionally narrow and its runtime is a Go library.

go get github.com/MontFerret/ferret/v2@latest

Engine -> compile query -> create session -> run

package main

import (
	"context"
	"fmt"
	"log"

	"github.com/MontFerret/ferret/v2"
)

func main() {
	ctx := context.Background()

	eng, err := ferret.New()
	if err != nil {
		log.Fatal(err)
	}
	defer eng.Close()

	plan, err := eng.Compile(ctx, ferret.NewAnonymousSource(`return 1 + 1`))
	if err != nil {
		log.Fatal(err)
	}
	defer plan.Close()

	session, err := plan.NewSession(ctx)
	if err != nil {
		log.Fatal(err)
	}
	defer session.Close()

	output, err := session.Run(ctx)
	if err != nil {
		log.Fatal(err)
	}

	fmt.Println(string(output.Content))
}

ferret migrate --dry-run # List the files that would change
ferret migrate --print   # Print a unified diff without changing files
ferret migrate           # Apply the migration