Learning golang and building efficient backend systems has been a lot of fun for me. Great language!

can't wait to see go 1.21 that introduces memory battle royales!

I love how people are rediscovering Arenas again! They are pretty much all I use for all my allocation needs because an arena equates to a lifetime group for allocations. And using arenas (like in Odin), you can just free all of the things at once rather than individually (e.g. paired malloc/free in C), which means in practice, you rarely need to free anything manually and just allocate when needed. And because arenas are really simple allocators, they are as fast as they can possibly get compared to any other memory allocation strategy.

6:05 regarding Go's GC. This is a very simplified overview because I can't detail it all in the comments, but the GC in go is mostly concurrent. It's a mark and sweep GC and when it kicks in, it takes 25% of the cores to identify what needs to be cleaned and what can live on. It does stop the world for a little bit for the cleanup but in general allocations can still happen when the GC is working since 75% of the go routines running are doing your work as opposed to 25% for the GC. I love Arenas btw.

Arenas make memory management in C almost trivial, so I'm very excited that Go is getting them too. It seems like Go is going in the right direction as opposed to other modern languages in my opinion.

I use memory arenas for some years now in C, it does not only improve performance over malloc everything, it also simplifies memory managment. You think more about lifetimes of groups then lifetimes of individual allocated objects (and free everything at ones instead of one by one.

Love your energy and passion doing these update videos, while also digging into the details. Keep it up friend!

I can see prime is starting his go arc

This was your best content in a while. Straightforward and informative, gg

One of the best articles, piqued my curiosity to know more about go GC!

Unfortunately, as the article notes, this memarena proposal is currently on hold and, as Ian says, "No decision has been made and likely won't be made anytime soon." So yeah, I was really excited about this feature as well, but now a bit conflicted feelings about it

Arenas + deferred is my favorite part of zig. Super curious to see how golang does with arenas

Love this addition to Go. Slowly experimenting with pushing the language forwards

I think in the javascript vs go example, Go would probably have to track pointers to other things and track that separately. However, if you are using a value, it would be just like part of the struct as in C (the same block of memory). I think a good example of this is slices where the slice header has a pointer to an array under the hood, similar to a standard array list. Copying a slice header would copy the pointer to the array, but not the array. If you do stuff to that slice while the original is unchanged, I think the copied one will eventually create a new array. Run the below test for example. You should see the capacity changing and the appends I think will cause a copy to new arrays in both. But in this case they'd be different arrays now under the hood. func TestSlice(t *testing.T) { s1 := []int{1, 2, 3} s2 := s1[1:] t.Logf("s1: %v, s2: %v", s1, s2) t.Logf("s1 len: %v, cap: %v", len(s1), cap(s1)) t.Logf("s2 len: %v, cap: %v", len(s2), cap(s2)) s2 = s2[1:] t.Logf("s1: %v, s2: %v", s1, s2) t.Logf("s1 len: %v, cap: %v", len(s1), cap(s1)) t.Logf("s2 len: %v, cap: %v", len(s2), cap(s2)) s2 = s2[1:] t.Logf("s1: %v, s2: %v", s1, s2) t.Logf("s1 len: %v, cap: %v", len(s1), cap(s1)) t.Logf("s2 len: %v, cap: %v", len(s2), cap(s2)) s2 = append(s2, 4) t.Logf("s1: %v, s2: %v", s1, s2) t.Logf("s1 len: %v, cap: %v", len(s1), cap(s1)) t.Logf("s2 len: %v, cap: %v", len(s2), cap(s2)) s1 = append(s1, 5) t.Logf("s1: %v, s2: %v", s1, s2) t.Logf("s1 len: %v, cap: %v", len(s1), cap(s1)) t.Logf("s2 len: %v, cap: %v", len(s2), cap(s2)) }

Yay arena allocators! About time Go caught up with... C. 😂 But really though, one of the things proper modern languages should have is easy, pluggable, context-based memory allocator management.

This is the first time I’ve learned about arenas, this looks amazing

Whoever wrote this blog post is a genius! Instant sub for sure!

Golang is awesome! It was _really_ annoying when it did not have Generics. But now that it fixed this major problem, its incredible!

6:02 Yes, it is. In one application I made for Domotic, the program creates an array of about 2GB so that GC is only called when a lot of memory is used. There is probably a better way to do it, but that worked at the time and was never changed.

Props to @acornspits in chat for saying "Don't pee in the pool" when buffer pools were brought up😂😂 That made me laugh harder than it should of

This is effectively like a stack memory that is unwound and returned once you are done with whatever you wanted to do. Ofcourse it's a lot more flexible and I can imagine you can implement this directly on top of an OS call to fetch / return memory pages. So you use a whole page at once and return it once you are done.

Maybe it has changed in recent versions, but the Go GC used to work by stopping the world long enough for the GC thread to scan memory, then it would release the global lock and deallocate unused objects in the background. Of course, this applies only to memory on the heap; if you can avoid the heap altogether, then you can avoid spending time in the GC stop-the-world (easier said than done, especially if you have data that needs to be accessed concurrently via Mutex/RWMutex).

That manual gc stuff you're doing in node is very very very similar to what we're having to do in our maui app in C# because MAUI has memory ISSUES

You know this was edited by chatGPT when the text feels the need to remind you that this feature is currently experimental and unsupported three times.

So this is basically the concept of having specialized heaps in C/C++. One of the cool things about computer programming is that we reinvent the wheel, over and over with new tools.

Historic new paradigm - a chunk of memory that you get to use!

Looks like a feature which you can benefit the most when you know that you are about to load a huge amount of domain aggregate objects into memory. It is hard to imagine how Go decides which can go into one arena.

Dmitry Filimonov is the CTO of Pyroscope!! Cool!! Once I helped the company I was working for with Pyroscope. Team loved it. I did too.

This makes go more attractive for things like gamedev or other general app development

Prime should give classes on stuff; maybe api-gateways, docker, prisma, and other common software?

That sign off was amazing -agen

I find it quite amusing that were solving problems like its 1999 😄 yes it does help but its literally the same as writing a custom allocator for c. I would even argue that this isnt suited for go as go is meant to be simple and foolproof. This adds quite a few pitfalls to keep in mind

Looking into it it looks like something simmilair to ECS principles? It's interesting how much GameDev usually associated stuff can still be utilized in traditional workflows

Thank you for this kind of content loko, I really enjoy it.

Good to see but is a pretty standard solution to this problem. Using fixed type memory pools built on large slabs of preallocated memory is common in C, C++, Java, etc.

We used to call this concept in C++ a memory pool. Looks like it's the same thing or I didn't understand it correctly?

Yes, Go does have "Stop the world" garbage collection. Erlang does garbage collection as an event, which is local to that event loop. It's about the only version of garbage collection that I thought was manageable.

Fun fact I learned recently: LISP had garbage collection in 1960, 3 years after Fortran was invented and 22 years before C. LISP was also the first language to use a memory heap, so garbage collection actually *is* "traditional memory management."

i think we need a video or course on optimizing node applicaiton.

read Jason Gregory's Game Engine Architecture once and it has a chapter on allocators and memory pools. well worth a read that book, but its a chonky tome

I wish every GC collected language had this. In C# one could just spawn a bunch of UI nodes (like in unity's UIToolkit) and be able to delete all of them later

I never understood the point of garbage collection. For simple allocations it doesn't provide any benefit and for complex allocations it doesn't do what you want and you need to do some weird tricks to try to make it do the right thing. And all the time there is this mysterious performance killing process going on in the background which is extremely difficult to observe or control. As a C++ programmer I never do manual memory allocation on principal and everything "just works" and is super fast.

So now I can decide to use GC only or use this "kind of" manual memory allocation, right?

I think the Go team should get a z80 banked system so they can realise that with banked memory management it is not so dissimilar to arenas, which is a very common memory management paradigm

Is it possible to implement arenas in JS? With ArrayBuffer I guess

Maybe it's stupid question but GO with borrow checker is possible?

Okay, so I'm still waiting for when the competition and contention is being explained, and there's some kind of bits and bytes destruction with fitness functions going on. Disappointingly it's just all talk of memory pooling. I mean, I get it, the term memory pools instantly puts sweat on my forehead, all the prerequisites and thought and planning that goes into using a memory pool properly, designing data structures so they can be reused (mutability ugh), fetching and releasing them, dealing with being over limits, resizing strategies. I mean, judging by the explanations and context given here, this sounds like runtime managed memory pools. An improvement on manual pools, but still sounds like pools.

Other than DreamBird, Go is the greatest language to have been concocted by the wizards.

Interesting... appears to me that someone realizes that "Java Heap Space" is not a bad idea at all ... but I liked a LOT that Go is evolving memory management!

id tune in on twitch if you did some more go stuff

Leptos is so good that it is the sole reason you continue to use Rust? Damn, that's high praise.

Write code in C++ and use custom memory allocators and RAII, use flyweight pattern. How would you flyweight in go😂?

Rust has bumpalo for arenas, I wonder if you could write a nodejs package that exposes a rust-based arena interface using Neon

I love Go

Getting this correct without borrow checker will be "fun".

So we are going form OOP to DOP

12:52 Why pop all the items before nulling their array? If something other than their array held pointers to them, the gc() would not clear them anyway.

make more Go content thanks.

Leptos and Greg Johnston are great

"what is this" 00:00 ChatGPT Editor

So, it's like Mark() and Release() we had in Pascal in 80s?

OCaml for backend projects?

RAII and smart pointers also eliminate the need for manual memory management with minimal overhead.

Go uses a lot of energy

serious C programming been doing arena memory management approach for decades

If you need frequent memory requirement, why sync.Pool{} ?

Clap for greg! Clap Clap Clap

I guess wasm does not help you with your node memory problem at Netflix?

Primeagean moving away from Rust apart from Leptos? A couple of months ago it was a lot of praise. Anyway :) Cool that you're exploring different languages, Zig, OCaml etc.

Wow - what's old is new again. The Amiga had this concept decades ago, called "Memory Pools". You can make and release small allocations out of the pools, and then free the whole pool at once.

@5:30 Yes, latency from GC is a big issue in most languages. One reason Erlang's GC system is so interesting and why a server in Erlang can have much better overall latency and performance characteristics than other dynamic languages and even compiled languages with GC. Working in fintech... the hoops Java devs have jumped through over the years to remove latency is entertaining. At the end of the day they mostly end up doing most of their own memory management after sometimes years of painful rewriting and profiling. Sometimes custom JVMs are needed.

go discovering america

Editor ChatGPT lmao

Wait i thought this got pulled / permanent hold due to API issues?

It surprises me that you actually call the GC in node. The only times I tried it, it actually made performance worse.

Chat gpt as an editor

Go is the greatest language I've never tried.

I really didn’t like Js prototypes before Go. Now I think they’ve brought me a lot of fun compared to boring go syntax(I mean I like go syntax a lot, but not in this case)

Remember when the Java team said that nobody should use reflection? Good thing that nobody does...

Arenas

I've written a few hundred projects in go and I honestly think this feature will lead to more wasted time than anything. Go needs to change how it allocates memory by having memory semantics. This could be achieved through the type system internals but instead of doing that they add generics and more ways to complicate your memory model. Every problem their generics implementation solves could have been covered by allowing interfaces to specify data, allowing structs to have predefined values (thus omitting the need for interfaces in the first place), or just allowing operator overloads (which would also solve some of the problems the current generics implementation introduced). It's crazy to me. They work so god damned hard to solve irrelevant problems. Parametric syntaxes are all you need.

Golang is top language.

All my homies use rust 🦀🦀

Golang is probably the greatest language ever made. Small, simple, pragmatic, fast, powerful.

In JS you can also do... array.length = 0 And then call gc. It works in the same way.

Young generation GC is part of JVM for 20+ years and you don't have to use any programming to trigger it. Easy peasy

Is go slowly turning into a low level language? Bcz that's what I'm getting from this video

isin't there a max size for each network request like 64k can't you just put it in the stack and forgot about it. i mean that what i did in c 😂

A naive mark & sweep garbage collector can even pause for several seconds in extreme cases.

Go ftw

Garbage Collection as memory management is older than C.

wow another 1960s concept making its way into a 2023 language. I guess that's... progress?

Use Rust?

I really wanted to give golang a try but not being able to compile my code if I have an unused import or variable is a bummer. The fact that golang team isn't officially introducing a flag or something to be used while debugging the code is saddening. Their stance is "it will make the compile time slower & result in bad code" is childish. Many language compilers remove unused codes when building for production, but treat unused imports/variable a warning instead of an error. But golang is like, "we don't do it here" 😑 not gonna use golang unless they fix that issue. Otherwise sticking with rust and typescript. Thanks to golang team for upsetting so many new golang learners & forcing them to never try golang again 👏

Htitty :D

PrimeFeet

so java does it and it's a "java finally arrives at 2010 kekw", but go does it and it's a great, awesome, well designed language?

O

There you go… all the Rust foundation shitshow has started to alienate even the Primeagen

lol jq