프로그래밍 언어, 대상 및 플랫폼에서

I started as a Java developer, but for some time now, I have broadened my horizons. Recently, I thought about how early languages were dedicated to a single target and platform, and now they are broadening their focus. In this post, I want to write down my thoughts in the hope that it may be useful to others, probably to my future self.

Definitions

You may have been wondering about the title terms. I’m pretty sure that if you read this post, you have a pretty good picture of what a programming language is. Some may disagree on some finer points or raise a hair-splitting one, but it’s not a PhD thesis, only a post on my blog. I must define what I mean by target and platform in the context of this post before going further.

Target
A target only makes sense in the context of compiled programming languages. For example, C’s target is native code, and Java’s is bytecode.

Platform
A platform is the system that will ultimately run the target. Native code runs on the operating system; bytecode on the JVM.

Early programming languages

Early programming languages had a single target and platform. I mentioned C and Java, but Ruby, Python, JavaScript, etc., were all the same.

Programming language Target Platform C Native code Operating system C++ Native code Operating system Java Bytecode JVM Python – Python runtime TypeScript JavaScript Browser & server-side JS JavaScript – Browser

I believe it was the case for a long time. It changed at some point, though.

Multi-target is the new black

The first time I heard about multi-target was in Scala. Scala came from the era of single-target and targeted bytecode on the JVM platform. However, in 2015, Martin Odersky announced Scala.js, which added JavaScript to Scala’s target.

The original article was published on InfoWorld, but it seems to have redirection issues nowadays. Here’s the introduction on a copy:

Scala, developed as a functional and object-oriented language for the JVM, is now multiplatform, with developers using it in abundance on JavaScript via Scala.js, Scala founder Martin Odersky says.

With Scala.js, developers write code in Scala, and the code is then compiled to JavaScript, analogous to using Microsoft’s TypeScript. Developers can leverage their Scala skills in Web development. “[Scala is] very popular on JavaScript now,” Odersky said at the Scala Days conference in San Francisco.

—- Scala.js lets you compile Scala to JavaScript

While Scala was the first I had heard about, other languages started to target JavaScript: I know at least Kotlin and Clojure, two originally JVM-bound languages. From that point on, it seemed every language started to add more targets. When they didn’t, third parties tried to do it.

I believe that Kotlin was the epitome of such a strategy. It started with JavaScript, but the team later added native with LLVM and is currently working on WebAssembly, as far as I know. Java developers weren’t left behind. The GraalVM project, managed by Oracle, allows them to generate native code. A third-party project, TeaVM, targets JavaScript and WebAssembly. It seems that nowadays lots of languages target Wasm.

Here’s a small excerpt of languages and what targets and platforms they support at the time of this writing. It can’t be exhaustive and obviously focuses on the JVM ecosystem, which I happen to know better.

Programming language Native/supporting project Target Platform Java Native Bytecode JVM GraalVM Native code Desktop OS TeaVM JavaScript Browser WebAssembly Wasm runtime C – Kotlin Native Bytecode JVM JavaScript Browser Server-side runtimes Native Desktop OS iOS Android Dart Native JavaScript Browser WebAssembly Wasm runtime DartNative Native Desktop OS iOS Android Rust Native Native code Desktop OS Native via a target WebAssembly Wasm runtime rustc_codegen_jvm Bytecode JVM Zig Native Native code Desktop OS Zig and WebAssembly WebAssembly Wasm runtime Swift Native Native code Desktop OS ARM machine code Android SwiftWasm WebAssembly Wasm runtime Python Native Python runtime Desktop OS jythonc (archived) Bytecode JVM py2wasm WebAssembly Wasm runtime

Again, this is just a snapshot of projects I know at the time of this writing.

Discussion

Programming languages were initially focused on a single target and platform. With time, more and more languages broaden their horizon. It comes either as part of the language itself or is an effort from third parties.

It made sense so far. The bigger your organization’s investment in a programming language, the harder it is to pivot to another one. In that light, GraalVM’s native is a value proposition for Java-heavy organizations using Kubernetes. The JVM was meant for long-running tasks, while Kubernetes is built on the idea of stopping pods and starting new ones.

However, with the fast progress of AI, I wonder whether the trend will continue. Some might question the value. Instead of GraalVM’ifying existing Java applications, why not rewrite them directly in Rust, which natively compiles to machine code? This won’t happen for core applications at the beginning, but I expect some may experiment with peripheral ones. If the experience nets benefits in terms of resource usage, then it may gnaw at core apps.

I’m very interested in the next few years to understand whether I’m imagining things, or if it will be a complete upheaval of the landscape.

To go further:

• Scala.js lets you compile Scala to JavaScript
• GraalVM
• TeaVM
• DartNative
• rustc_codegen_jvm
• Zig and WebAssembly
• SwiftWasm

Originally published at A Java Geek on June 21st, 2026.