OSCON 2012 notes

[Nick Sabalausky]

On Sun, 22 Jul 2012 01:24 -0700
Jonathan M Davis <jmdavisProg at 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<pjmlp at 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.