Scala 3 auf dem Server: Warum überhaupt?

Scala 3 auf dem Server zu verwenden, ist für viele immer noch eine Rechtfertigungsübung. Man muss erklären, warum man nicht einfach bei Java bleibt. Oder warum man sich nicht mit Kotlin begnügt. Oder warum eine Sprache mit stärkerer Ausdruckskraft auf der Serverseite angeblich mehr bringt als nur akademische Eleganz.

Für mich ist die Antwort deutlich einfacher: Ich benutze Scala 3 auf dem Server, weil ich dort Modelle bauen will, die präzise bleiben, auch wenn das System wächst. Nicht alles in einem Serverprojekt ist komplex. Aber genau die Stellen, die komplex werden, profitieren von einer Sprache, die nicht nur Syntax liefert, sondern Form.

Der wichtigste Punkt ist nicht Kürze. Der wichtigste Punkt ist Struktur. Scala 3 zwingt mich nicht dazu, alles als bloße Java-Beans und Service-Klassen zu denken. Es erlaubt mir, technische Integrationen pragmatisch zu halten und gleichzeitig an den Stellen, an denen Fachlichkeit wichtig wird, präziser zu formulieren.

Man sieht das schon an einer scheinbar kleinen Stelle wie dem Routing im Frontend-Teil dieses Projekts. Die Seite /blog wird nicht einfach mit einer großen, undurchsichtigen App-Komposition geladen. Stattdessen ist klar sichtbar, was zur Route gehört, welcher Query-State aufgebaut wird und wann asynchron geladen wird.

private def initBlogPostsPage(): Future[Route.Factory] = {
  val searchQuery = Property("")
  var tableLinks = Seq.empty[app.domain.core.Link]
  val postsProperty = RemoteTableList.create[Data[BlogPost]](pageSize = blogPostsPageSize) { query =>
    BlogPost
      .list(
        query.index,
        query.limit,
        query = searchQuery.get,
        sorting = query.effectiveSortSpecs(Seq("publishedAt:desc", "created:desc"))
      )
      .map { table =>
        tableLinks = table.links.toSeq
        table
      }
  }

  RemoteTableList.reloadFirstPage(postsProperty, pageSize = blogPostsPageSize).map { _ =>
    Route.factory {
      BlogPostsPage(postsProperty, searchQuery, tableLinks)
    }
  }
}

Das ist kein heroisches Beispiel für funktionale Programmierung. Es ist etwas viel Wichtigeres: lesbarer Server- und UI-Code ohne unnötige Aufblähung. Scala 3 hilft hier nicht, weil sie exotisch ist. Sie hilft, weil sie genau genug ist, um Zustand, Asynchronität und Modellgrenzen klar zu halten.

Auf dem Server wird das noch deutlicher. Wenn ich Fachobjekte wie BlogPost modelliere, will ich nicht dauernd zwischen „eigentlich fachlich“ und „eigentlich nur technische DTO-Hülle“ hin- und herspringen. Ich will ein Modell, das seine Regeln sichtbar trägt.

@JsonbProperty
@NotBlank
@Size(min = 3, max = 220)
@Pattern(regexp = "^[a-z0-9]+(?:-[a-z0-9]+)*$")
@Column(nullable = false, unique = true, length = 220)
var slug: String = uninitialized

@JsonbProperty
@Enumerated(EnumType.STRING)
@Column(nullable = false, length = 24)
var status: BlogPostStatus = BlogPostStatus.DRAFT

Natürlich ließe sich das auch in Java schreiben. Die Frage ist nicht, ob es möglich ist. Die Frage ist, wie gut der Rest des Systems damit weiterarbeiten kann. Scala 3 gibt mir einen Werkzeugkasten, der von kleinen Hilfsfunktionen bis zu stärkeren Modellierungsformen reicht, ohne dass ich jedes Mal den Stil des ganzen Projekts wechseln muss.

Der zweite Grund ist Nüchternheit. Scala 3 ist für mich kein Bekenntnis gegen die JVM-Welt, sondern eine gute Sprache innerhalb der JVM-Welt. Ich kombiniere sie hier bewusst mit Jakarta-Standards, JPA, Validation, RESTEasy und einem expliziten Build. Gerade diese Kombination ist mir wichtig. Scala 3 ersetzt nicht die Plattform. Sie schärft nur die Art, wie ich mich auf ihr bewege.

Der dritte Grund ist Langfristigkeit. Architektur scheitert selten daran, dass eine Sprache zu wenig Features hatte. Sie scheitert daran, dass ein Codebestand seine Form verliert. Wenn alles technisch irgendwie möglich ist, aber fachlich immer unklarer wird, entsteht Reibung. Scala 3 ist für mich ein Mittel gegen diese Erosion. Nicht automatisch. Nicht magisch. Aber spürbar.

Ich will auf dem Server keine Sprache, die mich zu viel reden lässt, wenn das Modell schon klar ist. Ich will aber auch keine Sprache, die mich zwingt, Präzision in Boilerplate zu verstecken. Scala 3 liegt für mich genau zwischen diesen beiden Extremen.

Am Ende ist die eigentliche Frage also nicht: Warum Scala 3 auf dem Server? Die interessantere Frage ist: Warum sollte ich auf der Serverseite absichtlich mit einem stumpferen Werkzeug arbeiten, wenn mir Präzision, Modellklarheit und ruhige Architektur wichtig sind?

Für mich gibt es darauf keine überzeugende Antwort. Deshalb läuft dieser Blog auf Scala 3.