alchemy VS go

+1 for r/emudev. Amazing community, and was a huge help to me when i was building my first gameboy emulator. https://github.com/shafinsiddique/alchemy

Let's continue our journey into Go. Last time, we got Go set up in WSL and covered some fundamentals like values, variables, and constants. This time, we'll dive into for loops and conditional blocks, the building blocks of decision-making and iteration in Go. We're working our way through Go by Example if you want to follow along.

Related Go Issue

and http3 is being implemented https://github.com/golang/go/issues/70914

Since Go has strong backwards compatibility guarantees, they're unlikely to commit to APIs that may need to change in the standard library.

Go, created by Google, has become a favorite in the backend world thanks to its simplicity, speed, and built-in concurrency through goroutines and channels. Its compiled nature allows for highly performant applications that often outperform interpreted languages, making it an excellent choice for robust backend systems.

[2]: https://github.com/golang/go/issues/71497

Learning things is fun so I've decided it's time to learn go and because I enjoy making these little series I thought I'd write about it too.

It's not just system calls. E.g. reflection package uses unsafe too: https://github.com/golang/go/blob/master/src/reflect/value.g... .

Unfortunately, OS vendors like microsoft are quite incompetent at running root stores https://github.com/golang/go/issues/65085#issuecomment-25699...

I don't think any reasonable member of the Go community would claim that any aspect of the language and its standard library is perfect. The many open issues on https://github.com/golang/go attest to that.

One example, if I may: the errors.As function is far from ergonomic. It would have been much better if generics had come to the language before that function was added to the standard library. Modern alternatives exist: https://pkg.go.dev/github.com/jub0bs/errutil

A similar issue in Go, that I've encountered in real code: https://github.com/golang/go/issues/27505#issuecomment-71370...

In a nutshell, if you want to use the death signal, which is very handy and useful, you also need to lock an OS thread so that it can't be destroyed. Fortunately I'm only spawning one process so I don't need to jump through hoops, I can just dedicate a thread to it, but it would be inconvenient to want to spawn lots of processes that way.

Speaking more generally, a lot of things that I learned in the 200xs apply to "processes", and things I just osmosed over the years as applying to "processes", were changed to apply to "threads" over the decades and a lot of people have not noticed that, even now. Even though I know this, my mental model of what is associated to a thread and what is associated to a process is quite weak, since I've not yet needed to acquire a deep understanding. In general I would suggest to people that if you are dealing with this sort of system programming that you at least keep this general idea in your head so that the thought pops up that if you're having trouble, it may be related to your internal beliefs that things related to "processes" are actually related to "threads" and in fact just because you did something like set a UID or something somewhere in your code doesn't necessarily mean that that UID will be in effect somewhere else.