View mode: basic / threaded / horizontal-split · Log in · Help
January 21, 2013
Re: D popularity
On Monday, 21 January 2013 at 16:14:45 UTC, H. S. Teoh wrote:

The only thing holding me back from D is that it is unreliable. 
I'm not just talking about bugs in Phobos (which can easilly 
found and/or fixed).

I'm talking about all the unreliable voldemort structs, the 
context pointers, the delegates, the destructor sequences, memory 
management and whatnot.

I can see that these issues are being fixed and worked on, but 
today, I would NEVER even dream of using D in a professional 
project.

The only way for that to work would be to use a "restricted D": 
No non-static structs, no allocating delegates etc. It's a hard 
sell to management.

I use it at work to quickly deploy helper scripts, because it is 
so easy, and I know what I'm doing, but it stops there. It HAS to 
stop there :( ...
January 21, 2013
Re: D popularity
On Mon, Jan 21, 2013 at 05:32:12PM +0100, monarch_dodra wrote:
> The only thing holding me back from D is that it is unreliable. I'm
> not just talking about bugs in Phobos (which can easilly found and/or
> fixed).
> 
> I'm talking about all the unreliable voldemort structs, the context
> pointers, the delegates, the destructor sequences, memory management
> and whatnot.

Oh? What's so unreliable about delegates? I find that they work quite
well in general.

But yeah, anything involving dtors is treading on a minefield. As is
structs with hidden context pointers. It was presented in a very
attractive way in TDPL, but given the treatment of structs as value
types ("glorified ints" as TDPL puts it), having hidden context pointers
involving them is a dangerous game.


> I can see that these issues are being fixed and worked on, but today,
> I would NEVER even dream of using D in a professional project.
> 
> The only way for that to work would be to use a "restricted D": No
> non-static structs, no allocating delegates etc. It's a hard sell to
> management.

I don't find the need to use non-static structs that often, actually.
Delegates, yes, but I haven't found any showstopper issues with them
yet.


> I use it at work to quickly deploy helper scripts, because it is so
> easy, and I know what I'm doing, but it stops there. It HAS to stop
> there :( ...

What I find frustrating with D is that most features work extremely well
when used in isolation, but put them together with each other, and
suddenly you're in untested territory filled with bugs and obscure
corner cases with buggy behaviours.


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce
January 21, 2013
Re: D popularity
> Oh? What's so unreliable about delegates? I find that they work 
> quite
> well in general.

This for example:
http://d.puremagic.com/issues/show_bug.cgi?id=5710
January 21, 2013
Re: D popularity
On Monday, 21 January 2013 at 17:56:05 UTC, H. S. Teoh wrote:
> On Mon, Jan 21, 2013 at 05:32:12PM +0100, monarch_dodra wrote:
>> The only thing holding me back from D is that it is 
>> unreliable. I'm
>> not just talking about bugs in Phobos (which can easilly found 
>> and/or
>> fixed).
>> 
>> I'm talking about all the unreliable voldemort structs, the 
>> context
>> pointers, the delegates, the destructor sequences, memory 
>> management
>> and whatnot.
>
> Oh? What's so unreliable about delegates? I find that they work 
> quite
> well in general.
>
> [SNIP]
>
> T

I've stayed away from them mostly, so I may be unfair, but I'm 
mostly thinking about delegates that reference external data via 
context pointers.

Come to think about it, everything I dislike about about D always 
boils down to "context pointer". That thing is so scary unsafe, 
and can so easily back fire on you :(

I don't have the hindsight yet to be allowed to declare it was a 
terrible idea, but that's what I'm thinking right now.

Heck, I'm kind of wishing we had a compiler switch to ban and/or 
warn on such usage. Or at least, make them explicit opt-ins for 
crying out loud.
January 21, 2013
Re: D popularity
On Mon, 21 Jan 2013 09:54:59 +0100
"deadalnix" <deadalnix@gmail.com> wrote:
> 
> We move from ruby on rail to Node.js for scalability reasons 
> !!!!!!

I take it this "scalability reason" is to avoid scalability?

You should to read Ted Dziuba's "Node.js is Cancer", he explains it
better than I can:
(He's destroyed all his good older posts, but I managed to save this
one from a cache:)
https://semitwist.com/mirror/node-js-is-cancer.html
January 21, 2013
Re: D popularity
On 01/21/2013 07:09 PM, monarch_dodra wrote:
> On Monday, 21 January 2013 at 17:56:05 UTC, H. S. Teoh wrote:
>> On Mon, Jan 21, 2013 at 05:32:12PM +0100, monarch_dodra wrote:
>>> The only thing holding me back from D is that it is unreliable. I'm
>>> not just talking about bugs in Phobos (which can easilly found and/or
>>> fixed).
>>>
>>> I'm talking about all the unreliable voldemort structs, the context
>>> pointers, the delegates, the destructor sequences, memory management
>>> and whatnot.
>>
>> Oh? What's so unreliable about delegates? I find that they work quite
>> well in general.
>>
>> [SNIP]
>>
>> T
>
> I've stayed away from them mostly, so I may be unfair, but I'm mostly
> thinking about delegates that reference external data via context pointers.
>
> Come to think about it, everything I dislike about about D always boils
> down to "context pointer". That thing is so scary unsafe, and can so
> easily back fire on you :(
>
> I don't have the hindsight yet to be allowed to declare it was a
> terrible idea, but that's what I'm thinking right now.
>
> Heck, I'm kind of wishing we had a compiler switch to ban and/or warn on
> such usage. Or at least, make them explicit opt-ins for crying out loud.

That does not answer the question.
January 21, 2013
Re: D popularity
On Mon, 21 Jan 2013 13:27:48 -0500
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 21 Jan 2013 09:54:59 +0100
> "deadalnix" <deadalnix@gmail.com> wrote:
> > 
> > We move from ruby on rail to Node.js for scalability reasons 
> > !!!!!!
> 
> I take it this "scalability reason" is to avoid scalability?
> 
> You should to read Ted Dziuba's "Node.js is Cancer", he explains it
> better than I can:
> (He's destroyed all his good older posts, but I managed to save this
> one from a cache:)
> https://semitwist.com/mirror/node-js-is-cancer.html
> 

Also, FWIW, while most of that sounds like it would also apply to
Vibe.d, it's drastically mitigated in Vibe.d's case because:

A. Unlike Node.js, Vibe.d I/O will automatically trigger a fiber switch
to a different request while the I/O, purely behind the scenes,
completes asynchronously.

B. Vibe.d uses a real language instead of requiring your server to be
written in a toy language that thinks it's ok to force every f*@^ing
variable in a "scalable" program to be an associative array of
Variants, whether they need to be or not.

The *one* thing in that guy's article that I admit I don't really buy
is the complaint about it being non-Unixy. Yea, "The Unix Way" is
certainly very good, but when it means shuffling every damn request on
a highly "scalable" server between separate processes, I think it's
perfectly reasonable to bend the rules a bit and not be religious about
the Unix Scripture.
January 21, 2013
Re: D popularity
On Mon, Jan 21, 2013 at 01:27:48PM -0500, Nick Sabalausky wrote:
> On Mon, 21 Jan 2013 09:54:59 +0100
> "deadalnix" <deadalnix@gmail.com> wrote:
> > 
> > We move from ruby on rail to Node.js for scalability reasons 
> > !!!!!!
> 
> I take it this "scalability reason" is to avoid scalability?
> 
> You should to read Ted Dziuba's "Node.js is Cancer", he explains it
> better than I can: (He's destroyed all his good older posts, but I
> managed to save this one from a cache:)
> https://semitwist.com/mirror/node-js-is-cancer.html

Anything that involves running javascript on a *server* cannot possibly
be a good idea. (I mean, I have hesitations about running javascript on
the *client*, needless to say a server...)


T

-- 
The best compiler is between your ears. -- Michael Abrash
January 21, 2013
Re: D popularity
On Mon, 21 Jan 2013 10:49:30 -0800
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Mon, Jan 21, 2013 at 01:27:48PM -0500, Nick Sabalausky wrote:
> > On Mon, 21 Jan 2013 09:54:59 +0100
> > "deadalnix" <deadalnix@gmail.com> wrote:
> > > 
> > > We move from ruby on rail to Node.js for scalability reasons 
> > > !!!!!!
> > 
> > I take it this "scalability reason" is to avoid scalability?
> > 
> > You should to read Ted Dziuba's "Node.js is Cancer", he explains it
> > better than I can: (He's destroyed all his good older posts, but I
> > managed to save this one from a cache:)
> > https://semitwist.com/mirror/node-js-is-cancer.html
> 
> Anything that involves running javascript on a *server* cannot
> possibly be a good idea. (I mean, I have hesitations about running
> javascript on the *client*, needless to say a server...)
> 

Exactly.

Although, I'd be willing to entertain the idea that it's better than
running PHP on a server. Not that that's saying much. Case in point:
https://semitwist.com/articles/
January 21, 2013
Re: D popularity
On Mon, Jan 21, 2013 at 01:47:44PM -0500, Nick Sabalausky wrote:
> On Mon, 21 Jan 2013 13:27:48 -0500
> Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
[...]
> > You should to read Ted Dziuba's "Node.js is Cancer", he explains it
> > better than I can: (He's destroyed all his good older posts, but I
> > managed to save this one from a cache:)
> > https://semitwist.com/mirror/node-js-is-cancer.html
> > 
> 
> Also, FWIW, while most of that sounds like it would also apply to
> Vibe.d, it's drastically mitigated in Vibe.d's case because:
> 
> A. Unlike Node.js, Vibe.d I/O will automatically trigger a fiber switch
> to a different request while the I/O, purely behind the scenes,
> completes asynchronously.
> 
> B. Vibe.d uses a real language instead of requiring your server to be
> written in a toy language that thinks it's ok to force every f*@^ing
> variable in a "scalable" program to be an associative array of
> Variants, whether they need to be or not.
[...]

Yeah, I remember when I was young and foolish, and believed for a short
moment the hype about "dynamic typing" languages. I quickly discovered
that dynamic typing is about the worst plague ever to befall the
programming world as soon as you do anything more than trivial textbook
examples. You have to be constantly vigilant of what types are being
passed around in those variables, because they *might* just happen to be
a string where you expected an int, or an int where you expected an
object! So much code comes crashing down as soon as you hand it a
variable of the wrong type -- which the language explicitly allows you
to, and in fact, which is the language's selling point in the first
place!

So as soon as you move beyond trivial toy programs into real-world
applications, you start feeling the need -- the desperate need -- to vet
each and every single variable passed into your code for their type, and
worse, the exact fields present in an object type, because so much code
depends on variables being, uh, of specific, non-varying types? It's
either that, or constantly checking if something is equal to NULL, or
sorry, I mean, ===NULL (as opposed to ==NULL or =NULL or <>NULL or
====NULL or whatever stupid UFO operator it is nowadays that they use to
patch a type system on top of a broken language). And you quickly find
yourself reimplementing a type system on top of the language, which
*should have provided one in the first place*.

This article cinched it for me:

http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/

(Summary for the tl;dr people: dynamic languages == static languages
straitjacketed with only a single type.)

To conclude, I have to say that so far, the number of times I've
actually *needed* to use a Variant type in my entire career is 1 (out of
the hundreds if not thousands of programs I've written). And that one
time was when I was writing an interpreter for a DSL. How many
interpreters are written in Javascript? I rest my case. :)


T

-- 
Let's eat some disquits while we format the biskettes.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home