On 11/4/2019 11:52 PM, drug wrote:
> Yeah. Also some companies try to drop the current language for Rust and then after some time of Rust experience switch back. Considering huge hype about Rust and comparing it to Go it's obviously that something is wrong with Rust adopting.
> I totally agree to Andrei about Rust and I think it is a good but niche language and with abnormal hype.

I'm going to speculate that Rust is a bit like pure functional programming. It's a great paradigm, but is inconvenient for that last mile of the code one needs to write. I've struggled with getting that last mile done with other languages (Pascal), and it would consume an inordinate amount of time.

This is why D has "pure" functions. You can slip in and out of functional programming as you like.

I'm working on an ownership/borrowing system for D. But the idea is it will only be active in functions marked as @live.

On Monday, 4 November 2019 at 10:56:29 UTC, IGotD- wrote:
> On Monday, 4 November 2019 at 09:19:16 UTC, Daniel Kozak wrote:

> A programmer who only used Python before is going to choose D over Rust and that's where the masses are.

I think you are really right, especially with a good framework for example for machine learning.

Alas with a good deep learning D solution, we will for sure use D for that, instead of doing the work in python, and then translating the successful one into C++ for performance and embedding, for example.

On 11/6/19 8:02 AM, Walter Bright wrote:
> I'm going to speculate that Rust is a bit like pure functional programming. It's a great paradigm, but is inconvenient for that last mile of the code one needs to write. I've struggled with getting that last mile done with other languages (Pascal), and it would consume an inordinate amount of time.

I like your simile. Some developers complain that working with hardware in Rust means huge amount of unsafe code. The last mile in Rust can be really difficult.

> 
> This is why D has "pure" functions. You can slip in and out of functional programming as you like.
> 
> I'm working on an ownership/borrowing system for D. But the idea is it will only be active in functions marked as @live.

For example in Rust it's very hard to implement tree where nodes can point to both its parent and children because in trivial case both parent and child node are borrow each other that is impossible in Rust.

On 11/5/19 10:00 PM, user5678 wrote:
> Tiobe... a great indication of how biased we are. When the language they like progress people forget that they've said about 1 million times that the Tiobe index is BS.

I wouldn't say that D community is biased but in general I agree to you.

On Wednesday, 6 November 2019 at 05:02:10 UTC, Walter Bright wrote:
> I'm going to speculate that Rust is a bit like pure functional programming. It's a great paradigm, but is inconvenient for that last mile of the code one needs to write.

Yes, but I guess one could say that for Go as well.

On the other hand, the number of projects in Go seems to taper off, while the number of contributors is steadily increasing. So in the case of Go that might suggest that people  are now able to find libraries that are suitable and start contributing to those instead of creating new ones.  So, Go appears to have found a stable niche where it can become solid. Despite being inconvenient in some ways, and quite frankly, despite missing features that is welcome when writing larger programs.

In the case of Rust, it is expanding, and it seems like people are in the process of figuring out how to best write libraries for it and to figure out where Rust is the best solution.  I would expect Rust to do really well in all larger server scenarios in the long term, where you often deal with many objects, tree-like structures, require reliability and also need memory-efficiency.

I would expect Rust to do less well in audio/video/embedded, unless some really good Rust-frameworks appear that let you do audio/video/embedded in a high level fashion. Which could happen, e.g. if the Firefox team invest in reusable audio/video components for Rust. Swift isn't really a great language for audio/video either (for other reasons), but it works out  because of the frameworks Apple provide as a foundation.

I don't see anything in the Rust semantics that prevents it from becoming a good semi-high-level language for writing applications and servers. It all hangs on whether it eventually provides a good multi-platform framework.


> This is why D has "pure" functions. You can slip in and out of functional programming as you like.
>
> I'm working on an ownership/borrowing system for D. But the idea is it will only be active in functions marked as @live.

The trend is going towards programmers expecting to spend less effort on speccing function signatures and have the IDE/compiler du more of that by static analysis, flow-typing and the like. That is an argument against Rust, but also against @attributes...

On Monday, 4 November 2019 at 10:56:29 UTC, IGotD- wrote:

> Speaking of Rust, I think Rust will remain a niche language because it is a bit too complicated than what benefits it gives. A programmer who only used Python before is going to choose D over Rust and that's where the masses are.

I'm not going to speculate about Rust's future, but that's consistent with my story. I used Rust before using D. Rust had all the hype and D was selling itself as a dialect of C++ in those days, so the decision to go with Rust was easy. It didn't take long to realize that Rust was not going to work. It has a learning curve like Vim. That meant that even ignoring the hideous syntax, which might be better now, nobody I was working with (the Python type of programmer) was ever going to write a line of Rust. It was hard to understand what it brought to the table for most of the programming world.

After trying Go and not liking that either, I decided to give D a try during a free moment one evening, expecting to not spend more than a few minutes on it. What I found was a surprisingly well-designed language that had little in common with C++ other than the common ancestor of C. For anyone looking at compiled languages for speed, D was miles ahead of anything else in terms of the combination of ease of use and features.

On Wednesday, 6 November 2019 at 09:18:58 UTC, Paolo Invernizzi wrote:
> Alas with a good deep learning D solution, we will for sure use D for that, instead of doing the work in python, and then translating the successful one into C++ for performance and embedding, for example.

Out of curiosity, does that mean that you prefer to do the training on your own machines rather than "renting" existing infrastructure (cloud solutions)? Having little experience with deep learning (although some with basic ML), I thought the advantage of using a ready-made like the Python one from Google is that you have a large set of prewritten libraries from both Google and other third party contributors that you can compose?

Also, if you create your own training-environment, you would still have to run it on a cluster with GPUs? Then distill it down into something that can run well on a single CPU/GPU/SoC?

Maybe a framework can do that translation well... but I guess then the better option would be to have a dedicated high level language that translates well to both the training-environment and the final host environment. That seems more reasonable to me?

Or maybe you talk about the initial preprocessing of data? In which case you can do it now by interfacing with Python from D?

On Wednesday, 6 November 2019 at 09:40:29 UTC, drug wrote:
> On 11/6/19 8:02 AM, Walter Bright wrote:
>
> For example in Rust it's very hard to implement tree where nodes can point to both its parent and children because in trivial case both parent and child node are borrow each other that is impossible in Rust.

Trees are like computer science fundamentals and they are located in a wide variety of programs. Having a link to the parent is mandatory for doing a fast sorted walk through the elements in tree. You can do it rust but that means unsafe code and also you cannot use the memory management of Rust. Maybe with a reference counted object it will be easier.

I'm trying to wrap my head around that they created a language that cannot support simple, common and fundamental algorithms used for more than a half of a century. The designers of Rust should have known better.

On Wednesday, 6 November 2019 at 11:43:30 UTC, IGotD- wrote:
> I'm trying to wrap my head around that they created a language that cannot support simple, common and fundamental algorithms used for more than a half of a century. The designers of Rust should have known better.

Depends on what you think Rust safe-mode is. If you view it as high level language then that is OK as it can be done as an ADT. That means you have to create ADTs outside the safe language.

If writing such ADTs are not possible in Rust, then that would be more of a meta-programming deficiency than a type system deficiency (or both).

Reference counting and garbage collection are not alternatives, in the general case... that is way too slow... There are no safe alternatives to Rust's model, in the general case, if you want to allow arbitrary optimizations. Although you can do it in Rusts model with node-ids and indexes, but that is only efficient if you know the upper bound of the number of nodes.

So, while Rust's model isn't perfect, there are no known competitive alternative models that work for graphs on the heap either!

It is waaay to early to judge Rust, they have not hit the end of the road yet.  We'll have to wait and see what their meta-programming ADT  and type-system story evolves into.

On 11/6/19 2:43 PM, IGotD- wrote:
> Trees are like computer science fundamentals and they are located in a wide variety of programs. Having a link to the parent is mandatory for doing a fast sorted walk through the elements in tree. You can do it rust but that means unsafe code and also you cannot use the memory management of Rust. Maybe with a reference counted object it will be easier.

Yes, I wasn't clear on that. Of course I meant it is hard in safe Rust.
Just because in other case there is no reason to use Rust at all I believe

> 
> I'm trying to wrap my head around that they created a language that cannot support simple, common and fundamental algorithms used for more than a half of a century. The designers of Rust should have known better.
>