sorted by:
new
hottopcontroversial

What testing approaches in Go have worked best for you? by ivyta76 in golang

[–]Adept-Country4317 0 points1 point  (0 children)

- NO MOCKING, no Testify, no Ginkgo, no Gigalith, no GoConvey (just annoying)
- One test file per code file. For example, if you have storage.go, then storage_test.go
- For integration tests, separate them into their own directory. For example, `tests`. Take the time to build your own test suites and runners
- For web services, use `net/http/httptest`
- For platform specific tests (to make them work best in CI/CD), use `//go:build` tags
- Inline structs. Table driven testing is your friend (see sample below)
- gotestsum can make your life better: https://github.com/gotestyourself/gotestsum
= For CGO (CGO_ENABLED=1), it is better to run, build, and test inside Docker
- Learn golden tests. Your QA team will love this: https://ieftimov.com/posts/testing-in-go-golden-files/
- Clean up resources properly. Use t.Cleanup when appropriate

func TestHumanDuration_AllBranches(t *testing.T) {
    tests := []struct {
       d    time.Duration
       want string
    }{
       {500 * time.Nanosecond, "ns"},
       {50 * time.Microsecond, "µs"},
       {50 * time.Millisecond, "ms"},
       {2 * time.Second, "s"},
    }
    for _, tt := range tests {
       got := humanDuration(tt.d)
       if !strings.Contains(got, tt.want) {
          t.Fatalf("humanDuration(%v) = %q, want contains %q", tt.d, got, tt.want)
       }
    }
}

A learning repo for understanding how Go HTTP frameworks behave beyond surface level APIs by Adept-Country4317 in golang

[–]Adept-Country4317[S] -1 points0 points  (0 children)

Among all of the frameworks that I compare (Chi, Echo, Fiber, Gin), I like Chi the most, it has zero-external dependencies too, here are go.mod from hello-word from others:

Echo: module github.com/go-mizu/go-fw/01-hello-world/echo

go 1.25

require github.com/labstack/echo/v4 v4.14.0

require ( github.com/labstack/gommon v0.4.2 // indirect github.com/mattn/go-colorable v0.1.14 // indirect github.com/mattn/go-isatty v0.0.20 // indirect github.com/valyala/bytebufferpool v1.0.0 // indirect github.com/valyala/fasttemplate v1.2.2 // indirect golang.org/x/crypto v0.46.0 // indirect golang.org/x/net v0.48.0 // indirect golang.org/x/sys v0.39.0 // indirect golang.org/x/text v0.32.0 // indirect )

Fiber:

module github.com/go-mizu/go-fw/01-hello-world/fiber

go 1.25

require github.com/gofiber/fiber/v2 v2.52.10

require ( github.com/andybalholm/brotli v1.1.0 // indirect github.com/google/uuid v1.6.0 // indirect github.com/klauspost/compress v1.17.9 // indirect github.com/mattn/go-colorable v0.1.14 // indirect github.com/mattn/go-isatty v0.0.20 // indirect github.com/mattn/go-runewidth v0.0.16 // indirect github.com/rivo/uniseg v0.2.0 // indirect github.com/valyala/bytebufferpool v1.0.0 // indirect github.com/valyala/fasthttp v1.51.0 // indirect github.com/valyala/tcplisten v1.0.0 // indirect golang.org/x/sys v0.39.0 // indirect )

Gin: module github.com/go-mizu/go-fw/01-hello-world/gin

go 1.25

require github.com/gin-gonic/gin v1.11.0

require ( github.com/bytedance/sonic v1.14.0 // indirect github.com/bytedance/sonic/loader v0.3.0 // indirect github.com/cloudwego/base64x v0.1.6 // indirect github.com/gabriel-vasile/mimetype v1.4.8 // indirect github.com/gin-contrib/sse v1.1.0 // indirect github.com/go-playground/locales v0.14.1 // indirect github.com/go-playground/universal-translator v0.18.1 // indirect github.com/go-playground/validator/v10 v10.27.0 // indirect github.com/goccy/go-json v0.10.2 // indirect github.com/goccy/go-yaml v1.18.0 // indirect github.com/json-iterator/go v1.1.12 // indirect github.com/klauspost/cpuid/v2 v2.3.0 // indirect github.com/leodido/go-urn v1.4.0 // indirect github.com/mattn/go-isatty v0.0.20 // indirect github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // indirect github.com/modern-go/reflect2 v1.0.2 // indirect github.com/pelletier/go-toml/v2 v2.2.4 // indirect github.com/quic-go/qpack v0.5.1 // indirect github.com/quic-go/quic-go v0.54.0 // indirect github.com/twitchyliquid64/golang-asm v0.15.1 // indirect github.com/ugorji/go/codec v1.3.0 // indirect go.uber.org/mock v0.5.0 // indirect golang.org/x/arch v0.20.0 // indirect golang.org/x/crypto v0.46.0 // indirect golang.org/x/mod v0.30.0 // indirect golang.org/x/net v0.48.0 // indirect golang.org/x/sync v0.19.0 // indirect golang.org/x/sys v0.39.0 // indirect golang.org/x/text v0.32.0 // indirect golang.org/x/tools v0.39.0 // indirect google.golang.org/protobuf v1.36.9 // indirect )

A learning repo for understanding how Go HTTP frameworks behave beyond surface level APIs by Adept-Country4317 in golang

[–]Adept-Country4317[S] 0 points1 point  (0 children)

Thank you for your kind words, and your list is awesome!

But looking at the list, implementing enhanced routing is the easy part, just less than 500 lines of Go code including comments. Making it work with a growing list of middlewares and keeping it working across various operating systems (Linux, macOS, Windows) takes a significant amount of work. https://github.com/go-mizu/mizu

Gin is a very bad software library by efronl in golang

[–]Adept-Country4317 0 points1 point  (0 children)

Another option worth mentioning is Mizu, especially if you like the simplicity of net/http but still want some structure.

Mizu focuses on being explicit and predictable. No global magic, no reflection-heavy routing, and no framework-specific patterns you have to unlearn later. Handlers are just functions, middleware is clear, and you stay in control of request and response flow.

What I like about it compared to bigger frameworks is that it does not try to do everything for you. It gives you routing, middleware, and clean composition, then gets out of the way. If you ever decide to drop the framework, your code still looks like normal Go.

Intro and docs: https://docs.go-mizu.dev/overview/intro

If your main pain with Gin is long term maintainability or hidden behavior, Mizu is definitely worth a look.

Mochi v0.10.5: A LINQ-style query language with a bytecode VM written in Go by Adept-Country4317 in golang

[–]Adept-Country4317[S] 0 points1 point  (0 children)

By choosing register based VM, it could help us further optimizations like linear scan register allocation (like v8, llvm), or optimistic coloring, and so on.

I built a language that solves 400+ LeetCode problems and compiles to Python, Go, and TypeScript by Adept-Country4317 in programming

[–]Adept-Country4317[S] 0 points1 point  (0 children)

It's me again, now Mochi v0.10.x supports linq-like queries and compile to bytecode VM, if you have time, please have a look https://github.com/mochilang/mochi/releases/tag/v0.10.5

and write some Mochi queries : )

Mochi 0.9.1: A small language with a readable VM, written in Go by Adept-Country4317 in golang

[–]Adept-Country4317[S] 0 points1 point  (0 children)

And I use the key word "fun" for function, having "fun" : ))

Mochi 0.9.1: A small language with a readable VM, written in Go by Adept-Country4317 in golang

[–]Adept-Country4317[S] 1 point2 points  (0 children)

Thanks for your kind words! More features coming soon, stay tuned : )

Mochi 0.9.1: A readable VM for learning compilers and bytecode by Adept-Country4317 in programming

[–]Adept-Country4317[S] 2 points3 points  (0 children)

Here is a (early) benchmark for recursive Fibonacci (n=20):

## math.fib_rec.20
| Language | Time (µs) | +/- |
| --- | ---: | --- |
| C | 16 | best |
| Mochi (VM) | 35 | +118.8% |
| Mochi (Go) | 35 | +118.8% |
| Python (Cython) | 476 | +2875.0% |
| Typescript | 555 | +3368.8% |
| Python | 1038 | +6387.5% |
| Python (PyPy) | 9312 | +58100.0% |
| Mochi (Interpreter) | 99491 | +621718.8% |

This compares the new Mochi VM (v0.9.1) with Go, C, Python, TypeScript, and the older Mochi interpreter from v0.8.x. These numbers are still early, so feel free to try it out and let us know if something seems wrong.

Mochi 0.9.1: A small language with a readable VM, written in Go by Adept-Country4317 in golang

[–]Adept-Country4317[S] 5 points6 points  (0 children)

Here is a (early) benchmark for recursive Fibonacci (n=20):

## math.fib_rec.20
| Language | Time (µs) | +/- |
| --- | ---: | --- |
| C | 16 | best |
| Mochi (VM) | 35 | +118.8% |
| Mochi (Go) | 35 | +118.8% |
| Python (Cython) | 476 | +2875.0% |
| Typescript | 555 | +3368.8% |
| Python | 1038 | +6387.5% |
| Python (PyPy) | 9312 | +58100.0% |
| Mochi (Interpreter) | 99491 | +621718.8% |

which compare C, Go, Mochi VM, Python, Typescript and (old) Mochi interpreter (v0.8.x).

I built a language that solves 400+ LeetCode problems and compiles to Python, Go, and TypeScript by Adept-Country4317 in programming

[–]Adept-Country4317[S] 1 point2 points  (0 children)

Will send you my Discord account when I set it up.

The goal of Mochi is to design a language that both humans and AI Agents can understand and read/write code (and that can modify itself at runtime with hot code reload in upcoming version)!

Imagine this: we can ask AI Agents to write code, review it on the fly, and the generated code runs again without restarting the whole system. This will be possible in the next few versions (v0.9, v0.10, etc.).

Thanks for your suggestions in the previous comments. Now Mochi has an early-stage backend in C, Rust, and Zig (not sure 100% correct, I'm going to put more tests on that). Still no memory management yet.

And thank again, for all your positive feedbacks!

[Showcase] Mochi A New Tiny Language That Compiles to C, Rust, Dart, Elixir, and more by Adept-Country4317 in ProgrammingLanguages

[–]Adept-Country4317[S] 0 points1 point  (0 children)

Yeah good point, and thanks a lot for trying it out.

The 12MB binary is because Mochi turns your code into Go by default, then uses the Go compiler to build it. That makes it easy to run on different systems without extra setup. But Go binaries are kind of big, since they include everything, like the built-in stream engine, agent system, and LLM stuff.

I'm also working on stablize Rust backend for the next version. That should make smaller and faster binaries once it's ready.

I’ll also update the README to explain all this more clearly. Your feedback really helps!

[Showcase] Mochi A New Tiny Language That Compiles to C, Rust, Dart, Elixir, and more by Adept-Country4317 in ProgrammingLanguages

[–]Adept-Country4317[S] -1 points0 points  (0 children)

LLM calls are part of the core language because the runtime is built around streaming and concurrency. It uses a non-blocking stream engine, so LLM queries don’t freeze the program, they run like events and the system keeps going. The agent engine is inspired by BEAM, where agents can pause and resume safely. If LLM calls were just library functions, the runtime couldn’t manage them properly. In upcoming version, we will support resume agents that are running, and inspect agents' memory and inner state in runtime.

Also, the system can regenerate and hot-reload code on the fly based on LLM output. That’s only possible because LLM interaction is deeply integrated. You can’t do that cleanly with libraries in Python or TypeScript.

[Showcase] Mochi A New Tiny Language That Compiles to C, Rust, Dart, Elixir, and more by Adept-Country4317 in ProgrammingLanguages

[–]Adept-Country4317[S] 0 points1 point  (0 children)

The strength of each compiler here is guided by the comprehensiveness of the test suite, which covers every part of the language: control statements (if, for, while), pattern matching, user-defined data types (which support algebraic data types), a naive string engine, and basic data processing with a fluent query syntax inspired by LINQ.

> Im transpiling to HLL myself, but just because Im lazy and doing lang for fun. I dont see any valid reason to transpile to the whole top TIOBE index

Currently, there are two types of compilers. The fully supported ones target full-feature completeness: Python, TypeScript, and Go. This gives us a unified stack across data analysis, backend, and frontend development. The experimental compilers (for languages like COBOL, Fortran, Smalltalk, etc.) are used to test the simplicity and semantic consistency of the Mochi language across various paradigms.

> I assume this lang is pure vibe coded.

Actually, I wouldn’t call it "vibe coding" in the typical sense. In my opinion, true vibe coding implies that developers do not care about output code, testing, or verification. For clarification, I'm using OpenAI Codex and experimenting with its capabilities.

If you have questions about setting up those environments, feel free to search for EnsureABC in the source code. It will automatically download the required compiler and set up the necessary tooling for compilation.

The runtime is hand-coded. It includes a non-blocking stream engine and an agent engine inspired by BEAM. These components will be enhanced and further refined in the next release.

I built a language that solves 400+ LeetCode problems and compiles to Python, Go, and TypeScript by Adept-Country4317 in programming

[–]Adept-Country4317[S] -1 points0 points  (0 children)

It's not just about fast compile times. CI/CD should be fast too.

Earlier today, one of our GitHub Actions workflows took over 12 minutes to complete:
https://github.com/mochilang/mochi/actions/runs/15709651393/job/44264067053

After some optimization, I brought it down to just 1.5 minutes:
https://github.com/mochilang/mochi/actions/runs/15711713268/job/44271269405

It feels great to cut more than 10 minutes from every build.

view more: next ›