Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Maybe their target is the App engine.


It's true that you can't directly import unsafe in your own Go code on App Engine. However importing standard library packages like encoding/gob, which then proceed to use the unsafe package for themselves, works just fine on App Engine.

App Engine is actually the biggest reason why I don't immediately like this change. For other environments I can just fork the Go 1.3 encoding/gob implementation and use that. However on App Engine I can't import unsafe myself, so the only way to run really fast unsafe code, is to use the standard library. This latest change removes that option from me.


It's more that by removing the use of unsafe it will play more nicely with the new concurrent garbage collector (slated for Go 1.5 in June).


Thanks for the heads up.

Are also there plans to expose more primitives in unsafe?

I remember seeing some posts related to possible required features as part of re-writing the whole stack in Go.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: