(Wrong) Direction of rust


Continuing the discussion from Rust beginner notes & questions:

Main points from the first linked post are shown below.

The strings discussion generates this subtopic:

Branch to Stream API and types for the first part of the following post

Rust beginner notes & questions
Subsubtopic: dereferencing and strings (especially interop)
Subsubtopic: dereferencing and strings (especially interop)

Rustaceans beware, the discussion here is particular to merits and demerits of Rust, try to stay calm. See To flame or not to flame about any emotional aspects.

Try to reach consensus on the many aspects of Rust that are mentioned here. If a valid demerit is filtered out, create a new linked topic and hammer it out there.


I don’t know what topics are left from the quoted posts that isn’t yet addressed in a parallel thread.

(Thanks for making all these posts by the way, @DrizztVD1 ! :slight_smile: )



I think the discussion of the role of a Rust governing body/individuals was pretty good and as-yet inconclusive. It’s mostly of academic (what would be ideal) interest though since Mozilla probably gets to make that decision.

Here are some points that are unrelated to the whole RustIO discussion afaik:


I agree, governance is still a topic. But I’m not sure what peter_bertok is trying to say. I feel that Rust follows the model of Python (a benevolent dictator for life who mostly follows community consensus). I feel it’s worked very well on the whole for Python, so why not for Rust :slight_smile:

The way I understand it, C/C++ were without governance for a while and the languages stagnated. Then there was a committee that made decisions by majority vote, which worked mostly well. Though I wouldn’t say C++ is going in the right direction. They’re ignoring features that are simple but very useful, like enums, and building all these complicated monster proposals that nobody really understands any more.

Bjarne Stroustrup: Remember the Vasa [pdf]

Bjarne quotes:

We often remind ourselves of the good ship Vasa. It was to be the
pride of the Swedish navy and was built to be the biggest and most
beautiful battleship ever. Unfortunately, to accommodate enough
statues and guns it underwent major redesigns and extension during
construction. The result was that it only made it half way across
Stockholm harbor before a gust of wind blew it over and it sank
killing about 50 people. It has been raised and you can now see it
in a museum in Stockholm. It is a beauty to behold - far more
beautiful at the time than its unextended first design and far more
beautiful today than if it had suffered the usual fate of a 17th
century battle ship – but that is no consolation to its designer,
builders, and intended users.

I don’t understand this, perhaps something else was meant instead of “module systems”? This seems incoherent. Python and Perl themselves have clear governance, it’s not a free-for-all. Of course, anyone can write modules and publish them on their homepage and in repositories.


I think the contention lies with the fact that there are many duplicates of the modules, with more being added daily. The proposal is to try to converge the development of crates in Rust to prevent several incompatible but similar dependencies that can shoot productivity in the foot. Some work has started here on this issue.

Personally, I’ve had problems with matplotlib and Plotly, both being powerful, but divergent modules that take hours(days) to learn. And the documentation and code examples of both were missing.


I’m sorry to hear you had problems with matplotlib; I had a good experience with it. In particular I’ve found it useful to have the examples page which lists the source code for each example.

But matplotlib does have a weird, very imperative API, because it was meant to mimic MATLAB’s plotting API. I’ve not looked at Plotly but I imagine they wanted to create a better API?

I agree that there is value in trying to bring different crates (APIs) together. To me, the forum is a good-enough enabler for this. I felt that @peter_bertok had an utopian view where one API for each concept should suffice, but I don’t think this is realistic for everything.

Are there really considerable amounts of ‘duplicated’ interfaces, besides stream I/O?


The discoverability of good crates enhances productivity. While there is a need to prevent duplication in the future (not necessarily now). The contention is that Rust should have a few excellent crates, instead of several average crates. The problem (in the future), is also that duplicate but incompatible crates cause overhead to the programmer, and the creation of such should be disincentivized as much as is reasonable.

I would go as far as to suggest that the number of similar crates be limited by maintaining a preference list, and a crate can only make it to that list if an RFC is accepted that explains why another similar crate is needed, why it cannot be incorporated into an existing crate, and the current crate is already mature and of excellent standard. This is really also to prevent duplication of discussions/effort for programmers. How to tread the balance between divergence vs convergence is a contentious point. But, my observation is that the status quo is too divergent i.e not enough pressure to contribute to existing crates.


I should note that the divergence in the C/C++ space is huge, due to the lack of package manager. I’d have to trawl the internet, download some old code, figure out how to merge it with the compiler header files, then hope it actually does what it claims.

So, stated differently, how many butterfly FFT crates do we really need? Because I can probably find you 1000 C/C++ ones.


I like this proposal of a preference list. One of the criteria could be that the crate has a bus factor ≥2.


I’m continuing crates discussion at: