Anyway, today I was discussing FFI between Rust and Go, specifically the overhead of calling Rust libraries through the C ABI using cgo.

Are there any scenarios where it actually makes sense to use Go's C ABI (via cgo) to call functions exported from Rust?

I often see people saying things like "calling Rust from Go with no overhead," but that made me wonder... does that really make sense? Is there any algorithm or workload that would justify writing it in Rust and then calling it from Go? I can't stop thinking about it.

To me, cgo clearly makes sense when interacting with C libraries, since that's exactly what it was designed for. But when it comes to Rust, I'm not so sure.

I'd love to hear your thoughts.

.

I often see people criticizing CGO (and for good reasons), mainly because it bypasses many of the safety guarantees and tooling that Go provides.

There are also issues involving the interaction between Go's scheduler and C code, as well as complications with callbacks. From what I understand, there can even be scheduling-related problems when interfacing Rust and Go through the C ABI.

However, I couldn't find any in-depth explanation from the Go team itself about why CGO is considered so problematic. More specifically, I'd like to understand why it's seen as so dangerous and what the actual sources of overhead are that make CGO calls around 30% slower (if I remember that number correctly).

This is mostly a personal curiosity. I'd like to better understand how CGO works internally, why it's considered risky, and where its performance costs come from. I'm even curious why, in some cases, it can be slower than calling WebAssembly.

form v1.9 — worth the upgrade from v1.5.x / v1.7.x

If your project pins an older github.com/ajg/form — v1.5.1 and the v1.7.x line are the versions most often seen in the wild, usually pulled in indirectly — v1.9 is a low-risk bump that folds in several years of hardening, new capabilities, and correctness fixes. The public API and the urlencoded wire format are unchanged, and every addition is opt-in or strictly additive, so upgrading is meant to be a drop-in go get -u (Go 1.17+). Nothing you rely on today changes shape; you just get more, and safer.

What you gain moving up from v1.5.x or v1.7.x:

• Resource-exhaustion hardening. Bounded slice growth and nesting depth by default, a fix for stack overflow on self-referential input, and an explicit MaxSize / MaxDepth / MaxBytes triad to bound untrusted input.
• Typed errors. form.Error now carries a Kind (syntax, parse, unknown-key, index, limit, unsupported, cycle, IO), inspectable via errors.As / Unwrap — no more string-matching to tell error classes apart.
• A form/multipart subpackage. Decode multipart/form-data (including file fields) straight into structs, following form's normal rules.
• **image/color hex decoding.** The fixed-channel color types decode from #rrggbb and friends — exactly what <input type=color> submits — with byte-faithful, opt-in hex encoding.
• Field-name mapping (KeysWith). Map struct field names to snake_case (or anything) at every level, without touching tags.
• **Reset for reuse.** Decoder.Reset / Encoder.Reset swap the stream while keeping config, so instances pool cleanly.
• math/big support, tested and documented.

v1.9 also fixes two bugs latent since at least v1.7: repeated-key implicit indexing silently corrupting slices, and MaxBytes(math.MaxInt64) reading empty instead of unbounded. A determinism fix makes conflicting scalar/composite key paths (a=1&a.b=2) resolve the same way every time, and the library is now fuzz-tested and input-contract hardened.

Full notes: https://github.com/ajg/form/releases/tag/v1.9.0

Static embeddings are very simple embeddings where each words or phrase maps to a fixed vector. The benefit of this approach is they are extremely resource efficient, fast, and don't require GPUs. Embedding quality is lower than transformer models but often still acceptable.

I've created a go library that supports the potion family of models from model2vec. By building the tokenizer from scratch just to target static embedding models it is significantly faster than the original python and rust libraries at non-batch encoding and can encode 20k-40k vectors per second dependent on the model.

Would love to hear any feedback!

Disclosure: I heavily used Fable in generating the tokenizers, to mitigate this the test suite validates embeddings are within tolerance of the reference implementation.

I have been building Rice - a minimal embeddable scripting language for Go applications.

Here are its features:

• Dynamic-typing
• Functional programming support
• Lightweight standard library
• Single-threaded execution
• Built-in profiler
• Verbose error-reporting
• An officially-made LLM prompts attachable to AI agents

Rice currently runs as an interpreter, with a bytecode virtual machine planned for a future release. I’m using this in my personal projects. It could be too early for production-grade applications.

You can try Rice at https://rice-playground.vercel.app/

Learning Rice: https://github.com/anhcraft/rice/tree/main/guides

Check out the repository at https://github.com/anhcraft/rice

I am looking for feedbacks and stars xD

This is basically an appreciation post and also curious on the community's opinion. I came originally from R (I'm a data analyst, not a dev) and there was F-all error handling. I did a lot of automation work in R and compelled to learn Python because all the API drivers were written for Python (was never intending to touch Java) and it was basically an "easy" language to pickup. I dabbled in Go since 1.11 probably but never got the chance to really build a project. Around that same era I was learning data-driven web applications, and got my hands on Django 2, which was awesome. I could ingest all these data from all these APIs and have it run on a browser. But the bloat got to me and swore on Flask.

Then came containerization. Which at the time I had no idea was fundamentally built by go (docker, podman, kubernetes , etc). Which I used a lot especially since I had to work a alot with cloudrun. It was always a flask or python app on cloud run. But after all that, no error handling, I almost never used try catch unless explicitly needed. The pivotal moment for me to try Go again was when net/http fixed its routing capabilities -- 1.22 I think, it was more like flask/django so naturally, I felt at home. But the error handling annoyed me at that time.

Now I'm building some sort of sentiment and relevance analyzer (another LLM wrapper of course, 'tis the trend of the season) and damn it I love the explicit error handling, especially with slog.Error, its like I was really missing out all these years. The way it reminds me to tag all the issues so i can easily troubleshoot is a godsend. I've heard a lot of people shitting on this saying its bloat but honestly for me it makes me more mindful.

High speed JSON encoding options using only the std library. I don't have specific code to show, but thought this was an interesting topic. I was in the process of changing from std json.Encoder to writing the raw json to a bufio.Writer, but discovered the new json/jsontext pkg provides great features for high speed json writing. See jsontext encoding.

My particular use case (single http response type that includes pre marshalled data) is a good fit for these techniques. Until recently I did not realize what options were available. I also tried replacing [][]byte with []json.RawMessage, but that approach was not helpful.

There are other related topics such as using compression and sync.Pools for the bufio.Writer and gzip.Writer.

AI (Gemini) seems to give inconsistent recommendations in this area, so beware.

Hello I am new to GOLANG and need some advice,

This post is regarding how professionals log their data(IE: errors, debug / info etc), is it best practice in go lang to have log statements scattered throughout the code base or a central logger that uses bubbled up errors?

This all is in regards to a web server backend using HTTP requests. Currently I have log statements that print the errors, certain info during startup etc.

If any more information is required or if this post is too "vague" let me know!

EDIT: This has been solved, thank you all for your information and feedback.

Currently, the only html formatter library I found are github.com/yosssi/gohtml and github.com/Joker/hpp.

However, they do not format javascript within <script> tag.

wasm fmt, a vscode extension, can format html and javascript within. However, its codebase is js+ts.

Anyone has any suggestion?

PS: I am looking for go library, not cli tool.

When AI coding assistants like Claude add packages to your project, they often pick whatever version sounds right — without checking whether it has known security vulnerabilities, whether the package is still actively maintained, or whether the name is a typo away from a malicious lookalike.

safer-dependencies is a security layer for Claude Code that audits packages before they’re added to your project. It detects and fixes risky dependencies, including CVEs, typosquats, abandoned packages, version-age issues, and adds package-cooldown periods across npm, PyPI, RubyGems, Maven, Go, and Rust.

Github: https://github.com/robert-auger/safer-dependencies

It occurred to me a few weeks ago why programming languages don't just try add metaprogramming capabilities with comments, without modifying the original compiler. So I went ahead and experimented how would it look like in golang.

So far so good! It's basically go templates that take in any package level go symbol and write code into a meta.go file.

You can do the same with the go/ast package, but metago makes it very easy to add your own custom transformations. No build tags, just write .metago templates, annotate structs, and run metago.

So far I've managed to make stringer, enums, mocks and even an efficient json serde template with metago. As an experiment, there's also a typesafe active record like orm in the repo. So you can do a lot with it!

Hey Gophers! Sharing this for anyone in Latin America or planning to visit Brazil in September.

GopherCon Latam is the largest Go conference in Latin America, now in its 9th edition. This year we're expanding to 3 days at CentroSul convention center in Florianópolis, SC.

Confirmed speakers include Bill Kennedy, Elton Minetto, Tiago Temporin, Daniela Petruzalek, Filippo Valsorda (ex-Google), and Jonathan Amsterdam from the Go team.

• 31+ speakers, 6 keynotes, 4 workshops
• Talks in Portuguese, English and Spanish
• 1,500 expected attendees

Use code GOLANG10 at checkout for 10% off - https://www.blueticket.com.br/evento/37825

Right now I have a back-end project in go lang that consist of the following folder structure

main.go internal/

internal contains subfolders such as api, assets, configs, pkgs, server, and folder such as users, which has a users/store.go and store/users.go almost each table or data point has a folder with a store and name.go

in my server I have a http folder which includes handlers.go handlers_users.go, http etc. etc.

my main.go includes things such as :

us, err := users.NewService(l, mail, userStore)
    if err != nil {
        _ = logger.Fatal(fmt.Sprintf("%+v", err))
        return
    }


    ts, err := tenants.NewService(l, tenantStore)
    if err != nil {
        _ = logger.Fatal(fmt.Sprintf("%+v", err))
        return
    }
a, err := api.NewService(us, ts, userSession, pqdriver, mail)
    if err != nil {
        // _ = logger.Fatal(fmt.Sprintf("%+v", err))
        return
    }


    httpCfg, err := cfg.HTTP()
    if err != nil {
        return
    }


    cookieCfg, err := cfg.COOKIE()
    if err != nil {
        return
    }


    h, err := http.NewService(httpCfg, cookieCfg, a, userSession)


    if err != nil {
        return
    }

The question is, if I wanted to have a MQTT ingestion, should I add this in the same back-end project or should I create a new project for this?

my first thought is to not run it in the same binary as if the back-end is down the mqtt ingestor is also down..

Edit: since the ingestor would need to access some domains/ methods of the back-end I think it might be better to use the same codebase but either way have two separate binaries..

I have an fairly large app that i've built from the ground up and im contracted to maintain for the foreseeable, so I want to follow best practices and make my life easier.

I'm a team of 1 so I have no other Go developers to bounce ideas off.

So here's where I'm getting confused:

Imagine you've got an exam taking website, and users can purchase certificates, I've got packages such as:

• exam
• exampurchase
• student
• organization

The exampurchase package for example, the service has a function like so:

package exampurchase

import (...)

type MarkExamPurchasedParams struct {
  ExamID int64

  PaymentProviderTransactionID *string
  PaymentProviderPromoCode     *string
  PaymentProviderCouponID      *string
  PaymentProviderPaymentType   []PaymentType

  OrganizationNumber *string

  // PurchaserUserID is the ID of the user who is paying for this exams certificate. It can be the student themselves or their manager.
  PurchaserUserID *int64
}

func (s *Service) MarkExamPurchased(ctx context.Context, p MarkExamPurchasedParams) error {
  ...
}

This MarkExamPurchased function is used by a lot of other packages, because exams can be marked as purchased in many different ways (by the student, via a stripe webhook, by their manager)

But to avoid circular dependencies, i'm basically re-declaring the params and the function signature in other packages.

For example, in organization:

package organization

import (...)

// Copied from exampurchase
type MarkExamPurchasedParams struct {
  ExamID int64

  PaymentProviderTransactionID *string
  PaymentProviderPromoCode     *string
  PaymentProviderCouponID      *string
  PaymentProviderPaymentType   []PaymentType

  OrganizationNumber *string

  // PurchaserUserID is the ID of the user who is paying for this exams certificate. It can be the student themselves or their manager.
  PurchaserUserID *int64
}

type ExamPurchaseService interface {
  MarkExamPurchased(ctx context.Context, params MarkExamPurchasedParams)
}

// Now I get to declare it as a dependency of this service, no import of exampurchase
type Service struct {
  repo                Repository
  examPurchaseService ExamPurchaseService
}

Is this correct? It feels like a lot of duplicated code, but in the same breath, the packages no longer need to import one another.

Just checking with others, looking for a discussion or even a thumbs up this is considered good practice?

I am trying to write Go code, but I have no idea in which IDE to write it, nor the secondary memory to install additional IDE like Visual Studio Code.

So how to write Go code in Visual Studio Community or Notepad? I have installed Go though.

Airfoil simulator write in Go.

Don't take it too seriously; I did the best I could, but the simulation has many issues, and I couldn't find the correct airfoil profiles.

However, the simulator is open source, and I accept code contributions.

https://github.com/crgimenes/kutta

Hello there!

I have been exploring gRPC, here I have written a blog post explaining the common concepts and tried to cover things which were unclear to me when I was going through the tutorial.

Hope it helps and would really appreciate feedback.

It is not AI generated, although have taken assistance in some places.

I have to implement transaction handling into my system.

I have two methods that are found on the internet.

1. Explicit parameter pattern

2. Context injection pattern

I have implemented the option one. But it has a problem.

I need to pass the db connection to the repository to each repository method call.

And also option 2 also has a problem. Usually we do not pass the db connection to the service layer. We just init the repository with the db connection and inject it into the service layer. But in the second option we have to maintain a db connection to handle common connection across multiple repositories that belong to the same transaction.

I need help to choose a good industry standard transaction handling pattern.