What are Rust's limitations?


#1

So, a first pass of https://doc.rust-lang.org/stable/book/ suggests Rust is focused on safety; speed; and concurrency but then it doesn’t appear to suggest what Rust’s limitations might be, relative to other languages.

For a noob, could someone suggest whether Rust is necessarily at a disadvantage in some areas?
If you were looking at an ideal polyglot stack, what languages would be the best for what tasks… or is it always very subjective and relative to the application and more often about the skill set of the devs involved?


#2

it does not have the level of monkeypatching supported by languages like Python or Perl.

You cant develop code as ‘fast’ as scripting languages like Python or Ruby.

You will have lots of ‘fun’ trying to get your code to actually compile.

Because it is a new language, people still complain about syntax.

its not webscale. /s


#3
  • It’s usually considered harder to write code that can’t rely on garbage collection, even with the borrow checker helping you.

  • Compared to C++ and especially C, Rust often produces larger binaries and less efficient code; the compiler is also considerably slower. I think Rust can overcome all of these issues in time, but for now…


#4

Regarding code without garbage collection, a lot of code can be much easier when you don’t have to care about memory. However, there is also a respectable class of problems that can be solved with very simple allocation patterns, and for which Rust’s allocation style will lead to much better locality and thus performance.

I’d take this with a grain of salt. My benchmarks support the notion that Rust is usually in the same ballpark as C and can sometimes be even faster (e.g. because of non-aliasing guarantees, easier stack usage, etc).

Compilation times are currently all over the map – there have been reports of minute-long compile runs for less than 3kloc source, but I usually get much less than that. Of course this depends on the contents of the source, so YMMV.


#5

It’s also good to remember that while a crate is Rust’s compilation and distribution unit, there is no need to have a big project in a single crate. Cargo supports using “sub-crates” perfectly well, which can drastically speed up compile times during development.


#6

Oh, and one point I forgot to mention: Optimization levels / options play a big part in the build time equation. If you tell LLVM to fully optimize and switch on LTO, you may grab a coffee before it’s done on any measurably-sized code base.

Luckily, compile times are high on the core team’s agenda, and those of us who are on nightly already seeing improvements on that front.


#7

It’s slower than C++ compilers?


#8

The ergonomy of the code.


#9

We don’t have enough measurements for this conclusion. Fact is, some people have observed large compile times in the past, others (myself included) have fairly fast builds. Since it very much depends on what the code is doing (e.g. macro usage vs. C++ templates) and what the compiler is doing to the code (e.g. inlining, loop unrolling, etc.), there is no general ‘rule’ on what is faster or slower to compile.

From my experience, rustc is certainly slower than go, but usually in the same ballpark as gcc, especially when the latter has to work with C++ code.


#10

I’m not sure about the aliasing part. Citing strncat from Reddit:


#11

Are we talking about the same Rust? I had a feeling Rust’s borrow checker makes aliasing almost impossible, unless you really want to implement one with unsafe code.


#12

Aliasing is very possible in Rust, but aliasing immutable pointers is not possible in (safe) Rust.


#13

OK, let me state my phrase another way: it’s (almost) impossible to make unsafe aliasing in safe Rust code.


#14

Even if we discount aliasing (btw. a lot of C code gets by with __restrict anyway), Rust still has some benefits when it comes to concurrency that C and C++ struggle to match.


#15

at the time of the question one can state only one thing about Rust - it is complex, much more then old good C. It introduces some notions that do not organically coexists with well known ones…(so one can expect some changes in the language) for good or for not good we shell see.


#16

I disagree. This would be true only when you look at the language alone. But the set of language plus all the implicit “you have to do X, don’t do Y, always check Z” is just as complex in C. In Rust, the language and compiler take over a lot of these rules, and enforce them.


#17

:slight_smile: stdsync, you are at your rights… but you consider Rust as "of language plus all the implicit “you have to do X, don’t do Y, …” on contrary i look on Rust as language +“systems programming language that runs blazingly fast, prevents nearly all segfaults, and guarantees thread safety”-that is declared official position…- and yet see no much of the declared in the reality


#18

No, that’s what I consider C.

Well, I haven’t seen a segfault with Rust so far, for example, and neither a crash/undefined behaviour due to wrong object sharing across threads. As for speed, there is certainly some potential for more optimization.


#19

In Rust, you cannot do:

struct Point<S>(u8, S);

#20

@Binero Yes you can.