See the thing is that I agree with most of your statements, so you're really not changing my mind with your arguments.

> Actually companies are becoming more aware that speed is a feature

No. If that were true, Python wouldn't be the fastest growing language, and we'd be hand optimizing everything in assembly and using languages that allowed us to do that (C). That was the entire point I was making. It's why Java won.

I can't figure out if Rust is serious about being a true competitor, or just merely riding the peak on the Gartner Hype Cycle [1].

[1] https://www.gartner.com/en/research/methodologies/gartner-hy...

Python is growing because it's a good scripting language, and there's a need in the ML community for a standard language to write scripts in. The ML community is growing like crazy, thus Python grows. Even though Python is secretly calling Fortran for scipy, or Tensorflow (C++), or PyTorch (also C++), all of which would make good candidates for Rust replacements. So obviously speed is necessary to enable what people are doing in Python.

I make the distinction between script and what we software engineers do, because I had the misfortune of spending half a decade in research doing ML, and those guys are not writing production programs. They're hacking out Jupyter notebooks and writing precariously balanced code that barely works.

That doesn't make Python suitable for large applications. It doesn't diminish the fact that CUDA is growing, SGX is growing, embedded is growing, that we're now unlocking 100G fiber, that we've reached the limits of single core performance, that intel is rolling out 8+ core consumer CPUs. Python is not going to shine for any of these things, but Rust will.

tl;dr: despite being relatively slow Python is a fantastic glue language. Some people thing rust is well positioned to steal Python's dinner.

To be fair, it's much more likely that Julia will be stealing Python's dinner, rather than Rust.

Django is not going to be rewritten in Julia. Neither is Linux going to be rewritten in Python. Different languages have different domains. Some of these comments seem to think all languages is competing in the same domain as if Rust is a direct competitor to Julia or JavaScript.

The context of the comment I replied to was that Python was fantastic glue code _for scientific computing_. Julia won't won't impinge on Django's usage share.

Rust will not steal Pythons dinner, they are used for completely different domains. The comment was saying that Rust might be a realistic alternative to C/C++/Fortran for modules which are not written in Python.

That's not what I said. I said Rust was a good candidate for all the things Python is using to actually do useful work. The underlying libraries written in Fortran, C, and C++.

Don't tl;dr; if you don't know how to r.

Speed matters, it’s just that it’s far from the top priority.

All else being held equal, developers and stake holders will choose the faster language, it just makes sense.

The trick is that speed is typically seen as diametrically opposed to usability, since quite a few languages achieve speed by turning all the safety rails off or existing way too close to the metal for comfort.

If rust could deliver speed without compromising on ease or safety, and I honestly don’t know if it can, then it will absolutely crush the competition.

Safety and speed are the big words on the box. Usability is harder, because it's somewhat a matter of opinion. As someone who has professionally worked with the expression based Haskell, Erlang, Elixir, and OCaml, I find Rust to extremely expressive. If you come from that camp and feel that OOP is a bad toolkit of abstraction and that higher order functions, typeclasses, type parameters, and ADTs are much more powerful, then I think yes, Rust ticks all the boxs.

> If rust could deliver speed without compromising on ease or safety, and I honestly don’t know if it can, then it will absolutely crush the competition.

It has to be more than safe and fast. It has to be a productive language to use. A dev can't sit for 6 months trying to figure out how to write a website, when he can pick up RoR and do it in a day.

That’s why I said “ease” too.

I think Rust should stop looking at C++ as the becnhmark / comparison point for complexity. The expectations that developers have from languages has increased over time, and Rust itself has contributed to raising that bar.

We don’t generally consider other languages as a measure of what complexity is “okay” or something, and are extremely aware of Rust’s complexity. Rust has a lot of requirements that directly lead to a lot of that complexity. But it’s neccesary, not incidental. Or that’s the hope, at least. Rust is also not perfect.

A lot of (but not all) complexity is solved in C/Python/Java by throwing a data structure at the problem. But is it a fair statement to say that not all data structures will work in Rust? Or is it better to say that some data structures work better in Rust than others?

Writing certain data structures in safe Rust can be hard, but not impossible. I’m not aware of any data structures that simply cannot be written in Rust.

Of course, since anything that can be written in C can be written in unsafe Rust.

Though, reading the post above yours, I was thinking more about the use of data structures than the implementation of them. In C++, when faced by the need to efficiently iterate through a data structure in different, incompatible orders, the tool of choice is often just to make intrusive linked lists with multiple next pointers per element. I think I've even once implemented something that was a priority queue (heap), two different lists and a tree at a same time.

While doing that in Rust is by no means impossible, it seems to me that the use of such a structure would be much more clumsy in Rust, to the point where I would try hard to solve the problem in some different way.

The languages are all turing-compatible anyway, so it's not about what can be done, it's about what approaches does the language make easy and promote. Overall I really like the kind of code idiomatic Rust tends to end up like.

Thanks for the thoughtful post. I do have a question, that maybe you can answer?

> The languages are all turing-compatible anyway, so it's not about what can be done, it's about what approaches does the language make easy and promote.

Turing completeness is kinda besides the point. We probably wouldn't be talking about it on HN if it wasn't. :)

I guess what I'm wondering is does Rust encourage simpler but possibly slower data structures, or are there some complex data structures which are simpler to ensure safety than other simpler ones?

In other words, does Rust encourage simplicity at the cost of speed?

As with all performance questions, the answer is “it depends.” For a look into this question, see http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...

Hey thanks for the response.

I'm happy that rust has a good set of performant data structures, but on the other I feel like it's too soon to say Rust is the big winner here as the author does. I've been very skeptical on fantastical claims by language promoters.

But taking the pain out of making common data structures is a good start.

I think if you'll look into the author's credentials he is far from a "language promoter."