On Wednesday, 2 October 2019 at 21:31:17 UTC, Ola Fosheim Grøstad wrote:
>
> Startups is not the best canary as startups have less risk-aversion and technology choices are more influenced by the preferences of the initial staff. They usually don't have enough experience with the task at hand when they start out to properly evaluate the tradeoffs, although since they often are cash-restricted they might go with what they think is the cheaper alternative (or "productivity" as you mentioned). How that works out is difficult to assess. No (sane) company will speak in negative terms about their tech-choices publicly of course, as it would undermine themselves in terms of PR. Thus it is also very difficult to assess what they say (they tend to speak positively about the tech they choose) and one has to assess how they expand into the tech platform as time goes on.

True, true. We never hear about "X dropped D", it's more like "X has command line tool in D now!" Wow! ;) But now that you say that, that might also be the reason for the "Everything's grand, would you PFO !" posts on this forum by people who built their organization / product around D. What if potential investors or clients hear that the technology they're using doesn't scale very well - "scale" as in expansion? The initial "advantage" might come back to bite them once they wanna scale up.

As for the big players, I can imagine that they like to play around with D to develop prototypes fast, and then see what other languages they can use to implement the real-world application. A language with a proper and healthy ecosystem. Python is often used for prototyping too, and then the real app is written in C++. This begs the question, is D becoming a native Python?

On Thu, 2019-10-03 at 08:20 +0000, Chris via Digitalmars-d wrote:
> […]
> language with a proper and healthy ecosystem. Python is often
> used for prototyping too, and then the real app is written in
> C++. This begs the question, is D becoming a native Python?

Wasn't one of the starting points of Nim to be a native Python? (In the same way Crystal is a native Ruby.)

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Thursday, 3 October 2019 at 09:03:10 UTC, Russel Winder wrote:

>
> Wasn't one of the starting points of Nim to be a native Python? (In the same way Crystal is a native Ruby.)

With the difference that Nim has the potential to become a native Python with all that's involved, i.e. rich ecosystem a la Python. But I think it can become much more than that. If you can compile it to C libs then it can become part of many things (mobile, embedded, gaming etc.)

Personally, I'd love to see scientists and the like to use Nim instead of Python so you can use their code for production (more or less) immediately.

On Thursday, 3 October 2019 at 09:13:37 UTC, Chris wrote:
> On Thursday, 3 October 2019 at 09:03:10 UTC, Russel Winder wrote:
>
>>
>> Wasn't one of the starting points of Nim to be a native Python? (In the same way Crystal is a native Ruby.)
>
> With the difference that Nim has the potential to become a native Python with all that's involved, i.e. rich ecosystem a la Python. But I think it can become much more than that. If you can compile it to C libs then it can become part of many things (mobile, embedded, gaming etc.)
>
> Personally, I'd love to see scientists and the like to use Nim instead of Python so you can use their code for production (more or less) immediately.

Problem is also that people using python don't want to be programmers... they just do stuff in python, and sometimes these stuff become mainstream. So if the idea is to say "use Nim instead of python" you basically kill the "why" the python stuff started being widely used and developed. You fallback in the "no-way" again.

I've observed this again two days ago where the UI of for a command line app required python-qt. The application could have been made in cpp, easily, but you know the authors just wanted to make their stuff...but now this ui is available on most linux distribs, no matter the way it's made.

On Thursday, 3 October 2019 at 09:36:17 UTC, LocoDelPueblo wrote:
>
> Problem is also that people using python don't want to be programmers... they just do stuff in python, and sometimes these stuff become mainstream. So if the idea is to say "use Nim instead of python" you basically kill the "why" the python stuff started being widely used and developed. You fallback in the "no-way" again.
>
> I've observed this again two days ago where the UI of for a command line app required python-qt. The application could have been made in cpp, easily, but you know the authors just wanted to make their stuff...but now this ui is available on most linux distribs, no matter the way it's made.

You have a point there. But the good thing about Nim is that you can generate C, C++ and Objective-C:

https://nim-lang.org/docs/backends.html

This can be done by the developer who works on the actual product. The scientist (or whoever develops the prototype) can do so in Python-like Nim, and then the dev ports or incorporates it with a compiler switch. Say you have great code in Nim and you wanna make an Android or iOS app. Just convert it to C or C++ and compile it for the mobile platform. I've never tried this in practice, but it sounds promising.

On Thursday, 3 October 2019 at 09:49:57 UTC, Chris wrote:
>
> You have a point there. But the good thing about Nim is that you can generate C, C++ and Objective-C:
>
> https://nim-lang.org/docs/backends.html
>
> This can be done by the developer who works on the actual product. The scientist (or whoever develops the prototype) can do so in Python-like Nim, and then the dev ports or incorporates it with a compiler switch. Say you have great code in Nim and you wanna make an Android or iOS app. Just convert it to C or C++ and compile it for the mobile platform. I've never tried this in practice, but it sounds promising.

Not bad at all:

https://nim-lang.org/docs/nimc.html#cross-compilation-for-android

https://nim-lang.org/docs/nimc.html#cross-compilation-for-ios

On Thursday, 3 October 2019 at 07:19:52 UTC, Rel wrote:
> As for startups I really like NoRedInk's story, who started with Ruby and React and eventually gradually switched to Haskell and Elm and never looked back. There are few talks on

That sounds interesting, transitioning to a functional programming setup from Ruby and React. I assume that they use a database backend that works well with FP to then.

On Thursday, 3 October 2019 at 10:15:49 UTC, Chris wrote:
> On Thursday, 3 October 2019 at 09:49:57 UTC, Chris wrote:
>>
>> You have a point there. But the good thing about Nim is that you can generate C, C++ and Objective-C:
>>
>> https://nim-lang.org/docs/backends.html
>>
>> This can be done by the developer who works on the actual product. The scientist (or whoever develops the prototype) can do so in Python-like Nim, and then the dev ports or incorporates it with a compiler switch. Say you have great code in Nim and you wanna make an Android or iOS app. Just convert it to C or C++ and compile it for the mobile platform. I've never tried this in practice, but it sounds promising.
>
> Not bad at all:
>
> https://nim-lang.org/docs/nimc.html#cross-compilation-for-android
>
> https://nim-lang.org/docs/nimc.html#cross-compilation-for-ios

My comment earlier was more on the fact that some said that Nim can be seen as a better python, just like D was sold as a better C or C++. It will work to some extant. But what will work, will it work because of the strategy ?

I think that a good example for D is the TSV tools. It works and is recognized because it's a serious project, tested, benchmarked, etc. I'm not even sure that the company the author works at plays **that** an important role. The titled terminal made in D, also very popular, but made by a non corporate developer tends to confirm this.

The strategy of "Y is a better X" is to make people moving from X to Y. So far in D successes are not movers, it's new projects, corporate or not.

On Thursday, 3 October 2019 at 10:49:47 UTC, LocoDelPueblo wrote:
>
> My comment earlier was more on the fact that some said that Nim can be seen as a better python, just like D was sold as a better C or C++. It will work to some extant. But what will work, will it work because of the strategy ?
>
> I think that a good example for D is the TSV tools. It works and is recognized because it's a serious project, tested, benchmarked, etc. I'm not even sure that the company the author works at plays **that** an important role. The titled terminal made in D, also very popular, but made by a non corporate developer tends to confirm this.
>
> The strategy of "Y is a better X" is to make people moving from X to Y. So far in D successes are not movers, it's new projects, corporate or not.

A big project, say a huge data mining / processing framework, would definitely help Nim and Python programmers are already familiar with the syntax. But there are other reasons why languages become popular. One reason (among many) why even great projects in D are ignored is D's atrocious ecosystem. In Python and Java for example I can download stuff I need, install dependencies (pip and gradle/maven) and that's usually it.

On Thursday, 3 October 2019 at 10:49:47 UTC, LocoDelPueblo wrote:
> The strategy of "Y is a better X" is to make people moving from X to Y. So far in D successes are not movers, it's new projects, corporate or not.

That is an interesting metric. There is at least one larger project moving from Pascal to D, based on what has been stated in public. Although, I guess, most native languages could have been used as the target if you transition from Pascal.