GO Vs D

16,947 views
Skip to first unread message

praks

unread,
Jul 25, 2010, 11:35:08 AM7/25/10
to golang-nuts
Hi All,

I am new to both Go and D languages. I would like to master in one of
them. However, I am confused which one is better. I would like to
develop a server using one of these language. I understand GO is still
understand development. I am looking for long term solution. Can some
one help out in this? Could someone enlist head-to-head comparison? I
hope it is not comparing apple with orange.

Regards,
praks

Go or Not to Go :D !

Archos

unread,
Jul 25, 2010, 11:51:28 AM7/25/10
to golang-nuts
Go is a language (mainly) designed for networking so your choice is
easy ;)

Andrew Gerrand

unread,
Jul 25, 2010, 7:34:15 PM7/25/10
to praks, golang-nuts
On 26 July 2010 01:35, praks <praks...@gmail.com> wrote:
> Hi All,
>
> I am new to both Go and D languages. I would like to master in one of
> them.

Go is a much simpler language than D, so mastering Go will take you
much less time. You should be able to understand its features after
playing with it for a few days, and master them within a few weeks. I
couldn't say the same for D.

> However, I am confused which one is better. I would like to
> develop a server using one of these language.

Go was developed primarily for writing server software, so I think
you'll find it a useful tool. Give it a try!

> I understand GO is still understand development.
> I am looking for long term solution.

Go is still under development, but the language is stable. We're using
it at Google for production work, so we're committed to furthering its
development. :-)

Andrew

Vincent Foley

unread,
Jul 25, 2010, 10:41:31 PM7/25/10
to golang-nuts
> Go is still under development, but the language is stable. We're using
> it at Google for production work, so we're committed to furthering its
> development. :-)
>

Will details of how Go is used (and received) at Google eventually be
available?

kar

unread,
Jul 25, 2010, 10:58:14 PM7/25/10
to golang-nuts
if you like politics in D (d1.0, d2.0, phobos, tango), i've been using
D for almost 5 yrs now porting my project from D+tango to Go and its a
breeze.
D1 is matured enough and production ready, very stable, i had a
program (crawler with 50 threads) running for 2 days wiht no problem.
love the GC.
D's spec is crazy multi-paradigm you name it they have it. No 64bit
support for DMD (D's official compiler), LDC (llvm front end for D1)
has 64bit support but still young.
For me it's time to move forward, Go is the future. Go has everything
i need, it's simple and it works.

Andrew Gerrand

unread,
Jul 25, 2010, 11:16:12 PM7/25/10
to Vincent Foley, golang-nuts
On 26 July 2010 12:41, Vincent Foley <vfo...@gmail.com> wrote:
> Will details of how Go is used (and received) at Google eventually be
> available?

When it's used in non-confidential projects, yes.

Andrew

Prakash Bhurke

unread,
Jul 26, 2010, 12:28:42 PM7/26/10
to kar, golang-nuts
Thanks Kar for sharing your experience. I have following doubts:

> if you like politics in D (d1.0, d2.0, phobos, tango), i've been using
> D for almost 5 yrs now porting my project from D+tango to Go and its a
> breeze.

Why are porting your projects from D+tango to Go ? What are problems
you faced while using D? Sorry I don't know history/politics of D.

> D1 is matured enough and production ready, very stable, i had a
> program (crawler with 50 threads) running for 2 days wiht no problem.

great!

> love the GC.
> D's spec is crazy multi-paradigm you name it they have it. No 64bit
> support for DMD (D's official compiler), LDC (llvm front end for D1)
> has 64bit support but still young.

Well, though Go is stable, it is still also under development. I don't
have any idea about 64-bit support development stage of both
languages.

> For me it's time to move forward, Go is the future. Go has everything
> i need, it's simple and it works.

Is D not the future? Which features are missing in D? Is there any
big vendor (like google) supporting D?

Sorry, I should I have asked some of above questions on D mailing list
or google it.

jimmy frasche

unread,
Jul 26, 2010, 12:31:22 PM7/26/10
to Prakash Bhurke, kar, golang-nuts
> Which features are missing in D?

I've never used D, but I have looked at it a few times and if anything
it has too many features.

Evan Shaw

unread,
Jul 26, 2010, 12:43:15 PM7/26/10
to Prakash Bhurke, golang-nuts
On Mon, Jul 26, 2010 at 11:28 AM, Prakash Bhurke <praks...@gmail.com> wrote:
> Why are porting your projects from D+tango to Go ? What are problems
> you faced while using D? Sorry I don't know history/politics of D.

I've never used D, but from what I understand their user base is
fragmented by two different, incompatible "standard" libraries. Then
there's D 2.0, which is still in development but is supposed to
address the incompatibility issue.

> Well, though Go is stable, it is still also under development. I don't
> have any idea about 64-bit support development stage of both
> languages.

Go supports 64-bit development. You might even say that it's slightly
"more supported," since I believe many of the developers use 64-bit
machines. That's not to say that 32-bit support is lacking; it's not.

> Sorry, I should I have asked some of above questions on D mailing list
> or google it.

If you want more than just the biased opinion of this list, that's a
good idea. ;)

- Evan

Jeff Dickey

unread,
Aug 12, 2010, 6:38:04 AM8/12/10
to jimmy frasche, Prakash Bhurke, kar, golang-nuts
Exactly. I love D, but it's the modern answer to PL/I with several ALGOL-68
extensions thrown in for flavour, and Modula-3 just because.

IMOO. YMMV. TINRAR. LSMFT.

Jeff

--
Jeff Dickey Seven Sigma Software and Services
Email: jdi...@seven-sigma.com
Phone/SMS: +65 8333 4403
Website: http://www.seven-sigma.com
More info at: http://card.ly/jdickey

Jonathan Amsterdam

unread,
Aug 12, 2010, 2:33:34 PM8/12/10
to golang-nuts
I'm reading Alexandrescu's book now. I recommend it to any student of
programming languages. It's well-written, and lays out some of the
design rationales.

D is designed to be a C++-killer. To a C++ programmer, it looks
relatively simple. And it would be difficult to point to a C++ feature
that would be missed by porting to D. Thus I could conceive of
convincing the co-workers in my C++ shop to move to D.

Go, on the other hand, is a (dramatic) step up from C. It lacks
features that many C++ programmers have grown accustomed to (e.g.
inheritance, generics, RAII). I cannot conceive of convincing my co-
workers to switch to Go; they have drunk too much OO kool-aid for
that.

Seth Hoenig

unread,
Aug 12, 2010, 3:17:13 PM8/12/10
to golang-nuts


Andrei Alexandrescu recently gave a Google Tech Talk that outlines D2
a little bit:

http://www.youtube.com/watch?v=RlVpPstLPEc


D and Go seem to both be competing for the next big language, but in
reality, they are very very different. Go is a very minimalist
language, while D2 gives you just about every feature and supports
every programming paradigm you've heard of (and some you haven't, like
using ranges instead of iterators).

However, I'd venture to say that Go is currently much more stable/
mature than D2. As stated above, D2 doesn't even have a 64 bit
compiler yet.

Nick Sabalausky

unread,
Aug 12, 2010, 6:21:12 PM8/12/10
to golang-nuts
Some comments from the D side of the fence:

The current top priority for Walter Bright is giving DMD (the main
official D compiler) the ability to create native 64-bit executables
(obviously, the 32-bit executables it currently produces do run fine
on 64-bit machines). There have been many 64-bit-related commits to
the repository in the last couple months:
http://www.dsource.org/projects/dmd/timeline?from=08%2F12%2F10&daysback=60
In fact, according to the commit logs, "hello world" was working on 64-
bit nearly a month ago.

D2 became language-stable back when Andrei's book came out.

Tango is sticking with D1 for the forseeable future, so the old Phobos-
vs-Tango thing is a non-issue. In fact, the whole reason Tango got
started in the first place was that back in the D1 days, Phobos wasn't
getting much attention and sucked. But then (years ago) Andrei came on
board to Phobos, and other people are getting onto Phobos now too, and
D2's Phobos is quite good now and improving more by the day. And if
Tango eventually did move to D2, it would co-exist just fine with
Phobos (and that's old news).

DMD is fully usable (and compilable) out-of-the-box on Windows (as
well as the Linux/BSD/OSX) *without* any reliance on MinGW or anything
like that.

There *are* D users/fans within Google. (Whether or not D is currently
used for any Google projects, I don't know, I don't work there, but
from what I understand, it's looking like there's a good chance that
in the future Google will be using both Go and D for various things.)
My point here is to dispel any mistaken notion that Google is against
D just because some of their workers have created a language with
similar goals.

It's been said that "Go is a simpler language and D is more complex",
but the reason D chose to toss in a lot of features is that experience
has shown that simple languages tend to result in complex user-code
(see Java or VB6, for instance). Complexity doesn't go away in a
"simple language", it just gets moved into *your* code. That said, D
is nowhere near as complex as C++. Much of C++'s complexity comes from
legacy baggage, rather than features. Also, unlike C++, you *don't*
need to understand the more complex things to write useful D code. (As
a side note: How the heck did "feature" suddenly become a bad thing?
Just because the mess that C++ has become gave it a bad name?)

Go may have been mainly designed for networking, but D has been
designed in large part for systems programming, which naturally
includes networking. (IMO, languages geared toward a narrow purpose
are a recent fad that gained popularity just because people saw the
growing inadequacy of obviously-aging formerly-general-purpose
languages, like C++, and jumped to the mistaken conclusion that it
must be an inherent limitation of general-purpose rather than a
consequence of continually bolting things (in a backwards-compatible
way) onto an antiquated base.)

Michael Jones

unread,
Aug 12, 2010, 6:41:03 PM8/12/10
to Seth Hoenig, golang-nuts
I think we all heard quite about ranges in Ada, Python, ...
--

Michael T. Jones

   Chief Technology Advocate, Google Inc.

   1600 Amphitheatre Parkway, Mountain View, California 94043

   Email: m...@google.com  Mobile: 650-335-5765  Fax: 650-649-1938

   Organizing the world's information to make it universally accessible and useful


Leandro Lucarella

unread,
Aug 12, 2010, 6:59:28 PM8/12/10
to golang-nuts
On 26 jul, 13:28, Prakash Bhurke <praks.wo...@gmail.com> wrote:
> Thanks Kar for sharing your experience.  I have following doubts:
>
> > if you like politics in D (d1.0, d2.0, phobos, tango), i've been using
> > D for almost 5 yrs now porting my project from D+tango to Go and its a
> > breeze.
>
> Why are porting your projects from D+tango to Go ? What are problems
> you faced while using D? Sorry I don't know history/politics of D.

About D politics, I just can say there is way too much community
fragmentation. With D2 things a little bit better (in that, and many
more factors). I think the worse problem in D how the language is
managed. Is really too complex to explain in a couple of lines, but
you can read these blog posts to get an impression (some issues
mentioned in those posts are outdated and some have been improved
considerably, so the only real way to know how things work is giving
it a try):

D and open development model: http://www.llucax.com.ar/blog/blog/post/6cac01e1
The D roadmap: http://www.billbaxter.com/techblog/?p=14
The Future of D Is Aaargh, My Eyes!:
http://while-nan.blogspot.com/2007/08/future-of-d-is-aaargh-my-eyes.html
The angry emo D rant: http://h3.gd/devlog/?p=22
The Present of D: http://www.jfbillingsley.com/blog/?p=53

I've been following D and, even when as a language is way better than
anything I saw before (I like Go though, but I don't agree that is a
*system* programming language, in that sense I think D is unique), I
wanted to move on because there is horribly managed, "the management"
had no idea of what an open source project is about. Fortunately
things are slowly changing, but sometimes changes are too slow. And
this is for DMD, the oficial/reference compiler. LDC (LLVM based
compiler) and GDC (GCC based compiler) are often better but too
amateur (and I'm not talking about quality, I'm talking about
commitment). They are supported by very nice people that have their
own life and spend time in the compilers only when they can, which I
find extremely reasonable (I do the same) but means that for some
large periods of time they are unsupported. In that sense I think D is
missing some big user that is willing to spend some money/men-hour in
supporting the development.

But I insist, that is only in the human-plane of the language
development (which is not a small part of the whole), technically, the
language is very good, complex, but not as complex as C++ and much
more clearer. Is certainly much more complex than Go (but much more
flexible too).

I've written a very brief comparison between Go and D (bare in mind
that it was only my first impression just after Go was released):
Go nuts: http://www.llucax.com.ar/blog/blog/post/-522a870c

> > For me it's time to move forward, Go is the future. Go has everything
> > i need, it's simple and it works.
>
> Is D not the future?

Only the future will tell :)

> Which features are missing in D?

Very few, if there is any problem with D features, I think it's it has
too many...

> Is there any big vendor (like google) supporting D?

No.

> Sorry, I should I have asked some of above questions on D mailing list
> or google it.

I hope you find this information useful.

Nick Sabalausky

unread,
Aug 12, 2010, 7:02:25 PM8/12/10
to golang-nuts
Michael Jones wrote:
> I think we all heard quite about ranges in Ada, Python, ...
>

I only know a little Python and I don't know any Ada, but my
understanding is that Python ranges are nothing more than a numeric
sequence. That's not what D ranges are (although that is a small
subset of what they can do). D's ranges are more comparable (in
concept, not necessarily implementation) to a pair of start/end
iterators, but with extra bonuses (and FAR saner usage syntax,
particularly compared to STL). A good explanation is here:
http://www.informit.com/articles/printerfriendly.aspx?p=1407357

Nick Sabalausky

unread,
Aug 12, 2010, 7:16:19 PM8/12/10
to golang-nuts
Leandro Lucarella wrote:
>
> I think the worse problem in D how the language is
> managed. Is really too complex to explain in a couple of lines, but
> you can read these blog posts to get an impression (some issues
> mentioned in those posts are outdated and some have been improved
> considerably, so the only real way to know how things work is giving
> it a try):
>

This is a rather YMMV kind of thing. I find it to work out just fine.
I think some people just find issue with the fact that the management
of D isn't highly-formalized with boatloads of "policies and
procedures" docs and corporate-like structure (and structure-for-the-
sake-of-structure, etc). Look at GCC for the antithesis of D. I tried
to make a contribution to GCC once, but gave up after wasting days
trying to wade through red-tape just to *try* to find the particular
red-tape I needed to deal with just to submit something.

Leandro Lucarella

unread,
Aug 12, 2010, 7:22:52 PM8/12/10
to golang-nuts
D2 ranges are Boost.Ranges, but they are a better fit for the
language. In C++ you have pointer <-> iterator, in D you have dynamic
arrays <-> ranges.

I still don't get why the D community in general (and Andrei usually
too, even when he mention the Boost and Adobe ranges in the article
you cited) embrace the ranges as they were an invention of their own
and as it was unique to D. Boost.Range was first release in November
19th, 2004[1] while the first range proposal in D was in September
8th, 2008[2].

[1] http://www.boost.org/users/history/version_1_32_0
[2] http://www.digitalmars.com/d/archives/digitalmars/D/announce/RFC_on_range_design_for_D2_12922.html

Nick Sabalausky

unread,
Aug 12, 2010, 7:32:50 PM8/12/10
to golang-nuts
Leandro Lucarella wrote:
>
> I still don't get why the D community in general (and Andrei usually
> too, even when he mention the Boost and Adobe ranges in the article
> you cited) embrace the ranges as they were an invention of their own
> and as it was unique to D. Boost.Range was first release in November
> 19th, 2004[1] while the first range proposal in D was in September
> 8th, 2008[2].
>

I suppose that may be a valid point. I think a significant chunk of
the D community is former C++ users who got really, really fed up with
C++ (like me). I know in my case I abandoned C++ out of disgust back
around 2001, so I never really got into boost, and certainly never
heard of Boost's ranges (although over those years I *have* heard a
lot about STL iterators, even outside the D community, so I'm guessing
iterators may be far more typical in C++ than Boost ranges).

Cory Mainwaring

unread,
Aug 12, 2010, 8:58:35 PM8/12/10
to Nick Sabalausky, golang-nuts
The main difference I see between Go and D from a philosophical standpoint is their ratio of power:simplicity. Go leans on the simplicity side, and maintains enough power to be seductive, like the lithe ballet dancer moving gracefully. D leans towards the powerful and sacrifices simplicity for it, such as an erotic dancer throwing her sexuality in your face, and augmenting it with body work.

Ballet vs Strippers. It's a matter of opinion on which is better. It seems both thought there should be a balance between C and C++, D is closer to C++ and Go is closer to C.

Jonathan Yedidia

unread,
Aug 12, 2010, 9:07:29 PM8/12/10
to golang-nuts
I'm in a similar position to the original poster, deciding between Go
and D,
but I think I've made up my mind in favor of D. Actually, I only
really learned
about D after trying Go, finding it didn't fit my needs as much as I'd
like, and looking for something
else similar that does. Here's my comparison:

1. Go isn't really quite a system language; it doesn't let you go as
low-level
as C. Pointer arithmetic or comparisons are forbidden unless you jump
through hoops, casting
between pointers pointing at different underlying types is forbidden,
there are no unions.
D doesn't encourage you to program at a low level; rather
it also encourages pointer-less programming, but it doesn't stand in
your way
like Go does. You can basically do everything you can do in C in D,
including
program in assembly if you want to. So you will definitely be able to
write fast
and low-level code. I like the way D makes the safe thing the default,
but also assumes
that the programmer knows what he or she is doing. I need to be able
to obtain
maximum performance from my programs, and I feel D lets me do that.

2. D's syntax is much closer to C or C++ or Java. Not a big deal, but
it feels less
alien. Also, I personally program using Knuth's CWEB literate
programming tools, and
making them work with D is a breeze compared to the changes necessary
to make
them work with Go, because D's syntax is so C/C++-like.

3. Both languages do a great job on letting you program in a Python-
like way with
a statically-typed language. The two have similar concurrency
features. The languages
are alike in a lot of ways. A major difference in philosophy is that
Go is smaller and simpler;
the goal was to make a language using only orthogonal features. D
basically tries
to add all useful features. So for example if you like generics, D is
the way to go.
But if simplicity itself is a major feature for you, Go has the
advantage there.

4. Go has better documentation at its web-site, and with the
distribution, but D has an excellent book by
Andrei Alexandrescu that came out recently. I would not have made the
switch without
the "Programming in D" book. Go could use a book too.

5. Go has the advantage of the support of Google, which looks to be
long-term.

6. I believe D inter-operates with C better than Go does.

7. Go has 64-bit compilers; D doesn't yet.

I think both languages are interesting and usable as they stand, and I
hope both succeed. I am
a bit put off by statements from the Go side that there hasn't been a
new systems language for
15 years. What about D? I almost didn't learn about D because I
believed them. They should
not say such things.

Nick Sabalausky

unread,
Aug 12, 2010, 9:47:53 PM8/12/10
to golang-nuts
Jonathan Yedidia wrote:
> I am
> a bit put off by statements from the Go side that there hasn't been a
> new systems language for
> 15 years. What about D? I almost didn't learn about D because I
> believed them. They should
> not say such things.
>

And Cyclone. And Vala. And BitC...

Cory Mainwaring

unread,
Aug 12, 2010, 9:49:57 PM8/12/10
to Nick Sabalausky, golang-nuts
I believe the wording was closer to: "the current languages in common use are over a decade old"

Leandro Lucarella

unread,
Aug 12, 2010, 9:54:26 PM8/12/10
to golang-nuts
On 12 ago, 20:22, Leandro Lucarella <llu...@gmail.com> wrote:
> On 12 ago, 20:02, Nick Sabalausky <nsetbtg...@mailinator.com> wrote:
> > I only know a little Python and I don't know any Ada, but my
> > understanding is that Python ranges are nothing more than a numeric
> > sequence. That's not what D ranges are (although that is a small
> > subset of what they can do). D's ranges are more comparable (in
> > concept, not necessarily implementation) to a pair of start/end
> > iterators, but with extra bonuses (and FAR saner usage syntax,
> > particularly compared to STL). A good explanation is here:http://www.informit.com/articles/printerfriendly.aspx?p=1407357
>
> D2 ranges are Boost.Ranges, but they are a better fit for the
> language. In C++ you have pointer <-> iterator, in D you have dynamic
> arrays <-> ranges.
>
> I still don't get why the D community in general (and Andrei usually
> too, even when he mention the Boost and Adobe ranges in the article
> you cited) embrace the ranges as they were an invention of their own
> and as it was unique to D. Boost.Range was first release in November
> 19th, 2004[1] while the first range proposal in D was in September
> 8th, 2008[2].

Since someone brought to my attention that this paragraph might be
misunderstood (which I agree), I want to clarify that I'm not saying
that the community in general, or Andrei in particular, is actively
avoiding giving proper attribution or credit, it's just a personal
feeling from how they refer to ranges. Maybe I shouldn't write "as
they
were they invention" and only said "as it was unique to D".

Andrei Alexandrescu

unread,
Aug 12, 2010, 11:03:45 PM8/12/10
to golang-nuts
Many thanks to the reader who brought this discussion to my attention.

There have been a lot of great points made here. Let me help with a
couple of factoids:

* Indeed a visit to "the other biased opinion" could help - try
http://www.digitalmars.com/NewsGroup.html, the digitalmars.D
newsgroup.

* A cursory visit to the above should clarify that there's little if
any politics going on. There was a politics-laden period in D's
history that is now long gone. Compare e.g. exchanges from a couple of
years ago with today's - it's night and day.

* About D having "too many features" - that statement evokes to me
Emperor Joseph II's famous "too many notes" remark (http://
www.youtube.com/watch?v=dCud8H7z7vU). Of course I'm not claiming D is
nearly as close to perfection as Mozart's music; I'm just saying that
such a blanket remark should be automatically backed up by concrete
arguments. For my money D has exactly the right amount of features to
achieve the torque we want it to have; removing any would make a
category of designs limp by being less precise, less safe, or less
efficient. I have no doubt that Go will also grow significantly with
usage - bolting generics onto it will make it much larger, and not
doing so is in my opinion not an option.

* About a 64-bit version - here Go is ahead of D but not for long, as
others have mentioned. I should add that Go's networking libraries are
more mature than D's. We are working on improving ours, and we believe
that the power of the language will be of great help with that design.

* Comparisons of Go with C and (respectively) D with C++ have some
merit. However, D has resolutely exited C++'s shade because it is good
at things C++ is not good at, in addition to being good at things C++
is good at. Also, Go would be tenuous to frame as a better C because
it cannot do everything C does - e.g. unsafe memory access and manual
memory management, which are needed in certain systems - and it
interoperates poorly with C.

* On a lighter note, I admit I was amused by the remark that no
systems language has been developed in the past 15 years. It's quite
difficult to find proper excuses and qualifications for that; even
though I made even bolder statements I've already had solid facts
backing me up. After having heard a major Go proponent make that
remark in a public talk as unequivocally as it gets, I went straight
ahead and googled for "systems programming language". If D were a
snake, it would have bitten me by the nose. I sure hope Go is not
overall characterized by self-isolation. We also do our best on the D
team to stay in touch with the latest research and development in the
Programming Languages field.

Kai Backman

unread,
Aug 13, 2010, 1:17:50 AM8/13/10
to Jonathan Yedidia, golang-nuts
On Fri, Aug 13, 2010 at 4:07 AM, Jonathan Yedidia <jsye...@yahoo.com> wrote:
> 1. Go isn't really quite a system language;

I respectfully disagree. I have not found the use of the unsafe
package to be of any practical limitation when writing systems
programs. I've also used manual memory management, basically mmapping
in memory pages and handing out the memory with a custom allocator.

Having used both languages for a few years I think this sums things up
nicely: Go is a better C, D is a better C++ (and Java is an even
better C++)

Kai

Russel Winder

unread,
Aug 13, 2010, 1:48:45 AM8/13/10
to Andrei Alexandrescu, golang-nuts
Andrei,

I have liked D for a long while, but until there is a stable 64-bit
v2.0, with AMD64 installers, alongside the 386 v2.0, it is not really a
viable language.

I really like Go because of the process/channels model (I have been a
fan of CSP, and actor model, for over 25 years) and the presence of some
(not enough?) reflection capabilities.

The actor model is getting a lot of promotion via Erlang and Scala,
software transactional memory is getting a lot of promotion via Haskell
and Clojure. occam lives on as occam-pi in KRoC and JCSP (on which we
have constructed GroovyCSP), CSP is even getting airtime in Python (via
PythonCSP and PyCSP). The overall goal here, which to a great extent
strikes me as the goal of Go's goroutines and channels, is to
commoditize processor and turn it into a resource that is managed by the
runtime system just as memory is. Applications should not have to worry
about multicore directly, though they do have to worry about
communications distance between processors so as to avoid inappropriate
assumptions about communications time and safety.

The problem for me with Go and D is that both languages give all the
appearance of being backward looking -- though this may just be
conditioned by worrying about Posix compliance.

For me there are two questions:

1. What is the language for writing the next big operating system?

2. Do PGAS languages have the edge for writing applications in the
future?

Linux and Mach, like Windows, are now really in "maintenance mode" their
architectures and fundamental capabilities are fixed and unchangeable.
Future hardware architectures show all the signs of heading directly
towards multiple, heterogeneous, multicore, NUMA architectures with
bus-level clustering, local clustering and wide-area clustering (if not
more communications levels) and operating systems and programming
languages are not really ready to handle this. Languages like Chapel,
X10, even Fortress are doing lots of interesting research in PGAS but
because they market themselves in the HPC arena, they don't get taken as
seriously as they should by a wider audience of programmers. Certainly
though they are neither ready, nor possible never appropriate, for the
leap of being languages with which to write operating systems.

So the question really is whether D and Go are just interesting
sidelines in the interregnum between the era of network connected
uniprocessors and that of massively parallel, multi-level architecture
systems.

Go and its goroutines handle bus-level multicores quite nicely but then
the next level is network, there is no concept of layered clustering. C
++0x gives us futures and asynchronous function call to give similar,
albeit different, functionality -- and restrictions. I haven't
investigated D as much as I would like because of the 64-bit problem and
because the Threads library up to version 2.047 had errors that meant
threads code would not compile on Ubuntu Lucid or Debian Testing (I
guess I should download and try 2.048) and, to be honest, shared memory
multi-threading is not my idea of doing parallelism as an applications
programmer.

I suspect there will be a lot of prejudice against using a language with
garbage collection for writing a new operating system, which gives doubt
about whether Go will get used for that -- despite all the splendid
Plan-9 related work. So can D really step up and be a candidate? Or
will people just descend to the arguments "C is the only language
because it is the only one with a low enough viewpoint"?

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

signature.asc

Stanley Steel

unread,
Aug 13, 2010, 2:47:06 AM8/13/10
to rus...@russel.org.uk, Andrei Alexandrescu, golang-nuts

I agree with your assessment about D and Go.  I have followed D for a long while (~2003) and Go since November.  I appreciate both languages and the effort and thought that went into them; they don't really seem to solve the big looming issues.  But, there are alternatives; too many it seems.  Teams are searching feverishly for the right solution to our programming problems related to multi-core systems.  I've been interested in a type-state oriented programming language called Plaid from a research team at Carnegie Mellon University (I know Rust exists).  They are funded by DARPA and the NSF.  Anyway, they are looking at automatic concurrency, immutability, etc.  Huge issues, that if solved, buy a lot for the developer.  It is worth reading through their white papers.  I am looking to port it to a systems language, or at least portions of it and currently have a short email trail going with the lead researcher.  It is built for the JVM much the same way Scala is, but I don't want anything to do with Oracle if I can help it.  Anyway, languages come and go all the time.  Those that are to be successful must reduce the pain of use found in currently popular languages, and even then it is an uphill battle.  I wish every language developer the best of luck; their work benefits us all.

Stanley Steel

unread,
Aug 13, 2010, 2:58:06 AM8/13/10
to rus...@russel.org.uk, Andrei Alexandrescu, golang-nuts
P. S. Andrei, I have your book sitting on my desk right in front of me, next to my ANTLR reference book.  I preordered it on Amazon last summer.  Great work!  You said there are certain books that do not have an author listed on the front; my book does not have your name under the painting on the front cover.  What is the significance of that?

Taru Karttunen

unread,
Aug 13, 2010, 3:32:02 AM8/13/10
to Andrei Alexandrescu, golang-nuts
On Thu, 12 Aug 2010 20:03:45 -0700 (PDT), Andrei Alexandrescu <iro...@gmail.com> wrote:
> * Comparisons of Go with C and (respectively) D with C++ have some
> merit. However, D has resolutely exited C++'s shade because it is good
> at things C++ is not good at, in addition to being good at things C++
> is good at. Also, Go would be tenuous to frame as a better C because
> it cannot do everything C does - e.g. unsafe memory access and manual
> memory management, which are needed in certain systems - and it
> interoperates poorly with C.

Package unsafe does go a long way there serving for all the evil pointer
tricks. And of course one can trivially call C and assembly code
compiled by gc/ga without using any external tools.

- Taru Karttunen

bioinfornatics

unread,
Aug 13, 2010, 7:26:03 AM8/13/10
to golang-nuts
Hello,
About a 64-bit version, the compiler LDC and Tango library support
both 32 and 64 bit.
* LDC is LLVM based and use the DMD frontend. it is a free software
under BSD license.
http://www.dsource.org/projects/ldc
* Tango is too under BSD license
http://www.dsource.org/projects/tango/wiki

About networking library they are mango under BSD license:
http://www.dsource.org/projects/mango


Feel free for help and improve these project

Andrei Alexandrescu

unread,
Aug 13, 2010, 9:42:34 AM8/13/10
to golang-nuts
On Aug 13, 12:48 am, Russel Winder <rus...@russel.org.uk> wrote:
> Andrei,
>
> I have liked D for a long while, but until there is a stable 64-bit
> v2.0, with AMD64 installers, alongside the 386 v2.0, it is not really a
> viable language.

I agree.

> I really like Go because of the process/channels model (I have been a
> fan of CSP, and actor model, for over 25 years) and the presence of some
> (not enough?) reflection capabilities.
>
> The actor model is getting a lot of promotion via Erlang and Scala,
> software transactional memory is getting a lot of promotion via Haskell
> and Clojure.  occam lives on as occam-pi in KRoC and JCSP (on which we
> have constructed GroovyCSP), CSP is even getting airtime in Python (via
> PythonCSP and PyCSP).  The overall goal here, which to a great extent
> strikes me as the goal of Go's goroutines and channels, is to
> commoditize processor and turn it into a resource that is managed by the
> runtime system just as memory is.  Applications should not have to worry
> about multicore directly, though they do have to worry about
> communications distance between processors so as to avoid inappropriate
> assumptions about communications time and safety.

If you're a fan of the actor model then you'll be glad that D uses it.
Fortunately Addison-Wesley agreed to publish online the TDPL chapter
on concurrency:

http://www.informit.com/articles/printerfriendly.aspx?p=1609144

D uses Actor, Go uses CSP. If squinting hard enough the two models are
about as powerful. However, we strongly think that message passing is
not appropriate for everything. At the same time we believe that low-
level races are the worst kind of weakness in a type system.

To define sharing without races, D has a coherent model for
immutability (via the immutable qualifier) and a model for lock-free
sharing (via the sharing qualifier). The system is simpler than that
of race-free academic languages (i.e. Cormac Flanagan's or Boyapati/
Rinard's work on Java extensions) and also less powerful, but we
believe that message passing + immutability + limited sharing form a
very compelling proposition.

Go is simpler in that it doesn't formalize sharing, but also wants to
be expressive, which exposes it to data races. If you create a channel
of *int, my understanding (and please correct me if I'm wrong) only
convention can help you from having two threads access the same
integer. It only gets worse with pointers to more elaborate data
types, and history has shown that convention is a poor mechanism for
ensuring thread safety of any kind. For my money that's simply not an
option.

> The problem for me with Go and D is that both languages give all the
> appearance of being backward looking -- though this may just be
> conditioned by worrying about Posix compliance.

I don't understand this part.

> For me there are two questions:
>
> 1.  What is the language for writing the next big operating system?
>
> 2.  Do PGAS languages have the edge for writing applications in the
> future?

In my humble opinion PGAS has still a ways to go to prove its
usefulness outside specialized parallel computing.
We don't use D's old thread libraries for most or any modern
concurrent work. We designed the message passing mechanism to scale
seamlessly to out-of-process and out-of-machine communication, but we
have not realized that flexibility yet. What is certain is that D's
type system is expressive enough to allow libraries to reject during
compilation embarrassments such as transporting pointers over the
network.

> I suspect there will be a lot of prejudice against using a language with
> garbage collection for writing a new operating system, which gives doubt
> about whether Go will get used for that -- despite all the splendid
> Plan-9 related work.  So can D really step up and be a candidate?  Or
> will people just descend to the arguments "C is the only language
> because it is the only one with a low enough viewpoint"?

D can do everything C can do.

One closing note - since this is a group dedicated to discussions
about the Go programming language, I think it would be polite to
direct future questions to a D-specific forum. Thank you.

Andrei Alexandrescu

unread,
Aug 13, 2010, 9:44:26 AM8/13/10
to golang-nuts
On Aug 13, 1:58 am, Stanley Steel <st...@kryas.com> wrote:
> P. S. Andrei, I have your book sitting on my desk right in front of me, next
> to my ANTLR reference book.  I preordered it on Amazon last summer.  Great
> work!  You said there are certain books that do not have an author listed on
> the front; my book does not have your name under the painting on the front
> cover.  What is the significance of that?

The only significance of that is that an error at the printer made the
authorless TDPL copies a rare collector's edition. There are only 1830
copies total that don't have the author's name on the cover. There
were a lot more, but they have been recycled.

Ian Lance Taylor

unread,
Aug 13, 2010, 10:30:22 AM8/13/10
to Andrei Alexandrescu, golang-nuts
Andrei Alexandrescu <iro...@gmail.com> writes:

> At the same time we believe that low-
> level races are the worst kind of weakness in a type system.

That's an interesting perspective. I agree that low-level races are a
serious problem in modern programming. But phrasing in terms of a
problem in the type system seems odd to me. It seems to me that the
purpose of a type system is to ensure that the only appropriate
operations are applied to a particular piece of data. But a low-level
race is not a result of an inappropriate operation, it's a result of two
appropriate operations being applied without necessary safeguards.
Using the type system to avoid races is like using the type system to
prevent two different programs from writing to the same file at the same
time; it seems to me to be working at the wrong level.


> To define sharing without races, D has a coherent model for
> immutability (via the immutable qualifier) and a model for lock-free
> sharing (via the sharing qualifier). The system is simpler than that
> of race-free academic languages (i.e. Cormac Flanagan's or Boyapati/
> Rinard's work on Java extensions) and also less powerful, but we
> believe that message passing + immutability + limited sharing form a
> very compelling proposition.

I wasn't able to find the docs on the sharing qualifier (the docs
suggest that it is called shared, but I couldn't find any docs on that
either). Can you point me to a description of how it works?


> Go is simpler in that it doesn't formalize sharing, but also wants to
> be expressive, which exposes it to data races. If you create a channel
> of *int, my understanding (and please correct me if I'm wrong) only
> convention can help you from having two threads access the same
> integer. It only gets worse with pointers to more elaborate data
> types, and history has shown that convention is a poor mechanism for
> ensuring thread safety of any kind. For my money that's simply not an
> option.

You're quite right: Go does permit data races, and does currently rely
only on convention to avoid them. Go's advantage over C++, and it is a
significant advantage, is that the rules for valid sharing are fairly
simple, and the language makes it much easier to do valid sharing.

As far as I know it is an open question whether it is possible to have a
language that is simple, expressive and efficient, and is also able to
prevent or detect data races. One approach is the type system, but as
noted I think that is the wrong level and not simple. Another approach
is transactional memory, whether in hardware or software, but that is
not efficient and also checks operations at the wrong level--the byte
rather than the struct.

In Go it's natural to think of sending a pointer on a channel as a
transfer of ownership. That suggests a model in which the compiler
warns about cases where sending a pointer on a channel is followed by a
write through the pointer. Go's package system makes it possible to do
this reliably inter-procedurally, but of course it's possible to write
complex looping code, or code that changes behaviour based on user
input, that defies analysis.

It also suggests a "safe" compilation mode in which pointers are
annotated with ownership information. Sending a pointer on a channel
changes ownership. Writing through a pointer checks ownership. This is
problematic in that it only detects races which actually occur, not
races which could theoretically occur.

I really don't know how feasible these ideas are.

Ian

Andrei Alexandrescu

unread,
Aug 13, 2010, 11:19:03 AM8/13/10
to golang-nuts
On Aug 13, 9:30 am, Ian Lance Taylor <i...@google.com> wrote:
> Andrei Alexandrescu <iro...@gmail.com> writes:
> > At the same time we believe that low-
> > level races are the worst kind of weakness in a type system.
>
> That's an interesting perspective.  I agree that low-level races are a
> serious problem in modern programming.  But phrasing in terms of a
> problem in the type system seems odd to me.

Here are some starting points that could be helpful:

Object types against races, by Flanagan/Abadi
http://tinyurl.com/3xf798g

Type inference against races, by Flanagan/Friend
http://tinyurl.com/2uzm729

A parameterized type system for race-free Java programs, by Boyapati/
Rinard
http://tinyurl.com/34mvbb8

The papers are rather involved but the introductions tend to give a
good overview of the gist of the work.

> I wasn't able to find the docs on the sharing qualifier (the docs
> suggest that it is called shared, but I couldn't find any docs on that
> either).  Can you point me to a description of how it works?

As I mentioned, the entire chapter on concurrency in TDPL is available
for free online:

http://www.informit.com/articles/printerfriendly.aspx?p=1609144

> You're quite right: Go does permit data races, and does currently rely
> only on convention to avoid them.  Go's advantage over C++, and it is a
> significant advantage, is that the rules for valid sharing are fairly
> simple, and the language makes it much easier to do valid sharing.

How does Go simplify the rules for valid sharing? Far as I can tell it
can only simplify if it renders undue aliasing undefined. Does Go have
something equivalent to Java's volatile and C++0x's atomic?

> In Go it's natural to think of sending a pointer on a channel as a
> transfer of ownership.  That suggests a model in which the compiler
> warns about cases where sending a pointer on a channel is followed by a
> write through the pointer.  Go's package system makes it possible to do
> this reliably inter-procedurally, but of course it's possible to write
> complex looping code, or code that changes behaviour based on user
> input, that defies analysis.

I'm afraid things are much more complicated than just rejecting a
write through the passed pointer. Interprocedural alias analysis has
known and well-understood challenges. To date, no language I know
relies on interprocedural alias analysis for semantic checking.

> It also suggests a "safe" compilation mode in which pointers are
> annotated with ownership information.  Sending a pointer on a channel
> changes ownership.  Writing through a pointer checks ownership.  This is
> problematic in that it only detects races which actually occur, not
> races which could theoretically occur.
>
> I really don't know how feasible these ideas are.

This is well-trodden ground. The brief answer is - it is possible (by
formalizing uniqueness within the language) but out the window goes
simplicity.

Andrei Alexandrescu

unread,
Aug 13, 2010, 11:27:13 AM8/13/10
to golang-nuts
On Aug 13, 12:48 am, Russel Winder <rus...@russel.org.uk> wrote:
> I suspect there will be a lot of prejudice against using a language with
> garbage collection for writing a new operating system, which gives doubt
> about whether Go will get used for that -- despite all the splendid
> Plan-9 related work.  So can D really step up and be a candidate?  Or
> will people just descend to the arguments "C is the only language
> because it is the only one with a low enough viewpoint"?

D is already being used for implementing a kernel:

http://wiki.xomb.org

I am not familiar with the project beyond knowing it exists. FWIW to
me it is obvious that D is capable for kernel work, simply because it
has what it takes.


Andrei

Michael Jones

unread,
Aug 13, 2010, 3:02:59 PM8/13/10
to Andrei Alexandrescu, golang-nuts
Thank you Andrei and Ian for demonstrating the best level of intellectual discussion that one could hope for in an open discussion forum.

Ian Lance Taylor

unread,
Aug 13, 2010, 4:00:54 PM8/13/10
to Andrei Alexandrescu, golang-nuts
Andrei Alexandrescu <iro...@gmail.com> writes:

>> I wasn't able to find the docs on the sharing qualifier (the docs
>> suggest that it is called shared, but I couldn't find any docs on that
>> either).  Can you point me to a description of how it works?
>
> As I mentioned, the entire chapter on concurrency in TDPL is available
> for free online:
>
> http://www.informit.com/articles/printerfriendly.aspx?p=1609144

Thanks. As you know, this approach is clearly different from the one in
Go, which is a transfer of ownership model, where the transfer of
ownership is enforced only by convention. And, of course, Go doesn't
use the type system, which follows Go's general guideline of keeping the
type system light weight.


>> You're quite right: Go does permit data races, and does currently rely
>> only on convention to avoid them.  Go's advantage over C++, and it is a
>> significant advantage, is that the rules for valid sharing are fairly
>> simple, and the language makes it much easier to do valid sharing.
>
> How does Go simplify the rules for valid sharing? Far as I can tell it
> can only simplify if it renders undue aliasing undefined. Does Go have
> something equivalent to Java's volatile and C++0x's atomic?

The rules for valid sharing are encapsulated in the slogan "don't
communicate by sharing memory; instead, share memory by communicating."
That is, always use channels to communicate between goroutines. Always
ensure that a single goroutine owns shared data, and use an explicit
channel send to transfer ownership to a different goroutine.

This approach can be used in other languages also, of course; the
advantage I see in Go is that the language makes it simple and easy.

Ian

Andrei Alexandrescu

unread,
Aug 13, 2010, 8:15:27 PM8/13/10
to golang-nuts
On Aug 13, 2:02 pm, Michael Jones <m...@google.com> wrote:
> Thank you Andrei and Ian for demonstrating the best level of intellectual
> discussion that one could hope for in an open discussion forum.

Let's keep it that way!

Andrei Alexandrescu

unread,
Aug 13, 2010, 8:39:36 PM8/13/10
to golang-nuts
On Aug 13, 3:00 pm, Ian Lance Taylor <i...@google.com> wrote:
> Andrei Alexandrescu <iro...@gmail.com> writes:
> >http://www.informit.com/articles/printerfriendly.aspx?p=1609144
>
> Thanks.  As you know, this approach is clearly different from the one in
> Go, which is a transfer of ownership model, where the transfer of
> ownership is enforced only by convention.  And, of course, Go doesn't
> use the type system, which follows Go's general guideline of keeping the
> type system light weight.

I understand. So what we have now is:

(1) Pass-by-bitblt through channels for value types (i.e. no
indirections, which means dynamic arrays are unduly shared). There is
no checking that a value type being passed actually does not have
indirections.

(2) Pass of ownership by unchecked convention for data with
indirections.

(3) Everything else is undefined.

If that's true, parts 1 and 2 are of limited expressiveness but it's
part 3 that's really problematic, and I'm not sure a putative
programmer understands the implications. Essentially that means even
lock-based programming relies on implementation-level vagaries because
without a memory model the compiler and the processor are relatively
free to hoist data around rather freely. We're back to the reorderings
hell often showcased as motivators of Java's and C++0x's memory
models.

> >> You're quite right: Go does permit data races, and does currently rely
> >> only on convention to avoid them.  Go's advantage over C++, and it is a
> >> significant advantage, is that the rules for valid sharing are fairly
> >> simple, and the language makes it much easier to do valid sharing.
>
> > How does Go simplify the rules for valid sharing? Far as I can tell it
> > can only simplify if it renders undue aliasing undefined. Does Go have
> > something equivalent to Java's volatile and C++0x's atomic?
>
> The rules for valid sharing are encapsulated in the slogan "don't
> communicate by sharing memory; instead, share memory by communicating."
> That is, always use channels to communicate between goroutines.  Always
> ensure that a single goroutine owns shared data, and use an explicit
> channel send to transfer ownership to a different goroutine.
>
> This approach can be used in other languages also, of course; the
> advantage I see in Go is that the language makes it simple and easy.

A memory model may as well be the perfect example where simplicity is
your enemy - not defining one is indeed simple, but has huge costs to
the user in one or more of correctness, portability, safety,
expressiveness, and efficiency.

So essentially (again I'm basing this on inference from what I've read
on golang.org and this discussion) one must only use the patterns (1)
and (2) in concurrent code. This severe limitation further erodes Go's
capabilities when compared to C, and I think it's reasonable that I
find Go's offering severely wanting for serious concurrent work.


Andrei

Ian Lance Taylor

unread,
Aug 13, 2010, 9:21:34 PM8/13/10
to Andrei Alexandrescu, golang-nuts
Andrei Alexandrescu <iro...@gmail.com> writes:

> I understand. So what we have now is:
>
> (1) Pass-by-bitblt through channels for value types (i.e. no
> indirections, which means dynamic arrays are unduly shared). There is
> no checking that a value type being passed actually does not have
> indirections.
>
> (2) Pass of ownership by unchecked convention for data with
> indirections.
>
> (3) Everything else is undefined.
>
> If that's true, parts 1 and 2 are of limited expressiveness but it's
> part 3 that's really problematic, and I'm not sure a putative
> programmer understands the implications. Essentially that means even
> lock-based programming relies on implementation-level vagaries because
> without a memory model the compiler and the processor are relatively
> free to hoist data around rather freely. We're back to the reorderings
> hell often showcased as motivators of Java's and C++0x's memory
> models.

Go does have a memory model: http://golang.org/doc/go_mem.html . The
memory model does define mutexes. They are stylistically discouraged
for use in most Go code, but they are available and well-defined when
required.

Ian

Andrei Alexandrescu

unread,
Aug 13, 2010, 10:14:30 PM8/13/10
to golang-nuts
> Go does have a memory model:http://golang.org/doc/go_mem.html.  The
> memory model does define mutexes.  They are stylistically discouraged
> for use in most Go code, but they are available and well-defined when
> required.

Thanks, I'd missed that. Will take a look.

dic...@gmail.com

unread,
Aug 13, 2010, 11:22:59 PM8/13/10
to golang-nuts
I've been a C++ programmer for about 16 years, and I find this debate
fascinating.

I must admit that I find the idea of a simple, compiled & garbage
collected language very tantalizing. That said, I choose to work in C+
+ and not C because I do like the expressiveness of many of it's
features.

Perhaps there is room for both languages in the world? I think the
next few years will be very interesting... :) I think I'll learn
both...

David Leimbach

unread,
Aug 13, 2010, 11:39:56 PM8/13/10
to golang-nuts

It couldn't hurt. And you will be able to clear up any
misconceptions for yourself that may have been introduced in this
thread about either language.

david

unread,
Aug 14, 2010, 3:12:14 AM8/14/10
to golang-nuts
It might be off topic, but I don't think that there is only two
languages fighting for next big thing. Yes we do have Go, we do have D
(let's hope they finish 2.0 version and fix runtimes mess), but there
other languages like Objective-C (yes, it's old language already, it's
the fastest growingI for now), Vala Language which like C# front-end
for C language (generates C code and then compiles it).

It's very hard to decide which language is going to become next big
think, discussion might take years and you still won't get answer you
are looking for. Most of those languages are still in development.
Vala is developed for 4 years already (0.10.0 coming in September), D
2.0 for 3 years already (so far no indication when it will be
released), Go for a year. And development still requires many years
and many years are required for adaptation.

Some of languages are gonna stay as academic, enthusiasts languages.

Just my thoughts.

Scott Lawrence

unread,
Aug 14, 2010, 3:48:46 AM8/14/10
to david, golang-nuts
OTOH, taking a few quick glances around
(http://www.complang.tuwien.ac.at/anton/comp.lang-statistics/ mainly),
it looks like most popular programming languages of today spent a good
deal of time in obscurity. In 1997, 8 years after the python project
was begun, it was at level of obscurity comparable to ada today (if
these statistics are to be trusted). Java did better - it was
announced in 1995, and JDK1.0 was released in 1996. It rose out of
obscurity within the next two years. C seems to have done about as
well/poorly as python - it was working well in 1973 (when the Unix
kernel for PDP-11 was written in it - I'm reading from
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html, I wasn't alive
then), but C wasn't "spreading widely" until the 1980s (again,
semi-quoting). Of course, B was around for a good bit before C (two
years at least), and the BCPL description was around in 1969, 4 years
before any part of it was ready for handling the Unix kernel.

So counting the years elapsed seems a poor predictor of language adoption.


--
Scott Lawrence

Paulo Pinto

unread,
Aug 14, 2010, 4:32:07 AM8/14/10
to golang-nuts
I believe that the regardless of C's merits as a programming language,
then only
reason it got widespread use was because of Unix.

It was Unix's implementation language, and Unix was widely adopted in
Universities.

So most people got to learn it in CS classes and tried to make use of
the language
outside Unix, which lead to the language popularity.

If C was just another language, not tied to Unix, I doubt we would
still use it today.

--
Paulo

On Aug 14, 9:48 am, Scott Lawrence <byt...@gmail.com> wrote:
> OTOH, taking a few quick glances around
> (http://www.complang.tuwien.ac.at/anton/comp.lang-statistics/mainly),
> it looks like most popular programming languages of today spent a good
> deal of time in obscurity. In 1997, 8 years after the python project
> was begun, it was at level of obscurity comparable to ada today (if
> these statistics are to be trusted). Java did better - it was
> announced in 1995, and JDK1.0 was released in 1996. It rose out of
> obscurity within the next two years. C seems to have done about as
> well/poorly as python - it was working well in 1973 (when the Unix
> kernel for PDP-11 was written in it - I'm reading fromhttp://cm.bell-labs.com/cm/cs/who/dmr/chist.html, I wasn't alive
> then), but C wasn't "spreading widely" until the 1980s (again,
> semi-quoting). Of course, B was around for a good bit before C (two
> years at least), and the BCPL description was around in 1969, 4 years
> before any part of it was ready for handling the Unix kernel.
>
> So counting the years elapsed seems a poor predictor of language adoption.
>

Paulo Pinto

unread,
Aug 14, 2010, 4:42:00 AM8/14/10
to golang-nuts
Couldn't agree more.

What many people forget when introducing the next best thing is the
famous
"worse is better" theorem.

http://en.wikipedia.org/wiki/Worse_is_better

Human psychology is a complex matter, and you may introduce the best
tool
that you can imagine. BUT it really has to have a big selling point,
otherwise
people will not change.

People will prefer to live with the problems they already know and are
able to
manage, than going through the pain of change if they don't that much
better in
the end.

You can of course always force change, but people won't make it
gladly.

I too would like that a new systems programming language could replace
C and C++, I just wonder if with the current computer architecture it
will ever happen.

Because the replacement language needs to offer more than just a GC +
improved
type system. It has to have a "Wow factor" to create critical mass,
otherwise people
will stay with what they already know.

--
Paulo

Paulo Pinto

unread,
Aug 14, 2010, 5:01:33 AM8/14/10
to golang-nuts
One of the good things that Java brought to the market, regardless of
what you feel
about the language/environment was to make GC enabled languages
acceptable by the IT industry. To the point that most people accept it
nowadays.

In the academia there were already quite a few efforts to write
operating systems
in GC enabled language, just to name a few:

http://en.wikipedia.org/wiki/Oberon_operating_system
http://en.wikipedia.org/wiki/Modula-3
http://programatica.cs.pdx.edu/House/
http://research.microsoft.com/en-us/projects/singularity/

Speaking of existing OS, I expect MacOS X and Windows to evolve slowly
in that direction,
but it will still take quite some years.

But maybe that is where the previous attempts have failed. By
proposing radical changes,
instead of slowly evolve already existing systems.

--
Paulo

On Aug 13, 7:48 am, Russel Winder <rus...@russel.org.uk> wrote:
>
> I suspect there will be a lot of prejudice against using a language with
> garbage collection for writing a new operating system, which gives doubt
> about whether Go will get used for that -- despite all the splendid
> Plan-9 related work.  So can D really step up and be a candidate?  Or
> will people just descend to the arguments "C is the only language
> because it is the only one with a low enough viewpoint"?
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: rus...@russel.org.uk
> London SW11 1EN, UK   w:www.russel.org.uk skype: russel_winder
>
>  signature.asc
> < 1KViewDownload

Giuseppe Altea

unread,
Aug 14, 2010, 5:38:29 AM8/14/10
to Paulo Pinto, golang-nuts

Tried go - liked it because of simple design fast compile speed and ability to evovle into a first class alternative to c something that is needed c evelved in late 70s early 80s in mini and then micro processor environment something that addresses the advancement in cpu threading and messaging technologies but has a simple highly portable core with updated abikities to use them parallel technologies is really needed I think go is a valid attempt at that and takes hit at it a a nice spot with a nice blend of new fearues to reflect the kinds of programs that could written for newer gen hardware
Giuseppe

Jonathan Yedidia

unread,
Aug 14, 2010, 11:56:34 AM8/14/10
to golang-nuts


On Aug 14, 3:12 am, david <david.abdurachma...@gmail.com> wrote:
> Most of those languages are still in development.
> Vala is developed for 4 years already (0.10.0 coming in September), D
> 2.0 for 3 years already (so far no indication when it will be
> released), Go for a year.

I don't understand what you mean by "no indication when it will be
released" for D. You can download the DMD 2.048 compiler today and it
works; I haven't found anything that doesn't match the description in
"The D Programming Language" book. Sure D is still in development; so
is Python, Ruby, Java, and any other language that isn't dead.

unread,
Aug 14, 2010, 12:54:36 PM8/14/10
to golang-nuts
On Aug 13, 4:30 pm, Ian Lance Taylor <i...@google.com> wrote:
> That's an interesting perspective.  I agree that low-level races are a
> serious problem in modern programming.  But phrasing in terms of a
> problem in the type system seems odd to me.  It seems to me that the
> purpose of a type system is to ensure that the only appropriate
> operations are applied to a particular piece of data.  But a low-level
> race is not a result of an inappropriate operation, it's a result of two
> appropriate operations being applied without necessary safeguards.
> Using the type system to avoid races is like using the type system to
> prevent two different programs from writing to the same file at the same
> time; it seems to me to be working at the wrong level.

Just wait a minute. Why do you think "using the type system to prevent
two different programs from writing to the same file at the same time"
is a bad idea? If both programs are written in the same language (or
in different languages, but you happen to have the appropriate
capabilities to deal with this particular synchronization issue), then
why not. It seems to me that such a type system is possible. I agree
that it would be weird and unusual, because type systems don't usually
deal with such stuff - but being weird and unusual does *not* imply
being bad.

I don't think there exists such a type system. So, if it does not
exist (the idea hasn't been tried yet), then how do you know it is a
bad idea?

Imagine, you have some program that reads a configuration file when it
is started. I think you will agree with me that the program would not
start properly if in the middle of the process the file was
overwritten by some other process. It would be nice if the type system
could reject programs in which this kind of concurrent modification
*might* happen. For example, trying to compile the code

1 fd := open(config_file)
2 option1 := read_int(fd, "option1")
3 option2 := read_bool(fd, "option2")
4 close(fd)

would yield the following compile-time error:

file "input", lines 1-4: You moron, you cannot do it this way because
there would be some issues related to a possible concurrent
modification of the file. Try to use function "openAndLock" instead of
"open".

If I understand you correctly, you are saying the following: If a type
system happens to be sufficiently advanced to be able to detect this
kind of error, then in your opinion such a type system is totally bad.
The reason being that it is "working at the wrong level".

Is THAT what you are saying?

unread,
Aug 14, 2010, 12:58:06 PM8/14/10
to golang-nuts
On Aug 14, 11:38 am, Giuseppe Altea <ggprot...@gmail.com> wrote:
> Tried go - liked it because of simple design fast compile speed ...

In my experience, the compiler is *not* as fast as advertised. Sure,
it is faster then GCC. But lighting-fast? No.

chris dollin

unread,
Aug 14, 2010, 1:58:47 PM8/14/10
to ⚛, golang-nuts

How fast is it advertised as being and what for you would count as
"lightning fast"?

Chris

--
Chris "allusive" Dollin

Seth Hoenig

unread,
Aug 14, 2010, 2:37:31 PM8/14/10
to golang-nuts
My question is, "who cares?". Both D and Go (and other languages)
compile massive projects in a matter of minutes instead of hours. When
you have improvements based on orders of magnitude, it seems awfully
petty to be comparing or complaining about compile times.

Ian Lance Taylor

unread,
Aug 14, 2010, 2:43:05 PM8/14/10
to ⚛, golang-nuts
⚛ <0xe2.0x...@gmail.com> writes:

> If I understand you correctly, you are saying the following: If a type
> system happens to be sufficiently advanced to be able to detect this
> kind of error, then in your opinion such a type system is totally bad.
> The reason being that it is "working at the wrong level".
>
> Is THAT what you are saying?

Yes, although I wouldn't use exactly those words, that is more or less
what I am saying.

Ian

Scott Lawrence

unread,
Aug 14, 2010, 4:12:21 PM8/14/10
to ⚛, golang-nuts

Well, for all programs I've written or looked at so far (nothing very
large, though), they've compiled in less time than it took my editor
(emacs, or kate) to start up. That's not bad.

--
Scott Lawrence

Jessta

unread,
Aug 14, 2010, 5:21:34 PM8/14/10
to ⚛, golang-nuts
On Sun, Aug 15, 2010 at 2:54 AM, ⚛ <0xe2.0x...@gmail.com> wrote:
> Imagine, you have some program that reads a configuration file when it
> is started. I think you will agree with me that the program would not
> start properly if in the middle of the process the file was
> overwritten by some other process. It would be nice if the type system
> could reject programs in which this kind of concurrent modification
> *might* happen. For example, trying to compile the code
>
> 1  fd := open(config_file)
> 2  option1 := read_int(fd, "option1")
> 3  option2 := read_bool(fd, "option2")
> 4  close(fd)
>
> would yield the following compile-time error:
>
> file "input", lines 1-4: You moron, you cannot do it this way because
> there would be some issues related to a possible concurrent
> modification of the file. Try to use function "openAndLock" instead of
> "open".

Such a type system exists. http://en.wikipedia.org/wiki/Linear_type_system
But any language with this type system would have to be purely functional.
Which has it's own set of disadvantages.

Everything is a trade off. This kind of checking would be really nice
to have, but
you can't do it without complicating the language.

> If I understand you correctly, you are saying the following: If a type
> system happens to be sufficiently advanced to be able to detect this
> kind of error, then in your opinion such a type system is totally bad.
> The reason being that it is "working at the wrong level".
>
> Is THAT what you are saying?
>

In a imperative language, like Go, the type system is entirely the
wrong level for this kind of behaviour.

- Jessta

--
=====================
http://jessta.id.au

unread,
Aug 18, 2010, 3:04:56 AM8/18/10
to golang-nuts
On Aug 14, 7:58 pm, chris dollin <ehog.he...@googlemail.com> wrote:
> On 14 August 2010 17:58, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>
> > On Aug 14, 11:38 am, Giuseppe Altea <ggprot...@gmail.com> wrote:
> >> Tried go - liked it because of simple design fast compile speed ...
>
> > In my experience, the compiler is *not* as fast as advertised. Sure,
> > it is faster then GCC. But lighting-fast? No.
>
> How fast is it advertised as being and what for you would count as
> "lightning fast"?

I will give you some concrete (approximate) numbers:

- number of lines being compiled: 9222
- time it takes to compile them: 0.47 seconds (user-space)

Thus the speed of the Go compiler is 19621 lines / second. On my
notebook CPU, it means the compiler consumes 84909 CPU cycles per 1
line of Go code. In my opinion, lightning fast would mean to consume
much less than that. Alternatively, I would be willing to accept it as
lightning-fast if it was per 1 *changed* line of Go code (but it's
not).

- final binary size: 3 MB
- link time: 1.27 seconds (user space)

In other words, if I modify the Go code (i.e: modify 1 of those 9222
lines), it will in the end take approximately 2 seconds to compile the
whole application. It should be noted that those 9222 lines span over
multiple files. However it is not possible to compile those files in
isolation, so even if just a single file is modified, all (or at least
most of) those files need to be fed to the Go compiler.

The Go compiler is repeating the very same mistake (at least I think
of it as a mistake) performed by majority of all other compilers: it
is not doing any automatic caching or incremental compilation. I do
*not* think a compiler that isn't doing any *automatic* caching nor
any *automatic* sub-file dependency analysis is a high-speed compiler.

Nick LaForge

unread,
Aug 18, 2010, 3:20:13 AM8/18/10
to golang-nuts
If neglecting to cache is what's holding back performance, then I
think the architecture is in good shape. It would be strange to
abandon experimental software for want of optimization....

unread,
Aug 18, 2010, 3:26:35 AM8/18/10
to golang-nuts
Considering that most of a software developer's work is concentrated
around incremental changes, I think the Go compiler is slower here by
something like 100x than it should be. Spending more than 10
milliseconds on compiling a package in which I only touched a single
function - this seems like on overkill to me, irrespective of whether
the package has 100 lines or 100000 lines.

It seems to me that compilation speed is more a matter of compiler
architecture and of certain factors *unrelated* to the language being
compiled, rather than solely a property of the language itself. One of
those "unrelated factors" is for example the following: whether the
text editor used by the programmer is able to inform the compiler
about the parts of the source file which have been modified.

unread,
Aug 18, 2010, 3:42:28 AM8/18/10
to golang-nuts
On Aug 14, 8:43 pm, Ian Lance Taylor <i...@google.com> wrote:
Well, but if you want to detect the error (I mean: the error I
described previously) *before* you run the program, is there some
other option than detecting it during compile-time or by some static
code analysis tool? (And by "tool" I don't mean "a human resource".)

An other option here is that you don't want to be able to statically
detect such an the error at all. This would be a completely different
situation of course.

unread,
Aug 18, 2010, 4:43:08 AM8/18/10
to golang-nuts
On Aug 18, 9:20 am, Nick LaForge <nicklafo...@gmail.com> wrote:
> If neglecting to cache is what's holding back performance, then I
> think the architecture is in good shape.

... but you could apply this rule to virtually any compiler out there.
For example:

- GCC's neglect to cache is holding back performance, so by your
logic, GCC's architecture is in good shape

- Java JIT's neglect to cache native code is holding back performance
(especially startup and warm-up time), so by your logic, Java JIT's
architecture is in good shape

Generalized:

- CPython's neglect of "not to recompute what does not need to be
recomputed" is holding back performance, so by your logic, CPython's
architecture is in good shape

- Bash's neglect of "not to recompute what does not need to be
recomputed" is holding back performance, so by your logic, Bash's
architecture is in good shape

In other words, you seem to like compilers and interpreters which are
utilizing the CPU for various sorts of redundant computations. Your
"reason d'tre" is to feed the CPU with work, irrespective of whether
that work is redundant or not. CPU has work to do --> you happy; CPU
is idle --> you not happy.

Your opinion: For a software to be good it just needs to pretend it is
doing something. The more it pretends the better its quality.

My opinion: The less redundant computation a software performs (and
all other attributes of the software remain the same), the better its
quality.

> It would be strange to abandon experimental software for want of optimization....

I never said that Go should be abandoned.

Cory Mainwaring

unread,
Aug 18, 2010, 6:08:06 AM8/18/10
to ⚛, golang-nuts
Go isn't as fast at compiling as maybe it should be. However, could
you take a similar 9222 lines of C++ code and compile it? Might I know
how long that takes on your notebook CPU? I get the feeling it might
be a significant enough figure that Go's lack of optimization can be
overlooking when compared.

Maybe it's not as fast as lightning, but for ten thousand lines of
code, half a second isn't too terrible. 50ms would be significantly
better, so future optimization by adding incremental compilation or
automatic caching could be cool. But for now, if all of the other
compilers are making the same mistakes, and 1.5 seconds isn't fast
enough for your ten thousand lines of code, you probably won't be
satisfied with interpreters either, since they run the code orders of
magnitude slower than compiled versions for the most part. JIT
compilers might be ok, but those should run into the same problems
too.

So the question comes back to: why stop using a language based on a
compiler that is faster than most other compilers? Do you just not
code at all?

unread,
Aug 18, 2010, 6:39:20 AM8/18/10
to golang-nuts
On Aug 18, 12:08 pm, Cory Mainwaring <olre...@gmail.com> wrote:
> Go isn't as fast at compiling as maybe it should be. However, could
> you take a similar 9222 lines of C++ code and compile it? Might I know
> how long that takes on your notebook CPU? [cut]

Why are you asking when you already know the answer?

The primary problem is that current C/C++ compilers would be parsing
much more than those 9222 lines - which of course is primarily caused
by the fact that it is not doing any "caching" of included header
files. If the C/C++ compiler would be able to do that efficiently
(which is hard), then its speed might not be that bad in comparison to
Go.

> Maybe it's not as fast as lightning, but for ten thousand lines of
> code, half a second isn't too terrible. 50ms would be significantly
> better, so future optimization by adding incremental compilation or
> automatic caching could be cool. But for now, if all of the other
> compilers are making the same mistakes, and 1.5 seconds isn't fast
> enough for your ten thousand lines of code, you probably won't be
> satisfied with interpreters either, since they run the code orders of
> magnitude slower than compiled versions for the most part. JIT
> compilers might be ok, but those should run into the same problems
> too.
>
> So the question comes back to: why stop using a language based on a
> compiler that is faster than most other compilers?

I don't understand why are multiple people here thinking that I am
suggesting to stop using Go. I NEVER SAID THAT. I only said that
compilation is not lightning-fast - which is true.

Anh Hai Trinh

unread,
Aug 18, 2010, 7:30:38 AM8/18/10
to ⚛, golang-nuts
On Wed, Aug 18, 2010 at 2:26 PM, ⚛ <0xe2.0x...@gmail.com> wrote:
>
> Considering that most of a software developer's work is concentrated
> around incremental changes, I think the Go compiler is slower here by
> something like 100x than it should be. Spending more than 10
> milliseconds on compiling a package in which I only touched a single
> function - this seems like on overkill to me, irrespective of whether
> the package has 100 lines or 100000 lines.
>

The Go compiler is already incremental. The compilation unit is package.


--
@chickamade

Nick LaForge

unread,
Aug 18, 2010, 10:18:38 AM8/18/10
to golang-nuts
> I don't understand why are multiple people here thinking that I am
> suggesting to stop using Go. I NEVER SAID THAT. I only said that
> compilation is not lightning-fast - which is true.

Sorry, I had jumbled Giuseppe's and your posts in my head.

Rohit Yadav

unread,
Oct 11, 2013, 4:54:23 PM10/11/13
to golan...@googlegroups.com, iro...@gmail.com
Hi,

Since the last active message on this thread a lot of progress was achieved by both the projects, would anyone like to share latest comparisons between the two languages and the ecosystem around it (tooling, usage, adoption, etc.)?
We see that Go is nowadays used for not just writing servers but general programs as well, how does D scale to that and if Andrei and others can update us on D with respect to areas where Go excels such as ease of writing concurrent software, tooling, ease of learning the language and its hackability.

Regards,
Rohit

On Saturday, 14 August 2010 06:09:36 UTC+5:30, Andrei Alexandrescu wrote:
On Aug 13, 3:00 pm, Ian Lance Taylor <i...@google.com> wrote:
> Andrei Alexandrescu <iro...@gmail.com> writes:
> >http://www.informit.com/articles/printerfriendly.aspx?p=1609144
>
> Thanks.  As you know, this approach is clearly different from the one in
> Go, which is a transfer of ownership model, where the transfer of
> ownership is enforced only by convention.  And, of course, Go doesn't
> use the type system, which follows Go's general guideline of keeping the
> type system light weight.

I understand. So what we have now is:

(1) Pass-by-bitblt through channels for value types (i.e. no
indirections, which means dynamic arrays are unduly shared). There is
no checking that a value type being passed actually does not have
indirections.

(2) Pass of ownership by unchecked convention for data with
indirections.

(3) Everything else is undefined.

If that's true, parts 1 and 2 are of limited expressiveness but it's
part 3 that's really problematic, and I'm not sure a putative
programmer understands the implications. Essentially that means even
lock-based programming relies on implementation-level vagaries because
without a memory model the compiler and the processor are relatively
free to hoist data around rather freely. We're back to the reorderings
hell often showcased as motivators of Java's and C++0x's memory
models.

> >> You're quite right: Go does permit data races, and does currently rely
> >> only on convention to avoid them.  Go's advantage over C++, and it is a
> >> significant advantage, is that the rules for valid sharing are fairly
> >> simple, and the language makes it much easier to do valid sharing.
>
> > How does Go simplify the rules for valid sharing? Far as I can tell it
> > can only simplify if it renders undue aliasing undefined. Does Go have
> > something equivalent to Java's volatile and C++0x's atomic?
>
> The rules for valid sharing are encapsulated in the slogan "don't
> communicate by sharing memory; instead, share memory by communicating."
> That is, always use channels to communicate between goroutines.  Always
> ensure that a single goroutine owns shared data, and use an explicit
> channel send to transfer ownership to a different goroutine.
>
> This approach can be used in other languages also, of course; the
> advantage I see in Go is that the language makes it simple and easy.

A memory model may as well be the perfect example where simplicity is
your enemy - not defining one is indeed simple, but has huge costs to
the user in one or more of correctness, portability, safety,
expressiveness, and efficiency.

So essentially (again I'm basing this on inference from what I've read
on golang.org and this discussion) one must only use the patterns (1)
and (2) in concurrent code. This severe limitation further erodes Go's
capabilities when compared to C, and I think it's reasonable that I
find Go's offering severely wanting for serious concurrent work.


Andrei

ecstati...@gmail.com

unread,
Aug 1, 2017, 8:05:00 AM8/1/17
to golang-nuts, iro...@gmail.com
I come back to this forum I read a long time ago, because after having used Go for several projects, I've recently switched to D, and I wanted to share my opinion on it.

First, if I can make a caricatural comparison, i'd like to say that to me, Go is just a "much better C", while D is instead a "much better C++".

I mean, like Go, D has also an incredibly fast compilation, a GC, and it provides very convenient maps, arrays, strings, slices, foreach, ranges, concurrency, etc, all at the language level.

But D also gives you reference classes, genericity, function polymorphism, conditional compilation, design by contract assertions, compile-time meta programming, and many other features that are severely lacking in Go.

Moreover, with D you can really go low-level like in C if you need to. It also has C-like pointers, structs, inline assembly, etc, if you want to use C or C++ functions and data structures without wrapper code.

Finally, what's really nice is that D provides all these features through a very simple, classic and convenient syntax, which make it quite easy to port your code from C, C++, Java, C#, Go, etc.

Of course, Go, as a web-centric language, has obviously a much more complete standard library when it comes to web development.

So if you want to interact with servers, databases and anything like that, Go may remain the best alternative.

But for your command line or desktop developments, I think D could be much more appropriate than Go...

kultig...@gmail.com

unread,
Aug 1, 2017, 8:54:45 AM8/1/17
to golang-nuts, iro...@gmail.com
But D also gives you reference classes, genericity, function polymorphism, conditional compilation, design by contract assertions, compile-time meta programming, and many other features that are severely lacking in Go.

That's the biggest reason i love Go, except maybe ken thompson :)

- A language that doesn’t have everything is actually easier to program in than some that do.  Dennis M. Ritchie

- Do Less. Enable More. Russ Cox

Konstantin Khomoutov

unread,
Aug 1, 2017, 10:09:54 AM8/1/17
to ecstati...@gmail.com, golang-nuts, iro...@gmail.com
On Tue, Aug 01, 2017 at 05:04:24AM -0700, ecstati...@gmail.com wrote:

[...]
> Go, as a web-centric language, has
[...]

Mildly put, this is a bold but unfounded statement.

Web development is indeed booming, but it's booming on most contemporary
programming languages -- be them PHP, Python, C#/.NET and JS.
Go just happens to neatly solve web-related problems but it by no means
is a web-centric language.

ecstati...@gmail.com

unread,
Aug 1, 2017, 4:49:10 PM8/1/17
to golang-nuts, iro...@gmail.com
I've written only what I know for sure, i.e. that Go is used a lot for server side applications.

I didn't know it was also used a lot on the client side for mobile and desktop GUI applications, sorry for my ignorance.

ecstati...@gmail.com

unread,
Aug 1, 2017, 4:51:21 PM8/1/17
to golang-nuts, iro...@gmail.com
Indeed a language that offer much less tools is much easier to learn, and also to master.

But from my personal experience, D is *at least* as easy to learn than Go, if not easier.

Just the fact that it doesn't break much with the familiar syntax of C#, Java, C++, etc helps a lot in making the transition.

And genericity and polymorphism are invaluable tools when optimizing code reuse without reducing execution speed.

I know that everything can be done with interfaces, but unfortunately they run slower (according to the Golang website) than direct calls to type-specific code, and most of the time even with interface you have to manually adapt the implementation anyway.

And copy/pasting then adapting manually the code is dumb and error proof. If you have always managed to avoid doing that for your Go applications, then I'm happy for you, this means you are much smarter than me.


On Tuesday, August 1, 2017 at 1:54:45 PM UTC+1, Doğan Kurt wrote:

Doğan Kurt

unread,
Aug 1, 2017, 5:11:10 PM8/1/17
to golang-nuts, iro...@gmail.com
But from my personal experience, D is *at least* as easy to learn than Go, if not easier.

I seriously doubt, no offense. Go is so small and so intuitive, one can argue that there are people out there who knows most of the Go unknowingly :) 

Just the fact that it doesn't break much with the familiar syntax of C#, Java, C++, etc helps a lot in making the transition.

Go's syntax is very familiar to C, i've never heard it was an issue. The only think you must get used to is declarations and i LOVE the Go way. I remember the days i was struggling with C's declaration model, the spiral rule etc. sure we use typedefs but it rather feels like a hack. 
I can write any declaration no matter how complex it is, with my eyes closed in Go. It's so great.

And genericity and polymorphism are invaluable tools when optimizing code reuse without reducing execution speed.

I don't ever remember duplicating any code in C. I can't understand how people are unable to write reusable code with C, seriously.  Whenever i discuss this with a C++ programmer, they immediately share some generic Max function that works with int and double.  I admit i use macros in that case, but come on it's not even 1% of the serious programming you do in C. 

If you are a competent C programmer (structured programming in general), you know how to write reusable code. 

Wojciech S. Czarnecki

unread,
Aug 2, 2017, 3:36:18 AM8/2/17
to golan...@googlegroups.com
On Tue, 1 Aug 2017 05:04:24 -0700 (PDT)
ecstati...@gmail.com wrote:

> But D also gives you reference classes, genericity, function polymorphism,
> conditional compilation, design by contract assertions, compile-time meta
> programming,

All things above to be avoided in _maintainable_ software.

Mantra: every working line of code is written once by one person
then it is read hundreds/thousands of times by dozens of people.

Go spares your pair, then supervisor, from manually enforcing on
you hard local rules: "We use C++ but you are forbidden to use:
exceptions, overloading, auto, weak ... ". Go language by itself gives
you all that -do-not-use-this-and-that- checks for free ;)

> and many other features that are severely lacking in Go.
Luckily. These and many other features _luckily_ lacking in Go.
Something that can't be used also can't be abused.

From the software maintainer pov Go is both readable and debuggable.
In Go one may grasp execution path and functionality from the very
fragment of source s/he is reading now. With very few exceptions.

Throw in any level of meta programming, even simple function overload,
and suddenly reader of a fragment of code is forced to read entirety of
entangled sources then map it mentally - all that just to grasp importance
of that fragment s/he has read a while ago. Rinse and repeat on each level
deep.

Any business gain (man-hour wise) form higher level 'features' is null, void
and negative at first bug hunt on production code. More so if said code
authors are long gone from the team. Many businesses learnt this
hard way and now they know better; now they go for Go.

> But for your command line or desktop developments, I think D could be much
> more appropriate than Go...

Unless your CLI/desktop is supposed to be easily maintained for years to come.

PS. If one want some joy and entertainment off writing, one may go for
Racket [https://racket-lang.org/]. Every program in it sooner than later
evolves into separate language of its own. Language only author can
understand. Even if just for a while ;).

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

ecstati...@gmail.com

unread,
Aug 2, 2017, 3:51:43 AM8/2/17
to golang-nuts, iro...@gmail.com
For all the common parts with Go (functions, methods, reference classes, strings, arrays, slices, ranges, foreach, etc), honestly I don't know why you say it's simpler in Go.

Can you show me two examples of code side by side, and tell me "look how much simpler it's with Go's" ?

Because from what I read, I'm sometimes wondering if you really know that the type declarations in D are MUCH simpler than in C/C++.

For instance :

int[]
    first_array_of_ints,
    second_array_of_ints;

int[string]
    first_map_of_ints_indexed_by_a_string,
    second_map_of_ints_indexed_by_a_string;

TYPE
    first_reference_to_an_object_of_this_type,
    second_reference_to_an_object_of_this_type;

So, with all due respect, how many applications have you already programmed in D before telling me that Go's syntax is so simpler to use and to learn ?

I agree there are much less possibilities in Go, but that doesn't mean it's automatically a simpler language to learn for all the common parts with D. Seriously.

Because I had to learn both, and at least for a C++/Java/C# programmer like me, D transition was almost immediate, really a matter of hours to become comfortable with the language. Everything was alike, but much simpler and easier than in C++.

Believe me or not, I've taught programming with D to my two teenagers with D. Really.

I've chosen it because it was the only strongly-typed language close to Javascript that was really easy to learn, while allowing them to quickly switch to C++, Java or C# later if they wanted to.

Go is much simpler than C++ too, I agree of course, but for having learned both Go then D, again from the point of view of a former C++/Java/C# programmer like me, I didn't feel that quickly at home with Go than with D, mainly because Go diverged much more from its predecessors than D from a syntactic point of view.

So, again from a syntactic point of view, I don't think how you can affirm that it's much easier in Go than in D to declare and use types, references, functions, methods, slices, arrays, foreach, and all the common stuff between both languages.

Honestly, no offense intended.

ecstati...@gmail.com

unread,
Aug 2, 2017, 4:03:59 AM8/2/17
to golang-nuts
I agree with you that the code must be developped using the KISS principle.

Look at the D code of my github account. All you will see is "baby-code".

The more complex stuff I use in D are genericy and polymorphism.

And, from my personal experience, the lack of genericity and polymorphism in Go often forces me code in a less straightforward manner than in D.

I have to find an indirect way (interface, etc) of doing something that would be simple and straightforward in D.

Maybe I'm force to develop more powerful or sophisticated code in Go's way, I don't know, but I will never say that my Go code is much easier to program or to maintain than the same implementation in D.

My github account is now full of tools progressively converted to D from an initial implementation in Go or Node.js, so I begin to have some experience in switching a tool from a language to another...

Egon

unread,
Aug 2, 2017, 4:33:48 AM8/2/17
to golang-nuts, iro...@gmail.com
On Wednesday, 2 August 2017 10:51:43 UTC+3, ecstati...@gmail.com wrote:
For all the common parts with Go (functions, methods, reference classes, strings, arrays, slices, ranges, foreach, etc), honestly I don't know why you say it's simpler in Go.

Can you show me two examples of code side by side, and tell me "look how much simpler it's with Go's" ?

Because from what I read, I'm sometimes wondering if you really know that the type declarations in D are MUCH simpler than in C/C++.

error* (**callbacks)(int);

Error[] function(int)[][string] callbacks;

var callbacks map[string]func(int) []error

ecstati...@gmail.com

unread,
Aug 2, 2017, 4:46:08 AM8/2/17
to golang-nuts
And btw, this doesn't mean that just because there are genericity and polymorphism in D, that I must use them.

Most of the time, I don't even need to use them, like in Go, so I simply don't use them.

What I'm saying is that, sometimes, you have to apply a similar function to different types for instance, and in this particular case, using genericiy OR polymorphism can get the job done quickly and in a cleaner way (DRY principle).

That doesn't happen all day long, but I'm occasionally in such situation, I really regret there is no native genericity and polymorphism in Go.

Using interfaces and stuff can indeed solve the problem in a way or another, but that's far from the simple, easy and obvious way to solve it.

At least that's what I feel each time I have to implement such code. Because for web-related development,

Because despite I prefer D as a general purpose language, I'm still using Go to develop server side applications which interact with browsers and databases.

Its extensive standard library obviously makes it still the best tool for the job, no doubt about it.


On Wednesday, August 2, 2017 at 8:36:18 AM UTC+1, ohir wrote:

ecstati...@gmail.com

unread,
Aug 2, 2017, 5:05:43 AM8/2/17
to golang-nuts, iro...@gmail.com
Still waiting the Go version of this very useful D code...

I'm not asking you to browse the web to find to find most complex declaration you can ever do in D, Go or C++ for instance.

I've never used such ridiculous code in my Go/D/C++/Java/C# applications, and neither will you.

I'm just asking you show me how simple code in Go will become much more complicated in D, as this is what you seem to think.

And I mean something we will all use all day long (ex: declaring or using functions/types/arrays/slices/references/loops/etc etc), not the most complicated code you can come up with.

THAT would be useful, and also a fair comparison between both languages.

Because from what I see below, I may think you couldn't manage to find such an example

But maybe I'm wrong, I don't know...

Doğan Kurt

unread,
Aug 2, 2017, 5:22:19 AM8/2/17
to golang-nuts, iro...@gmail.com
Let's not make it personal. I personally respect walter bright and andrei alexandrescu a lot and because of a very dear friend of mine, i started fiddling with D as early as 2010. 

Surely it's a great leap forward from C++. But someone who comes from a language as small as C, it's way harder to learn than Go. This is my personal experience. If you are already a C++ programmer, which i never was able to become one, it can be simple for your taste, but not for ours. 

I religiously believe in unix philosophy and D is not simple and certainly not small for my taste. 

Just because somebody is smart and capable doesn't mean he/she has a good taste. Let's not forget bjarne stroustrup created C++.

Egon

unread,
Aug 2, 2017, 5:33:03 AM8/2/17
to golang-nuts, iro...@gmail.com
The example contained 3 versions, C, D and Go.

function pointer tables aren't that uncommon, maybe the []error part is uncommon

Examples from real world code:


And I've used it in Go, Java, C#, JavaScript, Delphi, C...

The main reason you don't see these one-liners often in C, D et. al. is because they are hard to read.

For common C, C++ examples, see signal and interrupt vector tables.

Chris Hopkins

unread,
Aug 2, 2017, 5:47:36 AM8/2/17
to golang-nuts


On Wednesday, 2 August 2017 09:46:08 UTC+1, ecstati...@gmail.com wrote:
And btw, this doesn't mean that just because there are genericity and polymorphism in D, that I must use them.

No, but the person reading your code must understand them.  Not only that but they must understand the "clever" way you have used them.
I came to go for the concurrency, I stayed for the fact that I have yet to come across a piece of code I can't quickly understand.

Every other language I come across that has "advanced" features seems to be an exercise in programmer vanity showing off how clever they are. I spend way more time & brain power trying to reverse engineer someone either showing off their "clever" use of an obscure part of the language than they could ever save with a few less keystrokes.
The trouble with gerericity and polymorphism and operator overload and all the others are they hide functionality which is great from an academic perpective; when it comes down to debugging what on earth is going wrong they are IME a nightmare.

I think this is why this is turning into a holy war on this list, they are without a doubt great ideas that in theory hide complexity and provide better abstraction and lots of other good things that we should all strive for. The trouble is, in practice many find them to be too powerful for real world use except in certain carefully controlled examples.

I get the impression you want them to make writing code quicker, do you not then share the opinion that in practice for large poorly understood 3rd party systems they make comprehension harder?

Regards

ecstati...@gmail.com

unread,
Aug 2, 2017, 6:25:06 AM8/2/17
to golang-nuts, iro...@gmail.com
Ok I understand you now. Maybe I'm biased because I like both languages, but I'm not convinced that this example illustrates well Go's simplicity compared to D.

For 99% of my personal daily use of both languages, very honestly, I've never felt that using types, functions, arrays, etc etc was simpler in Go compared to D.

Even for more complex stuff like concurrency, I think that both languages still remain quite close, despite I think that Go's channel system is the best approach to the problem.

ecstati...@gmail.com

unread,
Aug 2, 2017, 6:36:38 AM8/2/17
to golang-nuts
As I said, it's not because something sophisticated exists in a language that you have to use it.

It's quite the opposite. But indeed, with Go you don't have the problem, because these features were removed from the language to avoid the temptation to use them.

I can understand that, because many developers have no enough discipline or taste for simplicity, but the unfortunate price to pay is that in the few cases where it REALLY helps in making clear code that is easier to understand and to maintain, that is sad.

There are many possibilities in D which are not needed in Go, but I don't think why you think that genericity (ex: Pool<SomeType>, etc) and polymorphism (same method name for a similar argument of a different type) are considered as evil.

Properly used, they have their use place in any modern language like Go.

I personally that using interfaces when genericity was a simle and obvious solution is what requires more cleverness.

And I'm not saying that using interfaces for this is a bad solution, I'm just saying that I don't see the simplicity advantage in it.

Because everytime I have to use interfaces or duplicate implementation for such situations, I don't feel at all that Go is helping me implementing easier or simpler code.

Egon

unread,
Aug 2, 2017, 6:43:41 AM8/2/17
to golang-nuts, iro...@gmail.com
Yes, I would agree -- the type declarations won't bother you in real-world, because when they become unreadable, then you would use additional types to clarify them... in any language.

And, I have nothing against either languages -- I used D in my BSc thesis and Go in my MSc thesis.

The main difference, as I see, is that Go is much more restricted, which means you have to work harder to fit your code into that model, leading to better structures overall. Over time you will learn the simpler ways of structuring your code. With D you have a tons of flexibility, which means often your first idea, what to write, succeeds -- which means the design will be less polished. Also this means that you won't tacitly learn to simplify your code.

Yes, you can also write as simple code in D as in Go; the caveat is that Go forces you more into that direction... at the cost of flexibility of the language. So you can write more complex and complected code in D -- for better and worse.

+ Egon

Michael Jones

unread,
Aug 2, 2017, 10:26:09 AM8/2/17
to Egon, golang-nuts, iro...@gmail.com
I've often found it helpful to consider extreme limit cases. 

In solo/school/hobby programming, you code and test more than you debug and you understand intent implicitly because you are coding it as you go. As a professional at work, as part of a team, in a code review regime, using third-party libraries, evolving large systems, the time distribution between coding, testing, debugging, and understanding are different. What is the limit case?

The (hypothetical) limit would be no coding and all testing, debugging, and understanding. Make it theatrical--the meteor will destroy the Earth unless you alone can find the bugs in the billion-line space shield software system during the next few days or hours. Now, in such a case, think what language and ecosystem features might be helpful. Which are neutral? Which might hurt? 

I have my own answers, but I raise this to encourage to consider the question for themselves. If you do, I expect that you'll see matters at issue from a different point of view, from a new perspective that will bring a different concept of value. Even though the situation is rather extreme, it has much in common with most programming in the large.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Michael T. Jones
michae...@gmail.com

eric....@gmail.com

unread,
Aug 2, 2017, 11:39:32 AM8/2/17
to golang-nuts, egon...@gmail.com, iro...@gmail.com
I'm still not convinced that using a language which is especially limited by design always helps in implementing the simplest solution, that will be the easiest to maintain.

Maybe it's the case most of the time, but from my personal experience, you can only get that result by using the right tool for the right job.

And by "right" I mean the simplest tool which gets you the right result.

Fortunately, that doesn't happen all the time, but sometimes Go doesn't give gou that simplest tool, and in that case I severely regret I wasn't trusted enough so that they let me choose that appropriate tool.

Michael Jones

unread,
Aug 2, 2017, 2:34:01 PM8/2/17
to eric....@gmail.com, golang-nuts, Egon, Andrei Alexandrescu
If I was unclear...I do not mean that Go is the ultimate answer to those questions, or that D (or whatever) is the anthesis of them. I wish Go was different in various ways too.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Lucio

unread,
Aug 3, 2017, 6:50:44 AM8/3/17
to golang-nuts
Maybe, just maybe, you should consider that your opinion of the Go language is a long list of wishful thinking and given that you already have an alternative, you should accept that few Go developers/users are going to take your side.

Hoping that Go's vast library should magically materialise in D, or that Google will be persuaded by your arguments to invest effort in D, is idle sophism. Perhaps more useful would be some effort to translate the rather simpler language Go to the more powerful (at least in your opinion) D. That may in fact be productive and may prove rather than merely state your case.

Lucio.

PS: I think David Bright is a genius. I still have my original copies of Zortech C++ (versions 1 and 2) which almost certainly have only antiquarian value. But the man who produced that masterpiece deserves to be recognised. So if he happens to stumble on this discussion, let it be clear that my lack of interest in D is no reflection of my respect for its originator.


On Wednesday, 2 August 2017 10:03:59 UTC+2, ecstati...@gmail.com wrote:
I agree with you that the code must be developped using the KISS principle.

Look at the D code of my github account. All you will see is "baby-code".

Maybe, just maybe,The more complex stuff I use in D are genericy and polymorphism.

eric....@gmail.com

unread,
Aug 3, 2017, 9:04:20 AM8/3/17
to golang-nuts
I agree that despite genericity is the #1 feature requested by Go developers in Google's last official survey, there are few chances they change their mind.

Idem for polymorphism.

So indeed, I've clearly understood that Google and most Go developers don't care at all about having templating, genericity and polymorphism features added to the language.

Anyway, I've already followed your advice, don't worry ;)

I've developped an open source generic preprocessor (Genesis) that can be used to add Allman style and a form of genericity to Go, and whetever language feature can be implemented using its macro system.

And I've recently developed a compiler for Helix, a PHP-like language which has more or less the same syntax as my Phoenix language, but which emits Go code instead of PHP code.

It's not finished yet, but at least the templating and the primitive genericity system works already well enough for my personal use cases.

So as you see, I'm not just uselessly trying to "move the mountain"...

Jan Mercl

unread,
Aug 3, 2017, 9:15:31 AM8/3/17
to eric....@gmail.com, golang-nuts
On Thu, Aug 3, 2017 at 3:04 PM <eric....@gmail.com> wrote:

> I agree that despite genericity is the #1 feature requested by Go developers in Google's last official survey, ...

True version: 16% of the respondents answered "generics" to the question "What changes would improve Go most?"


--

-j

ecstati...@gmail.com

unread,
Aug 3, 2017, 9:27:19 AM8/3/17
to golang-nuts, eric....@gmail.com
So you mean these 16% thought that Genericity would improve the language, but that it should not be added to the language.

Ok, maybe I've misinterpreted the survey, I'm not a psychologist, I agree... ;)

Jan Mercl

unread,
Aug 3, 2017, 9:34:01 AM8/3/17
to ecstati...@gmail.com, golang-nuts, eric....@gmail.com
On Thu, Aug 3, 2017 at 3:27 PM <ecstati...@gmail.com> wrote:

> So you mean these 16% thought that Genericity would improve the language, but that it should not be added to the language.

True version: I meant precisely only what I wrote.

--

-j

ecstati...@gmail.com

unread,
Aug 3, 2017, 9:52:14 AM8/3/17
to golang-nuts, ecstati...@gmail.com, eric....@gmail.com
Honestly, I didn't know what I was saying was not true. Sincerely. As I said, I'm a developer, not a psychologist. Interpreting people's thought is not my job, I'm just a developer, and I haven't even graduated from university, I just have a bachelor's degree in software development.

Sorry for my mistake...

Jan Mercl

unread,
Aug 3, 2017, 10:01:39 AM8/3/17
to ecstati...@gmail.com, golang-nuts, eric....@gmail.com
On Thu, Aug 3, 2017 at 3:52 PM <ecstati...@gmail.com> wrote:

>  Honestly, I didn't know what I was saying was not true. Sincerely. As I said, I'm a developer, not a psychologist. Interpreting people's thought is not my job, I'm just a developer, and I haven't even graduated from university, I just have a bachelor's degree in software development.

I've only presented the facts, not any interpretation of them, so there are none of my thoughts to interpret. 

--

-j

Ian Lance Taylor

unread,
Aug 3, 2017, 10:03:18 AM8/3/17
to ecstati...@gmail.com, golang-nuts, eric....@gmail.com
I don't think this thread is going anywhere useful.

If people want to discuss technical comparisons between Go and D, that is fine.

I want to encourage people to stop second guessing motives and
comments. That does not seem helpful.

Thanks.

Ian

ecstati...@gmail.com

unread,
Aug 3, 2017, 10:56:21 AM8/3/17
to golang-nuts, ecstati...@gmail.com, eric....@gmail.com
I've already apologized for my misinterpretation. I want to point out that I was 100% sincere in what I was saying.

Sorry if some of you have taken this for a bold lie, this wasn't absolutely meant this way.

To be completely honest, I still believe what I was saying, even if I admit now that this was subject to interpretation.

And I agree that the addition of generics to Go is not especially relevant to this discussion on Go vs D.

Russel Winder

unread,
Aug 3, 2017, 11:29:00 AM8/3/17
to Lucio, golang-nuts
On Thu, 2017-08-03 at 03:50 -0700, Lucio wrote:
>
[…]
> PS: I think David Bright is a genius. I still have my original copies of 
> Zortech C++ (versions 1 and 2) which almost certainly have only antiquarian 
> value. But the man who produced that masterpiece deserves to be recognised. 
> So if he happens to stumble on this discussion, let it be clear that my 
> lack of interest in D is no reflection of my respect for its originator.

Walter rather than David?

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

Lucio De Re

unread,
Aug 3, 2017, 11:16:38 PM8/3/17
to Russel Winder, golang-nuts
Walter Bright, indeed. Thank you for the correction.

I hope it was clear enough in context and my slip-up did not offend anyone.

Lucio.
--
Lucio De Re
2 Piet Retief St
Kestell (Eastern Free State)
9860 South Africa

Ph.: +27 58 653 1433
Cell: +27 83 251 5824
FAX: +27 58 653 1435
It is loading more messages.
0 new messages