The software development community is actively discussing the concept of unified language sets as a potential solution to the challenges of working with multiple programming languages across projects. This discussion stems from an article proposing a classification system for programming languages into four distinct levels based on their execution model and typing system, with a suggestion for a unified language set built around Rust.
The Multi-Language Development Problem
Modern software development often requires teams to work with multiple programming languages simultaneously, each serving different purposes within a project ecosystem. As one commenter pointed out, we tend to use languages from different levels in different settings (front end, back end, systems) and we spend an awful lot of time writing glue code to get them to talk to each other. This reality creates significant overhead in terms of interoperability, requiring extensive work on foreign function interfaces (FFI) and serialization/deserialization between language boundaries. The proposed language set approach aims to address this by creating a family of syntactically similar languages that can seamlessly work together while targeting different performance and ease-of-use requirements.
Existing Approaches and Alternatives
Several commenters highlighted existing ecosystems that already attempt to solve this problem. The Clojure ecosystem was mentioned as having very useful dialects with broad overlap across different environments, including ClojureScript for browsers, Clojure for JVM, Babashka for scripting, and Jank for C/C++ interoperability. Similarly, Dart was identified as a language that has a JIT and can startup pretty quickly and interpret on the fly while also being able to ahead-of-time compile to efficient machine code when you're ready to ship, effectively bridging the proposed levels 2 and 3.
The Case Against Forced Unification
Not all community members were enthusiastic about the unified language approach. Some argued that domain-specific languages provide important benefits that shouldn't be sacrificed for syntactic uniformity:
Especially with LLMs to assist we don't gain much anymore from making everything one syntax, one language, etc. Projects like Dotnet Blazor/ASP.NET or Python Streamlit/Dash IMO are forced and are more trouble than they're worth. The OP suggestion, where everything is Rust, has the same problem; it's too forced.
This perspective suggests that embracing specialized languages may be more productive than attempting to create a one-size-fits-all solution, particularly as tools like large language models increasingly help developers work across different syntaxes.
Programming Language Classification Levels
- Level 4: Interpreted, dynamically typed (JavaScript, Python, PHP)
- Level 3: Interpreted, statically typed (Hack, Flow, TypeScript, mypy)
- Level 2: Compiled with automatic memory management (Go, Java, C, Haskell, Objective-C, Swift)
- Level 1: Compiled with manual memory management (Rust, C, C++)
Proposed Language Set
- Rust: Level 1 - Maximum performance with manual memory management
- RustGC: Level 2/3 hybrid - Garbage collected with compilation for deployment
- RustScript: Level 4 - Dynamic typing for rapid prototyping
Technical Feasibility and Direction
An interesting technical insight from the discussion involves the directionality of language compatibility. One commenter noted that it's easier to interpret a constrained language than to compile a dynamic language designed with an interpreter in mind. This suggests that starting with a lower-level language like Rust and building higher-level variants (as proposed with RustGC and RustScript) may be more feasible than trying to make a language like JavaScript or Python more compilable.
The community also discussed the potential of adding automatic garbage collection to Rust, with one commenter expressing strong support while acknowledging that RustGC code wouldn't be trivial to convert to traditional Rust. But going in the opposite direction should be trivial.
The discussion around language sets reflects broader tensions in software development between standardization and specialization. While a unified approach could reduce the cognitive load and integration challenges of multi-language development, it may also sacrifice the domain-specific advantages that specialized languages provide. As development tools continue to evolve, particularly with AI assistance, the balance between these approaches may shift, potentially making cross-language development less burdensome without requiring syntactic uniformity.
Reference: From Languages to Language Sets