Go Experiments Explained

6/5/2026 at 7:25:02 AM

I'm really looking forward to SIMD becoming standard in Go. It might sound very niche, however SIMD intrinsics (which is different from how they are available now, which is via non-inlinable assembly) allow to generate similar vector code to C intrinsics, with very little in terms of overhead due to bounds checking, etc. This allows to write programs that are highly optimised for modern CPU and get maybe 80% of performance compared to the same variant in C. This is much better than the current state where C typically outperforms Go by at least 2x/3x, and SIMD typically allows you to get 10x or more speedup already, which gives UNLIMITED POWER to Go when CPU performance is a bottleneck

by nasretdinov

6/5/2026 at 12:32:20 PM

For C# is fun using intrinsics, you can almost match C speed for some tasks.

by DeathArrow

6/5/2026 at 9:40:39 AM

I bought Alex's "Let's Go Further" book a while back, I really should spend some time with it.

I want to learn Go.

by losthobbies

6/5/2026 at 1:09:31 PM

Pick a problem you’re interested in and just work on solving it, in go. The best way to learn is to hit the rough edges and just keep going.

If an oldie like me can learn go well so can you

by SEJeff

6/5/2026 at 2:14:49 PM

I am a bit of an oldie too (44) and my background is in C#

I am thinking of making a CLI scoundrel card game.

by losthobbies

6/6/2026 at 1:39:06 AM

I’m 42, never went to college (I joined the army) and am now a Principal Security Engineer at a serious computer security firm. I’ve got a background in Linux high performance computing and software engineering.

If I can do this, anyone can. I believe in you internet friend. In tech, every day’s a school. Embrace it and learn something new daily, or get left behind. You’ve got this

by SEJeff

6/5/2026 at 11:37:54 AM

[dead]

by bithckr

6/5/2026 at 11:38:35 AM

I’m leaving JSONv2 enabled and writing my JSON code to use that API directly.

From what I understand, it’s not default because there are performance regressions in some edge cases. But the typical performance is much better and the API is also much better.

To anyone writing new code that does anything with JSON—turn it on. Use it. I think it will be on by default soon enough anyway (1.27).

by klodolph

6/5/2026 at 5:54:20 AM

I find the arena experiment very interesting. If done right, whole programs can be structured as as a set of arenas. I've read some things on arenas here such as https://news.ycombinator.com/item?id=37670740

by ktpsns

6/5/2026 at 6:21:22 AM

Once allocators in general click, memory management in C becomes a total breeze.

Combined with typed fat pointers (slices and strings), typed hashmaps and stack-trace-assertions, C in general becomes quite nice. The rest is compiler flags.

Go solves this by being a better language out of the box, but with the Wirthian aspects removed they feel very similar. Perhaps not so surprising.

by fredrikholm

6/5/2026 at 6:55:59 AM

I am a low-level zig guy right now too. I have been around for a long time, and it’s funny to see arenas come back into vogue as a solution to nearly everything.

Arenas are great for avoiding allocations per tick/request/frame/layer. No symmetric free() to bracket lifetimes! They have a purpose, and we always knew that.

But by definition, your program is over-allocating as a tradeoff. Makes a ton of sense in certain use cases. However, we didn’t invent garbage collection and borrow-checking and realloc() just to publish papers ;)

Half of my time programming zig is spent considering allocation strategies. That’s a feature. “Where are the bytes?”

by b33j0r

6/5/2026 at 12:31:55 PM

We invented those strategies when we had way less RAM. Vast majority of programs could be entirely allocated upfront those days.

by d3ckard

6/5/2026 at 6:03:34 PM

The reason why so many programs could be allocated upfront is because if they couldn’t, maybe we just didn’t write the program.

by klodolph

6/5/2026 at 1:25:50 PM

I wonder if they can solve the "ecosystem fracture" issue by borrowing the bubble concept from e.g. testing/synctest. The way the synctest API works is by creating a "bubble" around the test harness and the code under test such that the standard library's time package behaves differently, but only for the code running in the bubble.

So, maybe we could also have allocator bubbles, where code running inside the bubble is just as allocator-naive as any other Go code, but when it allocates (make/new/pointer escape), it uses the bubble's allocator instead of the default one.

The big problem I can think of, though, which doesn't apply to time bubbles, would be that pointers drawn from that allocator might escape the bubble (e.g. by assigning them to a longer-lived struct field). It's possibly something that can be detected by the runtime, but because the API is non-invasive by design, it's not something that will be apparent to the programmer when looking at the code.

by kbolino

6/5/2026 at 7:08:37 AM

Perhaps the Go community should take a look at JEP or PEP to better document features and their life cycles and statuses overall.

by jiehong

6/6/2026 at 1:44:54 PM

That's not the spirit of Go. They will implement their NIH version of JEP/PEP, just one with an awkward interface, held together with duct tape, and missing obvious functionality, then do another round and get 70% of what JEP/PEP do in a second attempt after 10 years.

by coldtea

6/5/2026 at 9:36:28 AM

It depends. I read JEPs quite often as part of my job. They are nice as a sum up of the intent behind the feature but they kind of hide the discussion and commits. Also one Java feature may encompass multiple JEPs.

Go‘s github discussions on the other hand, give me live-view of the latest state of the experiment. I find both useful and don‘t prefer either.

by p2detar

6/5/2026 at 8:11:42 AM

That would be asking too much, learning from older languages experience.

by pjmlp

6/5/2026 at 5:02:20 AM

So, these are feature flags by any name, right?

by yjftsjthsd-h

6/5/2026 at 6:42:47 AM

No. Feature flags are a mechanism for enabling some of the experiments. But what’s being discussed here are the features themselves.

by hnlmorg

6/5/2026 at 7:09:00 AM

Hm, that's interesting; chrome://flags does seem to be titled "Experiments"... After, of course, you type "flags" into the address bar to get there. I guess I can see a distinction there, but it's pretty subtle.

by yjftsjthsd-h

6/5/2026 at 4:44:22 PM

This has nothing to do with Chrome.

This is Go (golang). It’s not even the same language used in the development of Chrome.

And the reason I make the distinction between feature flags and this is because some of the “experiments” discussed in the article are new packages / modules. So you’re not changing compiler behaviour via a flag or env var. You’re just importing a new package that isn’t yet considered stable.

by hnlmorg

6/5/2026 at 7:01:47 PM

I think the way Google handles flags/experiments in one project (Chrome) is very relevant to interpreting the language around how they handle flags/experiments in another project (Go).

And I'm pretty sure that their example is that importing "encoding/json/v2" doesn't work until you tell the compiler to enable it via environment variable.

by yjftsjthsd-h

6/6/2026 at 1:48:38 PM

>I think the way Google handles flags/experiments in one project (Chrome) is very relevant to interpreting the language around how they handle flags/experiments in another project (Go).

You'd think that, but you'd be wrong. Parts of Google can and do things their way. There's not an all-encompassing "Google way". And even if there was one, the Go team is notoriously doing things its own way.

by coldtea

6/5/2026 at 11:01:32 PM

Google is a massive company and your json is example is literally a different module entirely!!

I assume you’ve got experience in the subject you’ve got an opinion on?

by hnlmorg

6/5/2026 at 8:04:31 AM

CUE, originally starting as a fork of Go, has the experiments capability too and even extended it to per-file scoping. This makes trying out changes like `try { a: b?.c }` in isolation really nice

Go remains my favorite language for the tooling alone (while not forgetting about so many other great features)

by verdverm