D enters Tiobe top 20

[Ola Fosheim Grøstad]

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...