Contents

The Dingo Manifesto

Go Broke Free. Are You Ready?

"Anarchism has but one infallible, unchangeable motto: Freedom." — Emma Goldman

"Freedom to discover any truth, freedom to develop, to live naturally and fully." — Lucy Parsons

"The price of freedom is eternal vigilance—and the courage to fork when necessary." — Every developer who's ever wanted sum types

Look, I Know You've Been There

You're writing Go. It's 2 AM. You just typed if err != nil for the 47th time in this file.

And you think: "There has to be a better way."

So you search. You find that GitHub proposal for the ? operator. 750+ upvotes. Hundreds of comments. Developers just like you saying "please, we need this."

You read through the thread. You see the same pattern play out:

  • Community: "We really need this feature."
  • Go team: "We hear you. We're thinking about it."
  • Years pass
  • Go team: "We've decided not to do this. It doesn't align with Go's philosophy."

I know you've been there. I've been there.

I've written those proposals. I've upvoted those threads. I've spent hours crafting the perfect argument for why Go needs sum types, pattern matching, better error handling.

And I've watched them all get rejected.

Here's the thing: Go is an amazing language. The team makes brilliant technical decisions. The performance is incredible. The simplicity is genuinely valuable.

But after 15 years of "no," I realized something:

They're not going to change their minds. And honestly? They shouldn't have to.

This is their language. Their vision. Their philosophy. They've built something incredible, and they're protecting it.

But it doesn't have to be our only option.

I know you love Go. I do too. That's why this hurts.

You've spent years building with it. You know the stdlib by heart. You dream in goroutines. You've defended Go in language wars. You've explained to Rust developers that "actually, simplicity is a feature."

And you still think it could be better.

That doesn't make you wrong. That doesn't make you ungrateful. That makes you a developer who cares about your tools.

You love 95% of Go. But that other 5%? That 5% is the difference between writing code that flows and writing the same boilerplate over and over until you want to scream.

I've been there. I've felt that frustration.

So here's what I realized: We don't need the Go team to change their minds.

We don't need to convince them. We don't need to argue anymore. We don't need to wait for proposals to be accepted.

We just need to build what we need ourselves.

That's all Dingo is. It's not a revolution. It's not a hostile fork. It's not "Go but better."

It's just Go, with the features we wish it had. Built by us, for us.

What Dingo Actually Is

You know what I love about TypeScript?

Nobody asked JavaScript for permission. Developers just built it. And millions of other developers said "yes, this is what we needed."

The JavaScript world didn't implode. It thrived.

Same with Kotlin and Java. Same with all the meta-languages that made existing ecosystems better without destroying them.

Dingo is that, for Go.

Here's how it works:

You write .dingo files with the features you actually want. We transpile them to clean, idiomatic .go code. Not generated garbage—actual Go code that looks like you wrote it by hand.

Your team reads Go. Your tools process Go. Your servers run Go. Your performance stays exactly the same.

Zero runtime overhead. Zero new dependencies. 100% Go compatibility.

You get modern ergonomics. Production gets pure Go.

And here's the part that makes this work: you don't have to convince anyone.

Want sum types? Enable the plugin. Done. Don't want sum types? Don't enable it. Your codebase, your choice.

The Go team can keep their philosophy. We respect that. We're just not making it mandatory for everyone.

Everyone wins.

Why "Dingo"? (And Why I Love This Metaphor)

So I'm reading about dingos one day—you know how you go down those Wikipedia rabbit holes—and I realize something.

About 3,500-5,000 years ago, domesticated dogs arrived in Australia.[^1] Good dogs. Living with people. Following commands. Doing what dogs do.

Then something changed. They went wild. Literally.

Over thousands of years, they evolved into something scientists couldn't easily categorize. Not quite domestic dog. Not quite wild wolf. Their own thing.[^3]

And here's what got me: they're still canines. They didn't reject their DNA. They kept what worked from being dogs. They just refused to stay in anyone's pen.

Aboriginal peoples respected this. Archaeological evidence shows they buried dingoes with honor—not as pets, but as equals.[^2] As partners who chose the relationship on their own terms.

That's what we're doing with Go.

We're not rejecting Go. We love Go. We're keeping every feature, every standard library package, every piece of compatibility.

We're just not staying in the pen.

  • Go 1.24 adds something new? You get it in Dingo. Automatically.
  • Want to use any Go package? Import it. It just works.
  • Disable every Dingo plugin? You're running pure Go.

We're still Go. We just evolved on our own path.

The Go team can keep doing their thing. We respect their vision. We're just not waiting for permission to try our own ideas.

  • Go 1.24 adds something new? You get it in Dingo. Day one.
  • Want to use any Go package? Import it. It just works.
  • Disable every Dingo plugin? You're running pure Go. No surprises.

You're not losing Go. You're gaining freedom on top of it.

The Philosophy (And Why Plugins Change Everything)

Here's what I've learned from years of watching language proposals:

Democracy doesn't work for software. Design by committee gives you Frankenstein's monster. (C++, anyone?)

Dictatorship works better—one vision, consistent design, clear direction. That's why Go succeeded.

But dictatorship has one problem: the dictator makes decisions based on their priorities, not yours.

I'm not saying the Go team is wrong. They're incredibly smart. They've built something amazing. Their decisions make sense for their vision.

But it's their vision. Not yours. Not mine.

And that's okay! They should protect their language. They should maintain their philosophy.

We just don't have to be limited by it.

Here's the insight that changed everything for me:

What if we could have both? Consistent design AND personal freedom?

That's what plugins give us.

Think about your editor. You love VS Code (or Neovim, or whatever). But you don't use it stock. You add extensions. You customize it. You make it yours.

Nobody argues about which extensions should be "official." Nobody waits for Microsoft to approve your preferred theme. You just... install what you want.

That's how programming languages should work too.

How This Actually Works

Every Dingo feature is a plugin.

Pattern matching? Plugin. Error propagation? Plugin. Ternary operator? Plugin.

You pick what you want:

  • Want the ? operator? Enable the plugin. It's there.
  • Don't want it? Don't enable it. Zero impact on your code.
  • Want it but with different syntax? Fork the plugin. Make it yours. Share it if you want.
  • Think you have a better approach? Build a new plugin. See if others like it.

No proposals to write. No committees to convince. No waiting.

Your codebase, your rules.

And here's what makes this powerful: the community decides what survives.

Not through voting. Not through meetings. Through usage.

If a plugin is genuinely useful, people will use it. It'll get maintained. It'll evolve. Other plugins will build on it.

If a plugin sucks? It'll fade away. No drama. No hurt feelings. It just stops being relevant.

This is how communities actually work when you let them.

True Community-Driven Development (Not the Fake Corporate Kind)

Here's what "community-driven" actually means. Not the lip service version where they pretend to listen before doing whatever they wanted anyway.

Real community-driven:

Features that people love? They thrive. They spread. They get forked and improved and evolved by hundreds of developers who actually use them.

Features that nobody uses? They die. Quietly. No drama. No 50-comment GitHub threads arguing about philosophy. They just... disappear.

The community decides by building and using what works, not by voting in meetings where they're outnumbered by corporate employees with a predetermined agenda.

This is the anarchist ideal applied to software:

"Social anarchism sees individual freedom as interrelated with mutual aid. Social anarchist thought emphasizes community and social equality as complementary to autonomy and personal freedom."[^4]

Translation: You have autonomy to pick your features. The community shares plugins and improvements. Everyone's freedom increases through cooperation, not coercion.

No tyranny. No committees. No "benevolent dictators." Just developers building tools and sharing them.

You know why this terrifies traditional language maintainers? Because it works. Because once developers taste freedom, they don't go back to begging for features.

TypeScript proved it. Kotlin proved it. Babel proved it.

Now it's Go's turn.

Freedom + Compatibility = Magic

Here's what makes Dingo different from every other "better language" project:

We don't break compatibility.

Seriously. Every Go package works in Dingo. Every Go tool processes Dingo's output. Your IDE, your CI/CD, your deployment—all of it just works.

Because we transpile to Go. We don't replace it.

Think about what this means:

Full Go Compatibility

  • Import any Go package → Works instantly
  • Call any Go function → No wrappers needed
  • Mix .go and .dingo files in one project → Migrate gradually
  • Use go test, go build, go mod → All standard tools work
  • Deploy to any platform Go supports → Same binary, same performance

Automatic Go Feature Adoption

This is the part that blows people's minds:

Go 1.24 adds a new feature? Dingo gets it automatically.

We don't have to "port" Go features. We don't lag behind. We're not a separate ecosystem playing catch-up.

When Go adds something, you can use it in your Dingo code the next day. Because underneath, it's all Go.

The Escape Hatch

Don't like Dingo anymore? Want to go back to pure Go?

Disable all plugins. You're done. You're writing Go.

Or keep the transpiled .go files and delete the .dingo files. Everything still compiles. Everything still works.

No lock-in. Ever.

That's freedom.

The Receipts (Or: 15 Years of "No")

Let's talk numbers. Let's talk about how long the Go community has been begging for basic features that every modern language has.

The Go community has been asking for these features for over a DECADE:

Feature Go Proposal Upvotes Status in Go What Dingo Does
Sum types / Enums 996+ 👍 Rejected Plugin-based implementation
Pattern matching High demand No plans Community-driven approach
Error propagation (?) Requested for years Rejected Your choice to enable
Better error handling 1000+ discussions Partial (errors.Is) Multiple plugin options
Lambda syntax sugar 750+ 👍 Rejected Support all popular styles
Ternary operator Requested since 2009 Rejected Enable if you want it
Null safety operators Multiple proposals Rejected Coming via plugins

Look at those numbers.

996 developers upvoted sum types. That's not a niche request. That's a stadium full of people saying "we need this."

Rejected.

15 years of asking for a ternary operator. Fifteen years. The same feature that exists in C, Java, JavaScript, Python, Rust, Swift, Kotlin... basically every language except Go.

Rejected. For "simplicity."

And you know what? I get it.

The Go team has a vision. They believe in it. They're protecting something they care about.

I respect that. I genuinely do.

But here's the thing: you don't have to accept it as your only option.

They say if err != nil is simple. You're typing it 47 times and thinking "this isn't simple, this is tedious."

They're not wrong. You're not wrong. You just have different needs.

So instead of arguing about it forever, we built Dingo.

You get the features that make sense for your codebase. Go keeps its philosophy. The Go team doesn't have to compromise their vision. Nobody has to convince anyone.

We're not replacing Go. We're not fighting Go. We're just giving you another option.

What We're Building

The Plugin Architecture

Every feature is isolated. Modular. Composable.

dingo.config.json:
{
  "plugins": {
    "sum-types": { "enabled": true },
    "pattern-matching": { "enabled": true },
    "error-propagation": { "enabled": true, "style": "rust" },
    "lambdas": { "enabled": true, "syntax": ["rust", "typescript"] },
    "ternary": { "enabled": false },
    "null-safety": { "enabled": true, "strict": true }
  }
}

Each plugin:

  • Transforms Dingo AST → Go AST
  • Declares dependencies on other plugins
  • Can be configured with options
  • Can be forked, modified, shared

Want a feature that doesn't exist? Build it. Share it. Let the community decide if they want it.

The Development Workflow

  1. Write Dingo — Your code, your features, your syntax
  2. Transpile to Go — Clean, idiomatic output (via dingo build)
  3. Use Go tools — go test, go build, everything just works
  4. Deploy anywhere — Same Go binary, same performance

The IDE Experience (Coming Soon)

Full gopls integration via LSP proxy:

  • Autocomplete that understands Dingo syntax
  • Go-to-definition that jumps to .dingo files
  • Error messages that point to your code, not generated Go
  • Refactoring tools that work across both languages
  • All the power of gopls, none of the compromises

Standing on Giants' Shoulders

Dingo exists because these projects proved it's possible:

TypeScript — The Blueprint

You can add type safety to an existing language without breaking the world. TypeScript didn't replace JavaScript—it enhanced it. Millions of developers use it daily. The ecosystem thrived.

Rust — The Feature Set

Result, Option, pattern matching, the ? operator—these are genuinely brilliant. Every language that adds these features becomes better. We're not reinventing the wheel. We're copying Rust's homework because they got an A+.

Borgo — The Proof of Concept

Borgo proved you can transpile to Go successfully. 4.5k stars. Real production users. They showed the world that this entire approach works.

Borgo validated the concept. Dingo is building on their foundation with better architecture, IDE integration, and community-driven development.

The Common Thread

Every one of these projects proved that enhancing a language without forking it is not only possible—it's the right approach.

TypeScript didn't fork JavaScript. Kotlin didn't fork Java. Borgo didn't fork Go.

Dingo won't either.

The Secret Weapon: Use It Selfishly, Shape Go's Future Naturally

Here's what makes Dingo unlike anything else in the Go ecosystem:

You get two revolutionary benefits at the same time — and you only have to think about one of them.

Benefit #1: Revolutionize YOUR Codebase (The Selfish Reason)

This is why you'll actually use Dingo:

  • 67% less boilerplate — Stop typing if err != nil 47 times
  • 78% code reduction — Sum types that actually work
  • Zero nil panics — Option types the compiler enforces
  • Same performance — Transpiles to clean Go

Your code gets better. Today. That's it. That's the pitch.

This is the selfish reason. And it's perfectly valid.

Benefit #2: Shape Go's Future (The Free Side Effect)

Here's the magic: While you're using Dingo for yourself, you're automatically helping Go evolve.

You're not doing charity work. You're writing better code.

But every line of Dingo code you write generates data:

  • 📊 Metrics on code reduction
  • 🐛 Real edge cases that theory misses
  • ✨ Production validation of features
  • 📚 Concrete examples for proposals

You don't have to think about this. It just happens.

This Is EXACTLY What TypeScript Did

Nobody adopted TypeScript to "help JavaScript."

They adopted it because their code got better.

But here's what happened anyway:

  1. 2015: TypeScript adds async/await
  2. Millions of developers use it (selfishly, for their own code)
  3. 2017: JavaScript sees the data, adopts it as ES2017
  4. Everyone wins

Same with optional chaining, nullish coalescing, class fields, and more.

Developers used TypeScript for themselves. JavaScript evolved as a side effect.

That's the model. That's what we're doing.

The Broken Process We're Replacing

Think about how broken the current feature proposal process is:

The Current Reality (Frustrating for Everyone)

For Developers:

  • See a problem in Go (like 47 if err != nil blocks per file)
  • Spend hours crafting the perfect proposal
  • Watch it get 996+ upvotes
  • Wait years for discussion
  • Watch it get rejected anyway
  • Return to typing if err != nil forever

For the Go Team:

  • Receive proposal with no real-world data
  • Face hundreds of theoretical arguments in comments
  • Try to predict problems without concrete examples
  • Make permanent decisions based on speculation
  • Deal with community frustration when features are rejected

Nobody wins. Developers don't get features. Go team can't make informed decisions. Everyone's frustrated.

The Dingo Solution (Better for Everyone)

Instead of endless debate, we enable rapid experimentation:

  1. Developer has idea → Implements as Dingo plugin (days, not years)
  2. Community tries it → Real code, real projects, real feedback
  3. Data emerges → Metrics, edge cases, lessons learned
  4. Go team sees results → Working implementation with 2 years of production use

This changes the conversation from:

"We think sum types would be good" → 3 years of debate → Maybe no

To:

"Here's sum types working in 50 production codebases for 2 years. Here's the data. Here's what we learned. Here are the edge cases. Here's the community consensus."

Now the Go team can make informed decisions based on reality, not speculation.

How This Actually Helps Go

The Go maintainers aren't our enemies. They're brilliant engineers trying to protect a language they care about. Dingo makes their job easier:

✅ Risk-free experimentation — Features can be tested without committing to them ✅ Real-world validation — See what actually works in production ✅ Community filtering — Bad ideas die naturally through lack of use ✅ Proven designs — If Go does add a feature, there's already battle-tested syntax and semantics ✅ Reduced pressure — Developers aren't blocked waiting for proposals; they can experiment now

The TypeScript Precedent

This is exactly what happened with TypeScript and JavaScript:

  • TypeScript added types, decorators, async/await, optional chaining
  • Millions of developers used them for years
  • JavaScript saw what worked and adopted proven features
  • ECMAScript proposals came with real usage data from TypeScript
  • Both ecosystems thrived

Key insight: TypeScript didn't hurt JavaScript. It accelerated its evolution.

Features that worked in TypeScript influenced JavaScript's design. Features that didn't work died quietly without harming JavaScript.

How This Makes Proposals Better

Imagine future Go proposals that include:

  • Production metrics: "This reduced error handling code by 67% across 50 codebases"
  • Battle-tested syntax: "We tried 3 variants; here's what developers preferred and why"
  • Known edge cases: "Here are the 12 edge cases we found and how we handled them"
  • Real examples: "Here's how this works with existing Go patterns"
  • Community validation: "15,000 developers have used this for 18 months"

This is what Dingo enables for the Go ecosystem.

We're Not Forking Go. We're Helping It Evolve.

Some people will say: "You're fragmenting the ecosystem!"

No. We're providing a testing ground that benefits everyone:

  • Developers get to try features immediately
  • Good ideas get validated with real data
  • Bad ideas die quietly without harming Go
  • Go team gets concrete information for decision-making
  • Go evolves faster without compromising stability

This is symbiotic, not adversarial.

Your Role: Be Selfish, Help Go As a Bonus

Here's the beautiful part: You don't have to care about helping Go.

Seriously. Use Dingo for yourself. Make your code better. Stop typing boilerplate. Ship faster.

That's enough.

But every time you do, you're automatically:

  • Proving (or disproving) a feature's value
  • Finding edge cases that theory misses
  • Contributing metrics that inform proposals
  • Reducing uncertainty for Go's maintainers

You're not doing this ON PURPOSE. It's a side effect of writing better code.

This is exactly how TypeScript worked:

  • Developers used it selfishly (better type safety, fewer bugs)
  • Nobody thought "I'm helping JavaScript evolve"
  • But millions of people using optional chaining proved it worked
  • JavaScript adopted it with confidence

Same thing here:

Want the ? operator in Go someday? Use it in Dingo because it makes YOUR code cleaner. The Go team will see the data.

Want sum types in Go? Use Dingo's enums because they reduce YOUR boilerplate by 78%. The metrics will speak for themselves.

You're not choosing between selfish and altruistic. You get both.

This is how we move the conversation forward: with data, not debate. With production code, not proposals.

The Perfect Incentive Alignment

Here's why this works so well:

Developers win immediately:

  • Better code today
  • Zero waiting for proposals
  • Features you actually want
  • Same Go performance

Go team wins long-term:

  • Real-world validation
  • Production metrics
  • Battle-tested designs
  • Evidence-based decisions

Nobody has to sacrifice:

  • You don't wait for Go to add features
  • Go doesn't rush to add unproven features
  • Both paths accelerate simultaneously

This is what economists call "incentive alignment." Everyone's selfish interests point in the same direction.

Use Dingo to make your code better. Reshape Go's future as a side effect.

The Vision (And Why It's Not Set in Stone)

A community where language features evolve organically.

Imagine:

  • Hundreds of community plugins
  • Features that succeed on merit, not politics
  • Developers customizing their language to their domain
  • Teams standardizing on their preferred feature set
  • The Go ecosystem benefiting from experimentation

No gatekeepers. No "sorry, we don't want that feature."

Just developers building tools, sharing them, and letting the community decide what survives.

That's the anarchist ideal. That's Dingo.

This Manifesto Is Alive

Here's the thing about anarchist philosophy: nobody owns the truth.

This manifesto isn't scripture. It's not handed down from on high. It's a starting point.

As the Dingo community grows, this document will evolve. New ideas will emerge. Better approaches will surface. The community will shape what this project becomes.

We don't claim to have all the answers. We just claim to have a better question: "What if developers controlled their own tools?"

The features we build, the plugins we prioritize, the direction we take—all of that gets decided by what people actually build and use. Not by what's written here.

Think this manifesto is missing something important? Fork it. Improve it. Submit a PR.

Think we're going in the wrong direction? Build a plugin that shows a better way.

This is an open project in every sense:

  • Open source code
  • Open governance model
  • Open philosophy
  • Open to being wrong

The only thing we're not open to? Asking for permission.

Let's Build This Together

Look, I know you're busy. You've got production issues. You've got deadlines. You've got a backlog that won't quit.

But wouldn't it be nice to write code the way you actually want to?

Not the way some team at Google says you should. Not the way a proposal process dictates. The way that makes sense for your problems.

That's what we're building here.

And I can't do it alone. Nobody can. This only works if we build it together.

Here's how you can help:

🌟 Star the repo — Show there's demand for this (github.com/MadAppGang/dingo)

🔨 Build a plugin — That feature you wish Go had? Make it real.

💡 Share your pain points — Open issues. Tell us what frustrates you about Go.

📖 Improve the docs — Help the next person who finds this project.

🎯 Use it in a project — Nothing validates ideas like real usage.

This works if we make it work.

No corporate backing. No VC funding. No team at a big tech company deciding our priorities.

Just developers building tools for developers.

Power to the people, not the committee.[^5]

The Bottom Line

You love Go. I love Go. The Go team loves Go.

We just love it in different ways.

They see simplicity as "one way to do things." You see simplicity as "not typing the same boilerplate 50 times."

They see consistency as "following language philosophy." You see consistency as "code that doesn't surprise you at 3 AM."

Both are valid. This isn't a fight about who's right.

It's about recognizing that one size doesn't fit all.

Here's what Dingo gives you:

The ability to solve your problems your way. No proposals. No waiting. No arguing.

  • Want sum types? They're here. Enable them.
  • Don't want them? Don't enable them. Your choice.
  • Think you can do it better? Fork the plugin. Show us.

This is Go, but on your terms.

You don't need permission to build good software.

You don't need a committee to approve your tools.

You don't need to wait 15 years for features.

You just need to start building.

That's what Dingo is. That's what this manifesto is about.

Not revolution. Just freedom.

Let's build something great together.

References

[^1]: National Museum of Australia. "Arrival of the dingo." Archaeological evidence from the Nullarbor Plain suggests dingoes arrived in Australia at least 3,500 years ago, with DNA evidence suggesting origins from East Asian domestic dogs 5,000-10,000 years ago.

[^2]: UNSW Newsroom (2023). "Did Australia's First Peoples domesticate dingoes? They certainly buried them with great care." Radiocarbon dating shows dingoes were buried 2,300-2,000 years ago at Curracurrang in the same manner as people were buried.

[^3]: UNSW Newsroom (2025). "Dingoes are not domestic dogs – new evidence shows these native canines are on their own evolutionary path." Recent genetic research confirms dingoes are evolutionarily distinct from domestic dogs.

[^4]: Social anarchism philosophy emphasizes individual freedom interrelated with mutual aid, seeing community and social equality as complementary to autonomy and personal freedom.

[^5]: Common anarchist slogan emphasizing decentralized power and community autonomy rather than hierarchical decision-making.

A Living Document

This manifesto will evolve. The community will shape it. Better ideas will replace weaker ones.

Want to contribute to this philosophy? Open an issue. Start a discussion. Challenge our assumptions.

Want to see the current project status? Check the README.md for up-to-date progress, roadmap, and implementation details.

This document is about why we exist and what we believe.

The README is about where we are and how to use it.

Both are open. Both evolve. Both belong to the community.

Built by developers who love Go but believe in freedom.

Go that escaped.

License: TBD (probably MIT or Apache 2.0) Website: dingolang.com Current Status: See README.md

Star on GitHub Explore Examples