3 ms·

"Oh, and there isn't any pointer math, so you won't screw yourself with it." It has been said before and I'll say it again here, but because you can mess stuff

by jetti 14y ago

"Oh, and there isn't any pointer math, so you won't screw yourself with it." 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).

ericbb 14y ago
Incidentally, I don't think it's entirely true that "there isn't any pointer math". I've never used it but I understand that you can do C-like pointer tricks by using the package called "unsafe": http://golang.org/pkg/unsafe/ http://golang.org/pkg/unsafe/ and http://golang.org/ref/spec#Package_unsafe http://golang.org/ref/spec#Package_unsafe
- dchest 14y ago
  Yes, indeed. Here's the "canonical" C strlen translated to unsafe Go with pointer arithmetic: 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"))) } Not that anyone should use it :-) 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 http://golang.org/src/pkg/crypto/sha256/sha256.go#L105
pekk 14y ago
I agree, but at the same time it seems good for pointer math to be marked off as unusual - something you only do when you are down a manhole, not the default way of doing normal things.
barrkel 14y ago
I think it's an excellent reason for not having something in a language. 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.
stevvooe 14y ago
Pointer math is effectively replaced with [slices][1], which are much more flexible and less error prone. [1]: http://blog.golang.org/2011/01/go-slices-usage-and-internals.html http://blog.golang.org/2011/01/go-slices-usage-and-internals...
smosher 14y ago
Pointer arithmetic is an important feature in languages like C, but languages like Go don't really want it. The language domain doesn't call for and it plays havoc with the GC.

by jetti 14y ago

ericbb 14y ago

Incidentally, I don't think it's entirely true that "there isn't any pointer math". I've never used it but I understand that you can do C-like pointer tricks by using the package called "unsafe": http://golang.org/pkg/unsafe/ http://golang.org/pkg/unsafe/ and http://golang.org/ref/spec#Package_unsafe http://golang.org/ref/spec#Package_unsafe

dchest 14y ago
Yes, indeed. Here's the "canonical" C strlen translated to unsafe Go with pointer arithmetic: 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"))) } Not that anyone should use it :-) 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 http://golang.org/src/pkg/crypto/sha256/sha256.go#L105

pekk 14y ago

I agree, but at the same time it seems good for pointer math to be marked off as unusual - something you only do when you are down a manhole, not the default way of doing normal things.

barrkel 14y ago

I think it's an excellent reason for not having something in a language. 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.

stevvooe 14y ago

Pointer math is effectively replaced with [slices][1], which are much more flexible and less error prone. [1]: http://blog.golang.org/2011/01/go-slices-usage-and-internals.html http://blog.golang.org/2011/01/go-slices-usage-and-internals...

smosher 14y ago

Pointer arithmetic is an important feature in languages like C, but languages like Go don't really want it. The language domain doesn't call for and it plays havoc with the GC.