On 3/17/2013 1:17 AM, Paulo Pinto wrote:
> On 17.03.2013 09:05, Russel Winder wrote:
>> So what are the features that Go is ignoring that D has?
> - exceptions;
> - enumerations;
> - generic types;
> - direct use of OS APIs, without the need of writing wrappers;
> - currently only static compilation is available;
> - due to static compilation only model, there are issues with 3rd party code;
> - no support for meta-programming;
> - rich set of available libraries;
> - the PR about go routines and channels, usually forgets to mention that similar
> features do exist as libraries for other languages

I'd like to add that D has:

- operator overloading
- user defined attributes
- dll's (coming soon)
- vector operations
- SIMD operations
- scope guard
- compile time function execution
- true immutability and purity
- inline assembler


> Their talk about fast compilation is also quite effective with young developers
> that did not grew up with Modula-2 and Mac/Turbo Pascal or using other compiled
> languages with modules, so they think Go is the first compiled language to offer
> that.

Andrei did some tests a while back showing that D compiles considerably faster than Go. High compilation speed has been a major factor among companies who have adopted D.

On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote:
[…]
> The first known one is that Go is the only strong typed language to eschew generics in the 21st century.

On the other hand, perhaps generics is not a good thing, yet has created an unchallenged mindset? NB I am tainted by C++ templates and generics on the JVM both of which really suck as far as I am concerned – C# has much less of a problem here, and Scala hacks it's way around it. Also I use Python a lot which has only one variable type, reference to object. Heterogeneity is not your enemy.

I like the experiment of objects as values with methods added as needed, very Pythonic. Go even makes this static compile time type checked; though I think they miss the underlying irony of this.

Far too many "object oriented" languages have forgotten that the computational model is one of sending messages to objects asking them to undertake a behaviour.  Statically typed languages constrain objects not to be able to evolve their behaviours.

> For the rest, copying from my discussion on Lambda the Ultimate about C++ developers not jumping into Go (http://lambda-the-ultimate.org/node/4554#comment-71504):
> 
> - exceptions;
> - enumerations;
> - generic types;
> - direct use of OS APIs, without the need of writing wrappers;
> - currently only static compilation is available;
> - due to static compilation only model, there are issues with 3rd party
> code;
> - no support for meta-programming;
> - rich set of available libraries;
> - the PR about go routines and channels, usually forgets to mention that
> similar features do exist as libraries for other languages

Go is a stripped down C with stronger type checking. memory management and CSP. This actually makes it an important language in the scheme of things, even if I agree with you that in so many way it is a regression into the 1960s.

The major problem for all statically compiled languages is the reliance on hardware integers.

> I know you can fake enumerations with typed consts, but it is not the same thing as real enumerations.

On the other hand C and C++ enumerations are just syntactic sugar for the same thing so not real difference. In fact exactly the opposite, they are a delusion. Conversely Java enumerations are a bit heavyweight.

> My point about direct OS APIs is that while D and Rust follow the approach used by other languages where you just declare bindings, Go forces the use of the CGO tool and a C compiler that speaks Go ABI.

I guess this is because of the segmented stacks architecture behind the realization of Go.

> Their talk about fast compilation is also quite effective with young developers that did not grew up with Modula-2 and Mac/Turbo Pascal or using other compiled languages with modules, so they think Go is the first compiled language to offer that.
> 
> Feel free to destroy. :)

Far from it. I think Go is a significant improvement over C, but that in 2013 applications programmers should be using something better. I continue to be surprised by Python people moving to Go. The only "positive" for Go is goroutines. Python's GIL's days are numbered at which point even that issue goes away.

The issue is then how to make D appealing to Python programmers. People need to convince me why I should stop training people to use Python. This will be hard given that C/C++/Python is now the standard model for computational systems.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sun, 2013-03-17 at 01:57 -0700, Walter Bright wrote: […]
> I'd like to add that D has:
> 
> - operator overloading
> - user defined attributes
> - dll's (coming soon)
> - vector operations
> - SIMD operations
> - scope guard
> - compile time function execution
> - true immutability and purity
> - inline assembler
[…]

On the other hand "creeping featurism" can be a bad thing. Isn't the mantra "small language, large (properly indexed) library"?

Immutability though I like. Single assignment rules.

Inline assembler is anathema.

> Andrei did some tests a while back showing that D compiles considerably faster than Go. High compilation speed has been a major factor among companies who have adopted D.

Excellent.

Java / Scala is an interesting battle: Java is massively verbose, Scala is not; Java takes a while to compile, Scala takes eons. Hence static Groovy (as well as dynamic), and Kotlin. The jury is still out on whether Ceylon has any relevance to the universe.

PS Can I have shared objects last week please ;-)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

17-Mar-2013 14:06, Russel Winder пишет:
> On Sun, 2013-03-17 at 01:57 -0700, Walter Bright wrote:
> […]
>> I'd like to add that D has:
>>
>> - operator overloading
>> - user defined attributes
>> - dll's (coming soon)
>> - vector operations
>> - SIMD operations
>> - scope guard
>> - compile time function execution
>> - true immutability and purity
>> - inline assembler
> […]
>
> On the other hand "creeping featurism" can be a bad thing. Isn't the
> mantra "small language, large (properly indexed) library"?
>

Built-in channels and goroutines don't count as feature creep ? ;)

> Immutability though I like. Single assignment rules.
>
> Inline assembler is anathema.
>
>> Andrei did some tests a while back showing that D compiles considerably faster
>> than Go. High compilation speed has been a major factor among companies who have
>> adopted D.
>
> Excellent.
>
> Java / Scala is an interesting battle: Java is massively verbose, Scala
> is not; Java takes a while to compile, Scala takes eons. Hence static
> Groovy (as well as dynamic), and Kotlin. The jury is still out on
> whether Ceylon has any relevance to the universe.
>
> PS Can I have shared objects last week please ;-)
>


-- 
Dmitry Olshansky

On Sunday, 17 March 2013 at 08:57:48 UTC, Walter Bright wrote:
> I'd like to add that D has:
>
> - operator overloading
> - user defined attributes
> - dll's (coming soon)

So it doesn't.

> - vector operations
> - SIMD operations
> - scope guard
> - compile time function execution
> - true immutability and purity

It isn't guaranteed by the current type system.

> - inline assembler
>
>
>> Their talk about fast compilation is also quite effective with young developers
>> that did not grew up with Modula-2 and Mac/Turbo Pascal or using other compiled
>> languages with modules, so they think Go is the first compiled language to offer
>> that.
>
> Andrei did some tests a while back showing that D compiles considerably faster than Go. High compilation speed has been a major factor among companies who have adopted D.

If you use some of the mentioned above features, resources required to compile can explode dramatically.

On 17.03.2013 11:01, Russel Winder wrote:
> On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote:
> […]
>> The first known one is that Go is the only strong typed language to
>> eschew generics in the 21st century.
>
> On the other hand, perhaps generics is not a good thing, yet has created
> an unchallenged mindset? NB I am tainted by C++ templates and generics
> on the JVM both of which really suck as far as I am concerned – C# has
> much less of a problem here, and Scala hacks it's way around it. Also I
> use Python a lot which has only one variable type, reference to object.
> Heterogeneity is not your enemy.
>
> I like the experiment of objects as values with methods added as needed,
> very Pythonic. Go even makes this static compile time type checked;
> though I think they miss the underlying irony of this.

I think for static strong type languages you need some kind of genericity support like generics, parametric types or similar.

There are many other ways to implement them. Eiffel, Modula-3, Ada
and many other strong type languages also offer generics.

Interfaces are halfway there, because if you are not allowed to use operators as functions, then there is always the need to write boilerplate code, even for basic types.

Dynamic type languages don't require this of course, given the way their
type systems work.

>
> Far too many "object oriented" languages have forgotten that the
> computational model is one of sending messages to objects asking them to
> undertake a behaviour.  Statically typed languages constrain objects not
> to be able to evolve their behaviours.

I might be brain damaged here, because I used OO in Object Pascal, C++, Smalltalk, CLOS, Prolog, Java, C#, VB, C++, ML and a few obscure languages.

So I don't see the mainstream enterprise OO way of doing things as the only way of how OO is supposed to be.

Sadly most developers in the enterprise world lack this kind of understanding and write the type of code that gives bad name to OO.

>
>> For the rest, copying from my discussion on Lambda the Ultimate about
>> C++ developers not jumping into Go
>> (http://lambda-the-ultimate.org/node/4554#comment-71504):
>>
>> - exceptions;
>> - enumerations;
>> - generic types;
>> - direct use of OS APIs, without the need of writing wrappers;
>> - currently only static compilation is available;
>> - due to static compilation only model, there are issues with 3rd party
>> code;
>> - no support for meta-programming;
>> - rich set of available libraries;
>> - the PR about go routines and channels, usually forgets to mention that
>> similar features do exist as libraries for other languages
>
> Go is a stripped down C with stronger type checking. memory management
> and CSP. This actually makes it an important language in the scheme of
> things, even if I agree with you that in so many way it is a regression
> into the 1960s.

Here they follow Niklaus Wirth, which I admire, school of though.

When he went out to create Oberon, he decided to remove all language features he did not consider essential in a programming language.

Actually all the successors, Oberon-2, Component Pascal and Active Oberon were created by his students or collaborators. In 2011 the last Oberon language report, Oberon-07, removes even a few more features.

On his talk at HOPL-3 he recognizes that the industry did not follow his appreciation for smaller languages.

http://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf

Go seems to be heading this way, as Rob Pike already wrote a blog entry about the same issue, where he mentions that Go only attracts Ruby and Python guys, but not the C++ one he expected to attract.

Although I am a big fan of the Oberon operating systems and languages, I think we are no longer in the late 90's, and given the mainstream acceptance of many features that used to be only academic, why throw them away?

Go's workarounds for lack of generics remind me of the time C++ still lacked generics and there were a few pre-processor tools to generate
generic code. Borland used to ship one in their compilers.

I don't miss those days.

>
> The major problem for all statically compiled languages is the reliance
> on hardware integers.
>
>> I know you can fake enumerations with typed consts, but it is not the
>> same thing as real enumerations.
>
> On the other hand C and C++ enumerations are just syntactic sugar for
> the same thing so not real difference. In fact exactly the opposite,
> they are a delusion. Conversely Java enumerations are a bit heavyweight.

I prefer the enumerations the Pascal away, similar to what Java and .NET offer with primitives for generic manipulation of values.

>
>> My point about direct OS APIs is that while D and Rust follow the
>> approach used by other languages where you just declare bindings, Go
>> forces the use of the CGO tool and a C compiler that speaks Go ABI.
>
> I guess this is because of the segmented stacks architecture behind the
> realization of Go.
>
>> Their talk about fast compilation is also quite effective with young
>> developers that did not grew up with Modula-2 and Mac/Turbo Pascal or
>> using other compiled languages with modules, so they think Go is the
>> first compiled language to offer that.
>>
>> Feel free to destroy. :)
>
> Far from it. I think Go is a significant improvement over C, but that in
> 2013 applications programmers should be using something better. I
> continue to be surprised by Python people moving to Go. The only
> "positive" for Go is goroutines. Python's GIL's days are numbered at
> which point even that issue goes away.

Me too.

>
> The issue is then how to make D appealing to Python programmers. People
> need to convince me why I should stop training people to use Python.
> This will be hard given that C/C++/Python is now the standard model for
> computational systems.
>

Actually I think the day PyPy becomes the main Python implementation there is hardly the need for Python developers to write C or C++ code.

--
Paulo

On Sat, 16 Mar 2013 11:14:15 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 3/16/13, Suliman <evermind@live.ru> wrote:
>> Hi folks! I had wrote small article about Rust vs D. I hope that
>> you will like it!
>>
>> http://versusit.org/rust-vs-d
>>
>
> This code:
>
> ```
> In D a similar code would look as follows:
> void main() {
>   for (int i = 0; i < 10; i++) {
>       writeln("Hello");
>  }
> }
> ```
>
> Should really be:
>
> ```
> foreach (i; 0 .. 10)
>      writeln("Hello");
> ```
>
> It avoids the common mistake of using a signed 32-bit type for indexing.

That is not a mistake in this code.  In fact, your replacement still uses signed types.

> Also your example code seems to embed some strange hidden Unicode
> characters (Error: unsupported char 0xfeff) which make copy-pasting
> and running the examples not work.

feff is a BOM (byte order mark) which is typically at the beginning of a file to establish the number of bits per code point and the byte order of the code points.  It is not strange, and it should be handled correctly by dmd.  If not, that is a bug.

-Steve

>Nice writeup. Could you please fix the code formatting? Indentation is lost at least on Chrome and Firefox on OSX. Then I'll be glad to post on reddit.

Andrei Alexandrescu, I redid it and put source code as files for downloading till we will not fix or bbcode parser. You may check. I would thanks full if you will reddit it.

Yesterday I had tried to put it reddit, but I have never used reddit before and do not sure that it was added at proper section.

On 3/17/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> In fact, your replacement still uses
> signed types.

Hmm, I was expecting it to always be size_t. Apparently it's based on the range:

foreach (i; 0 .. int.max) { }  // i is int
foreach (i; 0 .. size_t.max) { }  // i is size_t

Well, we can put a 'size_t' in there so it's not too bad.