|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.)
|Re: [go-nuts] Re: GO Vs D||Michael Jones||8/12/10 3:41 PM|
I think we all heard quite about ranges in Ada, Python, ...
Michael T. Jones
Chief Technology Advocate, Google Inc.
Email: email@example.com Mobile: 650-335-5765 Fax: 650-649-1938
Organizing the world's information to make it universally accessible and useful
|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.
|Re: [go-nuts] Re: GO Vs D||Michael Jones||8/13/10 12:02 PM|
Thank you Andrei and Ian for demonstrating the best level of intellectual discussion that one could hope for in an open discussion forum.
Michael T. Jones
Chief Technology Advocate, Google Inc.
Email: firstname.lastname@example.org Mobile: 650-335-5765 Fax: 650-649-1938
Organizing the world's information to make it universally accessible and useful
|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|
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||Jan Ziak||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||Jan Ziak||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||Jan Ziak||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||Jan Ziak||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||Jan Ziak||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||Jan Ziak||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||Jan Ziak||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||Anh Hai 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:
|Re: GO Vs D||ecstati...@gmail.com||8/1/17 5:05 AM|
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...
|Re: GO Vs D||Doğan Kurt||8/1/17 5:54 AM|
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
|Re: [go-nuts] Re: GO Vs D||Konstantin Khomoutov||8/1/17 7:09 AM|
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.
|Re: GO Vs D||ecstati...@gmail.com||8/1/17 1:49 PM|
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.
|Re: GO Vs D||ecstati...@gmail.com||8/1/17 1:51 PM|
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.
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.
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.
|Re: GO Vs D||Doğan Kurt||8/1/17 2:11 PM|
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 :)
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.
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.
|Re: [go-nuts] Re: GO Vs D||ohir||8/2/17 12:36 AM|
On Tue, 1 Aug 2017 05:04:24 -0700 (PDT)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 ;)
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
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.
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
|Re: GO Vs D||ecstati...@gmail.com||8/2/17 12:51 AM|
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 :
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.
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.
|Re: [go-nuts] Re: GO Vs D||ecstati...@gmail.com||8/2/17 1:03 AM|
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...
|Re: GO Vs D||Egon||8/2/17 1:33 AM|
On Wednesday, 2 August 2017 10:51:43 UTC+3, ecstati...@gmail.com wrote:
Error function(int)[string] callbacks;
var callbacks map[string]func(int) error
|Re: [go-nuts] Re: GO Vs D||ecstati...@gmail.com||8/2/17 1:46 AM|
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.
|Re: GO Vs D||ecstati...@gmail.com||8/2/17 2:05 AM|
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...
|Re: GO Vs D||Doğan Kurt||8/2/17 2:22 AM|
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++.
|Re: GO Vs D||Egon||8/2/17 2:33 AM|
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:
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.
|Re: [go-nuts] Re: GO Vs D||Chris Hopkins||8/2/17 2:47 AM|
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?
|Re: GO Vs D||ecstati...@gmail.com||8/2/17 3:25 AM|
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.
|Re: [go-nuts] Re: GO Vs D||ecstati...@gmail.com||8/2/17 3:36 AM|
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.
|Re: GO Vs D||Egon||8/2/17 3:43 AM|
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.
|Re: [go-nuts] Re: GO Vs D||Michael Jones||8/2/17 7:26 AM|
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.
|Re: [go-nuts] Re: GO Vs D||Eric Pelzer||8/2/17 8:39 AM|
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.
|Re: [go-nuts] Re: GO Vs D||Michael Jones||8/2/17 11:34 AM|
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.
|Re: [go-nuts] Re: GO Vs D||Lucio||8/3/17 3:50 AM|
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.
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.
|Re: [go-nuts] Re: GO Vs D||Eric Pelzer||8/3/17 6:04 AM|
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"...
|Re: [go-nuts] Re: GO Vs D||Jan Mercl||8/3/17 6:15 AM|
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?"
|Re: [go-nuts] Re: GO Vs D||ecstati...@gmail.com||8/3/17 6:27 AM|
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... ;)
|Re: [go-nuts] Re: GO Vs D||Jan Mercl||8/3/17 6:34 AM|
On Thu, Aug 3, 2017 at 3:27 PM <ecstati...@gmail.com> wrote:
True version: I meant precisely only what I wrote.
|Re: [go-nuts] Re: GO Vs D||ecstati...@gmail.com||8/3/17 6:52 AM|
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...
|Re: [go-nuts] Re: GO Vs D||Jan Mercl||8/3/17 7:01 AM|
On Thu, Aug 3, 2017 at 3:52 PM <ecstati...@gmail.com> wrote:I've only presented the facts, not any interpretation of them, so there are none of my thoughts to interpret.
|Re: [go-nuts] Re: GO Vs D||Ian Lance Taylor||8/3/17 7:03 AM|
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.
|Re: [go-nuts] Re: GO Vs D||ecstati...@gmail.com||8/3/17 7:56 AM|
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.
|Re: [go-nuts] Re: GO Vs D||Russel Winder||8/3/17 8:29 AM|
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 ofWalter rather than David?
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russ...@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
|Re: [go-nuts] Re: GO Vs D||Lucio||8/3/17 8:16 PM|
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 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
|Re: [go-nuts] Re: GO Vs D||Russel Winder||8/3/17 11:39 PM|
On Fri, 2017-08-04 at 05:15 +0200, Lucio De Re wrote:It was, no worries: it was just me ensuring the record was correct.