I think so, but probably not reliably and/or for the long term.

In terms of the actual unmap call, the payload is in the munmap call, which is a syscall, and if you do have to set up the registers for that call, Go does have its assembler support which should be able to do that for you. You should be able to write Go source code that would perform that call, although you're going to be poking into some corners of Go most programmers never have to get into. You can also get to fuse, which in my experience is great at producing uninterruptible sleeps even when you're not trying to do it on purpose....

However, in terms of reliability and the long term, you have the problem that you're not the only thread in the program the way a C program can count on that, and if any of those other threads wake up and their memory is missing, it'll probably result in the process dying. You can do a couple things to try to avoid that a little, like pinning yourself to an OS thread and running the program in one CPU mode, but especially on the latest version of Go where they've implemented true pre-emption, you can't keep the runtime from running by just hogging the execution thread anymore.

So I suspect that as long as you win the race to unmap everything before the runtime wakes up (which may also require you to call sysmap through the assembly code directly, rather than using the syscall libraries as I'm pretty sure those notify the scheduler of what you're doing), you may be able to briefly be a process with no RAM mapped, but in human terms it won't be long before the runtime wakes up to do something, anything, and crash the process as a result. There's no way to avoid that in Go. You won't be able to have a process just sitting there indefinitely with no mapped RAM that you can admire and treasure and hand off to your children as part of their inheritance.

> you have the problem that you're not the only thread in the program the way a C program can count on that

Note that if you link against libc I think it would be legal for it to create a thread behind your back, so even in this case you're not quite safe.

Normally I'm not a fan of people nitpicking language choices... but in this case I upvoted because this is a really weird "stupid program trick" and I'm curious what languages support such shenanigans.

can a bf interpreter be written in sed?

https://github.com/izabera/bfsed

we're programmers, anything can be done with enough time or money

Can you write a program to tell if any given program is going to halt?

Tell you what: you give me time and money, and I'll work on this program. Keep giving me time and money until I tell you I've succeeded.

Can someone write a program to tell me how much money I’d need to give you?

Give me time and I'll tell you at the end how much money you need to give me.

Sounds like a good deal if we don't need to pay until you're done!

No need to be difficult, just give me an estimate. Is this going to be a small, medium or large t-shirt size task?

Agreed, take all the time you need.

Sure, I'll just be giving you half your wage with each coming hour.

As long as linear execution time is acceptable, okay. Give me a couple million dollars and I'll have it to you in a week.

With enough time, sure! [0][1]

[0] Disclaimer: may take slightly longer than heat death of current universe.

[1] Alternative solution: https://m.xkcd.com/1266/

Surely rust is the preferred option for that? Go hasn't been nearly as vocal in my experience.