On Monday, 2 January 2017 at 09:25:28 UTC, ketmar wrote:
> On Tuesday, 5 January 2016 at 12:27:12 UTC, Ola Fosheim Grøstad wrote:
>
> so, mine results are:
>> 1. migrate legacy C++ code bases to D when C++ bindings are final?
> never wanted, never did. accomplished.
>
>> 2. integrate with numerical solutions like TensorFlow?
> never wanted, never did. accomplished.
>
>> 3. create web services with vibe.d?
> never wanted, never did. accomplished.
>
>> 4. run D apps in the cloud?
> never wanted, never did. accomplished.
>
>> 5. run D apps on mobile?
> never wanted, never did. accomplished.
>
>> 6. create runtime less programs (games, embedded)?
> never wanted, never did. accomplished.
>
>> 7. work on the D language/phobos ?
> aliced is alive and kicking. accomplished.
>
>> 8. or something else?
> i have no life, so no. accomplished.
>
>> What other languages do you think you will use or toy with in 2016 and for what purpose?
> none. mine CPU is too weak, it can support only one language

Your doesn't support the Intel Polyglot (TM) technology yet ? I've heard that you just need to put a line of pencil at a particular place to activate it. It creates a jumper with the carbon...the problem is that you need a good magnifying glass to do this, otherwise it activates a PII emulation mode :/

On Monday, 2 January 2017 at 10:03:09 UTC, Basile B. wrote:
> Your doesn't support the Intel Polyglot (TM) technology yet ?
alas. CPU is too old, no fancy tech there. it can hardly cope even with 32 bits.

On Monday, 2 January 2017 at 10:15:28 UTC, ketmar wrote:
> On Monday, 2 January 2017 at 10:03:09 UTC, Basile B. wrote:
>> Your doesn't support the Intel Polyglot (TM) technology yet ?
> alas. CPU is too old, no fancy tech there. it can hardly cope even with 32 bits.

Let's not play the idiots too much...It was a joke of course. All system languages are compiled as bytecode anyway...

That being said, the pencil line trick existed well, it was in the ealy 2000's, on AMD Athlons, but related to OC, not to parallelism.

On Monday, 2 January 2017 at 10:33:40 UTC, Basile B. wrote:
> Let's not play the idiots too much...

T_T

this is the only thing i can do good enough...

On Tuesday, 5 January 2016 at 12:27:12 UTC, Ola Fosheim Grøstad wrote:
> I wonder what kind of programming people plan or _hope_ to use D for in 2016?
>
> Do you have plans to:
>
> 1. migrate legacy C++ code bases to D when C++ bindings are final?
>
> 2. integrate with numerical solutions like TensorFlow?
>
> 3. create web services with vibe.d?
>
> 4. run D apps in the cloud?
>
> 5. run D apps on mobile?
>
> 6. create runtime less programs (games, embedded)?
>
> 7. work on the D language/phobos ?
>
> 8. or something else?

In 2016 I planned to use D to replace some parts of our large monitoring system (Python-based "graphite" metric storage and visualization tools). What I needed was:

1. Language quality - perfect.

2. Fast numeric processing - perfect.

3. Easy deployment - not ok: there is no system-wide packaging for D libraries (I'd like to see debian .deb's for most D third-party libraries, or at least something like 'pip' for python). Correct me if I'm wrong but dub can't deploy system-wide.

4. Lack of some important for me libraries with D-way API (not one-to-one C-wrappers). But this is improved during last year.

5. Easy development - not ok. Correct me if I'm wrong but still no stable support for debugging - demangling problems for OSX out of the box (not sure about Linux). No good plugins for most popular IDE.

6. Lack of some standard libraries - namely libasync. When I use library for my app, which I hope to use for years, I'd like to be sure that library development will not rely on single person motivation, spare time availability, etc.

So, during 2016 I was not ready to use D in production.

In 2017 I hope to see better progress in D weak areas. I hope to continue to contribute to D community and language, and use it for my personal projects.

>
>
> What other languages do you think you will use or toy with in 2016 and for what purpose?
>
> What would it take for you to use D instead, or what changes would be needed for you to move from language X to D?

On Mon, 02 Jan 2017 11:51:59 +0000, ikod wrote:
> 3. Easy deployment - not ok: there is no system-wide packaging for D libraries (I'd like to see debian .deb's for most D third-party libraries, or at least something like 'pip' for python).

Hrm, my workplaces have tended to simply copy binaries to the target system -- with java, fat jars; with C#, zipped up executables and DLLs.

In D, I tend to get statically linked executables, which are pretty convenient on that front.

It's interesting to see that some people use debian packages for that.

> Correct me if
> I'm wrong but dub can't deploy system-wide.

dub fetch --cache=system $PKG

This lets you run `dub run $PKG` as any user.

> 5. Easy development - not ok. Correct me if I'm wrong but still no stable support for debugging - demangling problems for OSX out of the box (not sure about Linux).

I'm similarly intrigued that other people use debuggers. I think I pull one out about once per year. printf debugging is my go-to -- and my primary programming language at work is Java.

On Monday, 2 January 2017 at 17:09:41 UTC, Chris Wright wrote:
> On Mon, 02 Jan 2017 11:51:59 +0000, ikod wrote:
>> Correct me if
>> I'm wrong but dub can't deploy system-wide.
>
> dub fetch --cache=system $PKG
>
> This lets you run `dub run $PKG` as any user.
>

thanks for the info!