|GO Vs D||praks||7/25/10 8:35 AM|
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.
Go or Not to Go :D !
|Re: GO Vs D||Archos||7/25/10 8:51 AM|
Go is a language (mainly) designed for networking so your choice is
|Re: [go-nuts] GO Vs D||Andrew Gerrand||7/25/10 4:34 PM|
On 26 July 2010 01:35, praks <praks...@gmail.com> wrote:
Go is a much simpler language than D, so mastering Go will take you
> However, I am confused which one is better. I would like to
Go was developed primarily for writing server software, so I think
> I understand GO is still understand development.
Go is still under development, but the language is stable. We're using
|Re: GO Vs D||Vincent Foley||7/25/10 7:41 PM|
> Go is still under development, but the language is stable. We're usingWill details of how Go is used (and received) at Google eventually be
|Re: GO Vs D||kar||7/25/10 7:58 PM|
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
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.
|Re: [go-nuts] Re: GO Vs D||Andrew Gerrand||7/25/10 8:16 PM|
On 26 July 2010 12:41, Vincent Foley <vfo...@gmail.com> wrote:
When it's used in non-confidential projects, yes.
|Re: [go-nuts] Re: GO Vs D||Prakash Bhurke||7/26/10 9:28 AM|
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
Why are porting your projects from D+tango to Go ? What are problems
> D1 is matured enough and production ready, very stable, i had a
> love the GC.
Well, though Go is stable, it is still also under development. I don't
> For me it's time to move forward, Go is the future. Go has everythingIs 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
|Re: [go-nuts] Re: GO Vs D||soapboxcicero||7/26/10 9:31 AM|
> Which features are missing in D?
I've never used D, but I have looked at it a few times and if anything
|Re: [go-nuts] Re: GO Vs D||Evan Shaw||7/26/10 9:43 AM|
On Mon, Jul 26, 2010 at 11:28 AM, Prakash Bhurke <praks...@gmail.com> wrote:
I've never used D, but from what I understand their user base is
> Well, though Go is stable, it is still also under development. I don't
Go supports 64-bit development. You might even say that it's slightly
> Sorry, I should I have asked some of above questions on D mailing list
If you want more than just the biased opinion of this list, that's a
|Re: [go-nuts] Re: GO Vs D||Jeff Dickey||8/12/10 3:38 AM|
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.
|Re: GO Vs D||Jonathan Amsterdam||8/12/10 11:33 AM|
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
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
|Re: GO Vs D||Seth Hoenig||8/12/10 12:17 PM|
Andrei Alexandrescu recently gave a Google Tech Talk that outlines D2
a little bit:
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
|Re: GO Vs D||Nick Sabalausky||8/12/10 3:21 PM|
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:
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
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
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.)
|This message has been hidden because it was flagged for abuse.|
|Re: GO Vs D||Leandro Lucarella||8/12/10 3:59 PM|
On 26 jul, 13:28, Prakash Bhurke <praks.wo...@gmail.com> wrote: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!:
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
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
Only the future will tell :)
Very few, if there is any problem with D features, I think it's it has
I hope you find this information useful.
|Re: [go-nuts] Re: GO Vs D||Nick Sabalausky||8/12/10 4:02 PM|
Michael Jones 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:
|Re: GO Vs D||Nick Sabalausky||8/12/10 4:16 PM|
Leandro Lucarella wrote: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.
|Re: GO Vs D||Leandro Lucarella||8/12/10 4:22 PM|
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 while the first range proposal in D was in September
|Re: GO Vs D||Nick Sabalausky||8/12/10 4:32 PM|
Leandro Lucarella wrote: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).
|Re: [go-nuts] Re: GO Vs D||Olreich||8/12/10 5:58 PM|
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.
|Re: GO Vs D||Jonathan Yedidia||8/12/10 6:07 PM|
I'm in a similar position to the original poster, deciding between Go
but I think I've made up my mind in favor of D. Actually, I only
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
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
like Go does. You can basically do everything you can do in C in D,
program in assembly if you want to. So you will definitely be able to
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
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
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
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
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
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
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.
|Re: GO Vs D||Nick Sabalausky||8/12/10 6:47 PM|
Jonathan Yedidia wrote:And Cyclone. And Vala. And BitC...
|Re: [go-nuts] Re: GO Vs D||Olreich||8/12/10 6:49 PM|
I believe the wording was closer to: "the current languages in common use are over a decade old"
|Re: GO Vs D||Leandro Lucarella||8/12/10 6:54 PM|
On 12 ago, 20:22, Leandro Lucarella <llu...@gmail.com> wrote:
> > I only know a little Python and I don't know any Ada, but mySince 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
were they invention" and only said "as it was unique to D".
|Re: GO Vs D||Andrei Alexandrescu||8/12/10 8:03 PM|
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
* 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.
|Re: [go-nuts] Re: GO Vs D||Kai Backman||8/12/10 10:17 PM|
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
Having used both languages for a few years I think this sums things up
|Re: [go-nuts] Re: GO Vs D||Russel Winder||8/12/10 10:48 PM|
I have liked D for a long while, but until there is a stable 64-bit
I really like Go because of the process/channels model (I have been a
The actor model is getting a lot of promotion via Erlang and Scala,
The problem for me with Go and D is that both languages give all the
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
Linux and Mach, like Windows, are now really in "maintenance mode" their
So the question really is whether D and Go are just interesting
Go and its goroutines handle bus-level multicores quite nicely but then
I suspect there will be a lot of prejudice against using a language with
|Re: [go-nuts] Re: GO Vs D||Stanley Steel||8/12/10 11:47 PM|
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.
|Re: [go-nuts] Re: GO Vs D||Stanley Steel||8/12/10 11:58 PM|
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?
|Re: [go-nuts] Re: GO Vs D||Taru Karttunen||8/13/10 12:32 AM|
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
- Taru Karttunen
|Re: GO Vs D||bioinfornatics||8/13/10 4:26 AM|
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.
* Tango is too under BSD license
About networking library they are mango under BSD license:
Feel free for help and improve these project
|Re: GO Vs D||Andrei Alexandrescu||8/13/10 6:42 AM|
On Aug 13, 12:48 am, Russel Winder <rus...@russel.org.uk> wrote:I agree.
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
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
I don't understand this part.
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
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.
|Re: GO Vs D||Andrei Alexandrescu||8/13/10 6:44 AM|
On Aug 13, 1:58 am, Stanley Steel <st...@kryas.com> wrote: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.
|Re: [go-nuts] Re: GO Vs D||Ian Lance Taylor||8/13/10 7:30 AM|
Andrei Alexandrescu <iro...@gmail.com> writes:
> At the same time we believe that low-
That's an interesting perspective. I agree that low-level races are a
I wasn't able to find the docs on the sharing qualifier (the docs
You're quite right: Go does permit data races, and does currently rely
As far as I know it is an open question whether it is possible to have a
In Go it's natural to think of sending a pointer on a channel as a
It also suggests a "safe" compilation mode in which pointers are
I really don't know how feasible these ideas are.
|Re: GO Vs D||Andrei Alexandrescu||8/13/10 8:19 AM|
On Aug 13, 9:30 am, Ian Lance Taylor <i...@google.com> wrote:Here are some starting points that could be helpful:
Object types against races, by Flanagan/Abadi
Type inference against races, by Flanagan/Friend
A parameterized type system for race-free Java programs, by Boyapati/
The papers are rather involved but the introductions tend to give a
good overview of the gist of the work.
As I mentioned, the entire chapter on concurrency in TDPL is available
for free online:
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?
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.
This is well-trodden ground. The brief answer is - it is possible (by
formalizing uniqueness within the language) but out the window goes
|Re: GO Vs D||Andrei Alexandrescu||8/13/10 8:27 AM|
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 withD is already being used for implementing a kernel:
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.
|This message has been hidden because it was flagged for abuse.|
|Re: [go-nuts] Re: GO Vs D||Ian Lance Taylor||8/13/10 1:00 PM|
Andrei Alexandrescu <iro...@gmail.com> writes:
>> I wasn't able to find the docs on the sharing qualifier (the docs
Thanks. As you know, this approach is clearly different from the one in
The rules for valid sharing are encapsulated in the slogan "don't
This approach can be used in other languages also, of course; the
|Re: GO Vs D||Andrei Alexandrescu||8/13/10 5:15 PM|
On Aug 13, 2:02 pm, Michael Jones <m...@google.com> wrote:Let's keep it that way!
|Re: GO Vs D||Andrei Alexandrescu||8/13/10 5:39 PM|
On Aug 13, 3:00 pm, Ian Lance Taylor <i...@google.com> wrote:
> >http://www.informit.com/articles/printerfriendly.aspx?p=1609144I 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
(2) Pass of ownership by unchecked convention for data with
(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
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.
|Re: [go-nuts] Re: GO Vs D||Ian Lance Taylor||8/13/10 6:21 PM|
Andrei Alexandrescu <iro...@gmail.com> writes:
> I understand. So what we have now is:
Go does have a memory model: http://golang.org/doc/go_mem.html . The
|Re: GO Vs D||Andrei Alexandrescu||8/13/10 7:14 PM|
> Go does have a memory model:http://golang.org/doc/go_mem.html. The
> memory model does define mutexes. They are stylistically discouragedThanks, I'd missed that. Will take a look.
|Re: GO Vs D||dic...@gmail.com||8/13/10 8:22 PM|
I've been a C++ programmer for about 16 years, and I find this debate
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
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
|Re: GO Vs D||David Leimbach||8/13/10 8:39 PM|
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.
|Re: GO Vs D||david||8/14/10 12:12 AM|
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.
|Re: [go-nuts] Re: GO Vs D||Scott Lawrence||8/14/10 12:48 AM|
OTOH, taking a few quick glances around
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.
|Re: GO Vs D||Paulo Pinto||8/14/10 1:32 AM|
I believe that the regardless of C's merits as a programming language,
reason it got widespread use was because of Unix.
It was Unix's implementation language, and Unix was widely adopted in
So most people got to learn it in CS classes and tried to make use of
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.
> 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,
|Re: GO Vs D||Paulo Pinto||8/14/10 1:42 AM|
Couldn't agree more.
What many people forget when introducing the next best thing is the
"worse is better" theorem.
Human psychology is a complex matter, and you may introduce the best
that you can imagine. BUT it really has to have a big selling point,
people will not change.
People will prefer to live with the problems they already know and are
manage, than going through the pain of change if they don't that much
You can of course always force change, but people won't make it
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 +
type system. It has to have a "Wow factor" to create critical mass,
will stay with what they already know.
|Re: GO Vs D||Paulo Pinto||8/14/10 2:01 AM|
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
In the academia there were already quite a few efforts to write
in GC enabled language, just to name a few:
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.
> 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> signature.asc
> < 1KViewDownload
|Re: [go-nuts] Re: GO Vs D||ggprotech||8/14/10 2:38 AM|
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
|Re: GO Vs D||Jonathan Yedidia||8/14/10 8:56 AM|
> Most of those languages are still in development.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.
|Re: GO Vs D||⚛||8/14/10 9:54 AM|
On Aug 13, 4:30 pm, Ian Lance Taylor <i...@google.com> wrote: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
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
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")
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
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?
|Re: GO Vs D||⚛||8/14/10 9:58 AM|
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.
|Re: [go-nuts] Re: GO Vs D||ehedgehog||8/14/10 10:58 AM|
How fast is it advertised as being and what for you would count as
|Re: GO Vs D||Seth Hoenig||8/14/10 11:37 AM|
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.
|Re: [go-nuts] Re: GO Vs D||Ian Lance Taylor||8/14/10 11:43 AM|
⚛ <0xe2.0x...@gmail.com> writes:
> If I understand you correctly, you are saying the following: If a type
Yes, although I wouldn't use exactly those words, that is more or less
|Re: [go-nuts] Re: GO Vs D||Scott Lawrence||8/14/10 1:12 PM|
Well, for all programs I've written or looked at so far (nothing very
|Re: [go-nuts] Re: GO Vs D||Jessta||8/14/10 2:21 PM|
On Sun, Aug 15, 2010 at 2:54 AM, ⚛ <0xe2.0x...@gmail.com> wrote:
Such a type system exists. http://en.wikipedia.org/wiki/Linear_type_system
Everything is a trade off. This kind of checking would be really nice
> If I understand you correctly, you are saying the following: If a typeIn a imperative language, like Go, the type system is entirely the
wrong level for this kind of behaviour.
|Re: GO Vs D||⚛||8/18/10 12:04 AM|
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: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
- 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.
|Re: GO Vs D||Nick LaForge||8/18/10 12:20 AM|
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....
|Re: GO Vs D||⚛||8/18/10 12:26 AM|
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.
|Re: GO Vs D||⚛||8/18/10 12:42 AM|
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.
|Re: GO Vs D||⚛||8/18/10 1:43 AM|
On Aug 18, 9:20 am, Nick LaForge <nicklafo...@gmail.com> wrote:... but you could apply this rule to virtually any compiler out there.
- 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
- 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
I never said that Go should be abandoned.
|Re: [go-nuts] Re: GO Vs D||Olreich||8/18/10 3:08 AM|
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
So the question comes back to: why stop using a language based on a
|Re: GO Vs D||⚛||8/18/10 3:39 AM|
On Aug 18, 12:08 pm, Cory Mainwaring <olre...@gmail.com> wrote:> 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
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.
|Re: [go-nuts] Re: GO Vs D||Hai-Anh Trinh||8/18/10 4:30 AM|
On Wed, Aug 18, 2010 at 2:26 PM, ⚛ <0xe2.0x...@gmail.com> wrote:
The Go compiler is already incremental. The compilation unit is package.
|Re: GO Vs D||Nick LaForge||8/18/10 7:18 AM|
> I don't understand why are multiple people here thinking that I amSorry, I had jumbled Giuseppe's and your posts in my head.
|Re: GO Vs D||Rohit Yadav||10/11/13 1:54 PM|
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.
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: