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 :( ...

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

> 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

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.

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

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.

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.

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

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/

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.