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 
(beside of course C# and C++), because Go has different enough 
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 
 (beside of course C# and C++), because Go has different enough 
 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 in research. Oberon, Modula-3, Sing# and so on. 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
next sibling parent 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
prev sibling next sibling parent 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
prev sibling next 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 next 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 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 next sibling parent "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
prev sibling next sibling parent "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?

As far as I understand it, Rust supports generic types a la C#, 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 "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
prev sibling next sibling 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?

As far as I understand it, Rust supports generic types a la C#, 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 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
prev sibling next sibling parent =?ISO-8859-1?Q?Jos=E9_Armando_Garc=EDa_Sancio?= <jsancio gmail.com> writes:
--bcaec517ad6c030e8704cacd291c
Content-Type: text/plain; charset=ISO-8859-1

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. --bcaec517ad6c030e8704cacd291c Content-Type: text/html; charset=ISO-8859-1 On Fri, Sep 28, 2012 at 3:21 PM, Nick Sabalausky <span dir="ltr">&lt;<a href="mailto:SeeWebsiteToContactMe semitwist.com" target="_blank">SeeWebsiteToContactMe semitwist.com</a>&gt;</span> wrote:<br><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">(My apologies if the article&#39;s author is reading this, no offense was</div></div> intended.)</blockquote><div><br></div><div>Doubt it. I believe the author was Rob Pike.</div></div><br> --bcaec517ad6c030e8704cacd291c--
Sep 28 2012
prev sibling next sibling parent 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 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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 - F# - 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 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 next sibling parent 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
prev sibling 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 "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
prev sibling next sibling parent 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
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 next sibling 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 next sibling parent "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
prev sibling 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 next 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 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 next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling 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 "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