java-vs-go-decision

Java vs Go Decision

Overview

You write both Go and Java. The wrong choice is not a style preference — it fights the grain of the problem and the repository for the life of the code. Decide deliberately, at the start of the task, before writing anything.

Core principle: The repository's existing language wins by default. Only greenfield services or the analiz task's explicit direction open the choice.

The Decision

digraph decide {
    "Repo already single-stack?" [shape=diamond];
    "Follow the repo's language" [shape=box];
    "Analiz task names a language?" [shape=diamond];
    "Use it" [shape=box];
    "Task shape?" [shape=diamond];
    "Go" [shape=box];
    "Java (Quarkus first)" [shape=box];

    "Repo already single-stack?" -> "Follow the repo's language" [label="yes"];
    "Repo already single-stack?" -> "Analiz task names a language?" [label="no / greenfield"];
    "Analiz task names a language?" -> "Use it" [label="yes"];
    "Analiz task names a language?" -> "Task shape?" [label="no"];
    "Task shape?" -> "Go" [label="perf / concurrency / latency / simple service"];
    "Task shape?" -> "Java (Quarkus first)" [label="rich domain / OOP / heavy business rules"];
}

Choose Go when

• The task is performance-, throughput-, latency-, or concurrency-sensitive (high-QPS API, streaming, fan-out, background workers).
• The service is small and mostly I/O plumbing over a datastore.
• The repository is already Go — always.

Choose Java when

• The domain is rich: many entities, invariants, and business rules that benefit from OOP modelling and a mature type/framework ecosystem.
• The repository is already Java — always.
• The analiz task specifies Java.

Within Java: Quarkus first. Reach for Spring Boot only when Quarkus does not fit (a required library has no Quarkus extension, the team/repo standard is Spring, or the deployment target expects a Spring app). See quarkus-service-architecture and spring-boot-fallback.

Hard Rule