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

Paulo Pinto pjmlp at progtools.org
Sun Mar 17 14:13:12 PDT 2013


Am 17.03.2013 20:28, schrieb 1100110:
> 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.

Uau, that much?!

I tend to use Python only for shell scripting type of tasks, so I wasn't 
aware that PyPy is so memory hungry.

--
Paulo


More information about the Digitalmars-d-announce mailing list