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

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

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

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

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

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

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

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.

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/

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