Go vs. D [was Re: Rust vs Dlang]

1100110 0b1100110 at gmail.com
Sun Mar 17 12:28:28 PDT 2013


On 03/17/2013 07:09 AM, Paulo Pinto wrote:
> 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

The day I can compile pypy without needing 8Gb of memory is the day I'll 
consider it.


More information about the Digitalmars-d-announce mailing list