Lost a new commercial user this week :(

[Manu via Digitalmars-d]

On 15 December 2014 at 11:29, Dicebot via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote:
>>
>> We were trying to use vibe.d, and we encountered bugs.
>>
>> We were unable to build Win64 code ...
>
>
> Here is exactly your problem - trying to do a web development on Windows :P
> Really I have never understood that counter-productive obsession with a
> habit that makes people differentiate development environments and
> production environments so much. You aren't going to use Windows servers,
> are you?

Okay, you go and tell the CEO of my company that we're switching environments!
We'll need all new software licensing, we'll need to re-jig the
company server and IT infrastructure, we'll also need to retrain ALL
the staff.
Then we'll have to deal with the vast majority of staff who hate
linux, and refuse to work in that environment.

What's our budget for this process? A few million? Plus finding new
staff to replace the ones that quit because they don't like linux.


> Well, that was somewhat off-topic grumpy remark. On actual marketing thing:
>
> In my opinion biggest evangelist mistake everyone makes it trying to
> advertise D for something it simply isn't. Which inevitably fails and leaves
> people extremely frustrated with false advertising, like to remain there
> forever as a prejudice against D. Because you will have a better luck
> torturing kittens than try false advertising and get caught.

Actually, I recommended it because I had had a positive experience
with vibe.d in the past. It seemed pretty solid.
Gotta start somewhere. I've had success promoting D to commercial
users in the past.


> Idea that any D project can compete with node.js in "easy to jump in" domain
> is absolutely ridiculous. Attempting this is just dooming yourself to fail.
> Same is trying to advertise it is stable mature language - reality is it is
> simply not true and people will find out it sooner or later.

Sorry, maybe it wasn't clear, we never tried it out against node.js,
we tried it first, on my recommendation.
When it was rejected, someone else suggested to look at node.js. We
looked at that, it just worked.


> I think trying to sell D should look something like this "Yes, D is horrible
> because of X, Y and Z but here is why it doesn't matter for our case : A, B
> and C". Don't pretend perfection but explain trade-offs.
>
> You won't beat node.js in getting started curve. You won't beat Java in
> designing huge complex systems (well, at least everyone says that). You
> won't beat C in raw low-level performance. But D will easily beat C in
> getting started curve and complex design, easily beat node.js in performance
> and complex design and (not-so-easily) beat Java in performance and overall
> versatility.

We didn't want any of those things from .js though. We're all
low-level/native coders.
We don't have time to debug language and library issues though. If we
didn't have tooling/library issues, we would have been perfectly happy
writing whatever code we needed to do our job.


> Remember the talk by Stephan (http://dconf.org/2014/talks/dilly.html) about
> their vibe.d usage in production and points he has made when comparing vs
> node.js? It was about performance, it was about resource overhead, it was
> about benefits of static type system and horrors of callback hell. It wasn't
> about how vibe.d is more shiny than node.js - and it was good.

Yeah, we weren't interested in literally anything about node.js.
Actually, the concept repulsed us.
We just tried it, and it didn't crash. That is all.

If vibe.d didn't crash, *or* if the debugger actually worked (such
that we could have debugged the crash), then we would have surely
stuck with that.
But we couldn't get behind a solution that was impossible to debug.


> If your colleagues went with node in the end and kept happy with it, quite
> likely they simple don't need advantages vibe.d can give to their project.
> There is no shame in it.

Is not the case. We would have preferred write our code in a native
language, but we don't have working time allocated to debug library
problems with tools that don't work.