Golang is rapidly becoming the language of choice for programming both simple applications for embedded hardware and elaborated high end software for computational clusters. Many of the major companies have adopted it as the default choice for new projects and it is starting to be quite widespread even among independent programmers. One of the main features it introduces are goroutines: a new approach to multithreading that scales better with modern multi-core hardware and operating systems. It allows programmers to handle a higher amount of concurrent tasks with a lower cost in terms of performances. Goroutines are scheduled by the go runtime and in order to make them more efficient than traditional threads, some features have been taken away from them, like thread-local storage and thread pointers. These and many other changes have been applied in order to grant a competitive task-switching time. Go's approach makes it the language that performs better in concurrent applications, but like many other optimizations it doesn't come for free. While it is widely known that go is very efficient, there is still little to no information about the implications that come with relying on its internal scheduler. Many guides and documentations treat goroutines as if they were traditional threads, failing to warn programmers on the differences and risks involved, creating a dangerous trend for the next generation of software. What are the implications of using goroutines instead of threads? Do they introduce new vulnerabilities? Can they be used in a safe way?