GO Vs D

Showing 1-68 of 68 messages
GO Vs D praks 7/25/10 8:35 AM
Hi All,

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

Regards,
praks

Go or Not to Go :D !
Re: GO Vs D Archos 7/25/10 8:51 AM
Go is a language (mainly) designed for networking so your choice is
easy ;)
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:
> Hi All,
>
> I am new to both Go and D languages. I would like to master in one of
> them.

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

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

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

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

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

Andrew

Re: GO Vs D Vincent Foley 7/25/10 7:41 PM
> Go is still under development, but the language is stable. We're using
> it at Google for production work, so we're committed to furthering its
> development. :-)
>

Will details of how Go is used (and received) at Google eventually be
available?
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
breeze.
D1 is matured enough and production ready, very stable, i had a
program (crawler with 50 threads) running for 2 days wiht no problem.
love the GC.
D's spec is crazy multi-paradigm you name it they have it. No 64bit
support for DMD (D's official compiler), LDC (llvm front end for D1)
has 64bit support but still young.
For me it's time to move forward, Go is the future. Go has everything
i need, it's simple and it works.
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:
> Will details of how Go is used (and received) at Google eventually be
> available?

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

Andrew

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
> D for almost 5 yrs now porting my project from D+tango to Go and its a
> breeze.

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

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

great!

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

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

> For me it's time to move forward, Go is the future. Go has everything
> i need, it's simple and it works.
Is D not the future? Which features are missing in D?  Is there any
big vendor (like google) supporting D?

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

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
it has too many features.

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:
> Why are porting your projects from D+tango to Go ? What are problems
> you faced while using D? Sorry I don't know history/politics of D.

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

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

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

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

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

- Evan

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.

Jeff

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


> From: jimmy frasche <soapbo...@gmail.com>
> Date: Mon, 26 Jul 2010 09:31:22 -0700
> To: Prakash Bhurke <praks...@gmail.com>
> Cc: kar <akma...@gmail.com>, golang-nuts <golan...@googlegroups.com>
> Subject: Re: [go-nuts] Re: GO Vs D


>
>>  Which features are missing in D?
>
> I've never used D, but I have looked at it a few times and if anything
> it has too many features.


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
design rationales.

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

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

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


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

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

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:
http://www.dsource.org/projects/dmd/timeline?from=08%2F12%2F10&daysback=60
In fact, according to the commit logs, "hello world" was working on 64-
bit nearly a month ago.

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

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

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

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

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

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

   1600 Amphitheatre Parkway, Mountain View, California 94043

   Email: mtj@google.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:
> Thanks Kar for sharing your experience.  I have following doubts:
>
> > if you like politics in D (d1.0, d2.0, phobos, tango), i've been using
> > D for almost 5 yrs now porting my project from D+tango to Go and its a
> > breeze.
>
> Why are porting your projects from D+tango to Go ? What are problems
> you faced while using D? Sorry I don't know history/politics of D.

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

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

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

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

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

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

Only the future will tell :)

> Which features are missing in D?

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

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

No.

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

I hope you find this information useful.
Re: [go-nuts] Re: GO Vs D Nick Sabalausky 8/12/10 4:02 PM
Michael Jones wrote:
> I think we all heard quite about ranges in Ada, Python, ...
>

I only know a little Python and I don't know any Ada, but my
understanding is that Python ranges are nothing more than a numeric
sequence. That's not what D ranges are (although that is a small
subset of what they can do). D's ranges are more comparable (in
concept, not necessarily implementation) to a pair of start/end
iterators, but with extra bonuses (and FAR saner usage syntax,
particularly compared to STL). A good explanation is here:
http://www.informit.com/articles/printerfriendly.aspx?p=1407357
Re: GO Vs D Nick Sabalausky 8/12/10 4:16 PM
Leandro Lucarella wrote:
>
> I think the worse problem in D how the language is
> managed. Is really too complex to explain in a couple of lines, but
> you can read these blog posts to get an impression (some issues
> mentioned in those posts are outdated and some have been improved
> considerably, so the only real way to know how things work is giving
> it a try):
>

This is a rather YMMV kind of thing. I find it to work out just fine.
I think some people just find issue with the fact that the management
of D isn't highly-formalized with boatloads of "policies and
procedures" docs and corporate-like structure (and structure-for-the-
sake-of-structure, etc). Look at GCC for the antithesis of D. I tried
to make a contribution to GCC once, but gave up after wasting days
trying to wade through red-tape just to *try* to find the particular
red-tape I needed to deal with just to submit something.
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[1] while the first range proposal in D was in September
8th, 2008[2].

[1] http://www.boost.org/users/history/version_1_32_0
[2] http://www.digitalmars.com/d/archives/digitalmars/D/announce/RFC_on_range_design_for_D2_12922.html
Re: GO Vs D Nick Sabalausky 8/12/10 4:32 PM
Leandro Lucarella wrote:
>
> I still don't get why the D community in general (and Andrei usually
> too, even when he mention the Boost and Adobe ranges in the article
> you cited) embrace the ranges as they were an invention of their own
> and as it was unique to D. Boost.Range was first release in November
> 19th, 2004[1] while the first range proposal in D was in September
> 8th, 2008[2].
>

I suppose that may be a valid point. I think a significant chunk of
the D community is former C++ users who got really, really fed up with
C++ (like me). I know in my case I abandoned C++ out of disgust back
around 2001, so I never really got into boost, and certainly never
heard of Boost's ranges (although over those years I *have* heard a
lot about STL iterators, even outside the D community, so I'm guessing
iterators may be far more typical in C++ than Boost ranges).
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
and D,
but I think I've made up my mind in favor of D. Actually, I only
really learned
about D after trying Go, finding it didn't fit my needs as much as I'd
like, and looking for something
else similar that does. Here's my comparison:

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

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

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

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

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

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

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

I think both languages are interesting and usable as they stand, and I
hope both succeed. I am
a bit put off by statements from the Go side that there hasn't been a
new systems language for
15 years. What about D? I almost didn't learn about D because I
believed them. They should
not say such things.
Re: GO Vs D Nick Sabalausky 8/12/10 6:47 PM
Jonathan Yedidia wrote:
> I am
> a bit put off by statements from the Go side that there hasn't been a
> new systems language for
> 15 years. What about D? I almost didn't learn about D because I
> believed them. They should
> not say such things.
>

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

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

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

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

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

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

* On a lighter note, I admit I was amused by the remark that no
systems language has been developed in the past 15 years. It's quite
difficult to find proper excuses and qualifications for that; even
though I made even bolder statements I've already had solid facts
backing me up. After having heard a major Go proponent make that
remark in a public talk as unequivocally as it gets, I went straight
ahead and googled for "systems programming language". If D were a
snake, it would have bitten me by the nose. I sure hope Go is not
overall characterized by self-isolation. We also do our best on the D
team to stay in touch with the latest research and development in the
Programming Languages field.
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
package to be of any practical limitation when writing systems
programs. I've also used manual memory management, basically mmapping
in memory pages and handing out the memory with a custom allocator.

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

 Kai

Re: [go-nuts] Re: GO Vs D Russel Winder 8/12/10 10:48 PM
Andrei,

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

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

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

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

For me there are two questions:

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

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

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

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

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

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

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

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
tricks. And of course one can trivially call C and assembly code
compiled by gc/ga without using any external tools.

- Taru Karttunen

Re: GO Vs D bioinfornatics 8/13/10 4:26 AM
Hello,
About a 64-bit version, the compiler LDC and Tango library support
both 32 and 64 bit.
* LDC is LLVM based and use the DMD frontend. it is a free software
under BSD license.
http://www.dsource.org/projects/ldc
* Tango is too under BSD license
http://www.dsource.org/projects/tango/wiki

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


Feel free for help and improve these project
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:
> Andrei,
>
> I have liked D for a long while, but until there is a stable 64-bit
> v2.0, with AMD64 installers, alongside the 386 v2.0, it is not really a
> viable language.

I agree.

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

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

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

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

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

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

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

I don't understand this part.

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

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

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

D can do everything C can do.

One closing note - since this is a group dedicated to discussions
about the Go programming language, I think it would be polite to
direct future questions to a D-specific forum. Thank you.
Re: GO Vs D Andrei Alexandrescu 8/13/10 6:44 AM
On Aug 13, 1:58 am, Stanley Steel <st...@kryas.com> wrote:
> P. S. Andrei, I have your book sitting on my desk right in front of me, next
> to my ANTLR reference book.  I preordered it on Amazon last summer.  Great
> work!  You said there are certain books that do not have an author listed on
> the front; my book does not have your name under the painting on the front
> cover.  What is the significance of that?

The only significance of that is that an error at the printer made the
authorless TDPL copies a rare collector's edition. There are only 1830
copies total that don't have the author's name on the cover. There
were a lot more, but they have been recycled.
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-
> level races are the worst kind of weakness in a type system.

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


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

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


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

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

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

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

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

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

Ian

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:
> Andrei Alexandrescu <iro...@gmail.com> writes:
> > At the same time we believe that low-
> > level races are the worst kind of weakness in a type system.
>
> That's an interesting perspective.  I agree that low-level races are a
> serious problem in modern programming.  But phrasing in terms of a
> problem in the type system seems odd to me.

Here are some starting points that could be helpful:

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

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

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

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

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

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

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

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

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

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

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

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

This is well-trodden ground. The brief answer is - it is possible (by
formalizing uniqueness within the language) but out the window goes
simplicity.
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 with
> garbage collection for writing a new operating system, which gives doubt
> about whether Go will get used for that -- despite all the splendid
> Plan-9 related work.  So can D really step up and be a candidate?  Or
> will people just descend to the arguments "C is the only language
> because it is the only one with a low enough viewpoint"?

D is already being used for implementing a kernel:

http://wiki.xomb.org

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


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

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


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

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

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

Ian

Re: GO Vs D Andrei Alexandrescu 8/13/10 5:15 PM
On Aug 13, 2:02 pm, Michael Jones <m...@google.com> wrote:
> Thank you Andrei and Ian for demonstrating the best level of intellectual
> discussion that one could hope for in an open discussion forum.

Let's keep it that way!
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:
> Andrei Alexandrescu <iro...@gmail.com> writes:
> >http://www.informit.com/articles/printerfriendly.aspx?p=1609144
>
> Thanks.  As you know, this approach is clearly different from the one in
> Go, which is a transfer of ownership model, where the transfer of
> ownership is enforced only by convention.  And, of course, Go doesn't
> use the type system, which follows Go's general guideline of keeping the
> type system light weight.

I understand. So what we have now is:

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

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

(3) Everything else is undefined.

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

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

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

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


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

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

Ian

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 discouraged
> for use in most Go code, but they are available and well-defined when
> required.

Thanks, I'd missed that. Will take a look.
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
fascinating.

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

Perhaps there is room for both languages in the world? I think the
next few years will be very interesting... :) I think I'll learn
both...
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
(http://www.complang.tuwien.ac.at/anton/comp.lang-statistics/ mainly),
it looks like most popular programming languages of today spent a good
deal of time in obscurity. In 1997, 8 years after the python project
was begun, it was at level of obscurity comparable to ada today (if
these statistics are to be trusted). Java did better - it was
announced in 1995, and JDK1.0 was released in 1996. It rose out of
obscurity within the next two years. C seems to have done about as
well/poorly as python - it was working well in 1973 (when the Unix
kernel for PDP-11 was written in it - I'm reading from
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html, I wasn't alive
then), but C wasn't "spreading widely" until the 1980s (again,
semi-quoting). Of course, B was around for a good bit before C (two
years at least), and the BCPL description was around in 1969, 4 years
before any part of it was ready for handling the Unix kernel.

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


--
Scott Lawrence

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,
then only
reason it got widespread use was because of Unix.

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

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

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

--
Paulo

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

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

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

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

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

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

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

--
Paulo
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
nowadays.

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

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

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

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

--
Paulo

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

Re: GO Vs D Jonathan Yedidia 8/14/10 8:56 AM


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

I don't understand what you mean by "no indication when it will be
released" for D. You can download the DMD 2.048 compiler today and it
works; I haven't found anything that doesn't match the description in
"The D Programming Language" book. Sure D is still in development; so
is Python, Ruby, Java, and any other language that isn't dead.
Re: GO Vs D 8/14/10 9:54 AM
On Aug 13, 4:30 pm, Ian Lance Taylor <i...@google.com> wrote:
> That's an interesting perspective.  I agree that low-level races are a
> serious problem in modern programming.  But phrasing in terms of a
> problem in the type system seems odd to me.  It seems to me that the
> purpose of a type system is to ensure that the only appropriate
> operations are applied to a particular piece of data.  But a low-level
> race is not a result of an inappropriate operation, it's a result of two
> appropriate operations being applied without necessary safeguards.
> Using the type system to avoid races is like using the type system to
> prevent two different programs from writing to the same file at the same
> time; it seems to me to be working at the wrong level.

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

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

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

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

would yield the following compile-time error:

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

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

Is THAT what you are saying?
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
"lightning fast"?

Chris

--
Chris "allusive" Dollin

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
> system happens to be sufficiently advanced to be able to detect this
> kind of error, then in your opinion such a type system is totally bad.
> The reason being that it is "working at the wrong level".
>
> Is THAT what you are saying?

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

Ian

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
large, though), they've compiled in less time than it took my editor
(emacs, or kate) to start up. That's not bad.

--
Scott Lawrence

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:
> Imagine, you have some program that reads a configuration file when it
> is started. I think you will agree with me that the program would not
> start properly if in the middle of the process the file was
> overwritten by some other process. It would be nice if the type system
> could reject programs in which this kind of concurrent modification
> *might* happen. For example, trying to compile the code
>
> 1  fd := open(config_file)
> 2  option1 := read_int(fd, "option1")
> 3  option2 := read_bool(fd, "option2")
> 4  close(fd)
>
> would yield the following compile-time error:
>
> file "input", lines 1-4: You moron, you cannot do it this way because
> there would be some issues related to a possible concurrent
> modification of the file. Try to use function "openAndLock" instead of
> "open".

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

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

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

- Jessta

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

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:
>
> > On Aug 14, 11:38 am, Giuseppe Altea <ggprot...@gmail.com> wrote:
> >> Tried go - liked it because of simple design fast compile speed ...
>
> > In my experience, the compiler is *not* as fast as advertised. Sure,
> > it is faster then GCC. But lighting-fast? No.
>
> How fast is it advertised as being and what for you would count as
> "lightning fast"?

I will give you some concrete (approximate) numbers:

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

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

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

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

The Go compiler is repeating the very same mistake (at least I think
of it as a mistake) performed by majority of all other compilers: it
is not doing any automatic caching or incremental compilation. I do
*not* think a compiler that isn't doing any *automatic* caching nor
any *automatic* sub-file dependency analysis is a high-speed compiler.
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:
> If neglecting to cache is what's holding back performance, then I
> think the architecture is in good shape.

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

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

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

Generalized:

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

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

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

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

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

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

I never said that Go should be abandoned.
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
code, half a second isn't too terrible. 50ms would be significantly
better, so future optimization by adding incremental compilation or
automatic caching could be cool. But for now, if all of the other
compilers are making the same mistakes, and 1.5 seconds isn't fast
enough for your ten thousand lines of code, you probably won't be
satisfied with interpreters either, since they run the code orders of
magnitude slower than compiled versions for the most part. JIT
compilers might be ok, but those should run into the same problems
too.

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

Re: GO Vs D 8/18/10 3:39 AM
On Aug 18, 12:08 pm, Cory Mainwaring <olre...@gmail.com> wrote:
> Go isn't as fast at compiling as maybe it should be. However, could
> you take a similar 9222 lines of C++ code and compile it? Might I know
> how long that takes on your notebook CPU? [cut]

Why are you asking when you already know the answer?

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

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

I don't understand why are multiple people here thinking that I am
suggesting to stop using Go. I NEVER SAID THAT. I only said that
compilation is not lightning-fast - which is true.
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:
>
> Considering that most of a software developer's work is concentrated
> around incremental changes, I think the Go compiler is slower here by
> something like 100x than it should be. Spending more than 10
> milliseconds on compiling a package in which I only touched a single
> function - this seems like on overkill to me, irrespective of whether
> the package has 100 lines or 100000 lines.
>

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


--
@chickamade

Re: GO Vs D Nick LaForge 8/18/10 7:18 AM
> I don't understand why are multiple people here thinking that I am
> suggesting to stop using Go. I NEVER SAID THAT. I only said that
> compilation is not lightning-fast - which is true.

Sorry, I had jumbled Giuseppe's and your posts in my head.
Re: GO Vs D Rohit Yadav 10/11/13 1:54 PM
Hi,

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

Regards,
Rohit

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

I understand. So what we have now is:

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

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

(3) Everything else is undefined.

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

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

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

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


Andrei
More topics »