Go or Rust for a backend? How to choose when you love both

A language isn’t chosen in the abstract. It’s chosen against constraints. Here is the project, and the four constraints that did all the work.

A mobile app, and its three audiences

The project is a native mobile app for iOS and Android. Its backend does what most backends do: authenticate, store, sync, notify. Nothing exotic, and that’s exactly what makes the choice interesting: neither Go nor Rust is ruled out from the start. This backend serves three audiences:

The app is by far the biggest consumer, and it talks over a mobile network that comes and goes. Keep this diagram in mind: it comes back in § 2.

Four constraints, each pulling its own way

Battery life is decided by the contract, not the language

Let’s pause on battery, because that’s where the most counterintuitive argument of this article hides. After each exchange, the cellular radio, one of the phone’s most power-hungry components, doesn’t go back to sleep right away: it stays awake for several seconds in case more data arrives (researchers call this the “tail”). Ten small, spaced-out requests therefore cost far more than a single one, even for the same volume:

Reread what battery asks of the backend: compact messages, few round trips, a reused connection, pushing rather than being polled. The backend’s language appears nowhere. What appears is the protocol. That’s why I chose the protocol before the language, and why that first choice weighed heavily on the second.

What the project is not

In an ADR, what you rule out matters as much as what you keep. Three “no”s weighed heavily:

If any of those three “no”s had been a “yes”, this article would probably have a different conclusion. I’ll show you which one in § 4, sliders included.

Before choosing the language, I had to choose how the app would talk to its server. At the time, I didn’t even think about it: I picked REST, as always. It was when I held it up against the constraints of § 1 that I started to have doubts.

The reflex: REST

I’ve used REST in almost every project, and that’s probably true for you too. The refresher fits in one picture:

Simple, universal, understood by every tool, from the browser to curl. But when I reread what battery asks of the backend, not a single box was ticked by default:

• Compact messages? JSON repeats every field name, in every message.
• A contract shared by the server and both apps? OpenAPI exists, but it’s optional, and often written after the fact.
• A server that tells you when something changes? By default, the app has to ask.

Nothing insurmountable: you can compress, generate clients, add a WebSocket. But each time, it’s one more brick to lay yourself, on both sides. So I wondered whether some protocol did all of this by design.

What I found next door

Two names kept coming up.

GraphQL mostly solved a problem of data shape, which I didn’t have. gRPC, I barely knew: I went to take a closer look.

gRPC in two minutes

gRPC comes from RPC, for Remote Procedure Call: instead of building an HTTP request, the app calls a function, and the server runs it. Everything starts from a contract, a .proto file, which describes the data and the functions in the same place:

syntax = "proto3";
package app.sync.v1;

// One file describes the whole contract: the data AND the calls.

// ── 1. The messages: the data exchanged, field by field ──
message SyncRequest {
  string device_id = 1;        // each field has a type…
  int64 since_version = 2;     // …and a number: the number travels, not the name
  repeated Change changes = 3; // a list of changes
}

message SyncResponse {
  int64 version = 1;
  repeated Change changes = 2;
}
// (Change, WatchRequest and Event are declared the same way.)

// ── 2. The service: the functions the app can call ──
service SyncService {
  // Send local changes and receive the server’s, in a single round trip.
  rpc Sync(SyncRequest) returns (SyncResponse);
  // While the app is in the foreground, the server pushes what changes.
  rpc Watch(WatchRequest) returns (stream Event);
}

From this single file, generators produce the code on each side:

At runtime, the app calls the function as if it were local. The generated code handles the network: a compact binary format, Protocol Buffers, over an HTTP/2 connection opened once.

What convinced me

It wasn’t the speed people attribute to gRPC that stopped me. It was the contract. A renamed field breaks the build, not production. And Protocol Buffers’ compatibility rules (you add fields, you never reuse a number) let the API evolve without breaking older versions of the app, which will stay installed for months on some phones.

It still had to face the constraints of § 1. First test, message size:

The rest fits in a table. On almost every row, gRPC does by design what REST asks you to add:

GraphQL kept one asset, the client’s freedom. But my problem was battery, and on that ground gRPC started several lengths ahead.

What gRPC costs

I’m wary of articles that present gRPC as a no-brainer. So I looked at the other side of the coin:

The real problem: browsers

That left the admin panel. It lives in a browser, and a browser doesn’t give JavaScript the control over HTTP/2 that gRPC needs: you have to go through gRPC-Web or the Connect protocol, with a proxy or a compatible server. Doable, but I wanted the right tool in each place, not one tool bent to fit everywhere.

And in a browser, the right tool is REST: readable JSON, curl to test, OpenAPI to document. Same conclusion for third-party services, which send their webhooks as JSON and will never speak our protobuf.

gRPC first, REST where it’s needed

That’s the answer I kept. Let’s go back to the diagram from § 1, with both protocols:

The app speaks gRPC: that’s almost all the traffic. REST keeps what speaks HTTP by nature: the browser, webhooks, and a few needs of the phones themselves, such as universal-link files or large file uploads.

gRPC, for the app

On the app side, the contract fits in the two calls of the .proto: Sync bundles everything into one round trip, Watch lets the server push. Their rhythm follows the app’s:

1. In the foregroundWatch is open

   The server pushes what changes. No more “anything new?” every thirty seconds.

2. In the backgroundThe system suspends the app

   The stream eventually closes. If something important comes up, a push notification (APNs, FCM) takes over.

3. Back in frontSync, then Watch

   A single round trip catches up on what was missed, and the stream resumes.

Why this mix weighs on the choice of language

This is where the protocol catches up with the language:

• gRPC is the core, so its ecosystem becomes criterion number one. Both languages have a gRPC library. The real question: is it official, complete, and will it still be the same in three years?
• REST is secondary and ordinary, so it barely separates them. Both languages serve JSON very well. It’s a criterion you check, not one that decides.
• One port, so the two must be married cleanly. One service to deploy, one certificate, one health check, one line on the bill: that’s the cost constraint talking. You need to serve gRPC and REST on the same address, without an extra proxy.

I’m not going to redo the comparison you find everywhere, with its benchmark tables and feature lists. Here’s what I look at, personally, when I compare two languages for a service that has to live a long time, and why.

What I don’t compare

What I compare

Same code, two philosophies

Nothing beats an example. Here’s the same business function in both languages: fetch a user’s profile, refusing deleted accounts.

func (s *Service) Profile(ctx context.Context, id string) (*Profile, error) {
	u, err := s.users.Get(ctx, id)
	if err != nil {
		return nil, fmt.Errorf("profile %s: %w", id, err)
	}
	if u.Status == StatusDeleted {
		return nil, ErrNotFound
	}
	// A new status added tomorrow?
	// Nothing will force me back here.
	return toProfile(u), nil
}

async fn profile(&self, id: UserId) -> Result<Profile, AppError> {
    let user = self.users.get(id).await?; // the error propagates
    match user.status {
        Status::Active => Ok(Profile::from(user)),
        Status::Deleted => Err(AppError::NotFound),
        // A new status added tomorrow?
        // The code won’t compile until
        // it’s handled here.
    }
}

The Go code is longer, and everything is in plain sight: every error, every return. A developer who has never written Go understands it by reading it. The Rust code is denser and safer: the error is typed, forgetting a case is impossible. But part of the work is elsewhere (converting errors into AppError, defined once and for all), and you have to know the language to see it.

Neither is “better”. Go optimizes for the person who reads the code without knowing it. Rust optimizes for the person who changes it six months later without remembering everything. Both are right; the question is which of these two people your project most needs to protect. And for me, a recent criterion tipped the answer.

You never write a backend with a language alone. You write it with a compiler, libraries, tools, habits and people. That’s the whole package I compared, criterion by criterion, with one simple question each time: which one best serves this project?

The summary, on one page

Seen this way, Go seems to win by a wide margin. That’s misleading: a table counts rows, it doesn’t weigh them. And that’s where the whole debate lies. If latency and modeling matter twice as much as the rest for you, the table no longer means anything. Hence the tool below.

With my weights, Go wins by about half a dozen points: a real lead, not a rout. Now check the box: a single criterion moving by one point, and the gap is halved. That, in one checkbox, is why the decision wasn’t easy. It’s also why I’ll revisit it.

Why Go

1. The best gRPC support, today

   That’s the reason that tipped the scales. gRPC is the heart of the backend, and grpc-go has been official, complete and stable for years, with the whole ecosystem around it. On the Rust side, the quality is there, but the reference library is changing hands. I didn’t want to build the core of the project on a transition.

2. Hiring, onboarding, handing over

   The team will grow. With Go, a good backend developer, whatever their original language, will be useful very quickly, and the codebase will stay readable by everyone, including whatever their AI assistant adds to it. A project doesn’t only live with those who started it: it lives with those who take it over.

3. A short feedback loop

   Compile, test, restart: in Go, it’s near-instant. Early in a product, you change your mind every day, and how fast you can be wrong and then fix it matters more than the speed of the binary.

4. A reduced attack surface

   TLS, cryptography, HTTP server, testing: the standard library covers the essentials. Fewer dependencies means less to audit and update, and fewer doors for a supply-chain attack. govulncheck does the rest.

5. Operations without surprises

   A static binary, a tiny image, cross-compilation with one environment variable, built-in profiling, and a compatibility promise that guarantees upgrades won’t turn into a project of their own. For a small team, that means less time on call.

6. Fast enough, and getting faster

   The service mostly waits on the database. For this profile, Go is more than fast enough, and its garbage collector improves with every release. “Fast enough” isn’t an excuse: it’s a criterion, provided you’ve checked it against your own load rather than a benchmark.

What I sacrifice, and how I compensate

I won’t pretend: by choosing Go, I give up things I really love in Rust. But a sacrifice you own can be compensated. Here, for each one, is what I put in place.

What would change my mind

A decision you can’t question isn’t a decision, it’s dogma. Here are the three events that would make me reopen this ADR:

• A service that really computes. If one day the critical path contains heavy processing (media, intensive cryptography, a real-time rules engine), that service will be written in Rust.
• A team that already speaks Rust. With two or three experienced Rust developers on the team, the hiring criterion collapses, and the weighing changes sides.
• A mature official gRPC crate in Rust. That’s the checkbox in the weighing. The day it’s stable and complete, the criterion that tipped everything becomes a tie.

There is no best language

I’ll say it plainly, because it’s the heart of this article: there is no best language. There are languages that make different bets. Go bets that simplicity scales with teams. Rust bets that rigor scales with systems. Both are right, and history has proven them right. The right question is never “which one is best?”, but “which of these two bets does my project need to win?”.

Had I been building a network proxy, a database, a game engine, embedded software or a WebAssembly module, I would have chosen Rust, without even opening an ADR. And, a small irony: if one day I want to share logic between the iOS and Android apps, inside the phone, it’s Rust I’ll turn to again, with tools like Mozilla’s UniFFI, which generate Swift and Kotlin bindings.

An architecture decision is only worth its implementation. Here’s how the pieces fit together, with the code that matters, and the pitfalls to know before diving in.

Overview: one port, two servers, one logic

The contract first

Everything starts from the .proto files, kept in a separate folder and versioned with the rest. I use Buf rather than protoc directly: a readable configuration to generate the Go code (and the apps’ code), a linter that enforces naming conventions, and above all breaking-change detection. That’s what protects older versions of the app installed on phones.

buf lint                                   # contract conventions
buf breaking --against '.git#branch=main'    # no breaking change against main
buf generate                               # Go code regenerated; the diff must be empty

Chi, for REST

For REST, I picked Chi, because it stays 100% net/http: its handlers and middlewares are the standard library’s, and it only adds what’s missing (route groups, sub-routers, proven middlewares), with no dependencies. Why Chi rather than Gin, Echo or Fiber? The comparison deserves an article of its own, and I’ll write one.

func NewRouter(svc *service.Service, auth *Auth) http.Handler {
	r := chi.NewRouter()
	r.Use(middleware.RequestID, middleware.Recoverer, middleware.Timeout(15*time.Second))

	r.Get("/healthz", healthz)                                         // the load balancer
	r.With(verifySignature).Post("/webhooks/{provider}", webhook(svc))   // third-party services
	r.With(auth.Mobile).Post("/mobile/v1/uploads", createUpload(svc)) // a presigned URL

	r.Route("/admin/api", func(r chi.Router) {                        // the admin panel
		r.Use(auth.Admin, httprate.LimitByIP(120, time.Minute))
		r.Get("/users", listUsers(svc))
		r.Post("/users/{id}/suspend", suspendUser(svc))
	})
	return r
}

One port: cmux

That leaves the piece that holds it all together, the diamond in the diagram above. cmux reads the start of each connection without consuming it, and hands it intact to the right server: gRPC if it carries content-type: application/grpc, HTTP otherwise. I chose it for a precise reason: it lets grpc-go use its own HTTP/2 transport, optimized for gRPC, whereas solutions that go through the standard HTTP server switch transports.

func main() {
	ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
	defer stop()

	svc := service.New(/* data access, configuration… */)
	auth := rest.NewAuth(/* keys, sessions… */)

	lis, err := net.Listen("tcp", ":8080")
	if err != nil {
		slog.Error("cannot listen", "err", err)
		os.Exit(1)
	}

	// One port, two servers: cmux reads the start of each connection and routes it.
	m := cmux.New(lis)
	grpcL := m.MatchWithWriters(
		cmux.HTTP2MatchHeaderFieldSendSettings("content-type", "application/grpc"),
	)
	httpL := m.Match(cmux.Any()) // everything else: REST

	grpcSrv := grpc.NewServer(
		grpc.ChainUnaryInterceptor(grpcapi.Recover, grpcapi.Auth, grpcapi.Log),
		grpc.KeepaliveEnforcementPolicy(keepalive.EnforcementPolicy{MinTime: 5 * time.Minute}),
	)
	grpcapi.Register(grpcSrv, svc)
	healthpb.RegisterHealthServer(grpcSrv, health.NewServer())

	var protos http.Protocols
	protos.SetHTTP1(true)
	protos.SetUnencryptedHTTP2(true) // Go 1.24+: HTTP/2 without TLS, behind the load balancer
	httpSrv := &http.Server{
		Handler:           rest.NewRouter(svc, auth),
		Protocols:         &protos,
		ReadHeaderTimeout: 5 * time.Second,
	}

	g, ctx := errgroup.WithContext(ctx)
	g.Go(func() error { return grpcSrv.Serve(grpcL) })
	g.Go(func() error { return ignoreClosed(httpSrv.Serve(httpL)) })
	g.Go(func() error { return ignoreClosed(m.Serve()) })
	g.Go(func() error {
		<-ctx.Done() // shutdown signal received, or one of the servers failed
		grpcSrv.GracefulStop()
		sctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
		defer cancel()
		err := httpSrv.Shutdown(sctx)
		m.Close()
		return err
	})
	if err := g.Wait(); err != nil {
		slog.Error("stopped on error", "err", err)
		os.Exit(1)
	}
}

// A server stopped on purpose is not an error.
func ignoreClosed(err error) error {
	if errors.Is(err, http.ErrServerClosed) || errors.Is(err, net.ErrClosed) || errors.Is(err, cmux.ErrListenerClosed) {
		return nil
	}
	return err
}

Pitfalls to know

Alternatives I ruled out (for now)

The tree and the image

backend/
├── proto/            # the contract: .proto, buf.yaml, buf.gen.yaml
├── gen/              # generated code, never edited by hand
├── cmd/server/       # main.go: one binary, one port
├── internal/
│   ├── service/      # business logic, no gRPC or HTTP
│   ├── grpcapi/      # gRPC → service adapters
│   ├── rest/         # Chi: admin, webhooks, mobile
│   └── store/        # data access
└── Dockerfile

FROM golang:1.26 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -trimpath \
    -ldflags="-s -w" -o /server ./cmd/server

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /server /server
EXPOSE 8080
ENTRYPOINT ["/server"]

The golden rule of this tree fits in one sentence: internal/service knows neither gRPC nor HTTP. Adapters translate protobuf messages and JSON requests into service calls, and service errors into gRPC or HTTP codes. That’s what lets you add a door, or close one, without touching the business logic. And it’s also what would make it possible, one day, to rewrite a service in Rust behind the same contract.

An honest ADR ends with its consequences, good and bad. It’s the section whoever wants to undo this decision one day will reread. Might as well make their job easier.

Your turn

I don’t claim to have the only right answer, just mine, for this project. Here are the questions I’m still asking myself. I’d love to read yours.