On Sun, 22 Jul 2012 01:24 -0700 Jonathan M Davis <jmdavisp...@gmx.com> wrote:
> On Sunday, July 22, 2012 10:10:43 Paulo Pinto wrote: > > Am 22.07.2012 01:13, schrieb Nick Sabalausky: > > > On Sat, 21 Jul 2012 14:41:05 +0200 > > > > > > Paulo Pinto<pj...@progtools.org> wrote: > > >> Regarding systems programming, Go could actually play in the same > > >> league as D > > > > > > [...] > > > > > >> The trick with Oberon, which Go also uses, is to have a special > > >> module reckognised by the compiler with primitives to do the low > > >> tricks C offers. Additionaly any function/method without body > > >> can be implemented in Assembly. This is nothing new, Modula-2 > > >> already worked like this. > > > > > > If a language has to resort to such "outside-of-the-language" > > > tricks like that to do system software, then it's just simply not > > > a systems language. > > > > How is this different from ANSI/ISO C, which is considered a systems > > programming language? > > It can actually use raw pointers and the like? It's my understanding > that pretty much all of the low level "system" stuff like that is > hidden from you in Go. So, the result would be a bit like calling > Java a systems language because you can use JNI to get at low level > stuff. > Right. IIRC, I think I heard that Go does have pointers, but they're very limited compared to C/D and there's no ptr arithmetic. Another thing would be reinterpret cast: Take a value and map a different type onto the same memory without any runtime overhead. That can be very useful for both speed and memory optimizations. I admit I don't actually know whether Go supports that, but from what I understand about the language it would surprise me. Actually, if it could, then that would effectively give it ptr arithmetic (and in a really ugly non-typesafe way), so I really doubt it.
