It has been said before and I'll say it again here, but because you can mess stuff up because you don't know what your doing is a terrible reason to not have something in a language (or even a program).
package main
import (
"fmt"
"unsafe"
)
func strlen(b []byte) int {
str := uintptr(unsafe.Pointer(&b[0]))
s := str
for ; *(*byte)(unsafe.Pointer(s)) != 0; s++ {}
return int(s - str)
}
func main() {
fmt.Println(strlen([]byte("ho ho ho\000")))
}
The safe and readable variant of this, often used in Go code, is "slice arithmetic", like this: http://golang.org/src/pkg/crypto/sha256/sha256.go#L105
[1]: http://blog.golang.org/2011/01/go-slices-usage-and-internals...
It's not you or me I'm worried about; it's all the other people, and their libraries that I may take dependencies on.
The more error-prone the constructs available in a language, the more likely artifacts created with the language, on average, are to have errors. The easiest way of eliminating these problems is to eliminate the constructs.
This only becomes a serious problem if the workarounds are too verbose, too inefficient, or impossible. Not all applications will need the workarounds. If that subset of applications is productive, the language may be viable - or at least, won't be non-viable because of lack of the given constructs.