July 09, 2012
"bearophile" <bearophileHUGS@lycos.com> wrote:
> I think Go is meant to be used mostly on 64 bit servers.

There aren't many people using Go on 32 bit systems. That's why there is (was?) a big memory leak on these systems which wasn't caught early on.
July 09, 2012
On Mon, Jul 9, 2012 at 4:24 PM, Stefan Scholl <stesch@no-spoon.de> wrote:
> "bearophile" <bearophileHUGS@lycos.com> wrote:
>> I think Go is meant to be used mostly on 64 bit servers.
>
> There aren't many people using Go on 32 bit systems. That's why there is (was?) a big memory leak on these systems which wasn't caught early on.

There aren't many people using Go, period.
July 10, 2012
Caligo <iteronvexor@gmail.com> wrote:
> On Mon, Jul 9, 2012 at 4:24 PM, Stefan Scholl <stesch@no-spoon.de> wrote:
>> "bearophile" <bearophileHUGS@lycos.com> wrote:
>>> I think Go is meant to be used mostly on 64 bit servers.
>> 
>> There aren't many people using Go on 32 bit systems. That's why there is (was?) a big memory leak on these systems which wasn't caught early on.
> 
> There aren't many people using Go, period.

Don't know about this, but "Programming in Go" is a bad book (talks about OO in Go and the author was clearly paid by number of words) but has a higher ranking on Amazon than "The D Programming Language".

And all the news sites and programmer blogs are nearly silent regarding D.

Maybe this changes after Polanski finishes his movie about D. ;-)
July 10, 2012
Am Sun, 08 Jul 2012 21:51:57 +0200
schrieb "Daniel" <wyrlon@gmx.net>:

> On Sunday, 8 July 2012 at 13:49:50 UTC, bearophile wrote:
> > This seems a bit overkill to me:
> >
> > It's also possible to avoid any type ambiguity by writing integer literals with a suffix. The suffixes i and u are for the types int and uint, respectively: the literal -3i has type int, while 127u has type uint. For the fixed-size integer types, just suffix the literal with the type name: 255u8, 50i64, etc.
> >
> 
> Many good ideas... am just singling out this one, as you seem to be of a different opinion in this particular case... I on the contrary wish D would have taken this route as well, because of the ubiquitous 'auto' and 'implicit template instantiation' features... furthermore vector simd types could also benefit.

Yes, this is the single most important Rust feature to me when typing. I've just had too many cases of mass-casts to ubyte or short where a suffix to the literal would only have cost one or two letters. 255ub = byte, 32000s = short

-- 
Marco

July 10, 2012
On 7/10/12 2:30 AM, Stefan Scholl wrote:
> Caligo<iteronvexor@gmail.com>  wrote:
>> On Mon, Jul 9, 2012 at 4:24 PM, Stefan Scholl<stesch@no-spoon.de>  wrote:
>>> "bearophile"<bearophileHUGS@lycos.com>  wrote:
>>>> I think Go is meant to be used mostly on 64 bit servers.
>>>
>>> There aren't many people using Go on 32 bit systems. That's why there is
>>> (was?) a big memory leak on these systems which wasn't caught early on.
>>
>> There aren't many people using Go, period.
>
> Don't know about this, but "Programming in Go" is a bad book (talks about
> OO in Go and the author was clearly paid by number of words) but has a
> higher ranking on Amazon than "The D Programming Language".

The book was released only in March; newer books usually have their highest rank during their first months. Also, TDPL has a paperback and a Kindle edition, which "compete" in rank with each other.

As an aside, Gedankenexperiment: imagine D were created at Google and Go were created by Walter. How would they have fared? I honestly think things would have been quite, um, different. I believe quite strongly is Go wouldn't have received any attention, and D would have been a riot.

> And all the news sites and programmer blogs are nearly silent regarding D.

I agree that that's a problem, and it starts with us.


Andrei
July 10, 2012
On 10 July 2012 13:35, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 7/10/12 2:30 AM, Stefan Scholl wrote:
>>
>> Caligo<iteronvexor@gmail.com>  wrote:
>>>
>>> On Mon, Jul 9, 2012 at 4:24 PM, Stefan Scholl<stesch@no-spoon.de>  wrote:
>>>>
>>>> "bearophile"<bearophileHUGS@lycos.com>  wrote:
>>>>>
>>>>> I think Go is meant to be used mostly on 64 bit servers.
>>>>
>>>>
>>>> There aren't many people using Go on 32 bit systems. That's why there is (was?) a big memory leak on these systems which wasn't caught early on.
>>>
>>>
>>> There aren't many people using Go, period.
>>
>>
>> Don't know about this, but "Programming in Go" is a bad book (talks about OO in Go and the author was clearly paid by number of words) but has a higher ranking on Amazon than "The D Programming Language".
>
>
> The book was released only in March; newer books usually have their highest rank during their first months. Also, TDPL has a paperback and a Kindle edition, which "compete" in rank with each other.
>
> As an aside, Gedankenexperiment: imagine D were created at Google and Go were created by Walter. How would they have fared? I honestly think things would have been quite, um, different. I believe quite strongly is Go wouldn't have received any attention, and D would have been a riot.
>

D would be in GCC and Go would be trying to baby step over the hurdle and find grip in the GCC community. :o)



>> And all the news sites and programmer blogs are nearly silent regarding D.
>
>
> I agree that that's a problem, and it starts with us.
>

Any future plans on D programming language books?   I must admit I'm more of a Pocket Reference guy though.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
July 10, 2012
Andrei Alexandrescu Wrote:

> On 7/10/12 2:30 AM, Stefan Scholl wrote:
> > Caligo<iteronvexor@gmail.com>  wrote:
> >> On Mon, Jul 9, 2012 at 4:24 PM, Stefan Scholl<stesch@no-spoon.de>  wrote:
> >>> "bearophile"<bearophileHUGS@lycos.com>  wrote:
> >>>> I think Go is meant to be used mostly on 64 bit servers.
> >>>
> >>> There aren't many people using Go on 32 bit systems. That's why there is (was?) a big memory leak on these systems which wasn't caught early on.
> >>
> >> There aren't many people using Go, period.
> >
> > Don't know about this, but "Programming in Go" is a bad book (talks about OO in Go and the author was clearly paid by number of words) but has a higher ranking on Amazon than "The D Programming Language".
> 
> The book was released only in March; newer books usually have their highest rank during their first months. Also, TDPL has a paperback and a Kindle edition, which "compete" in rank with each other.
> 
> As an aside, Gedankenexperiment: imagine D were created at Google and Go were created by Walter. How would they have fared? I honestly think things would have been quite, um, different. I believe quite strongly is Go wouldn't have received any attention, and D would have been a riot.
> 
> > And all the news sites and programmer blogs are nearly silent regarding D.
> 
> I agree that that's a problem, and it starts with us.
> 
> 

It was under my impression that is because whole D thing was badly engineered from the start. Programming work was great, but whole other parts of this en devour are badly played. Just too much messed up priorities.
July 10, 2012
On 7/10/12 10:59 AM, Patrick Stewar wrote:
> Andrei Alexandrescu Wrote:
>
>> On 7/10/12 2:30 AM, Stefan Scholl wrote:
>>> Caligo<iteronvexor@gmail.com>   wrote:
>>>> On Mon, Jul 9, 2012 at 4:24 PM, Stefan
>>>> Scholl<stesch@no-spoon.de>   wrote:
>>>>> "bearophile"<bearophileHUGS@lycos.com>   wrote:
>>>>>> I think Go is meant to be used mostly on 64 bit servers.
>>>>>
>>>>> There aren't many people using Go on 32 bit systems. That's
>>>>> why there is (was?) a big memory leak on these systems which
>>>>> wasn't caught early on.
>>>>
>>>> There aren't many people using Go, period.
>>>
>>> Don't know about this, but "Programming in Go" is a bad book
>>> (talks about OO in Go and the author was clearly paid by number
>>> of words) but has a higher ranking on Amazon than "The D
>>> Programming Language".
>>
>> The book was released only in March; newer books usually have
>> their highest rank during their first months. Also, TDPL has a
>> paperback and a Kindle edition, which "compete" in rank with each
>> other.
>>
>> As an aside, Gedankenexperiment: imagine D were created at Google
>> and Go were created by Walter. How would they have fared? I
>> honestly think things would have been quite, um, different. I
>> believe quite strongly is Go wouldn't have received any attention,
>> and D would have been a riot.
>>
>>> And all the news sites and programmer blogs are nearly silent
>>> regarding D.
>>
>> I agree that that's a problem, and it starts with us.
>>
>>
>
> It was under my impression that is because whole D thing was badly
> engineered from the start. Programming work was great, but whole
> other parts of this en devour are badly played. Just too much messed
> up priorities.

What I meant to say was that we're not writing enough about D, but I'll take a vote of non-confidence over that any day :o).

Andrei
July 11, 2012
>> Short keywords are only important with barebones editors like a default vi.
>> Nobody would use this for real development.
>
> I started I long discussion on Reddit, because I complained that the goal of 5 letter keywords is primitive, and brings back memories of the time the compilers were memory constraint.
...
> As someone that values readable code, I don't understand this desire to turn every programming language into APL.

Short or long, I don't think it matters if the IDE can help you with the long ones. I don't mind typing immutable, once, but if I had to do it 50 times a day? And somehow, even though I have been programming for over 20 years, I still type "reutrn" and "retrun" all the damn time! So "ret" would save me time.

Anyway I think short vs long is much ado about nothing. No one complains that we have to type "int" instead of "integer", after all. Most languages have only a few keywords, which people quickly learn. As long as all the standard library functions are well-named, I don't care about the language keywords.

Actually I think "fn" for functions is great, why?

1. Greppability. With the C syntax there is no way to search for function definitions. Even if we had an IDE to find functions for us, you are not always looking at source code in an IDE (you could be browsing a repository on the web)
2. Easier to parse. When the compiler sees "fn", it knows it's dealing with a function and not a variable or an expression. It seems especially beneficial inside functions, where perhaps X * Y might begin an expression (or is that impossible in D?)
3. Googlability. "function" will find results across all PLs, "fn" will narrow the search down quite a bit if you want to see code in Rust.

These benefits (except 3) all exist for "function" as well as "fn", but while many languages use "fun", requiring "function" for all functions is almost unheard of (at least I haven't heard of it), why? It's too damn long! We write functions constantly, we don't want to type "function" constantly.
July 11, 2012
On Wednesday, 11 July 2012 at 16:45:17 UTC, David Piepgrass wrote:
> Anyway I think short vs long is much ado about nothing. No one complains that we have to type "int" instead of "integer", after all. Most languages have only a few keywords, which people quickly learn. As long as all the standard library functions are well-named, I don't care about the language keywords.

Okay, I actually care a lot, just about the meaning of the keyword and not about whether it's abbreviated. I think D's use of "enum" for "static constant" and "static" for "thread singleton" (and three or four other things) is quite unfortunate, albeit understandable given the C heritage.