See also #33060.

Issue #29696 is meant to help with using too much memory, by letting you specify the max heap and get a callback when you are using too much memory, to shed load. That definitely helps with "monitor the currently running program's memory usage".

If "query the currently available RAM" means the RAM on the surrounding operating system, that's much harder. You can find out how much RAM the OS has, but you don't know how much should be used by other programs, nor how much should really be left for the OS's file cache to avoid thrashing on file access or even executing different pages of an executable. I'm not sure we're going to solve that ("tell me how much RAM I can use").

Closing as a duplicate of #29696.

letting you specify the max heap

I do not want to limit my own use of memory, I want to delay launching other tasks in entirely different programs according to currently available memory.

If I limit my program to use an arbitrary amount of RAM, then it's impossible to have a single executable that can behave itself correctly on both a Rasberry Pi and a developer's machine. I could add a configuration, but it's absolutely useless if I'm orchestrating entirely different programs on the same machine.

You can find out how much RAM the OS has, but you don't know how much should be used by other programs

Simple enough : Whatever they want. I'm not here to dictate how other programs behave, I'm here to dictate my own behaviour according to available resources. If I choke my systems by using too much RAM, then it's my fault and no one else's.

You don't know how much should really be left for the OS's file cache to avoid thrashing on file access or even executing different pages of an executable.

That's my problem, not the standard library's. It's nice to have high-level suggestions like that, but it's unnecessary.

I'm not sure we're going to solve that "tell me how much RAM I can use".

I'm not asking to solve "tell me how much RAM I can use", I'm asking for "tell me how much RAM is in use". The other problem probably can't be resolved by Go itself, but rather by individual programmers in their individual programs for their individual use cases.

Closing as a duplicate of #29696.

"add way for applications to respond to GC backpressure" has nothing to do with "mechanism for monitoring system memory".

I want to know if I can launch a task before launching it.

I found that an appropriate solution was to use mem.VirtualMemory() from github.com/shirou/gopsutil or host.Memory() from github.com/elastic/go-sysinfo.

There's a few things that should honestly be in the standard library. If Go is to be used as a server-side language, then it should be able to be optimized for a server environment. This includes being able to easily query available resources and react accordingly. It's all fun and games to process our 200 GiB of data concurrently, but it's not useful if it crashes the host. By Googling MEMORYSTATUSEX golang site:github.com, I found multiple packages that implements that :

• https://github.com/shirou/gopsutil/blob/master/mem/mem_windows.go
• https://github.com/elastic/go-windows/blob/master/kernel32.go