scale-benchmarks VS frpc-go

If you'd like a more apples-to-apples comparison you can run the benchmarks here: https://github.com/loopholelabs/scale-benchmarks/blob/master/regex/main_test.go

Our example is Rust regex vs Go regex: using Rust regex inside of a Scale Function significantly outperformed using Go's regex natively. If you're interested, you can check out the benchmarks we wrote here.

3. Calling mkswap, swapon and swapoff, which enables paging out to the block device provided by the NBD client and thus to the connected remote fRPC backend.

Its mostly intended as a tech demo for go-nbd[2] and the WIP r3map[3] library (efficient distributed mmap with mounting and migration support), and just as a fun experiment in general.

[1] https://frpc.io/

We're currently working on a couple of different projects, but everything we've launched so far (fRPC and Scale) is FOSS.

Hey everyone,

Founder of Loophole Labs here!

The team and I are happy to answer any questions you might have about fRPC, Frisbee, or Loophole in general!

We wrote fRPC because we really liked the DevX and tooling around the proto3 syntax, but we needed the generated code to be significantly more performant than what gRPC provides.

We also needed the ability to extend the RPC framework with other messaging patterns (like pub/sub) and we needed to be able to reuse the underlying TCP connections as required.

Today, fRPC can outperform gRPC by more than 4x, doing more than 2 million RPCs/second on a single node.

You can check out our docs site at https://frpc.io, or check out the repo at https://github.com/loopholelabs/frpc-go

We wrote fRPC because we really liked the DevX and tooling around the proto3 syntax, but we needed the generated code to be significantly more performant than what gRPC provides.

We also needed the ability to extend the RPC framework with other messaging patterns (like pub/sub) and we needed to be able to reuse the underlying TCP connections as required.

There's no way to do this with gRPC (or any other RPC framework that I'm aware of), and so fRPC was born!

As for streaming, it's not only planned (you can check out our roadmap here: https://frpc.io/getting-started/roadmap), but we've already got a PR open for it (https://github.com/loopholelabs/frpc-go/pull/2). Just need to work out a few more bugs before we merge.