www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Rust and D

reply "bearophile" <bearophileHUGS lycos.com> writes:
Most comparisons between Go and D on Reddit aren't good, but this 
time there is an almost decent comparison between D and Rust:

http://www.reddit.com/r/programming/comments/10k9ao/why_i_think_rust_is_the_language_of_the_future/

I think the most direct competitor of D is going to become Rust 

purposes.


 From the thread I have also learnt that some months ago they have 
removed typestate from Rust, because it doesn't pull its weight, 
as Andrei says (I think Rust was the first serious attempt at 
using this language feature, and now it will be hard to see 
another language with it):

https://mail.mozilla.org/pipermail/rust-dev/2012-July/002094.html

https://github.com/mozilla/rust/issues/1805

https://github.com/mozilla/rust/issues/2178

Bye,
bearophile
Sep 27 2012
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
 From the Reddit thread:

Walter:


 D has the  safe annotation, which prevents unsafe pointer 
 operations.


Rust has a statically enforced borrow/lend management system, and 
other things like memory regions, that make it smarter (and 
probably harder to use).

The Rust type system extends what can be made "safe". On such 
things the Rust type system looks more complex and refined than 
the D type system, so unless the Rust designers have done 
something very wrong (like adding lot of complexity for no gain), 
I expect such type system to give more back, that is not present 
in D.

-------------------------

Abscissa256:


 D has ADT: 
 http://dlang.org/phobos-prerelease/std_variant.html#Algebraic


Algebraic doesn't currently support recursion, and even when it 
does, "having ADTs" means having both a nice way to define them, 
and a good way to de-structure them. D doesn't have pattern 
matching, so the D usage of ADTs is less well supported and less 
good.

I think adding a full featured pattern matching in D is too much 
complex, but I think supporting structs in switch statements (and 
maybe also auto assignment to variables in such case structs) 
adds only a small amount of complexity while giving back a good 
amount of usefulness.

It was discussed a little here:
http://d.puremagic.com/issues/show_bug.cgi?id=596



 Also, D supports manual memory management.


But Rust is designed to work well without a GC, unlike D. Rust 
has several features that make it safer even when you are not 
using a GC. Rust also seems to appreciate stack allocation more 
than D. In D stack-allocated arrays are second class citizens in 
Phobos (and there are no VLAs like Ada, but I don't know if Rust 
has them), and seem generally underused. In D to allocate classes 
on the stack you can't use a native feature of the language, 
while in Rust it's a built-in, and doing this in Rust is safe 
enough.

Bye,
bearophile
Sep 27 2012
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 28 September 2012 at 00:17:43 UTC, bearophile wrote:

 Most comparisons between Go and D on Reddit aren't good, but 
 this time there is an almost decent comparison between D and 
 Rust:

 http://www.reddit.com/r/programming/comments/10k9ao/why_i_think_rust_is_the_language_of_the_future/

 I think the most direct competitor of D is going to become Rust 

 purposes.


 From the thread I have also learnt that some months ago they 
 have removed typestate from Rust, because it doesn't pull its 
 weight, as Andrei says (I think Rust was the first serious 
 attempt at using this language feature, and now it will be hard 
 to see another language with it):

 https://mail.mozilla.org/pipermail/rust-dev/2012-July/002094.html

 https://github.com/mozilla/rust/issues/1805

 https://github.com/mozilla/rust/issues/2178

 Bye,
 bearophile


I like Rust specially due to the ML influence the language has.

Currently I only have two issues with the language:

- funny characters a la Perl for the pointer types scattered 
everywhere
- their tendency to shorten reserved words (already discussed 
here)

Other than that it seems a nice language.

Go can be a systems programming language, as others have proven 


But the language is nothing more than an improved C, and we don't 
need to throw away all the nice abstractions that are now 
mainstream in computing. Plus if you pay attention, Go talks are 
always about Web/REST servers.

I already can do that with JVM/.NET languages, with better 
performance as Go, without giving up all the nice abstractions 
the languages offer. Go would have been dead already, if it 
wasn't developed inside Google.

I am looking forward to D and Rusts future.

--
Paulo
Sep 28 2012
parent reply "Froglegs" <lugtug yahoo.com> writes:
   The Rust website says this:

Generic types	yes, only simple, non-turing-complete substitution

   After seeing that I just assumed the language was worthless and
ignored it..  is there something more to this?
Sep 28 2012
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 28 September 2012 at 17:42:07 UTC, Froglegs wrote:

   The Rust website says this:

 Generic types	yes, only simple, non-turing-complete substitution

   After seeing that I just assumed the language was worthless 
 and
 ignored it..  is there something more to this?



Modula-3, Eiffel, Ada, among others.

Meaning you cannot play meta-programming tricks with them.

For me that is ok, sometimes in D I think we suffer from 
meta-programming overdose.
Sep 28 2012
parent "mist" <none none.none> writes:
There are also some people that think that compile time 
metaprogramming is the single best thing happened to programming 
languages. And, hey, what language will I use if you tear it 
apart from D? :P

On Friday, 28 September 2012 at 18:21:32 UTC, Paulo Pinto wrote:

 On Friday, 28 September 2012 at 17:42:07 UTC, Froglegs wrote:

  The Rust website says this:

 Generic types	yes, only simple, non-turing-complete 
 substitution

  After seeing that I just assumed the language was worthless 
 and
 ignored it..  is there something more to this?



 Modula-3, Eiffel, Ada, among others.

 Meaning you cannot play meta-programming tricks with them.

 For me that is ok, sometimes in D I think we suffer from 
 meta-programming overdose.
Sep 28 2012
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 28 September 2012 at 17:42:07 UTC, Froglegs wrote:

   The Rust website says this:

 Generic types	yes, only simple, non-turing-complete substitution

   After seeing that I just assumed the language was worthless 
 and
 ignored it..  is there something more to this?


Relevant: 
http://commandcenter.blogspot.co.uk/2011/12/esmereldas-imagination.html
Sep 28 2012
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 28 Sep 2012 23:54:10 +0200
"Peter Alexander" <peter.alexander.au gmail.com> wrote:


 On Friday, 28 September 2012 at 17:42:07 UTC, Froglegs wrote:

   The Rust website says this:

 Generic types	yes, only simple, non-turing-complete
 substitution

   After seeing that I just assumed the language was worthless 
 and
 ignored it..  is there something more to this?


 
 Relevant: 
 http://commandcenter.blogspot.co.uk/2011/12/esmereldas-imagination.html


Meh, a meta-complaint.

I love the quotes in the first paragraph about actresses, but mostly
it strikes me as an elaborate way to dismiss, or at least overly
downplay:

1. The importance of metaprogramming.

2. The impracticality of judging the myriad of languages out there
these days by going hands-on with all of them, and not having some way
to narrow things down to a realistic level first.

(My apologies if the article's author is reading this, no offense was
intended.)
Sep 28 2012
parent reply =?ISO-8859-1?Q?Jos=E9_Armando_Garc=EDa_Sancio?= <jsancio gmail.com> writes:
On Fri, Sep 28, 2012 at 3:21 PM, Nick Sabalausky <
SeeWebsiteToContactMe semitwist.com> wrote:


 (My apologies if the article's author is reading this, no offense was
 intended.)



Doubt it. I believe the author was Rob Pike.
Sep 28 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 28 Sep 2012 18:33:31 -0700
Jos=E9 Armando Garc=EDa Sancio <jsancio gmail.com> wrote:


 On Fri, Sep 28, 2012 at 3:21 PM, Nick Sabalausky <
 SeeWebsiteToContactMe semitwist.com> wrote:
=20

 (My apologies if the article's author is reading this, no offense
 was intended.)


=20
=20
 Doubt it. I believe the author was Rob Pike.
=20


(Had to look up that name) Ahh, I see. That explains the dismissal of
metaprogramming and generics, and the dismissal Go's objectors
via a roundabout strawman (Ie by complaining about the act of
complaining, and by categorizing of Go's complaints as merely
programmers loving to complain for the sake of complaining).

(And yea, I see the "[generics] are a fine thing", but he's still
overall very dismissive of their importance.)
Sep 28 2012
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 29 September 2012 at 06:11:30 UTC, Nick Sabalausky 
wrote:

 (Had to look up that name) Ahh, I see. That explains the 
 dismissal of
 metaprogramming and generics, and the dismissal Go's objectors
 via a roundabout strawman (Ie by complaining about the act of
 complaining, and by categorizing of Go's complaints as merely
 programmers loving to complain for the sake of complaining).

 (And yea, I see the "[generics] are a fine thing", but he's 
 still
 overall very dismissive of their importance.)


He's not dismissive of their importance. The point was that if 
you can dismiss a language based solely on its lack of generics 
then you are essentially admitting that you have very little 
imagination as a programmer. You are admitting that the only way 
you can do productive, meaningful work is if you have generics.

It's worth pointing out that a large fraction of (most?) 
programming languages do not have generics, yet people seem to be 
able to do meaningful work in them.

I imagine that the less imaginative hardcore Go programmers will 
look at D and say things like "wow, how can D programmers work 
without channels?", and maybe the Lisp programmers say "wow, how 
can D programmers work without homoiconic representation", and 
maybe the Haskell programmers say "wow, how can D programmers 
work with only crappy local type inference?"

As you can see, no matter what you think of these features, the 
arguments are pointless because it is very clear that you can do 
meaningful work without them. We get by without channels, 
homoiconicity, and full program type inference; just as the Go 
programmers get by without generics.
Sep 29 2012
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 29 Sep 2012 10:08:29 +0200
"Peter Alexander" <peter.alexander.au gmail.com> wrote:

 
 He's not dismissive of their importance. The point was that if 
 you can dismiss a language based solely on its lack of generics 


Goes back to my other original point:

---------------
2. [He's dismissing] The impracticality of judging the myriad of
languages out there these days by going hands-on with all of them, and
not having some way to narrow things down to a realistic level first.
---------------

If he were talking about some minor insignificant feature, then I agree
it'd be goofy to reject a language solely because of that. But that's
not what's happening. Generics are a major thing. Many people *do* find
them to make a big difference.

So there's three possibilities:

A. As I said, he's dismissing the impracticality of judging the myriad
of languages without having some way to narrow things down to a
realistic level.

Or he acknowledges that impracticality and:

B. He considers generics fairly unimportant/insignificant (ie, to the
point of feeling it's not worth using to narrow down language
choices), in which case *many* people clearly disagree with him. But
instead of addressing *that*, or even acknowledging it at all, he's
pulling a strawman with "They all just hatin' 'cause they like ta hate!"

C. He agrees that generics are a major thing that make a big
difference, in which case...what's he even complaining about?
Just being sore that his language isn't up to snuff? Or sore that
everyone doesn't have time to try out his "wonderful except for the
lack of generics" language?

So any way you take it, he's still not making much sense.


 then you are essentially admitting that you have very little 
 imagination as a programmer. You are admitting that the only way 
 you can do productive, meaningful work is if you have generics.
 


Ok, yes, he is saying that too, but it's a ridiculous point and a
faulty argument. (See below.)


 It's worth pointing out that a large fraction of (most?) 
 programming languages do not have generics, yet people seem to be 
 able to do meaningful work in them.
 


Still a pointless argument.

Name *any* feature X of a programming language and remove it: As
long as it doesn't render the language non-turing-complete or eliminate
the possibility of doing any I/O, then I can do useful things with the
language, and so can just about any other decent programmer. So sure,
that's true, he's right about that much.

Problem is, that's irrelevant: The important point he's missing is
"If feature X is helpful, then why should I *bother* going
without, when there are plenty of other languages (such as the one I'm
already using) that *do* provide me with that benefit?"

He fails to even *try* to answer that and instead just complains about
complaining.

So unless he's trying to say "You should try Go because it's not worse
than some languages", then his argument is a strawman.

Frankly, I'm getting the feeling he's frustrated at discovering that
a feature-light language and initial "Wow, a Google/Pike language!"
attention aren't enough to sell huge crowds of people on Go. And at
the realization that to get a large following, and better PR, he
needs to compete better on features.
Sep 29 2012
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 29 September 2012 at 10:27:26 UTC, Nick Sabalausky 
wrote:

 If he were talking about some minor insignificant feature, then 
 I agree
 it'd be goofy to reject a language solely because of that. But 
 that's
 not what's happening. Generics are a major thing. Many people 
 *do* find
 them to make a big difference.


So, with this in mind, do you think these hypothetical people are 
all justified?

(a) [Go programmer]: D is rubbish because it doesn't have 
channels.
(b) [Lisp programmer]: D is rubbish because it doesn't have 
homoiconicity.
(c) [Haskell programmer]: D is rubbish because it doesn't have 
full type inference.

All of those things are considered "a major thing" by their 
users, and many people do find them to "make a big difference."

My question to you: Is it okay to reject D solely with these 
arguments? If not, how is this any different from rejecting Go 
solely from its lack of generics?
Sep 29 2012
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 29 September 2012 at 10:53:57 UTC, Peter Alexander 
wrote:

 On Saturday, 29 September 2012 at 10:27:26 UTC, Nick Sabalausky 
 wrote:

 If he were talking about some minor insignificant feature, 
 then I agree
 it'd be goofy to reject a language solely because of that. But 
 that's
 not what's happening. Generics are a major thing. Many people 
 *do* find
 them to make a big difference.


 So, with this in mind, do you think these hypothetical people 
 are all justified?

 (a) [Go programmer]: D is rubbish because it doesn't have 
 channels.
 (b) [Lisp programmer]: D is rubbish because it doesn't have 
 homoiconicity.
 (c) [Haskell programmer]: D is rubbish because it doesn't have 
 full type inference.

 All of those things are considered "a major thing" by their 
 users, and many people do find them to "make a big difference."

 My question to you: Is it okay to reject D solely with these 
 arguments? If not, how is this any different from rejecting Go 
 solely from its lack of generics?


Because except for Go, all static languages developed after 1990, 
which managed to gain mainstream use, have some form of generics.

Just to name a few out of my mind:

- Ada
- Modula-3
- Eiffel
- C++
- D
- Java
- VB.NET
- Object Pascal/Delphi
- Ocaml

- Haskell
- Scala

For those like myself that use C++ since the 'C with classes' 
time, Go's lack of generics feels like time travel into a time 
where generics were some strange stuff in compiler design papers.

The days when C++ compiler vendors used to offer C macro 
processor hacks, or external tools to enable the use of fake 
generics in C++ code. Borland was one of them, for example.

Funny enough, this type of tooling seems to start appearing in 
the Go community, proving that regardless of what they say, the 
need is there.

--
Paulo
Sep 29 2012
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 29 September 2012 at 11:18:40 UTC, Paulo Pinto wrote:

 On Saturday, 29 September 2012 at 10:53:57 UTC, Peter Alexander

 My question to you: Is it okay to reject D solely with these 
 arguments? If not, how is this any different from rejecting Go 
 solely from its lack of generics?


 Because except for Go, all static languages developed after 
 1990, which managed to gain mainstream use, have some form of 
 generics.


There's two ways to interpret this sentence:

1. You claim it is okay to reject Go because it differs from 
other statically typed languages, or
2. You claim that all statically typed languages must have 
generics to be worth using.

I hope it is not 1, and if it is 2 then again, I find this 
incredibly unimaginative.

Interestingly, Rob Pike comments on this world view:

http://commandcenter.blogspot.co.uk/2012/06/less-is-exponentially-more.html
----
"Early in the rollout of Go I was told by someone that he could 
not imagine working in a language without generic types. As I 
have reported elsewhere, I found that an odd remark.

To be fair he was probably saying in his own way that he really 
liked what the STL does for him in C++. For the purpose of 
argument, though, let's take his claim at face value.

What it says is that he finds writing containers like lists of 
ints and maps of strings an unbearable burden. I find that an odd 
claim. I spend very little of my programming time struggling with 
those issues, even in languages without generic types.

But more important, what it says is that types are the way to 
lift that burden. Types. Not polymorphic functions or language 
primitives or helpers of other kinds, but types.

That's the detail that sticks with me."
----
Sep 29 2012
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 29 September 2012 at 12:04:50 UTC, Peter Alexander 
wrote:

 On Saturday, 29 September 2012 at 11:18:40 UTC, Paulo Pinto 
 wrote:

 On Saturday, 29 September 2012 at 10:53:57 UTC, Peter Alexander

 My question to you: Is it okay to reject D solely with these 
 arguments? If not, how is this any different from rejecting 
 Go solely from its lack of generics?


 Because except for Go, all static languages developed after 
 1990, which managed to gain mainstream use, have some form of 
 generics.


 There's two ways to interpret this sentence:

 1. You claim it is okay to reject Go because it differs from 
 other statically typed languages, or
 2. You claim that all statically typed languages must have 
 generics to be worth using.

 I hope it is not 1, and if it is 2 then again, I find this 
 incredibly unimaginative.


It is 2.

And before you say that it is due to lack of experience with Go.

I have tried. You will find lots of posts made by me about 
generics
and doing systems programming with GC enabled languages in gonuts.

Actually, you may even find some early code reviews made to my 
early
attempts to create the Windows version of the os.user package. 
Which
was latter on picked up by the Go team.

Or the early attempts to support some form of UI in Windows.

So I don't dismiss Go without language experience.


 Interestingly, Rob Pike comments on this world view:

 http://commandcenter.blogspot.co.uk/2012/06/less-is-exponentially-more.html
 ----


I belong to the C++ category he describes there. Actually his 
blog entry was discussed to great lengths at Lambda the Ultimate.

Personally I think they are throwing the baby with the water in 
terms of language design.

Go would have been a great language before Generic Programming, 
Meta-programming and functional programming became mainstream in 
the IT corporations.

Nowadays it feels like a step backwards. While using Go I 
travelled back in time to my university days when I thought 
Oberon or Component Pascal would become mainstream. Languages 
which share the same design philosophy.

But that was back in 1994.

--
Paulo
Sep 29 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 29 Sep 2012 14:05:19 +0200
"Peter Alexander" <peter.alexander.au gmail.com> wrote:

 
 Interestingly, Rob Pike comments on this world view:
 
 http://commandcenter.blogspot.co.uk/2012/06/less-is-exponentially-more.html
 ----
 "Early in the rollout of Go I was told by someone that he could 
 not imagine working in a language without generic types. As I 
 have reported elsewhere, I found that an odd remark.
 
 To be fair he was probably saying in his own way that he really 
 liked what the STL does for him in C++. For the purpose of 
 argument, though, let's take his claim at face value.
 
 What it says is that he finds writing containers like lists of 
 ints and maps of strings an unbearable burden. I find that an odd 
 claim. I spend very little of my programming time struggling with 
 those issues, even in languages without generic types.
 
 But more important, what it says is that types are the way to 
 lift that burden. Types. Not polymorphic functions or language 
 primitives or helpers of other kinds, but types.
 
 That's the detail that sticks with me."
 ----



Sounds like Pike is either implying that all approaches are created
equal, or that "types" are inferior. On the contrary, I think there's
good reason to prefer the type-based solution.

But maybe I'm wrong. Maybe I don't understand the other approaches well
enough. Maybe Pike would actually convince more people if he
spent more time explaining *how* Go sufficiently addresses the issue
and less time using meta-arguments to rehash "Why can't people just
start liking Go?"

It's unfortunate, because the more I read these quotes of his, the more
I have to wonder whether his emperor even has any clothes at all.
Sep 29 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/29/2012 5:05 AM, Peter Alexander wrote:

 There's two ways to interpret this sentence:

 1. You claim it is okay to reject Go because it differs from other statically
 typed languages, or
 2. You claim that all statically typed languages must have generics to be worth
 using.

 I hope it is not 1, and if it is 2 then again, I find this incredibly
 unimaginative.


Is it really? For example, all modern cars use fuel injection. That doesn't
make 
carbureted cars unusable, I've driven them just fine for decades, but I sure do 
prefer fuel injection. Most people prefer it so much that you can buy fuel 
injection kits to replace the carburetors on most older cars.

I would not buy a new car with a carburetor.

Same goes for electronic ignition. Man, is that better than the old
points/dwell 
system.
Sep 29 2012
prev sibling next sibling parent reply "Thiez" <thiezz gmail.com> writes:
On Saturday, 29 September 2012 at 10:53:57 UTC, Peter Alexander 
wrote:

 So, with this in mind, do you think these hypothetical people 
 are all justified?

 (a) [Go programmer]: D is rubbish because it doesn't have 
 channels.
 (b) [Lisp programmer]: D is rubbish because it doesn't have 
 homoiconicity.
 (c) [Haskell programmer]: D is rubbish because it doesn't have 
 full type inference.


Would you agree D would be better if it had those features?

How about we rephrase to something less inflammatory:
  [Go programmer]: I prefer not to use D because it doesn't have 
channels.
  [Lisp programmer]: I prefer not to use D because it doesn't have 
homoiconicity.
  [Haskell programer]: I prefer not to use D because it doesn't 
have full type inference.

Suddenly they all seem like perfectly acceptable arguments. If a 
person really likes/needs a certain language feature, then surely 
that is a good reason to reject a language that does not have 
this feature?

Many people like generics. Go doesn't have them. So why get angry 
if these people reject Go?
Sep 29 2012
parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 29 September 2012 at 12:09:35 UTC, Thiez wrote:

 Would you agree D would be better if it had those features?


Maybe. Maybe not. It's irrelevant.



 How about we rephrase to something less inflammatory:
  [Go programmer]: I prefer not to use D because it doesn't have 
 channels.
  [Lisp programmer]: I prefer not to use D because it doesn't 
 have homoiconicity.
  [Haskell programer]: I prefer not to use D because it doesn't 
 have full type inference.

 Suddenly they all seem like perfectly acceptable arguments. If 
 a person really likes/needs a certain language feature, then 
 surely that is a good reason to reject a language that does not 
 have this feature?


If the person has not even tried the language then no, I still do 
not think those are valid reasons to reject a language.



 Many people like generics. Go doesn't have them. So why get 
 angry if these people reject Go?


I like ice cream. Vegetables don't contain ice cream. So why get 
angry if I don't try vegetables?

Ok, so there's no reason to get angry, but I'd be an idiot to 
follow that logic.

The parallel is that I would consider it unhealthy to dismiss a 
language without trying it just because it lacks a feature that 
you happen to like. It may have something else that you like even 
more, or you may even find that the *lack* of a feature actually 
makes the language simpler and more expressive in ways you 
couldn't imagine (e.g. D's lack on inner struct pointers makes 
things significantly simpler).
Sep 29 2012
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 29 Sep 2012 12:54:26 +0200
"Peter Alexander" <peter.alexander.au gmail.com> wrote:


 On Saturday, 29 September 2012 at 10:27:26 UTC, Nick Sabalausky 
 wrote:

 If he were talking about some minor insignificant feature, then 
 I agree
 it'd be goofy to reject a language solely because of that. But 
 that's
 not what's happening. Generics are a major thing. Many people 
 *do* find
 them to make a big difference.


 
 So, with this in mind, do you think these hypothetical people are 
 all justified?
 
 (a) [Go programmer]: D is rubbish because it doesn't have 
 channels.
 (b) [Lisp programmer]: D is rubbish because it doesn't have 
 homoiconicity.
 (c) [Haskell programmer]: D is rubbish because it doesn't have 
 full type inference.
 
 All of those things are considered "a major thing" by their 
 users, and many people do find them to "make a big difference."
 


If they find those things to be as important to them as I find
metaprogramming to be, then yes, of course.

Personally, I think it's a stretch to compare those to "having
generics". But that's just me...and, apparently, a hell of a lot of
other people too, to Pike's dismay.


 My question to you: Is it okay to reject D solely with these 
 arguments?


If it's in-line with their needs, then yes. It'd be both selfish and
absurd for us to demand that everyone tries out and becomes proficient
with our language and our language's way of doing things before
deciding whether or not our language is right for them and worth their
time.

And in addition to all that, I doubt very much that most people who
say things to the effect of "I won't use Go because it lacks generics"
are *truly* basing it *purely* on the lack of generics, so the
whole question is academic anyway. Hell, I'm sure *I've* at some point
probably given the impression that generics are the only reason I'm not
into Go. But the reality is that there are also other reasons, and
"generics" is merely one of the biggest and most convenient to point
out.

Just as an example, I'm sure a *lot* of the "No generics, not
interested" crowd would also find this applicable, too:

"I'm happy enough with my current language and don't have time to
try another out unless there's already something about it that really
stands out to me as being likely worth the investment."
Sep 29 2012
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 29 September 2012 at 14:27:03 UTC, Nick Sabalausky 
wrote:

 My question to you: Is it okay to reject D solely with these 
 arguments?


 If it's in-line with their needs, then yes. It'd be both 
 selfish and
 absurd for us to demand that everyone tries out and becomes 
 proficient
 with our language and our language's way of doing things before
 deciding whether or not our language is right for them and 
 worth their
 time.


Again, no one is making any demands. I'm asking for one of two 
things from people: either try the language then form an educated 
opinion, or don't try it and say nothing. The problem is that 
people are reading "no generics", not trying the language, and 
then shouting out that it is rubbish.



 And in addition to all that, I doubt very much that most people 
 who
 say things to the effect of "I won't use Go because it lacks 
 generics"
 are *truly* basing it *purely* on the lack of generics, so the
 whole question is academic anyway.


See post 4 in this thread. That's what got me started.

http://forum.dlang.org/thread/tpwsxxjghbpsheexyrdq forum.dlang.org#post-hqhkcxyqtbrbasuknmdt:40forum.dlang.org

Yes, you said "most", and one post is not most, but I see this 
attitude a lot. Evidently Rob Pike does as well. I'm sure most 
people here have seen similar arguments against D.
Sep 29 2012
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 29 Sep 2012 19:04:01 +0200
"Peter Alexander" <peter.alexander.au gmail.com> wrote:


 On Saturday, 29 September 2012 at 14:27:03 UTC, Nick Sabalausky 
 wrote:

 My question to you: Is it okay to reject D solely with these 
 arguments?


 If it's in-line with their needs, then yes. It'd be both 
 selfish and
 absurd for us to demand that everyone tries out and becomes 
 proficient
 with our language and our language's way of doing things before
 deciding whether or not our language is right for them and 
 worth their
 time.


 
 Again, no one is making any demands. I'm asking for one of two 
 things from people: either try the language then form an educated 
 opinion, or don't try it and say nothing. The problem is that 
 people are reading "no generics", not trying the language, and 
 then shouting out that it is rubbish.
 
 

 And in addition to all that, I doubt very much that most people 
 who
 say things to the effect of "I won't use Go because it lacks 
 generics"
 are *truly* basing it *purely* on the lack of generics, so the
 whole question is academic anyway.


 
 See post 4 in this thread. That's what got me started.
 
 http://forum.dlang.org/thread/tpwsxxjghbpsheexyrdq forum.dlang.org#post-hqhkcxyqtbrbasuknmdt:40forum.dlang.org
 
 Yes, you said "most", and one post is not most, but I see this 
 attitude a lot. Evidently Rob Pike does as well. I'm sure most 
 people here have seen similar arguments against D.


Yea, I still don't see the problem.

First of all, he wasn't "shouting out that it is rubbish" - only stated
that he had assumed it to be *and* even asked if "is there something
more to it".

Second, obviously he's one of the many, many programmers who do
highly value generics, so it's not unreasonable for him to dismiss it
without trying it. How many people have so much free time they can go
trying out all the languages that sound wrong for them?

If Pike sees this sort of thing a lot and is bothered by it, then he
needs to either reevaluate Go's stance on generics or provide 
direct explanation why Go doesn't need them without dancing
around the issue with things like "Less is More" vagueness and "They're
just complaining" hand-waving. Otherwise he can't expect people's
apprehensions about it to magically go away.

We had a big PR problem with the whole two-incompatible-standard-libs
thing. What did we do? We fixed the damn problem and then
communicated whenever necessary about how and why it wasn't an issue.
What we didn't do was hop on our blogs to whine that people loved to
complain and weren't being fair to D.
Sep 29 2012
prev sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Saturday, 29 September 2012 at 17:03:33 UTC, Peter Alexander 
wrote:

  I'm sure most people here have seen similar arguments against 
 D.


The complaint I've seen in a similar vain have been, "D is too 
complex" "it has everything and the kitchen sink" "if someone 
asks for it, it gets added"

And all but the last one is true. These are valid concerns and 
should not be dismissed as "people complaining to complain." 
Attempts to explain that to simplify the language introduces 
complexity to the code may fail. But the concern is not any less 
valid.

What is more annoying is that the level of understanding the 
complexity is usually attributed to that of C++. I grasp meta 
programming to a fairly decent degree, but I fail to read and 
understand that demonstrated in C++. I have very limited 
experience with C++ and almost no familiarity with templates 
(outside of the overlap with D). The syntax makes a huge 
difference! And with such clean syntax I guess our semantics is 
cleaner too.

A similar parallel I may have identified is Go return values. 
These are compared to those used in C. But if I picked up on this 
correctly, errors codes must be explicitly ignored. In which case 
I think of checked exceptions, except now every call is made with 
a try.

As you can see I am trying to apply experience I have with other 
languages to conform an understanding of the experience I'd get 
from Go. It doesn't mean it will be exactly correct, but this is 
how we efficiently eventuate things. If I have only ridden roller 
coasters that go upside-down, if asked whether I would enjoy one 
that doesn't go upside-down, I can apply my knowledge of the time 
spent not being upside down for those that do and make a best 
guess if I would find it fun/scary.
Sep 29 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/29/2012 3:54 AM, Peter Alexander wrote:

 So, with this in mind, do you think these hypothetical people are all
justified?

 (a) [Go programmer]: D is rubbish because it doesn't have channels.
 (b) [Lisp programmer]: D is rubbish because it doesn't have homoiconicity.
 (c) [Haskell programmer]: D is rubbish because it doesn't have full type
inference.

 All of those things are considered "a major thing" by their users, and many
 people do find them to "make a big difference."


People can and do make those arguments and justifications.

The question is, really, how large of a class of programming problems does each 
of those features address?
Sep 29 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/29/2012 09:12 PM, Walter Bright wrote:

 On 9/29/2012 3:54 AM, Peter Alexander wrote:

 So, with this in mind, do you think these hypothetical people are all
 justified?

 (a) [Go programmer]: D is rubbish because it doesn't have channels.
 (b) [Lisp programmer]: D is rubbish because it doesn't have
 homoiconicity.
 (c) [Haskell programmer]: D is rubbish because it doesn't have full
 type inference.

 All of those things are considered "a major thing" by their users, and
 many
 people do find them to "make a big difference."


 People can and do make those arguments and justifications.

 The question is, really, how large of a class of programming problems
 does each of those features address?


a) can be done in a library. (eg. in D, but not in Go) Therefore,
claiming that D does not have channels is moot anyway.
b), c) enable more powerful abstractions. They help all programs
if the programmer knows how to leverage them.
Sep 29 2012
prev sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 29 September 2012 at 10:27:26 UTC, Nick Sabalausky 
wrote:

 Problem is, that's irrelevant: The important point he's missing 
 is
 "If feature X is helpful, then why should I *bother* going
 without, when there are plenty of other languages (such as the 
 one I'm
 already using) that *do* provide me with that benefit?"

 He fails to even *try* to answer that and instead just 
 complains about
 complaining.


The answer to that question is obvious: you should bother going 
without because other languages provide other things that your 
pet language does not (e.g. channels + simplicity in this case).

Searching for a better language is a search like any other. 
Hill-climbing is a poor search heuristic. Sometimes you have to 
be willing to lose features to find the higher peaks.
Sep 29 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 29 Sep 2012 13:06:33 +0200
"Peter Alexander" <peter.alexander.au gmail.com> wrote:

 
 The answer to that question is obvious: you should bother going 
 without because other languages provide other things that your 
 pet language does not (e.g. channels + simplicity in this case).
 
 Searching for a better language is a search like any other. 
 Hill-climbing is a poor search heuristic. Sometimes you have to 
 be willing to lose features to find the higher peaks.
 


And sometimes I need to get work done instead of trying out all of the
100's of languages out there in some altruistic quest to be fair to
everybody.
Sep 29 2012
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 29 September 2012 at 14:03:52 UTC, Nick Sabalausky 
wrote:

 And sometimes I need to get work done instead of trying out all 
 of the
 100's of languages out there in some altruistic quest to be 
 fair to
 everybody.


Nothing wrong with that, but rejecting a language because you 
don't have time to try it out is much different for rejecting it 
because it lacks a single feature.
Sep 29 2012
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 29 Sep 2012 16:15:51 +0200
"Peter Alexander" <peter.alexander.au gmail.com> wrote:


 On Saturday, 29 September 2012 at 14:03:52 UTC, Nick Sabalausky 
 wrote:

 And sometimes I need to get work done instead of trying out all 
 of the
 100's of languages out there in some altruistic quest to be 
 fair to
 everybody.


 
 Nothing wrong with that, but rejecting a language because you 
 don't have time to try it out is much different for rejecting it 
 because it lacks a single feature.


It's not as different as it may seem.

People have limited time. Some have more, some have less (hell,
probably most have less), but *nobody* can go trying out all the
languages out there, so we all have to have some some "filter" for
picking the ones we feel most likely to pay off, narrowed down to
whatever our schedule will even allow. Usually this is all implicit
and maybe even sub-conscious, but it's always there.

So when someone is "rejecting a language because it lacks a single
feature" without even trying it, then no, I don't believe that they
actually *are* rejecting it *just* because it lacks one feature, at
least not in most cases. Because there's always still an implicit "I
don't have time to pursue a language that I feel may not be likely
enough to pay off."
Sep 29 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/29/2012 1:08 AM, Peter Alexander wrote:

 As you can see, no matter what you think of these features, the arguments are
 pointless because it is very clear that you can do meaningful work without
them.
 We get by without channels, homoiconicity, and full program type inference;
just
 as the Go programmers get by without generics.


I think that argument is making the claims that:

1. all features are equally valuable

2. if one can get by without a feature, then that feature is not needed

Both of those are invalid.
Sep 29 2012
next sibling parent "Franciszek =?UTF-8?B?Q3pla2HFgmEi?= <home valentimex.com> writes:
On Saturday, 29 September 2012 at 19:09:46 UTC, Walter Bright 
wrote:

 On 9/29/2012 1:08 AM, Peter Alexander wrote:

 As you can see, no matter what you think of these features, 
 the arguments are
 pointless because it is very clear that you can do meaningful 
 work without them.
 We get by without channels, homoiconicity, and full program 
 type inference; just
 as the Go programmers get by without generics.


 I think that argument is making the claims that:

 1. all features are equally valuable

 2. if one can get by without a feature, then that feature is 
 not needed

 Both of those are invalid.


Exactly my thoughts. Templates enable abstraction. Go channels 
enable ... channels. Comparing both on the same level is 
ridiculous. Go has a vey low level of abstraction. I feel it is 
even worse than C. In C, void* can be a powerful abstraction 
tool, but in Go pointers are almost banned and made difficult to 
use. Empty interfaces do not cut it because they involve boxing 
and unboxing and they give you nothing that void * could not give 
you and easier. Interfaces in general? You cannot even sensibly 
define interfaces with methods that have that same interfaces as 
their return types (just try it). I cannot see Go being used 
beyond utf-8 text processing (web servers and the like). Numeric 
calculations? Without some serious abstraction tools nobody is 
going to waste their time. Other uses? Wherever you go 
abstraction (read generics and the like) rules. Not using 
abstraction means usually wasting your programming effort and 
redoing things multiple times. When people refuse to use 
programming languages without abstraction mechanisms it is 
exactly immagination that they use.
Sep 29 2012
prev sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 29 September 2012 at 19:09:46 UTC, Walter Bright 
wrote:

 On 9/29/2012 1:08 AM, Peter Alexander wrote:

 As you can see, no matter what you think of these features, 
 the arguments are
 pointless because it is very clear that you can do meaningful 
 work without them.
 We get by without channels, homoiconicity, and full program 
 type inference; just
 as the Go programmers get by without generics.


 I think that argument is making the claims that:

 1. all features are equally valuable

 2. if one can get by without a feature, then that feature is 
 not needed

 Both of those are invalid.


I'm not making claim 1, and claim 2 is true by definition.
Sep 29 2012
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 30 Sep 2012 00:12:33 +0200
"Peter Alexander" <peter.alexander.au gmail.com> wrote:


 On Saturday, 29 September 2012 at 19:09:46 UTC, Walter Bright 
 wrote:

 I think that argument is making the claims that:

 1. all features are equally valuable

 2. if one can get by without a feature, then that feature is 
 not needed

 Both of those are invalid.


 
 I'm not making claim 1, and claim 2 is true by definition.
 


Such a feature may not be *strictly* needed to accomplish a given task
within a given language. However, it may very well still be needed in
order to make said language actually worth switching to.

I can get by with conditional jumps instead of if/else blocks (ex:
Assembly, or old-school BASIC). And I even did for several years. But I
sure as hell won't anymore if I don't have to.

I, and many other people, find metaprogramming to be similarly "One
you try it, you don't want to leave it". Not only does Go not have
metaprogramming, but it doesn't even have the limited form of
metaprogramming, generics, that's already common in many other
languages. Therefore, the onus is on Go (or any other language that
lacks generics), to show that there's something about the langauge that
makes that sacrifice either worthwhile or at least somehow irrelevent.
Sep 29 2012
prev sibling parent reply "jerro" <a a.com> writes:
 1. all features are equally valuable

 2. if one can get by without a feature, then that feature is 
 not needed

 Both of those are invalid.


 I'm not making claim 1, and claim 2 is true by definition.


Brainfuck has all the needed language features by that definition.
Sep 29 2012
parent "Froglegs" <lugtug yahoo.com> writes:
  Go looks like a horrible combination of C and Lua, lacking the 
speed of C and the  power of Lua(and I'd bet LuaJIT beats Go for 
performance).

  Not all features are equal, for me, meta programming is such a 
useful thing that a language better have something damn 
impressive to replace it(especially a systems programming 
language). I scanned through the Rust docs and did not see 
anything that appeared capable of doing so.
Sep 29 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/28/12 5:54 PM, Peter Alexander wrote:

 On Friday, 28 September 2012 at 17:42:07 UTC, Froglegs wrote:

 The Rust website says this:

 Generic types yes, only simple, non-turing-complete substitution

 After seeing that I just assumed the language was worthless and
 ignored it.. is there something more to this?


 Relevant:
 http://commandcenter.blogspot.co.uk/2011/12/esmereldas-imagination.html


I remember the entry, it's caused some criticism on reddit or HN a while 
ago. Particularly the closing paragraph has grated many people, but 
heck, who hasn't had a bad blogging day?

We've experienced some similar criticism about D, which was quite 
clearly (in my opinion) a rationalization of a foregone disposition 
rather than a valid concern. One example that comes to mind is an email 
exchange with a C++ expert who latched onto D not supporting structs 
with internal pointers as an essential feature for many designs, which 
that person found unthinkable to adjust.

(I don't see how the parallel with the actress anecdote holds, as the 
punchline there is that an actor has to imagine being in other lines of 
work as the very part of acting.)

Anyhow, I've recently decided to acquire some fluency in Go and look 
into alternative ways to accomplish things I'd want to accomplish.


Andrei
Sep 29 2012
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 29 Sep 2012 08:15:56 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 
 (I don't see how the parallel with the actress anecdote holds, as the 
 punchline there is that an actor has to imagine being in other lines
 of work as the very part of acting.)
 


I'd been thinking the same thing. It was very amusing in the actress
context, but brining it into programming just didn't seem to fit.
Sep 29 2012
prev sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 28-09-2012 19:42, Froglegs wrote:

    The Rust website says this:

 Generic types    yes, only simple, non-turing-complete substitution

    After seeing that I just assumed the language was worthless and
 ignored it..  is there something more to this?


Let me just clarify to everyone that Rust *does* have macros, which is 
certainly better than nothing at all: 
https://github.com/mozilla/rust/blob/master/doc/tutorial-macros.md

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Sep 30 2012
prev sibling parent "BLM768" <blm768 gmail.com> writes:
Looking at Rust's concurrency model, it does have some great 
ideas.
I wonder what would happen if D used thread-local heaps...

As far as syntax goes, the "shared" keyword could be used to 
distinguish between the heap types. I'm not sure how all this 
would work with "new", but I'm sure someone can think of a clean 
syntax.

In all, it's an intriguing idea, and it could fit with D's 
current concurrency model extremely well. I can definitely see 
this breaking code, but not much more than the switch to TLS 
globals did. It might be something to consider eventually.
Sep 29 2012