On Thu, 2015-12-10 at 11:16 +0000, Ola Fosheim Grøstad via Digitalmars- d wrote:
> On Thursday, 10 December 2015 at 10:51:00 UTC, Russel Winder wrote:
> > Julia doesn'have that great a penetration in the market compared to Python, R, C++ and Fortran.
> 
> Sure, in day-to-day work people use what they have until they need to start over. How is the landscape going to unfold? What languages would you consider for a from-scratch scientific library? Same thing with Swift, what languages will you consider for cross platform mobile development in a year or two?

Julia clearly has a strong and (relatively slowly) growing community. It will require the "killer app" effect to change it from being a fairly niche language given the state of the R, Python, C++, Fortran establishment.

Clearly Go is biting into the C and Python usage, but I suspect mostly only in networking and networking-related things.

> Interestingly C++'s position has been strengthened within Google in the last few years, according to Chandler Carruth, so it does not look like Go will driven towards replacing C++? But, it probably has a solid position for smaller scale servers. I personally hope Google will adopt Swift. And I think that would be a better strategy for Google than pushing Go, Dart and so on.

C++17 and C++20 are very likely to undermine any move by C++ folk to Rust or D I suspect.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thursday, 10 December 2015 at 12:28:16 UTC, Russel Winder wrote:
> Julia clearly has a strong and (relatively slowly) growing community. It will require the "killer app" effect to change it from being a fairly niche language given the state of the R, Python, C++, Fortran establishment.

Yes, it will certainly take time. I've recently watched some of the videos from JuliaCon2015 and I'm getting this "constructive tinkerer" feeling from them. I'm perceiving the same kind of enthusiasm as you get from fans of SmallTalk, Processing and other "tinkering-languages". Such domain-oriented eco-systems can build very strong communities over time, I think.


> Clearly Go is biting into the C and Python usage, but I suspect mostly only in networking and networking-related things.

Yes, Python is much better for transforming data easily, so I am bit sceptical of Go as a replacement for other languages. Seems to be more of a "narrow" language, like for delivery of dynamic/interactive web content.

> C++17 and C++20 are very likely to undermine any move by C++ folk to Rust or D I suspect.

As long as the message "next version of modern C++ is going to be much better" is being delivered they probably will stick with it... I guess that is the strategy, announce the next version of C++ before the current one is implemented.

And that might also be a reason for people dropping Go. There is just no hope if you are unhappy with the current language.

I think maybe over time some embedded C++ could move to Rust. There seems to be some sporadic efforts to do runtime-less Rust. The language itself doesn't seem to be runtime heavy.

> C++17 and C++20 are very likely to undermine any move by C++ folk to Rust or D I suspect.

So I hope Walter and Andrew will do steps like including vibed in DMD distributive and will focus on Web-assembly. I am not sure that strategy of better integration with C++ is help to get more people interesting in D. It's just like IBM, that added support of Windows apps in OS/2 instead of writing native.

I really hope to see D more high level language instead language concurrent with with came niche with Rust.

On Thursday, 10 December 2015 at 13:31:00 UTC, Suliman wrote:
> So I hope Walter and Andrew will do steps like including vibed in DMD distributive and will focus on Web-assembly. I am not sure that strategy of better integration with C++ is help to get more people interesting in D.

I think it would require making D semantics aligned with C++, rather than trying to align C++ semantics with D. A 50% solution isn't really worth it.

Objective-C++ is a 100% C++ compatible solution. And that really makes a big difference.

On Thursday, 10 December 2015 at 13:31:00 UTC, Suliman wrote:
>> C++17 and C++20 are very likely to undermine any move by C++ folk to Rust or D I suspect.
>
> So I hope Walter and Andrew will do steps like including vibed in DMD distributive and will focus on Web-assembly. I am not sure that strategy of better integration with C++ is help to get more people interesting in D. It's just like IBM, that added support of Windows apps in OS/2 instead of writing native.
>
> I really hope to see D more high level language instead language concurrent with with came niche with Rust.

But here it is also problematic.

D is pretty close in syntax to Java and C#.

Both are now getting AOT compilers as part of their standard toolchains.

Java will eventually get a better story for value types with Java 10.

C# 7 and later are getting features from System C#, the version used to develop project Midori.

Given that one cannot consider a programming language without the eco-system, I don't see the type of customers we work with, switching away from the JVM or CLR.

--
Paulo

On Thursday, 10 December 2015 at 12:24:23 UTC, Russel Winder wrote:
> On Thu, 2015-12-10 at 13:12 +0100, Jacob Carlborg via Digitalmars-d wrote:
>> On 2015-12-10 11:52, Russel Winder via Digitalmars-d wrote:
>> 
>> > But D is a fully compiled language with an AOT compiler. How does a
>> > JIT
>> > fit into the workflow?
>> 
>> REPL, data/config format, perhaps vibe.d diet templates.
>
> So use of D syntax as a language that isn't actually D?

Is PyPy not really Python?

On Thursday, 10 December 2015 at 13:31:00 UTC, Suliman wrote:
> So I hope Walter and Andrew will do steps like including vibed in DMD distributive

Please no.

Not everything has to be in Phobos; this just puts unnecessary pressure on Phobos maintainers to work on vibe.d as well, and it will slow down vibe.d development DRASTICALLY due to the extra scrutiny for Phobos PRs. Not to mention that breaking changes will no longer be able to happen with vibe.d. Also, vibe.d seems to be doing just fine as it is.

On Thursday, 10 December 2015 at 15:25:16 UTC, Jack Stouffer wrote:
> On Thursday, 10 December 2015 at 13:31:00 UTC, Suliman wrote:
>> So I hope Walter and Andrew will do steps like including vibed in DMD distributive
>
> Please no.
>
> Not everything has to be in Phobos; this just puts unnecessary pressure on Phobos maintainers to work on vibe.d as well, and it will slow down vibe.d development DRASTICALLY due to the extra scrutiny for Phobos PRs. Not to mention that breaking changes will no longer be able to happen with vibe.d. Also, vibe.d seems to be doing just fine as it is.

You are right, but maybe at last to merge some common API?

On Thursday, 10 December 2015 at 12:12:28 UTC, Jacob Carlborg wrote:
> On 2015-12-10 11:52, Russel Winder via Digitalmars-d wrote:
>
>> But D is a fully compiled language with an AOT compiler. How does a JIT
>> fit into the workflow?
>
> REPL, data/config format, perhaps vibe.d diet templates.

Like how rdmd simplifies using dmd, you would want something that simplifies things further? Like so that when you run something from rdmd, it doesn't just compile things and then run, it starts running and then JITs what is needed.

I think there definitely would be something convenient about a language that you could easily compile or use like a scripting language without changing the syntax at all.

On 2015-12-10 18:36, jmh530 wrote:

>> REPL, data/config format, perhaps vibe.d diet templates.
>
> Like how rdmd simplifies using dmd, you would want something that
> simplifies things further? Like so that when you run something from
> rdmd, it doesn't just compile things and then run, it starts running and
> then JITs what is needed.
>
> I think there definitely would be something convenient about a language
> that you could easily compile or use like a scripting language without
> changing the syntax at all.

I'm not sure how related rdmd is to the above mentioned features. If one would use rdmd for the above, it would require to compile the code as a dynamic library and the load that. I guess that could be possible.

-- 
/Jacob Carlborg