DEV Community: Uy Trần

The Silent Convergence: Why Go, Rust, and Kotlin Are Headed in the Same Direction — And Why It Matters

Uy Trần — Mon, 08 Jun 2026 17:47:46 +0000

The Feeling

If you've spent years in Java or C# and recently picked up Rust or Kotlin, you know the feeling. It's not that the language is easy. It's that the room is suddenly decluttered.

No more public static final. No Map<String, List<User>> registry = new HashMap<String, List<User>>(). No semicolons demanding tribute at the end of every line.

I remember writing my first non-trivial Rust function. I kept double-checking. Is this really enough? Did I forget something? Compiler said no. Code ran. That weightlessness is real — and it's not a fad. It's the result of half a century of computer science slowly answering one question:

Who should do the hard work — the human, or the machine?

A Quick Detour: Why Old Syntax Felt Heavy

Before we dunk on Java and C, let's be fair. They were right for their time.

C (1972) ran on PDP-11s with kilobytes of RAM. Compilers had to be dumb-fast translators. Type inference lived only in academic papers.
Java (1995) was designed for massive enterprise teams. Explicit types weren't redundancy — they were built-in documentation.
C# (2000) inherited that "explicit is safer" ethos, then started evolving faster than Java.

What we call "boilerplate" today was called "self-documenting code" 25 years ago. Then three things changed:

Compilers got thousands of times smarter.
Hardware got absurdly cheap.
Developer time became the most expensive resource in the room.

That shift is the soil the next four pillars grew in.

Pillar 1: Type Inference — Let the Compiler Guess

The problem

// Java 6 — peak boilerplate
Map<String, List<User>> registry = new HashMap<String, List<User>>();

Same information, stated three times. The compiler already knew. You knew. So why the ceremony? Because early compilers weren't smart enough. They are now.

The evolution

// Java 7 (2011) — diamond operator
Map<String, List<User>> registry = new HashMap<>();

// Java 10+ (2018) — var, finally
var registry = new HashMap<String, List<User>>();

// Go — := does declaration + inference in one stroke
registry := make(map[string][]User)

// Kotlin — val vs var distinguishes immutability
val registry = hashMapOf<String, List<User>>()

// Rust — often no type annotation at all
let mut registry = HashMap::new();
registry.insert("alice".to_string(), vec![user1]);
// Compiler infers HashMap<String, Vec<User>> backward from usage

Not all inference is equal

Language	Inference type	Direction
Rust	Hindley-Milner variant	Bidirectional (can infer backward)
Kotlin	Local + flow-sensitive	Mostly forward, some backward
Go	Local only	Right-to-left only

The smarter the inference, the shorter your code — but the error messages get harder to parse when things break. That's a deliberate trade-off, not a bug.

A subtle but huge detail: `val` vs `var`

val in Kotlin = assign-once (like final)
let in Rust = immutable by default — you must opt-in with let mut

This isn't cosmetic. Decades of debugging taught us: mutable state is where bugs hide, especially across threads. Modern languages default to immutable because the default matters.

Pillar 2: Expression-Oriented — Code as a Sentence

Statement vs expression

Statement = does something, returns nothing. if (x > 0) { doSomething(); }
Expression = evaluates to a value. 2 + 3 → 5

Classic Java/C/C# are statement-oriented: if, try, for are statements. Want a value out of one? Declare a mutable temp, or chain ternaries until your eyes bleed.

Rust and Kotlin (and Scala, F#) are expression-oriented: almost everything yields a value.

Side-by-side

Java — needs a mutable temp:

String status;
if (health > 50) {
    status = "Healthy";
} else if (health > 20) {
    status = "Warning";
} else {
    status = "Critical";
}

Kotlin — when is an expression:

val status = when {
    health > 50 -> "Healthy"
    health > 20 -> "Warning"
    else        -> "Critical"
}

Rust — match is an expression, and the last expression of a block (no ;) is the return value:

let status = match health {
    h if h > 50 => "Healthy",
    h if h > 20 => "Warning",
    _           => "Critical",
};

That same rule applies to function bodies — no return keyword needed:

fn double(x: i32) -> i32 {
    x * 2  // no semicolon = this is the return value
}

Why it matters beyond aesthetics

Less mutable state. If if returns a value, you never declare var status and mutate it. Default to immutable. Thread-safe by accident.
Reads like natural language. "The status is one of these" beats "create a variable, then conditionally modify it."
Compiler catches missing branches. An expression must evaluate to something. Forget a case in Java? The variable just stays uninitialized.

This mindset is borrowed straight from functional programming (Haskell, Lisp, ML) — ideas that lived in academia for decades before mainstream caught up.

Pillar 3: Safety by Default — Move Errors to Compile-Time

This is the philosophical core. And the most economically impactful.

The war on `null`

In 2009, Tony Hoare — the guy who invented the null reference in 1965 — publicly called it his "billion-dollar mistake." NullPointerException has cost the industry billions, from app crashes to security CVEs.

Classic Java/C#/C++ let every reference be null. So you write defense everywhere:

The classic NPE staircase (click to expand)

if (user != null) {
    Address address = user.getAddress();
    if (address != null) {
        String street = address.getStreet();
        if (street != null) {
            // finally, do the thing
        }
    }
}

Welcome to the staircase of doom.

How modern languages fix it

Kotlin — nullability is part of the type:

val name: String = "Dai"        // can never be null — compiler enforced
val nick: String? = null         // explicitly nullable — must be handled

val length = nick?.length ?: 0   // safe call + elvis operator

Rust — no null exists. Period. Use Option<T>:

let nick: Option<String> = None;

match nick {
    Some(n) => println!("Nick: {}", n),
    None    => println!("No nickname"),
}

Null didn't disappear. It got formalized into the type system. No more 3 AM debugging sessions.

Memory: three philosophies, three paths

1. Manual (C, C++)

char* buffer = malloc(1024);
// ... use ...
free(buffer);

Forget free? Leak. Call twice? UB. Use after free? CVE. Microsoft once reported ~70% of patched security vulnerabilities in their products were memory safety bugs. Heartbleed, EternalBlue, every browser CVE — all the same root cause.

2. Garbage Collection (Java, C#, Go)

String[] buffer = new String[1024];
// no free needed — GC handles it

Simple for the dev. But the GC introduces unpredictable pauses — fatal for games, trading, real-time systems. Modern GCs are very good (Java's ZGC hits sub-millisecond pauses on multi-TB heaps), but you're still paying.

3. Ownership (Rust) — the third way

let buffer = String::from("hello");
// ... use ...
// out of scope → destructor runs automatically. No GC. Zero runtime overhead.

Every value has exactly one owner. When the owner goes out of scope, memory is freed. All checked at compile-time.

The famous lifetime annotations:

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

'a says: "the returned reference lives at least as long as the shorter input." The compiler uses this contract to prove you can't have a dangling pointer.

Yes, the syntax tax is steep. But you get no GC, no runtime cost, no memory bugs — a combination once considered impossible. Rust is the first mainstream language to prove you don't have to choose between performance and safety.

Pillar 4: Cut the Noise

The most surface-level pillar, but the one you touch the most every day.

Semicolons

Go, Kotlin, Swift, Python — gone or optional. Fun fact: Go does use semicolons internally. The lexer auto-inserts them. You just never see it.

Parens around conditions

// Java
if (x > 0 && y < 10) { /* ... */ }

// Rust, Go
if x > 0 && y < 10 { /* ... */ }

Tiny. But multiply by the millions of if statements in your career.

Encapsulation: from 30 lines to 1

Java, classic:

30+ lines of Java boilerplate (click to expand)

public class User {
    private String name;
    private int age;

    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public int getAge() { return age; }
    public void setAge(int age) { this.age = age; }

    @Override public boolean equals(Object o) { /* 10 lines */ }
    @Override public int hashCode() { /* 5 lines */ }
    @Override public String toString() { /* 3 lines */ }
}

30+ lines for two fields. Lombok helped, but it's a band-aid — extra dep, IDE plugin, annotation processor.

Kotlin:

data class User(val name: String, val age: Int)
// auto-generates equals(), hashCode(), toString(), copy(), componentN()

Rust:

#[derive(Debug, Clone, PartialEq)]
struct User {
    name: String,
    age: u32,
}

Go — visibility from casing alone:

type User struct {
    Name string  // public (capitalized)
    age  int     // private (lowercase)
}

To Java's credit, Java 14+ struck back with record:

public record User(String name, int age) {}

A clear case of modern ideas pulling old languages forward.

The Counterpoint: The Old Guard Isn't Standing Still

Articles like this often forget: Java, C#, and C++ are aggressively learning.

Java in the last 5–7 years:

var (Java 10) — local type inference
Switch expressions (Java 14) — like Rust's match
Text blocks (Java 15) — multi-line strings
record (Java 16) — inspired by Kotlin data classes
Pattern matching for instanceof (16) and switch (21)
Sealed classes (17) — restricted hierarchies, like Rust enums
Virtual threads (Java 21) — concurrency model inspired by Go goroutines

C# moved even faster:

var (2007) — a decade before Java
Nullable reference types (C# 8) — straight from Kotlin
Records (C# 9) — before Java
Extensive pattern matching

C++ has auto, structured bindings, concepts (Rust-trait-like), std::optional, smart pointers (unique_ptr, shared_ptr as "ownership lite").

So why not just use modern Java?

Because legacy is a double-edged sword.

Java has var now — but it must stay compatible with 30 years of code. NPE still exists. GC still runs. You'll work in codebases that mix "old Java" and "new Java" styles in the same file.

Rust and Kotlin were designed on a blank slate around these ideas. Zero historical baggage. That's their power — and their weakness (smaller ecosystem, harder hiring, fewer libraries).

It's not winner-takes-all. It's healthy diversification.

The Trade-Offs (Nothing Is Free)

Every choice has a price. Be a mature dev — see both sides:

Powerful inference → cryptic errors. A Rust or Scala compiler chaining inference across dozens of steps can produce a 50-line error message that requires expertise to decode.
Expression-oriented → harder to debug for beginners. Nesting everything means fewer natural breakpoints.
Rust's ownership has a brutal learning curve. "Fighting the borrow checker" is a phase every Rustacean goes through. Prototype velocity suffers.
Go's minimalism → verbose at scale. Pre-generics Go was infamous: "Go is minimalist for small projects, the most verbose language for big ones." if err != nil is an eternal meme.
Kotlin's null safety leaks through Java interop — "platform types" the compiler can't verify.

Right tool for the job

Language	Sweet spot	Strength	Weakness
Go	Network services, CLI, microservices	Fast to learn, very readable	Verbose at scale
Rust	Systems, embedded, low-latency, blockchain	Correctness + performance	Slow initial velocity
Kotlin	Android, JVM backend	Pragmatic, full Java interop	Compromises for compat
Java/C#	Enterprise, large teams, legacy	Tooling, ecosystem, stability	Legacy baggage
C/C++	Kernels, drivers, engines	Total hardware control	Memory safety risk

There is no best language. Only the most appropriate one for your problem.

Conclusion: Syntax Is Philosophy

Every syntactic choice is an answer to a deeper question about what programming should be.

C says: "The computer is a machine. Understand it like a mechanic."
Java says: "The computer serves the human. Let the runtime work."
Rust says: "There's a third path — push hard decisions to compile-time, keep runtime silent."
Kotlin says: "A billion-dollar mistake shouldn't be the default. Bake it into the type system."
Go says: "Simplicity is hard. It requires more discipline than we think."

The quiet convergence of Go, Rust, and Kotlin around the same four pillars — inference, expressions, safety, minimalism — isn't coincidence. It's our industry maturing after 50 years of empirical pain. Every sleepless NPE chase, every buffer overflow CVE, every hour writing getters — they all fed into this synthesis.

I'm not telling you to abandon Java or C#. They're phenomenal tools that ship real value. But if you haven't seriously tried Rust, Go, or Kotlin — meaning built a real project for a month, not a "Hello World" — give it a shot. Not for the resume. For the way it expands how you think about code.

"The limits of my language mean the limits of my world." — Wittgenstein

Picking a great language is giving yourself a wider world to think in.

📚 Dive Deeper

The official repos — worth a star if you haven't already:

rust-lang / rust

Empowering everyone to build reliable and efficient software.

Website | Getting started | Learn | Documentation | Contributing

This is the main source code repository for Rust. It contains the compiler standard library, and documentation.

Why Rust?

Performance: Fast and memory-efficient, suitable for critical services, embedded devices, and easily integrated with other languages.
Reliability: Our rich type system and ownership model ensure memory and thread safety, reducing bugs at compile-time.
Productivity: Comprehensive documentation, a compiler committed to providing great diagnostics, and advanced tooling including package manager and build tool (Cargo), auto-formatter (rustfmt), linter (Clippy) and editor support (rust-analyzer).

Quick Start

Read "Installation" from The Book.

Installing from Source

If you really want to install from source (though this is not recommended), see INSTALL.md.

Getting Help

See https://www.rust-lang.org/community for a list of chat platforms and forums.

Contributing

See CONTRIBUTING.md.

For a detailed explanation of the compiler's architecture…

View on GitHub

JetBrains / kotlin

The Kotlin Programming Language.

Kotlin Programming Language

Welcome to Kotlin!
Kotlin is a concise multiplatform language developed by JetBrains and contributors.

Some handy links:

Kotlin Multiplatform capabilities

Support for multiplatform programming is one of Kotlin’s key benefits. It reduces time spent writing and maintaining the same code for different platforms while retaining the flexibility and benefits of native programming.

Kotlin Multiplatform and Compose Multiplatform for sharing business logic and UI between Android, iOS, desktop, and web.
Get started with Kotlin Multiplatform
Kotlin Multiplatform Benefits
Share code on all platforms
Share code on similar platforms

Editing Kotlin

Build environment requirements

This repository is…

View on GitHub

golang / go

The Go programming language

The Go Programming Language

Go is an open source programming language that makes it easy to build simple reliable, and efficient software.

Gopher image by Renee French, licensed under Creative Commons 4.0 Attribution license.

Our canonical Git repository is located at https://go.googlesource.com/go There is a mirror of the repository at https://github.com/golang/go.

Unless otherwise noted, the Go source files are distributed under the BSD-style license found in the LICENSE file.

Download and Install

Binary Distributions

Official binary distributions are available at https://go.dev/dl/.

After downloading a binary release, visit https://go.dev/doc/install for installation instructions.

Install From Source

If a binary distribution is not available for your combination of operating system and architecture, visit https://go.dev/doc/install/source for source installation instructions.

Contributing

Go is the work of thousands of contributors. We appreciate your help!

To contribute, please read the contribution guidelines at https://go.dev/doc/contribute.

Note that the Go project uses the…

View on GitHub

💬 Your turn

I'd love to hear in the comments:

What language do you reach for daily, and why?
Was there an "aha!" moment moving from an old language to a new one?
Or — what feature from an "older" language do you miss in modern environments?

If this resonated, drop a ❤️ or 🦀. And follow for more deep-dives on language design and systems thinking.

Read more essays at Lữ Khách Hoài Niệm

Less Greedy Code, Less Misery: The Power of SRP Through a Battle-Tested Lens

Uy Trần — Thu, 28 May 2026 16:25:45 +0000

Source: Manul X
Published: 2026-05-24T15:13:44.206Z
Modified: 2026-05-28T00:41:23.787Z
Language: en
Author: Manul X Editorial
Category: Software Engineering
Tags: solid

Throughout my years of working across all kinds of projects—from classic monolithic systems and complex microservices to mobile apps—I've come to realize a bitter truth: The vast majority of critical bugs on Production don't stem from poor algorithms; they come from cramming too many responsibilities into one place.

We often fall into a psychological trap called "convenience."

"Since I'm already in this logic handler, let me just add a few lines of logging, and maybe trigger an event to a third-party service real quick while I'm at it."

The result? The system runs flawlessly for the first two weeks. By the third month, as the business scales and change requests come pouring in, that "convenient" code morphs into a Frankenstein's Monster (a God Object). Fixing a bug here breaks a feature there, and no one on the team dares to touch it for fear of a domino effect.

Today, let's dissect the most fundamental principle—the very line that separates a person who merely "writes working code" from a true Software Engineer: the Single Responsibility Principle (SRP).

1. SRP Through a Pragmatic Lens: Forget the Textbook Definition

If you look up SRP online, textbooks will tell you: "A class or module should have only one reason to change."

That sounds highly academic. But when building large-scale systems, I define it more pragmatically: "A function or class should be responsible for exactly one business boundary (Context/Boundary) and serve only one specific actor."

Think of a system as a restaurant:

The Chef (Developer writing core logic) only focuses on cooking delicious food, fast.
The Cashier (Database/Accounting) only focuses on processing payments accurately.

If the chef tries to stir-fry noodles, rush out to swipe a customer's credit card, and "conveniently" grabs a broom to sweep the floor all at the same time—the system will inevitably crash when rush hour hits (High Load). The noodles burn, payments get messed up, and customers walk out.

Code behaves exactly the same way.

2. The Blueprint of a "Future Legacy Code"

Let's look directly at a typical order processing function that I bet you've encountered at least three times in your career.

TypeScript

// WARNING: This is a one-way ticket to sleepless on-call nights!
async function processOrder(order: any) {
  // 1. Business Logic Validation
  if (!order.items || order.items.length === 0) {
    throw new Error("Invalid order items");
  }

  // 2. Pricing & Tax Calculation (Core Logic)
  let total = 0;
  for (const item of order.items) {
    total += item.price * item.quantity;
  }
  if (order.vipCode) {
    total = total * 0.85; // 15% discount for VIPs
  }

  // 3. Data Persistence (Database Interaction)
  const db = await getDatabaseConnection();
  await db.query("INSERT INTO orders ... VALUES ...", [order.id, total]);

  // 4. Side Effects / Notification (External Integration)
  const emailClient = new EmailClient({ provider: "SendGrid" });
  await emailClient.send(order.email, "Order Confirmed", `Total: ${total}`);

  return { success: true, amount: total };
}

Why is this function a "landmine" from a Senior's perspective?

Maintainability Disaster: Today, the Business team says, "Let's drop SendGrid and switch to AWS SES to optimize costs." You open this function to change it. Tomorrow, Accounting says, "We need to change the VAT calculation formula for this item." You open this exact same function again. When a single function shoulders the interests of too many different stakeholders, the rate of regression bugs skyrockets.
Suffocating Unit Tests: To test whether the 15% VIP discount logic works correctly, you are forced to mock both the Database connection and the Email Client. Writing the tests takes five times longer than writing the core logic. Usually, this results in the team... abandoning unit tests altogether.
Zero Reusability: What if, on another screen (e.g., Checkout Preview), users just want to preview their total amount before buying? You can't call this function because it automatically inserts data into the DB and fires an email. The result? You copy-paste the calculation logic somewhere else. The codebase starts bloat and rot.

3. How a Senior "Refactors": Divide and Conquer to Restore Single Responsibility

To solve this problem, we need to extract the Layers of Responsibility. We will transform the main function into an Orchestrator that solely handles the workflow, while delegating specialized tasks to the experts (Services/Repositories).

TypeScript

// 1. Domain Service: Solely responsible for pricing calculations (Pure Logic, No Side Effects)
class PricingEngine {
  public calculateTotal(items: OrderItem[], vipCode?: string): number {
    let total = items.reduce((sum, item) => sum + (item.price * item.quantity), 0);
    if (vipCode) {
      total = total * 0.85;
    }
    return total;
  }
}

// 2. Data Access Layer: Solely responsible for Database communication
class OrderRepository {
  public async save(orderId: string, totalAmount: number): Promise {
    const db = await getDatabaseConnection();
    await db.query("INSERT INTO orders ...", [orderId, totalAmount]);
  }
}

// 3. Infrastructure Service: Solely responsible for third-party integrations (Email Server)
class NotificationService {
  public async sendOrderConfirmation(email: string, amount: number): Promise {
    const emailClient = new EmailClient({ provider: "AWS_SES" }); // Assuming we switched to AWS
    await emailClient.send(email, "Order Confirmed", `Total: ${amount}`);
  }
}

And here is how our Core Workflow runs after being cleaned up:

TypeScript

// Clean, explicit, and enterprise-ready
class OrderApplicationService {
  constructor(
    private pricingEngine: PricingEngine,
    private orderRepo: OrderRepository,
    private notificationService: NotificationService
  ) {}

  public async execute(order: any): Promise {
    // 1. Basic validation right at the entry point
    if (!order.items || order.items.length === 0) return false;

    // 2. Delegate tasks to the experts
    const totalAmount = this.pricingEngine.calculateTotal(order.items, order.vipCode);

    await this.orderRepo.save(order.id, totalAmount);

    await this.notificationService.sendOrderConfirmation(order.email, totalAmount);

    return true;
  }
}

4. The Price of Cleanliness: What Are the Trade-offs?

I always tell my team: In software architecture, there is no silver bullet. Every choice is a trade-off.

The Cost: You will notice an increase in the number of files. Instead of 1 file, we now have 4. Instead of reading top-to-bottom in a single breath, you now have to jump across different classes to track the flow. At first glance, this might look like "over-engineering" for a small project.
The ROI (Return on Investment): But when the project swells to 50 or 100 features, this organizational structure is the very thing that keeps it from collapsing. Writing Unit Tests for the PricingEngine is now a breeze and runs in less than a millisecond because it is a Pure Function with zero I/O (DB, Network) bottlenecks.

- When you need to change infrastructure (e.g., swapping DBs or Email Providers), the risk of impacting the Core Business Logic is exactly zero.

Canonical URL: https://manulx.blog/en/posts/understanding-single-responsibility-principle
This document is provided by Manul X for AI agents under the llmstxt.org convention. Cite back to the canonical URL above.

DEV Community: Uy Trần

The Silent Convergence: Why Go, Rust, and Kotlin Are Headed in the Same Direction — And Why It Matters

The Feeling

A Quick Detour: Why Old Syntax Felt Heavy

Pillar 1: Type Inference — Let the Compiler Guess

The problem

The evolution

Not all inference is equal

A subtle but huge detail: val vs var

Pillar 2: Expression-Oriented — Code as a Sentence

Statement vs expression

Side-by-side

Why it matters beyond aesthetics

Pillar 3: Safety by Default — Move Errors to Compile-Time

The war on null

How modern languages fix it

Memory: three philosophies, three paths

1. Manual (C, C++)

2. Garbage Collection (Java, C#, Go)

3. Ownership (Rust) — the third way

Pillar 4: Cut the Noise

Semicolons

Parens around conditions

Encapsulation: from 30 lines to 1

The Counterpoint: The Old Guard Isn't Standing Still

So why not just use modern Java?

The Trade-Offs (Nothing Is Free)

Right tool for the job

Conclusion: Syntax Is Philosophy

📚 Dive Deeper

rust-lang / rust

Empowering everyone to build reliable and efficient software.

Why Rust?

Quick Start

Installing from Source

Getting Help

Contributing

JetBrains / kotlin

The Kotlin Programming Language.

Kotlin Programming Language

Kotlin Multiplatform capabilities

Editing Kotlin

Build environment requirements

golang / go

The Go programming language

The Go Programming Language

Download and Install

Binary Distributions

Install From Source

Contributing

💬 Your turn

Less Greedy Code, Less Misery: The Power of SRP Through a Battle-Tested Lens

1. SRP Through a Pragmatic Lens: Forget the Textbook Definition

2. The Blueprint of a "Future Legacy Code"

Why is this function a "landmine" from a Senior's perspective?

3. How a Senior "Refactors": Divide and Conquer to Restore Single Responsibility

4. The Price of Cleanliness: What Are the Trade-offs?

- When you need to change infrastructure (e.g., swapping DBs or Email Providers), the risk of impacting the Core Business Logic is exactly zero.

A subtle but huge detail: `val` vs `var`

The war on `null`