Go vs Java: simplicidad frente a ecosistema enterprise

Llevo años trabajando con Java y Spring Boot en entornos enterprise. Proyectos con decenas de módulos, pipelines de CI que tardan quince minutos, servicios que necesitan 512 MB de RAM solo para arrancar y servir un endpoint de health check. Java funciona, no digo que no. Pero cuando empecé a escribir servicios en Go, la sensación fue parecida a quitarte una mochila de veinte kilos que no sabías que llevabas. No todo es mejor en Go --- hay cosas donde Java sigue siendo imbatible --- pero la diferencia en ciertos escenarios es tan grande que merece una comparación honesta.

Este artículo no es un “Go bueno, Java malo”. Es lo que he visto al usar ambos en producción, con sus ventajas reales y sus fricciones reales.

Dos filosofías opuestas

Java nació en los 90 con la promesa de “write once, run anywhere” y una apuesta fuerte por la orientación a objetos. Con el tiempo, el ecosistema Java se convirtió en sinónimo de enterprise: frameworks enormes, patrones de diseño por capas, configuraciones XML que mutaron a anotaciones, y una cultura donde abstraer es casi siempre la respuesta. No digo que eso sea malo --- hay una razón por la que medio mundo corporativo funciona con Java --- pero sí tiene consecuencias.

Go nació en 2009 dentro de Google con un objetivo muy distinto: resolver problemas de ingeniería de sistemas a escala, con un lenguaje simple que cualquier persona del equipo pudiera leer y entender. No hay herencia, no hay excepciones, no hay genéricos (bueno, ahora sí, pero limitados), no hay magia. La filosofía es: menos features, menos ambigüedad, menos sorpresas.

En Java, la pregunta habitual es “¿qué patrón aplico?”. En Go, es “¿cuál es la forma más directa de resolver esto?”.

Esto no es solo una diferencia estética, y creo que mucha gente lo subestima. Afecta a cómo estructuras proyectos, cómo onboardeas a gente nueva, cómo depuras problemas a las 3 de la mañana y cuánto código tienes que mantener.

Si vienes de Java y estás considerando Go, te recomiendo empezar por una visión general de qué es Go y por qué existe antes de seguir con la comparación.

Estructura de proyecto: Maven/Gradle vs go mod

Un proyecto típico de Spring Boot con Maven o Gradle tiene una estructura que ya conoces si has tocado Java enterprise:

my-service/
├── pom.xml (o build.gradle.kts)
├── src/
│   ├── main/
│   │   ├── java/com/empresa/servicio/
│   │   │   ├── controller/
│   │   │   ├── service/
│   │   │   ├── repository/
│   │   │   ├── model/
│   │   │   ├── dto/
│   │   │   ├── config/
│   │   │   ├── exception/
│   │   │   └── Application.java
│   │   └── resources/
│   │       ├── application.yml
│   │       └── db/migration/
│   └── test/
│       └── java/com/empresa/servicio/
└── docker/

Un proyecto equivalente en Go:

my-service/
├── go.mod
├── go.sum
├── main.go
├── handler/
│   └── user.go
├── service/
│   └── user.go
├── repository/
│   └── user.go
├── model/
│   └── user.go
└── main_test.go

La diferencia salta a la vista. En Java, la estructura está dictada por convenciones del framework (Spring), del build tool (Maven/Gradle) y de la JVM (el classpath). En Go, la estructura es tuya. No hay convención obligatoria más allá de tener un go.mod y que el paquete main tenga una función main(). Eso puede ser liberador o caótico, dependiendo de la disciplina del equipo. Y siendo honestos, he visto proyectos Go tan desorganizados como cualquier monolito Java mal planteado.

Gestión de dependencias

Maven y Gradle son herramientas potentes, pero tienen una curva de aprendizaje considerable. Resolver conflictos de dependencias transitivas en Maven es un arte oscuro que nadie disfruta. Gradle con Kotlin DSL mejora las cosas, pero sigue siendo un sistema de build complejo que a veces sientes que necesita su propio equipo de mantenimiento.

En Go:

go mod init github.com/usuario/mi-servicio
go get github.com/gin-gonic/gin

Ya está. El fichero go.mod declara tus dependencias, go.sum las verifica, y go mod tidy limpia lo que no uses. No hay plugins, no hay BOMs, no hay dependencyManagement. Si quieres profundizar en cómo organizar un proyecto Go de verdad, tengo un artículo sobre arquitectura limpia en Go que entra en detalle.

Servicios backend: Spring Boot vs net/http y Gin

Pero dejemos la estructura de proyecto y vayamos a lo que importa de verdad: escribir servicios. Aquí es donde la diferencia se nota. Vamos con un ejemplo concreto: un endpoint REST que devuelve un usuario por ID.

Spring Boot (Java)

@RestController
@RequestMapping("/api/users")
public class UserController {

    private final UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }

    @GetMapping("/{id}")
    public ResponseEntity<UserDto> getUser(@PathVariable Long id) {
        return userService.findById(id)
            .map(ResponseEntity::ok)
            .orElse(ResponseEntity.notFound().build());
    }
}

@Service
public class UserService {

    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public Optional<UserDto> findById(Long id) {
        return userRepository.findById(id)
            .map(this::toDto);
    }

    private UserDto toDto(User user) {
        return new UserDto(user.getId(), user.getName(), user.getEmail());
    }
}

public interface UserRepository extends JpaRepository<User, Long> {}

Para que esto funcione necesitas: Spring Boot Starter Web, Spring Data JPA, una base de datos configurada en application.yml, anotaciones de entidad JPA en User, y una clase Application con @SpringBootApplication. El framework hace mucha magia por ti, pero es magia.

Go con Gin

package main

import (
    "net/http"
    "strconv"

    "github.com/gin-gonic/gin"
)

type User struct {
    ID    int64  `json:"id"`
    Name  string `json:"name"`
    Email string `json:"email"`
}

func main() {
    r := gin.Default()
    r.GET("/api/users/:id", getUser)
    r.Run(":8080")
}

func getUser(c *gin.Context) {
    id, err := strconv.ParseInt(c.Param("id"), 10, 64)
    if err != nil {
        c.JSON(http.StatusBadRequest, gin.H{"error": "invalid id"})
        return
    }

    user, err := findUserByID(id)
    if err != nil {
        c.JSON(http.StatusNotFound, gin.H{"error": "user not found"})
        return
    }

    c.JSON(http.StatusOK, user)
}

En Go, lo que ves es lo que hay. No hay inyección de dependencias automática, no hay proxies, no hay classpath scanning. El flujo es explícito: entra una request, parseas parámetros, llamas a tu lógica, devuelves una respuesta. Si algo falla, lo manejas ahí mismo. ¿Es más tedioso? Sin duda. Pero cuando algo se rompe a las 3 de la mañana, saber exactamente dónde mirar tiene un valor que no aparece en los benchmarks.

En Spring Boot, a menudo necesitas entender tres capas de abstracción para depurar un error. En Go, el stack trace te lleva directamente a la línea del problema.

Sin framework también funciona

Una cosa que en Java sería impensable --- escribir un servicio HTTP sin framework --- en Go es perfectamente viable:

package main

import (
    "encoding/json"
    "net/http"
)

func main() {
    http.HandleFunc("/api/health", func(w http.ResponseWriter, r *http.Request) {
        json.NewEncoder(w).Encode(map[string]string{"status": "ok"})
    })
    http.ListenAndServe(":8080", nil)
}

Esto compila, se ejecuta y sirve JSON. Sin dependencias externas. El paquete net/http de la librería estándar de Go es lo bastante bueno para muchos servicios reales. Intenta hacer lo mismo en Java puro, sin Spring, sin Javalin, sin nada: acabas reinventando medio framework.

Microservicios: donde Go brilla con fuerza

Este es probablemente el escenario donde la diferencia entre Go y Java se hace más evidente. Y la pregunta interesante no es solo de rendimiento, sino de operaciones.

Arranque y consumo de recursos

Cuando tienes 3 servicios, estas diferencias son anecdóticas. Cuando tienes 30 o 50, se convierten en factura de cloud, en tiempo de despliegue, en velocidad de scaling.

El Dockerfile lo dice todo

Java (Spring Boot):

FROM eclipse-temurin:21-jre-alpine
COPY target/my-service.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Go:

FROM golang:1.22 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o server .

FROM scratch
COPY --from=builder /app/server /server
EXPOSE 8080
ENTRYPOINT ["/server"]

El binario de Go es autocontenido. No necesita runtime, no necesita JVM, no necesita sistema operativo completo. Puedes usar scratch como imagen base --- literalmente un contenedor vacío con tu binario dentro. Esto tiene implicaciones de seguridad (menos superficie de ataque) y de operaciones (menos que puede romperse).

Para una visión más completa de Go en entornos cloud native y microservicios, tengo un artículo dedicado sobre microservicios con Go que entra en más detalle.

Rendimiento y uso de recursos

La conversación sobre rendimiento entre Java y Go tiene matices que muchos benchmarks ignoran. Y creo que esta es la parte que más conviene separar del ruido habitual.

JVM: potente pero con precio

La JVM es una maravilla de ingeniería. El JIT compiler optimiza código en caliente, el garbage collector ha mejorado enormemente (ZGC, Shenandoah), y para cargas de trabajo long-running con patrones predecibles, Java puede ser extremadamente rápido.

Pero ese rendimiento tiene un coste:

• Warmup: La JVM necesita tiempo para compilar el bytecode a código nativo. Los primeros miles de requests de un servicio recién arrancado son más lentos.
• Memoria base: El propio runtime de la JVM, las clases cargadas, el metaspace… todo suma antes de que tu código haga nada.
• GC pauses: Aunque los GC modernos son mucho mejores, siguen existiendo y siguen afectando a la latencia p99.

GraalVM Native Image intenta resolver esto compilando Java a binario nativo, y la idea es prometedora. Pero en la práctica añade complejidad, tiempos de compilación largos y restricciones en reflection y proxies dinámicos --- justo lo que Spring Boot usa intensivamente. Es una de esas soluciones que te entusiasma en la demo y luego te complica la vida en producción.

Go: predecible y ligero

Go compila a código nativo directamente. No hay warmup, no hay JIT, no hay bytecode intermedio. El rendimiento que ves en la primera request es esencialmente el mismo que verás en la millonésima.

// Un servidor HTTP en Go arranca y está listo en milisegundos
// No hay "cold start" más allá de lo que tarde tu código de inicialización
func main() {
    db := connectDB()
    defer db.Close()

    router := setupRoutes(db)
    log.Println("Server ready on :8080")
    http.ListenAndServe(":8080", router)
}

El garbage collector de Go es simple comparado con los de la JVM: prioriza latencia baja sobre throughput máximo. Para servicios que necesitan latencia predecible, esto es una ventaja real.

No es que Go sea “más rápido” que Java en todos los escenarios. Es que Go es más predecible y más barato de operar, especialmente cuando tienes muchos servicios pequeños.

Ecosistema: gigante enterprise vs librería estándar enfocada

Y aquí llegamos al punto donde tengo que ser justo con Java. Porque aquí es donde Java gana sin discusión. El ecosistema Java es probablemente el más grande y maduro del mundo del backend.

Lo que Java te da

• Spring Framework: Inyección de dependencias, AOP, transacciones, security, batch, integration, cloud… hay un starter para casi todo.
• JPA/Hibernate: ORM maduro con años de optimización.
• Librerías para todo: Apache Commons, Guava, Jackson, MapStruct, Lombok…
• Herramientas de observabilidad: Micrometer, Spring Actuator, integración nativa con Prometheus, Grafana, etc.
• Soporte empresarial: Red Hat, VMware (Broadcom), Oracle… hay empresas que te venden soporte y SLAs.

Lo que Go te da

• Librería estándar potente: net/http, encoding/json, database/sql, testing, crypto… para muchos servicios no necesitas nada más.
• Librerías enfocadas: Gin, Echo (routers), sqlx (SQL), pgx (PostgreSQL), zap (logging), cobra (CLIs).
• Menos opciones, menos parálisis: En Java, para hacer HTTP tienes RestTemplate, WebClient, Feign, OkHttp, Apache HttpClient… En Go, tienes http.Client de la stdlib. Funciona bien. Siguiente problema.

La diferencia filosófica es clara: Java te da un ecosistema donde puedes encontrar una solución prefabricada para casi cualquier problema. Go te da herramientas básicas sólidas y espera que construyas lo que necesites. Ninguno de los dos enfoques es universalmente mejor, pero sí cambian radicalmente cómo se siente el día a día de un proyecto.

¿Cuándo importa el ecosistema?

Si estás construyendo un sistema con autenticación OAuth2, integración con Active Directory, transacciones distribuidas, batch processing, y reporting --- el ecosistema de Spring te ahorra meses de trabajo. Esas son soluciones maduras, probadas, con documentación extensa.

Si estás construyendo un servicio que recibe requests, procesa datos y responde JSON, la librería estándar de Go más una o dos dependencias te dan todo lo que necesitas con menos complejidad.

Manejo de errores: excepciones vs errores explícitos

Esta es una de las diferencias que más choca cuando vienes de Java. Y es una de las que más dividen opiniones. Voy a intentar ser justo con ambos enfoques, aunque confieso que mi opinión ha ido cambiando con el tiempo.

Java: excepciones

public User findById(Long id) {
    return userRepository.findById(id)
        .orElseThrow(() -> new UserNotFoundException("User not found: " + id));
}

// En algún lugar del controller o un @ControllerAdvice
@ExceptionHandler(UserNotFoundException.class)
public ResponseEntity<ErrorResponse> handleNotFound(UserNotFoundException ex) {
    return ResponseEntity.status(404).body(new ErrorResponse(ex.getMessage()));
}

El modelo de excepciones te permite separar el flujo normal del manejo de errores. En teoría, eso suena bien. El problema es que las excepciones son invisibles en la firma del método (salvo checked exceptions, que nadie usa ya). Puedes llamar a un método sin saber que puede lanzar cinco excepciones distintas. Y eso, cuando lo descubres en producción, duele.

Go: errores como valores

func findUserByID(id int64) (*User, error) {
    user, err := db.QueryRow("SELECT id, name, email FROM users WHERE id = $1", id)
    if err != nil {
        if errors.Is(err, sql.ErrNoRows) {
            return nil, fmt.Errorf("user not found: %d", id)
        }
        return nil, fmt.Errorf("querying user %d: %w", id, err)
    }
    return user, nil
}

En Go, los errores son valores que se devuelven como parte del resultado de una función. No hay excepciones (bueno, hay panic, pero usarlo para control de flujo está mal visto). El resultado es que cada llamada a una función que puede fallar te obliga a decidir qué hacer con el error.

Sí, el famoso if err != nil se repite mucho. Es verboso. Pero tiene una ventaja que aprendes a valorar con el tiempo: nunca hay errores ocultos. Cuando lees código Go, ves exactamente dónde puede fallar cada operación y qué se hace al respecto.

// Esto es Go idiomático: cada error se maneja en el punto donde ocurre
file, err := os.Open("config.json")
if err != nil {
    return fmt.Errorf("opening config: %w", err)
}
defer file.Close()

data, err := io.ReadAll(file)
if err != nil {
    return fmt.Errorf("reading config: %w", err)
}

var config Config
if err := json.Unmarshal(data, &config); err != nil {
    return fmt.Errorf("parsing config: %w", err)
}

El manejo de errores en Go es tedioso de escribir pero fácil de leer. En Java, es fácil de escribir pero peligroso de ignorar.

Testing: JUnit/Mockito vs testing estándar

Java con JUnit y Mockito

@ExtendWith(MockitoExtension.class)
class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    void shouldReturnUserWhenExists() {
        User user = new User(1L, "Roger", "roger@oshy.tech");
        when(userRepository.findById(1L)).thenReturn(Optional.of(user));

        Optional<UserDto> result = userService.findById(1L);

        assertTrue(result.isPresent());
        assertEquals("Roger", result.get().getName());
        verify(userRepository).findById(1L);
    }

    @Test
    void shouldReturnEmptyWhenNotExists() {
        when(userRepository.findById(99L)).thenReturn(Optional.empty());

        Optional<UserDto> result = userService.findById(99L);

        assertFalse(result.isPresent());
    }
}

JUnit 5 es un framework de testing maduro y potente. Mockito facilita crear mocks de dependencias. Pero necesitas dependencias externas, anotaciones para configurar el contexto, y la verbosidad de Java se nota también aquí.

Go con testing estándar

package service

import (
    "testing"
)

type mockUserRepo struct {
    users map[int64]*User
}

func (m *mockUserRepo) FindByID(id int64) (*User, error) {
    user, ok := m.users[id]
    if !ok {
        return nil, fmt.Errorf("user not found: %d", id)
    }
    return user, nil
}

func TestFindUserByID_Exists(t *testing.T) {
    repo := &mockUserRepo{
        users: map[int64]*User{
            1: {ID: 1, Name: "Roger", Email: "roger@oshy.tech"},
        },
    }
    svc := NewUserService(repo)

    user, err := svc.FindByID(1)

    if err != nil {
        t.Fatalf("unexpected error: %v", err)
    }
    if user.Name != "Roger" {
        t.Errorf("expected name Roger, got %s", user.Name)
    }
}

func TestFindUserByID_NotExists(t *testing.T) {
    repo := &mockUserRepo{users: map[int64]*User{}}
    svc := NewUserService(repo)

    _, err := svc.FindByID(99)

    if err == nil {
        t.Fatal("expected error, got nil")
    }
}

Go incluye el paquete testing en la librería estándar. No necesitas frameworks externos. Los mocks son structs que implementan interfaces --- no hay magia de reflection ni generación de proxies. Ejecutas tests con go test ./... y ya.

La diferencia en velocidad de ejecución de tests es dramática, y no lo digo a la ligera. Un test unitario en Go se ejecuta en milisegundos. Un test de Spring Boot que levanta el contexto de la aplicación puede tardar 10-30 segundos solo en arrancar. Parece poco, pero esos segundos acumulados cambian tu forma de trabajar: con feedback inmediato, testeas más. Con feedback lento, testeas lo justo.

Concurrencia: goroutines vs threads

No puedo comparar Go y Java sin hablar de concurrencia, porque es una de las mayores fortalezas de Go. Aunque la situación está cambiando con Java 21, y eso merece reconocerse.

Java: threads y el problema histórico

Java ha mejorado enormemente con Virtual Threads (Project Loom, disponible desde Java 21). Pero durante años, la concurrencia en Java significaba ExecutorService, CompletableFuture, synchronized, y mucho cuidado con el estado compartido.

ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();
List<Future<Result>> futures = urls.stream()
    .map(url -> executor.submit(() -> fetchUrl(url)))
    .toList();

for (Future<Result> future : futures) {
    Result result = future.get(); // puede lanzar excepciones
    process(result);
}

Virtual Threads son un paso enorme en la dirección correcta. Pero son relativamente nuevos, y muchas librerías y frameworks todavía están adaptándose.

Go: goroutines y channels desde el día uno

results := make(chan Result, len(urls))

for _, url := range urls {
    go func(u string) {
        result, err := fetchURL(u)
        if err != nil {
            results <- Result{Error: err}
            return
        }
        results <- result
    }(url)
}

for range urls {
    result := <-results
    if result.Error != nil {
        log.Printf("error: %v", result.Error)
        continue
    }
    process(result)
}

Las goroutines son parte del lenguaje, no del framework. Los channels son primitivas del lenguaje para comunicación entre goroutines. El runtime de Go multiplexea miles de goroutines sobre unos pocos threads del sistema operativo. Esto no es un add-on --- es cómo Go funciona por defecto.

Go no inventó la concurrencia, pero la hizo accesible. Lo que en Java requería conocer ExecutorService, CompletableFuture, y reactive streams, en Go es una goroutine y un channel.

Cuándo elegir Java

Java sigue siendo la mejor opción en muchos escenarios. Sería deshonesto no reconocerlo, y creo que este es el punto donde más artículos “Go vs Java” fallan: presentan a Java como un dinosaurio, cuando en realidad sigue evolucionando y resolviendo problemas reales:

• Dominios complejos con mucha lógica de negocio: Si tu servicio tiene reglas de negocio elaboradas, flujos transaccionales complejos, y un modelo de dominio rico, Java con Spring te da herramientas maduras para gestionar esa complejidad.
• Equipos grandes con experiencia en JVM: Si tu equipo tiene 10 desarrolladores Java y cero experiencia en Go, migrar tiene un coste real.
• Integración enterprise: SAP, Oracle, sistemas legacy, mensajería JMS, SOAP… el ecosistema Java tiene conectores para todo.
• Proyectos con Spring ya en producción: Reescribir un monolito Spring Boot en Go “porque sí” es una idea terrible. Itera sobre lo que funciona.
• Android: Aunque Kotlin domina, el ecosistema Android es JVM.

El factor equipo

Este punto es crucial y a menudo se ignora en las comparativas técnicas. Y quizás sea el más importante de todo este artículo. Si tu empresa tiene 50 desarrolladores Java, un pipeline de CI/CD optimizado para JVM, librerías internas en Java, y años de conocimiento acumulado, la productividad de ese equipo en Java va a ser mayor que en Go durante mucho tiempo. La tecnología no existe en el vacío, y la mejor decisión técnica que ignora al equipo suele ser una mala decisión.

Cuándo elegir Go

Dicho todo lo anterior, Go brilla especialmente en estos escenarios:

• Microservicios pequeños y enfocados: Servicios que hacen una cosa, la hacen bien, y necesitan ser ligeros y rápidos de desplegar.
• CLIs y herramientas de infraestructura: Docker, Kubernetes, Terraform, Hugo… están escritos en Go por una razón. Un binario estático que distribuyes sin dependencias es imbatible.
• Servicios con alta concurrencia: Proxies, API gateways, workers que procesan miles de conexiones simultáneas.
• Equipos que valoran la simplicidad: Si quieres que cualquier persona del equipo pueda entender cualquier parte del código sin conocer frameworks complejos.
• Cloud native y contenedores: Imágenes Docker mínimas, arranque instantáneo, bajo consumo de memoria. Tu factura de cloud te lo agradecerá.
• Proyectos nuevos sin deuda técnica Java: Si empiezas de cero y el dominio no requiere el ecosistema enterprise de Java, Go te permite avanzar rápido con menos complejidad.

La tabla final

Conclusión

No hay un ganador universal entre Go y Java. Y creo que quien te diga lo contrario o no ha trabajado con ambos en producción o está simplificando demasiado. Pero sí hay contextos donde cada uno es claramente superior.

Si estás en un entorno enterprise con equipos Java, Spring Boot funcionando en producción, y dominios de negocio complejos, Java sigue siendo una elección sólida. No necesitas cambiar por cambiar.

Si estás construyendo servicios nuevos, infraestructura, herramientas de línea de comandos, o cualquier cosa donde la simplicidad, el rendimiento predecible y el coste operativo bajo importen más que el tamaño del ecosistema, Go merece una oportunidad seria.

Mi experiencia personal: después de años con Spring Boot, escribir un servicio en Go se siente como conducir un coche manual después de haber conducido siempre uno automático con cien botones en el salpicadero. Tienes más control, menos intermediarios, y la sensación de que entiendes exactamente lo que está pasando en cada momento. No es para todo el mundo ni para todo proyecto, pero cuando encaja, encaja de verdad.

La mejor tecnología es la que tu equipo puede mantener, operar y evolucionar con confianza. A veces eso es Java. A veces es Go. Y a veces es ambos en el mismo sistema.

Si quieres empezar a explorar Go con una base práctica, echa un vistazo a la guía para aprender Go desde cero. Y si ya tienes algo de experiencia, el artículo sobre arquitectura limpia en Go te ayudará a estructurar proyectos reales.