All projects

Go vs Go+ Research

Go+ layers higher-level syntax on Go's compiler and runtime. Does that actually reduce what a developer writes, or is it cosmetic?

2026GoGo+Comparative analysis

A comparative study of Go and Go+, testing whether Go+'s higher-level syntax actually reduces what a developer writes, using representative programs implemented in both languages.

What I built

Implemented the same representative programs in idiomatic Go and Go+ to compare directly.
Compared readability, control-flow constructs, and error-handling ceremony rather than raw performance.
Wrote up where the syntax difference actually helps and where it doesn't.

Key decision

I approached it as a comparative programming-language study rather than trying to argue one language is universally better. I compared language features and their effect on readability, development effort, and potential use cases like education, scripting, and rapid prototyping.

What this project taught me

Language design is mostly about trade-offs. Higher-level syntax makes common operations shorter and more approachable, but a language's value also depends on ecosystem, tooling, adoption, and the kind of software being built.
Go+ was interesting because it tries to make Go-style development more accessible without cutting itself off from the Go ecosystem.

The full reasoning

The problem, options, and constraints

Problem

Go+ takes Go's compiler, runtime, and single-binary deployment and layers higher-level syntax on top: lambdas, list comprehensions, lighter boilerplate. The question worth studying is whether that actually reduces how much a developer has to write and reason about, or whether it's cosmetic.

Observation

Go is intentionally simple, but I wanted to understand what happens when a language keeps the Go ecosystem and performance-oriented foundation while adding higher-level features like lambda expressions, list comprehensions, and simplified syntax.

The question

Does Go+ meaningfully reduce the amount and complexity of code developers write compared with Go, and where would those differences actually be useful?

User need

Educators need a language students can be productive in quickly without dropping them off a cliff later. People doing scripting and rapid prototyping need to move fast. Both want a path that doesn't dead-end when the work turns into real systems code.

Constraints

A comparison is only useful with objective, repeatable criteria, not 'this feels nicer'
Go+ is young: smaller ecosystem, fewer libraries, less documentation
Scope to representative tasks rather than survey the whole language

Options considered

Option	Trade-off
Micro-benchmark raw runtime performance Go vs Go+	Clean numbers, but Go+ compiles through Go. The runtime story is nearly identical, so it answers the wrong question
Compare language features and their effect on readability and development effort	Measures the thing that actually differs (the human side), but needs care to keep the criteria consistent
Survey ecosystem maturity and library coverage	Important for real adoption, but a moving target and less about the language design claim

Architecture

Comparison framework:
  Task set: small representative programs (data transforms, file/CLI scripts, prototypes)
    --> implement each in idiomatic Go and in Go+
    --> compare: readability, lines and control-flow constructs, error-handling ceremony, concepts to learn
  Use cases: education | scripting | rapid prototyping
  Held constant: compiler, runtime, single-binary deployment
  Recorded separately: ecosystem / library gaps

Selected code decisions

Where the syntax difference actually shows up

// Go: transform a slice
out := make([]int, 0, len(xs))
for _, x := range xs {
  if x%2 == 0 {
    out = append(out, x*x)
  }
}

// Go+: list comprehension
out := [x*x for x <- xs, x%2 == 0]

The two programs do the same work and compile the same way, but the Go+ version has fewer moving parts to get right. Across many small programs, that difference in what a reader has to track adds up.