r/golang

▲ 10 r/golang

Golang Slice Help (for a C guy)

I’m trying to get better with Go slices, and I’m having trouble building the right mental model.

When I learn a new language, I usually implement a deck of cards to practice things like traversal, initialization, and shuffling. Right now I’m implementing Fisher-Yates shuffle.

In C, I would write something like this:

void shuffle(int *array, int n) {
  if (n > 1) {
  srand(time(NULL)); 

  for (int i = n - 1; i > 0; i--) { 
    // Pick a random index from 0 to i 
      int j = rand() % (i + 1);
 
      //Swap array[i] with array[j]
         int temp = array[i];
         array[i] = array[j]; 
         array[j] = temp; 
    }

  }
}

This makes sense to me because I can clearly see the temporary variable and the swap.
Now Go's turn

func (d *Deck) Shuffle() {
for i := len(d.Cards) - 1; i > 0; i-- {
  j := rand.IntN(i + 1)
  d.Cards[i], d.Cards[j] = d.Cards[j], d.Cards[i]
  }
}

The part that confuses me is this line:

d.Cards[i], d.Cards[j] = d.Cards[j], d.Cards[i]

I understand that d.Cards is a slice, and that assigning to d.Cards[i] mutates the underlying array. But I don’t understand how this swap works without a temporary variable?

Is Go evaluating the right-hand side first, then assigning both values to the left-hand side? if so is slices the only place golang evaluates right side expressions first?

Also, for people who came from C/C++/Java/C#, did Go slices feel strange at first? Did the mental model eventually click?

reddit.com
u/VastDesign9517 — 20 hours ago
▲ 18 r/golang+1 crossposts

I made a clean, generic, zero-dependency matrix math package for Go.

Heyyy r/golang I have always felt that Go doesnt have some good matrix packages, so I decided to make one, been working on this for almost 4 months now, was slacking a bit due to college exam but finally I completed it, would love some feedback on this!!
Repo link:- https://github.com/Arceus-7/matrix
Go package page:- https://pkg.go.dev/github.com/Arceus-7/matrix
I hope this will be useful for many people <3

reddit.com
u/Nice_Syllabub_7327 — 20 hours ago
▲ 32 r/golang

Using HTTP/2 Cleartext for a server in Go 1.24+

If you're running a Golang service that uses SSE or needs to handle a lot of requests, you may want to look into supporting HTTP/2 over cleartext as long as you are behind some sort of load balancer that supports it. I wrote up a quick post showing how to do it in newer Go versions where it is much easier than before. We use Google Cloud Run, and I've included some config examples for that as well.

clarityboss.com
u/toofishes — 20 hours ago
▲ 4 r/golang

should i get tdt event driven

so i lately came across this course
https://threedots.tech/event-driven/

i am a final year computer engineering,

have a job offer i'm going to accept for software tester (java/C#),

i am mainly backend focused working in spring boot and little bit of go

i have basic to intermediate knowledge of Go, and i'd love to work on that

so should i get this course, i am getting a regional discount on this (40% off)

also should i get this course or their other course on backend development or both

if i take this course, would it make their backend course irrelevant in some way, or the other way around,

also let me konw your review of any of their training u've taken

thank you!!

u/Arcade_30 — 20 hours ago
▲ 8 r/golang

A regression in code I didn't touch

CPU data cache associativity issues are relatively well known. Instruction cache associativity issues, less so.

While working on go code, I investigated a surprising performance regression that turned out to be caused by L1 instruction cache associativity. In the code I didn’t even change.

The investigation included usage of go toolchain, but the underlying issue is mostly language-agnostic.

blog.andr2i.com
u/watman12 — 19 hours ago
▲ 108 r/golang

I built a Slack TUI in Go in a week (24Mb binary, daily driver, images supported)

grant.dev
u/dogas — 2 days ago
▲ 0 r/golang

Only bad vibes: should we roast people honest about AI usage?

Hi,

I wanted to make a post because I want to know what other community members think about this topic: roasting people honest about AI usage on their AI usage.

I have called out many projects in the past that were pure slop, oldest commit 2h ago, obviously vibed but pretending they built it. I was quite mean as well...

I think that's reasonable, we're calling bs out when we see it. Here is where I think we need to reconsider, I just read an article shared here about a person explaining how they vibed a slack tui in a weekend. They had a whole section about how they vibed it, how much time it took and how they did it. People were pointing out that it was made with AI in the comments, and it's like, yeah, they said it in the post, it's not like it's being hidden.

Why do I think we should talk about this? Because if we keep dunking on people who are up front about their AI usage they will start hiding it, eventually blurring the line. I'd much rather people be honest and then we can all decide if we want to support a project and use it or not.

Anyhow, I think it would be interesting to see the subreddit policy updated. I personally like seeing how people are using AI especially if it's in a tech article format. Maybe we could update the subreddit rules to further ban/limit vibed projects while allowing tech articles about how something was vibed?

Maybe I'm totally wrong and y'all just don't care, but I'd like to hear other peoples thoughts on this as I think it's interesting.

Rant over

reddit.com
u/narrow-adventure — 1 day ago
▲ 27 r/golang

Small Projects

This is the weekly thread for Small Projects.

The point of this thread is to have looser posting standards than the main board. As such, projects are pretty much only removed from here by the mods for being completely unrelated to Go. However, Reddit often labels posts full of links as being spam, even when they are perfectly sensible things like links to projects, godocs, and an example. r/golang mods are not the ones removing things from this thread and we will allow them as we see the removals.

Please also avoid posts like "why", "we've got a dozen of those", "that looks like AI slop", etc. This the place to put any project people feel like sharing without worrying about those criteria.

reddit.com
u/AutoModerator — 1 day ago
▲ 33 r/golang

Local-first knowledge base for lazy people, written in Go

A simple application for .md files:
- Only necessary features, restrictions foster creativity
- No need to install anything, all you need is a browser
- Works offline
- Local first, you own all your files
- Free and open source, you can tweak it however you want
- Extremely simple code. One person or an LLM can fit the whole project in head
- Portable, no build systems, just open web/index.html
- Out of the box synchronization
- The server is just one binary (or use iCloud/Dropbox/Google Drive for sync)
- Telegram chatbot for on-the-go access to your files

You can save notes, journal, tasks and basically everything in .md files. The best and "lazy" way to do it is through "chat" flow.

Fun fact.
Server infra before the rewrite to Golang:
docker + php-fpm + php7 + larvel + nginx + redis + cron + worker + certbot

Server after the rewrite to Golang:
server, a 15MB no-dependencies binary that has everything.

That's my favourite part of Golang :D

github.com
u/RobinCrusoe25 — 2 days ago
▲ 48 r/golang

pkg &amp; internal directories are way overused

TLDR; Opting for a flatter structure typically guides you organically away from pkg and overly nested internal.

pkg is now used considerably less than it used to be. But it's still fairly common. Mostly because lots of folks coming to Go encounter the standard package layout repo and copy the structure.

pkg is an old vestige from the GOPATH era. Then other large projects like k8s went w/ the structure & never changed it because of the size of the projects and their backward compat promises.

But that doesn't mean we should copy that w/o asking why. The extra layer of nesting makes imports ugly and code discovery harder. pkg pretty much has no place in today's greenfield projects. But I also don't go around rooting it out of existing projects.

Another common one is abusing the /internal directory in svcs. I review a ton of candidate assignment submissions at work, and it's pretty common to see the entire app code shoved into the internal directory. The common rationale is abstraction.

But if it's application code, then no one is importing it. So shoving everything into the internal package is lazy design instead of properly structuring the core subpackages.

In libraries, internal makes sense to keep implementation details away from users of the API. Even there, creating three layers of nesting is a code smell.

Code organization is subjective & contexual. Giving general advice is extremely hard. But one thing I have found teachable is this:

  • Go already doesn't allow import cycles
  • On top of that, you should design your packages so that dependencies flow inwards. This means outer/adaptor packages can depend on core packages, but core packages should not depend on the outer ones.
myapp/
  order/
    order.go              // package order: Order, LineItem, Status
    repository.go         // package order: Repository interface

  postgres/
    order_repository.go   // package postgres, imports "myapp/order"

  http/
    order_handler.go      // package http, imports "myapp/order"

Here, postgres and http can import order, but order doesn't import either of them. The core package doesn't know / care whether it is being used by HTTP, Postgres, Kafka, or anything else.

This is the only generalized rule that goes a long way for most applications and libraries. Otherwise, eschewing unnecessary nesting and gauging the smell from import paths is the way to go.

Another thing I've found quite helpful is running go doc continuously while developing something. This way, I can assess whether the public API looks ugly and overwhelming from a user's perspective.

reddit.com
u/sigmoia — 3 days ago
▲ 0 r/golang

I spent 8 months building a Cloud-Native programming language in Go because JS bugs drove me crazy. Meet Jabline.

Hey everyone.

I want to share a project I've been pouring my soul into for the past 7 to 8 months. But first, a little backstory on how this even started.

Like many people, my programming journey started a couple of years ago building simple Discord bots with JavaScript, and eventually moving into frontend and cloud stuff. While I thought JS was incredible at first, the deeper I got, the more I found myself burning hours debugging the most frustrating, senseless bugs.

I started learning other technologies like TypeScript, Go, and Rust, and my mind kept going to this crazy idea: Why not just build my own programming language?

At first, I wanted to build something brutal for the backend, something to rival C. But then I asked myself: Why add another language to the pile if C and Rust are already the kings there? Then I looked at the Cloud. In my opinion, there is no undisputed king for cloud development. You either deal with massive runtime overheads, complex setups, or languages that let developers easily shoot themselves in the foot with concurrency bugs.

I was talking to a friend who is deeply involved in modern cloud tech, and I asked him what architectural focus the VM should have. He told me: "Focus it entirely on the cloud. Give it native concurrency and parallelism."

That was the spark. That is how Jabline was born.

So, what actually is Jabline?

Jabline is a dynamically-typed language (with an AOT static type checker) that compiles an AST down to bytecode and runs on a highly optimized, stack-based Virtual Machine written entirely in Go.

It is not just a toy language; it is designed specifically for Backend, Microservices, and Cloud Architectures. It takes the expressive syntax of TS/JS and combines it with the raw, lightweight concurrency of Go.

Here is what it is actually good for and why I built it this way:

1. It compiles to a single, standalone binary You do not need node_modules or massive runtime environments. You write your code, run jabline build server.jb, and the compiler tree-shakes the runner, bundles the bytecode, and outputs a single executable. You can drop this into a tiny Alpine Docker container or an AWS Lambda function, and it runs instantly.

2. Batteries are included for the Web If you want to build a backend, you should not have to install 50 third-party packages. Jabline has a robust Standard Library tailored for the web:

  • std/http for fast REST APIs with Graceful Shutdown built-in.
  • std/websocket for real-time chat/notification servers.
  • std/db for immediate SQL persistence.

3. True, Safe Concurrency Jabline exposes Go's underlying goroutines through a simple spawn keyword, allowing you to run asynchronous background tasks effortlessly. But to prevent the classic concurrency bugs that ruin cloud servers, the VM handles the safety:

  • Thread-Safe Globals: The VM uses strict Mutex isolation when closures capture variables, preventing data races.
  • Built-in Semaphores: The HTTP server and spawn tasks share a dynamic limit (currently 10,000 concurrent tasks). If you get hit by a traffic spike, it queues requests gracefully instead of crashing your server (no fork bombs).

4. It consumes almost zero memory at idle A huge issue with running thousands of concurrent tasks in Node/Python is memory starvation. Jabline VMs spawn with a micro-stack of just 256 slots (around 2KB). It grows dynamically based on the function's depth up to 65k. You can run tens of thousands of concurrent WebSockets on a tiny, cheap VPS.

5. Zero-Allocation Hot Paths (GC Optimization) To make sure the language is actually fast under heavy math or loop workloads, the VM recycles its own memory. I implemented centralized sync.Pool structures. Every time a function finishes executing, its execution Frame is wiped and returned to the pool, virtually eliminating Garbage Collector pauses during deep call stacks.

6. AOT Type Checking I hated getting runtime errors in production for simple typos. Jabline has an Ahead-of-Time static type checker. You can type your variables (let x: int = 5) and if you try to return a string from a function expecting an int, the compiler catches it and aborts before it ever runs.

An example of what it looks like:

import "std/http"
import "std/db"

fn handleRequest(req: Hash): string {
    spawn {
        echo("Processing analytics in background...");
    }
    return "Hello from Jabline!";
}

let server = http.server(":8080");
server.get("/", handleRequest);

echo("Cloud Server running on port 8080...");

It has been a crazy 8 months taking this from an idea born out of JS frustration to a stable, cloud-ready VM.

I would love to hear your technical feedback, especially from the compiler and VM engineers here. How do you handle GC pressure in your interpreters, and what architectural improvements would you suggest for the VM?

GitHub Repo: https://github.com/Jabline-lang/Jabline

u/Choqlito — 2 days ago
▲ 34 r/golang

Golang Fyne

I am about to build a quite complex application using the Fyne desktop framework, would you recommend anything else (I originally wanted .NET WPF but can't be bothered with C# and I love go way better), have you done a complex production grade desktop app with Fyne?

Complex I mean, multi window, talking to printers etc.

Thanks in advance.

reddit.com
u/N_Sin — 3 days ago
▲ 32 r/golang

How do you structure and maintain large Go modular monoliths without drowning in architecture ?

I’m working on an e-commerce backend in Go. Stack is mostly:

  • Postgres
  • sqlc
  • huma + chi
  • SuperTokens self-hosted
  • ERPNext as the single source of truth, with the backend mostly acting as a BFF/gateway
  • Stripe

I started with good intentions: keep things clean, modular, properly separated, and follow some DDD/hexagonal architecture ideas without going full enterprise Java mode.

But once the project grows, keeping everything “clean” becomes exhausting.

A lot of the time, I feel like I’m spending more energy maintaining the architecture than actually shipping features.

The things that constantly become painful are:

  • Wiring dependencies
  • Avoiding circular imports
  • Transaction management across modules
  • Figuring out where code should live
  • Keeping boundaries clean without creating tons of boilerplate
  • Deciding when an interface is actually useful versus just architecture cosplay

At smaller scale, Go feels amazing: simple, productive, and fast.

At larger scale, though, I sometimes feel like there’s a missing middle ground between:

  1. “Just put everything in handlers/services”
  2. Ultra-pure clean architecture with 500 layers and endless interfaces

For people maintaining large Go codebases:

  • What architectural style ended up working for you?
  • Any package layout patterns that scale well?
  • How do you structure modules or bounded contexts?
  • Do you use mediators, event buses, or domain events?
  • How much coupling do you tolerate in practice?
  • Any repos, talks, articles, or open-source examples you’d recommend?

I’d really appreciate practical advice from people who’ve gone through this already.

>Edit: Formatting for readability.

reddit.com
u/Prestigious-Fox-8782 — 3 days ago
▲ 88 r/golang

Crazy how Go long-term maintainability is opposite of some other languages, my 7 y/o BaaS is un-archived

Probably the next episode topic in go podcast().

I open sourced StaticBackend in January 2020, in June 2024 I decided to archive the project since I did not reach enough traction. Seeing how Supabase got so many funding, I got discourage

Fast forward to January/February 2026 where I was still in need of a quick BaaS for testing 2 projects (SaaS) at the same time, so why not see how it feel to un-archive it and restart maintaining the project. The title might be a bit misleading, the archive period was 1.5 year, but the project is 7y, it was closed source before being open source.

Feel great, the v1.7 GitHub release adds some nice quality of live with the server-side functions, multi account for user, improved query parsing/field type assertion.

I've maintained 20 years old software in C# / .NET. It's doable, and SB isn't 10y yet, but with Go you typically do not have the same issues / situation I lived and heard other say, which are mainly, the tech debt is reaching a point where no matter the amount of tests (system and user) you have, deploying innevitably will mean something breaks somewhere. This seems to be a little bit more manageable in Go, not completely sure why exactly.

Another diff with Go is how comfortable it is to jump back into a project, even after 1.5 year. Old systems sometimes just do not require daily updates. A 15 years old production system need a decently good reason to change it, especially if the original programmers that worked on the system are not available anymore. I feel we do not have this as much in Go, the situation where "ho no, Bob is not there anymore, only them knew how to do X" or something. You just open the code and change it in Go.

I've been saying this for years in the pod, but this to me is truly where Go has its strongest strenght. It's not sexy, you only experience this after a very long time, but it's there and system are trustable and easy to maintained even if it's not your code.

What is StaticBackend exactly?

It's just a Go backend API that's re-usable in multiple projects that offers most of the feature a typical web application need on the backend, user management, database, blob storage, server-side function, schedule tasks, realtime event / pub-sub, etc.

When I initially built it I was tired of writing the same old code over and over for authentication, database querying, etc. It evolves to what it is now, which is a stable backend API that can easily be self-hosted and a full local development via the CLI that requires no extra service installed (i.e. you want to target Postgres, you don't need it in dev and when deploying the code just work because StaticBackend handle PostgreSQL, MongoDB, sqlite.

Un-archiving again showed me how Go is great at long term maintainability, it's a 7 years old project and instead of getting more complex with tech debt, well it's like the opposite with Go.

Github: https://github.com/staticbackendhq/core

Website: https://staticbackend.dev/

u/dstpierre — 3 days ago
▲ 119 r/golang

I rewrote my Node.js API in Go (mostly stdlib). My Docker image went from 200MB to 10MB. Would love some feedback!

Hey everyone, I recently migrated my personal REST API backend from Node.js (TypeScript/Express) to Go, sticking almost entirely to the standard library (net/http, slog, testing).

I started learning Go late december last year, took a short break for work, and recently pushed through to finish this rewrite. I'm trying to keep the codebase lean, so I've stuck almost entirely to the standard library.

Here's the GitHub Repo: https://github.com/ccrsxx/api

The API handles Spotify and Jellyfin integrations (with real-time SSE updates), managing guestbook, implementing Auth with GitHub Oauth, and tracking views and likes for my blog contents. For the database layer, I fully migrated to PostgreSQL using sqlc for queries and goose for migrations.

There is one exception to the rewrite: I still run a tiny Express service specifically for generating Open Graph images. I rely satori library to generate it with HTML and Tailwind CSS. I couldn't find a Go library that handles this, and I don't want to write it from scatch lol.

The resource improvements is the most interesting part of this migration IMO. My Docker image decreased from 205MB (Node.js) to just 10.1MB (Go), and average RAM usage dropped from ~100MB down to just 10MB. Running this on my server feels so lightweight now. Screenshot: https://i.ibb.co.com/xKvQJRqN/image.png

Coming from JavaScript world, I honestly disliked Go's error handling at first, it just felt way too verbose. But now I actually love it. Treating errors as real values instead of just throwing exceptions and let it bubble, it makes the code so much more predictable, and it really forces you to think about every possible unhappy path.

(AI disclosure: I used AI for boilerplate like converting massive TS interfaces into Go structs, grasping DI patterns to learn, and writing some of the tests. However, the core logic, wiring, and actual implementation were written by hand.)

Feedback is highly welcomed! If there are more idiomatic "Go ways" to handle my logic, please let me know.

u/ccrsxx — 3 days ago
▲ 0 r/golang

Free go backend hosting Option

Hi Everyone, I have made some hobby projects in golang. I had hosted them on zeabur it was free and use to solve my purpose.Now it has closed free tier i have move to render but it goes for sleep due to inactivity. Any suggestions for hosting small backend applications for free ?

reddit.com
u/hrs8 — 3 days ago