View mode: basic / threaded / horizontal-split · Log in · Help
July 21, 2012
Re: OSCON 2012 notes
On Saturday, July 21, 2012 19:13:20 Nick Sabalausky wrote:
> On Sat, 21 Jul 2012 14:41:05 +0200
> 
> Paulo Pinto <pjmlp@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.

I tend to agree. However, it's my understanding that when the Go folks talk 
about Go being a "systems language," they mean that it's meant for building 
large systems, not that it's meant for writing low-level stuff like kernels, 
which is what C++ and D mean when they call themselves systems languages. So, 
I believe that the core problem here is that the term is being used differently 
by different languages rather than Go claiming that they're a systems language 
in the C++/D sense when they have to rosert to outside of the language tricks. 
But I could be wrong about what they mean.

- Jonathan M Davis
July 22, 2012
Re: OSCON 2012 notes
On Sat, Jul 21, 2012 at 5:38 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Saturday, July 21, 2012 19:13:20 Nick Sabalausky wrote:
> > On Sat, 21 Jul 2012 14:41:05 +0200
> >
> > Paulo Pinto <pjmlp@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.
>
> I tend to agree. However, it's my understanding that when the Go folks talk
> about Go being a "systems language," they mean that it's meant for building
> large systems, not that it's meant for writing low-level stuff like
> kernels,
> which is what C++ and D mean when they call themselves systems languages.
> So,
> I believe that the core problem here is that the term is being used
> differently
> by different languages rather than Go claiming that they're a systems
> language
> in the C++/D sense when they have to rosert to outside of the language
> tricks.
> But I could be wrong about what they mean.
>
> - Jonathan M Davis
>

The Go people no longer refer to Go as a systems language.  I believe they
did intend for it to be a systems language in the same manner D is but over
time they decided to focus less on that.

Here's what Russ Cox said on that matter:

"We removed the word 'systems' because it was too limiting.
Go is more general than that.  It is still a great language for
writing systems."

Regards,
Brad Anderson
July 22, 2012
Re: OSCON 2012 notes
On 7/21/12 10:16 PM, Brad Anderson wrote:
> The Go people no longer refer to Go as a systems language.  I believe
> they did intend for it to be a systems language in the same manner D is
> but over time they decided to focus less on that.
>
> Here's what Russ Cox said on that matter:
>
> "We removed the word 'systems' because it was too limiting.
> Go is more general than that.  It is still a great language for
> writing systems."

Yah, it's one of those things that stuck just like "Scala is FP on the 
JVM", characterization that Martin Odersky himself was surprised of (and 
refuted).

Andrei
July 22, 2012
Re: OSCON 2012 notes
On Saturday, 21 July 2012 at 14:08:48 UTC, Adam D. Ruppe wrote:
> On Saturday, 21 July 2012 at 13:47:06 UTC, Michel Fortin wrote:
>> The web is a low-hanging fruit for D.
>
> Yea, I've been eating that fruit for years.
>
+1

Web development with D is quite easy and very enjoyable.
With Adam's work it even more easier.

I've done couple projects already with some of personal and 
Adam's stuff.

Also I've try out a bit with Vibe.d, Adam's stuff, Serenity and 
they give the feel of php-like capabilities but I think it would 
be better to get something like Ruby on Rails, Django or 
Whatever-php-framework-you-may-use that allows Rapid Web 
Development.

While making basic stuff like databases support, CGI/FCGI support 
etc to Phobos seems fine to me,

I think that creating specialized D framework for web development 
would be better idea (and for sure it shouldn't be placed in 
standard library).
July 22, 2012
Re: OSCON 2012 notes
On Saturday, 21 July 2012 at 05:14:57 UTC, Andrei Alexandrescu 
wrote:
> I'm back from OSCON 2012, where my talk has enjoyed a somewhat 
> unexpected good reception (OSCON is not the most down-D's-alley 
> audience).
>
> The talk abstract is at 
> http://www.oscon.com/oscon2012/public/schedule/detail/23888 and 
> the slides are at 
> http://www.slideshare.net/andreialexandrescu1/generic-programming-galore-using-d. 
> There will be a video up some time in the future for the entire 
> talk.
>
>[...]
>
> Cheers,
>
> Andrei

Looking forward to see it
July 22, 2012
Re: OSCON 2012 notes
Am 22.07.2012 01:13, schrieb Nick Sabalausky:
> On Sat, 21 Jul 2012 14:41:05 +0200
> Paulo Pinto<pjmlp@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?

--
Paulo
July 22, 2012
Re: OSCON 2012 notes
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@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.

- Jonathan M Davis
July 22, 2012
Re: OSCON 2012 notes
On Sun, 22 Jul 2012 01:24 -0700
Jonathan M Davis <jmdavisProg@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@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.
July 22, 2012
Re: OSCON 2012 notes
On 2012-07-21 19:51:37 +0000, Nick Sabalausky 
<SeeWebsiteToContactMe@semitwist.com> said:

> On Sat, 21 Jul 2012 09:47:06 -0400
> Michel Fortin <michel.fortin@michelf.ca> wrote:
>> 
>> And also, more and more it'd require ARM support to be competitive in
>> the GUI area.
> 
> Yes. But there's an even bigger reason for ARM: Mobile devices, like
> iOS and Android. I'm not personally a fan of them, but nonetheless those
> things are HUGE (no pun intended). And yet the ONLY real language
> choices there are C++, Java and Objective-C (and Lua if you count
> "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are
> out of the question if you want cross platform, which any sane developer
> should. So PERFECT fertile ground for D.
> 
> I know I keep harping on that, but it's a big issue for me since I'm
> deep into that stuff now and goddamn do I wish I could be doing
> it in D, but D's support on those devices (or just outputting C/C++)
> unfortunately just isn't mature enough ATM.

For my part, in the last year I've been building a big codebase that 
had to be C++ just because of this, with countless hours spent figuring 
out things that would have been a lot easier to do in D.

Here's the problem as I came to realize it: no single project is going 
to be enough to justify the investment required to make it happen. 
Nobody's project is by itself big enough to make D/Objective-C 
worthwhile to produce and maintain, because making it and then keeping 
it in sync with both D and Apple's Objective-C is a huge effort that'll 
in itself derail the project you were using to justify the investment. 
So D/Objective-C has to stand as a project of its own somehow.

Also, making it a cross-platform thing would require a similar 
investment for WinRT and Android (through JNI?). While it surely is 
technically possible and would sure help a lot of developers move away 
from C++, I'm not so sure such a thing will happen at all.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/
July 22, 2012
Re: OSCON 2012 notes
Am 22.07.2012 10:42, schrieb Nick Sabalausky:
> On Sun, 22 Jul 2012 01:24 -0700
> Jonathan M Davis<jmdavisProg@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@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.

Simple pointers are available.

package main
import "fmt"

func main() {
	x := 25
	y := &x
	fmt.Println("x is ", x)
	*y = 30
	fmt.Println("x is now ", x)
}


Pointer arithmetic is possible using the unsafe package, but should only 
be used if really needed, like interfacing with system code.

package main
import "fmt"
import "unsafe"

func main() {
	x := []byte{1, 2, 3, 4}
	fmt.Println("x is ", x)
	for i := 0; i < len(x); i++ {
                e := x[i]
		fmt.Printf("%d index is %d, at %x\n", i, e, &x[i])
	}

	y := &x[0]
	fmt.Println("Base adress ", y)
	size := unsafe.Sizeof(x[0])
	fmt.Println("Size per element ", size)
	for i := 0; i < len(x); i++ {
		cell := uint64(uintptr(unsafe.Pointer(y))) + (uint64(i) * uint64(size))
		value := (*byte)(unsafe.Pointer(uintptr(cell)))
		fmt.Printf("%d index is %d, at %p\n", i, *value, value)
	}
}


>
> 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.
>
>

Not really, you can fake it though, by using the enconding.binary package,

http://golang.org/pkg/encoding/binary/

--
Paulo
1 2 3 4 5
Top | Discussion index | About this forum | D home