
Why Rust is not a mature programming language - DarkCrusader2
https://codecs.multimedia.cx/2020/09/why-rust-is-not-a-mature-programming-language/
======
cormacrelf
The traits section seems to be more a problem of the author seeing object and
classes instead. Calling them traits and not classes should have been enough,
IMO, to dispel that, but it is a common mistake so fair enough. You should
think of them, as the compiler devs do, as Prolog code interpreted at compile
time.

Traits are sets. “Impl” means a type, or any type described by the
constraints, is in that set.

    
    
        trait A {}
        struct S;
        impl A for S {} // S is in A
        impl<T> A for Vec<T> where T: A {} // Vecs of A are also in A
    

Type constraints are a way to use those sets to specify which types are
allowed in which places. The compiler then tries to prove that the types you
do use are in fact in the sets you say they have to be in.

That’s it.

~~~
cormacrelf
On reflection I think they were referring to both traits and trait objects
instead (“Call tables”). I don’t know what more you can ask for than the Rust
Book’s entry on trait objects. Not sure how you get “immature language” from
this page:

[https://doc.rust-lang.org/book/ch17-02-trait-objects.html](https://doc.rust-
lang.org/book/ch17-02-trait-objects.html)

~~~
steveklabnik
Trait objects are kind of a pain and there are some improvements that could be
made there.

Here's a random example: if you want a trait object with more than one trait,
that only works today if one of the two is an auto trait: [https://play.rust-
lang.org/?version=stable&mode=debug&editio...](https://play.rust-
lang.org/?version=stable&mode=debug&edition=2018&gist=49039ad3198d4162eddc932c98a0f50b)

------
Gys
Once I regularly see the bashing of a language I know that language is
generally accepted and therefore mature.

~~~
srgpqt
Counterpoint : V-lang

~~~
edoceo
Wow, first I've heard of this. Looks neat.

Let me save others 6s [https://vlang.io](https://vlang.io)

------
staticassertion
No real argument about this, seems to be essentially true. I just have never
cared about anything in this article while writing Rust. The maturity I care
far more about is "if I want a library is it available, documented, api
stable, and relatively bug free", which Rust does _okay_ at.

~~~
singron
The lack of a language spec hurts, but it's gotten better. E.g. there used to
be no formal rules about what was OK to do in an unsafe block. There was a
general idea that you shouldn't use different mutable references to the same
thing at the same time, but in practice it was hard to tell what that really
meant. Then they came up with Stacked Borrows, which is a formal specification
for exactly that problem. Miri can even interpret your program and dynamically
check that you don't violate Stacked Borrows.

The Go language spec is really awesome, but the core language is so much
simpler, so it was probably a lot easier to come up with. E.g. if the spec
included every detail about escape analysis, pragmas, assembly, and cgo, it
would be significantly longer and more difficult to maintain.

------
jedisct1
In spite of its currently growing adoption, my prediction is that Rust will be
replaced in a foreseeable future.

Rust brought a novel idea to the landscape of programming languages. The
borrow checker is a great invention, and a great contribution to making
applications more secure.

The language itself is way too complicated. The learning curve is steep.
Improvements are made (e.g. lifetime elision) but they don't flatten the
curve.

Macros are very hard to debug and understand. Which is even more of an issue
when they are used by dependencies and something goes wrong. Error messages
don't help. Macros are powerful but can hide too much magic. Plus, they are a
language of their own.

"Why doesn't have this structure any methods?" "Oh, they are hidden in traits,
provided by other crates, themselves leveraging other traits from other
crates". "Still, it doesn't compile. Why?" "Oh, because of that generic that
requires traits from yet another crate that are only available when some Cargo
features has been enabled". Once again, this is difficult to follow and debug.

Zero-cost abstractions are great, but in Rust, they are overused. This makes
the language less accessible, but also constantly causes dependency issues due
to incompatible versions.

Rust is powerful but it is not optimized for developer happiness. Fighting the
compiler brings anger, not joy. Sure, the compiler may have good reasons to
complain. But as a developer, I'm happier and more productive when code
immediately runs, even if that means having to fix bugs later. This is from a
happiness view, not from a security perspective. But eventually, happiness
turns into productivity.

It's too late to fix this. But now that Rust demonstrated that memory safety
and speed were not incompatible, future system languages will feel obligated
to provide the same properties, maybe by using mechanisms similar to Rust.

So, my prediction is that Rust will slowly be replaced by new safe languages
that will be more accessible, more productive, more stable, and bring novel
ideas of their own. But Rust will have made history no matter what.

~~~
0x008
You are, of course, right in many of your points, but we have seen time and
time again that languages are successful for other reasons. It usually is a
matter of opportunity (i.e. it comes with a mature library that solves a hot
problem), not design. However, I am also unsure if rust is in the right spot
to gain wide traction or if it will stay in the Tier 2 of enthusiast, but not
commercially adopted programming languages, like many other great languages of
their times.

------
steveklabnik
Everyone is going to have a different definition of "mature", and that's fine
:) Obviously lots of respect for Kostya. I do think that framing these as
"maturity" is a good framing, that is, fundamentally, he's right. A lot of
this stuff has to do with Rust being so young, and in the future, it will be
taken care of. I would argue that this is a significantly _higher_ maturity
requirement than most people actually need, and that Rust is more mature in
other places and so may be for other people, but that's a different thing.

My take on the state of these issues:

> Rust does not have a formal language specification... I understand that
> adding new features is more important than documenting them but this is
> lame.

Most languages do not. It also really depends on what you mean by "formal."

It's not about being more important, it's that we value stability _very_
strongly, and don't have the ability to document things with the guarantees
we'd prefer. You might call it... not mature enough yet :)

There's been a bunch of movement here, I'm excited to see it continue to
develop!

> Function/method calling convention. ... I’m told that newer versions of the
> compiler handle it just fine but the question still stands

The objection here doesn't have to do with calling conventions, actually, this
is about "two-phase borrowing," described in a series of blog posts ending
here
[http://smallcultfollowing.com/babysteps/blog/2017/03/01/nest...](http://smallcultfollowing.com/babysteps/blog/2017/03/01/nested-
method-calls-via-two-phase-borrowing/)

I believe this will get even better with polonius
[https://nikomatsakis.github.io/rust-belt-
rust-2019/](https://nikomatsakis.github.io/rust-belt-rust-2019/)

Regarding argument evaluation order, technically it is not yet documented
[https://github.com/rust-lang/reference/issues/248](https://github.com/rust-
lang/reference/issues/248) but has been left-to-right for basically forever
[https://internals.rust-lang.org/t/rust-expression-order-
of-e...](https://internals.rust-lang.org/t/rust-expression-order-of-
evaluation/2605/34) and I actually thought that it _was_ documented as such. I
would expect this to shake out the exact same way as struct field destruction
order, that is, something that's been one way for a long time and so we
wouldn't change it even if maybe it's a good idea to.

> Traits... the problem is not me being stupid but rather the lack of formal
> description on how it’s done and why what I want is so hard. Then I’d
> probably at least be able to realize how I should change my code to work
> around the limitations.

Upcasting/downcasting is rarely used, and so has less love, generally, it's
true.

> First of all, bootstrapping process is laughably bad.

So, Kostya acknowledges

> Of course it’s a huge waste of resources for rather theoretical problem but
> it may prove beneficial for compiler design itself.

Which is I think the way most feel about it. _However_ , there is _some_
desire to improve this, for other, related reasons.
[https://matklad.github.io/2020/09/12/rust-
in-2021.html](https://matklad.github.io/2020/09/12/rust-in-2021.html) talks
about some of them.

> Then there’s LLVM dependency.

While this stuff is all true, we wouldn't be where we are without it.
Everything has upsides and downsides.

> And finally there’s a thing related to the previous problem. Rust has poor
> support for assembly.

He mentions asm; we're almost there! It took some time because it is not a
simple problem. At the end of this, we'll have _better_ support than C or C++
according to his metrics; these are not part of the language standard, so give
his previous comments about maturity, I find this one a _little_ weird, but it
is what it is. :)

> There’s also one problem with Rust std library that I should mention too.
> It’s useless for interfacing OS.

Yes, the intention of the standard library is to be _portable_ , so that's not
really a goal.

> But the proper solution would be to support at least OS-specific syscall()
> in std crate

This may in fact be a good idea! I'm not sure how much use it would actually
get.

~~~
lionkor
I agree in general, but I do feel like one counterargument needs to be brought
up:

> Most languages do not (have a formal specification)

Most languages also aren't trying to replace languages that do. C and C++ are
both languages that Rust, afaik rather officially, aims to replace in some
areas. It can be a great language like so many others, but if it wants to
replace these old giants, it needs to have a proper spec, maybe in the form of
an ISO standard. Of course that will come when its time, but thats a good
indicator of when a language can compete as an answer to the question of "what
tech will we use for our next big, important and highly specialized project?".

This is the pertect indicator of it not being as mature as what it aims to
replace.

~~~
weinzierl
I'd argue that when Rust is considered as an alternative in one of the domains
that C and C++ are prevalent today, the fact that it does not have a
formalized spec does actually hurt it today. For example: NVidia evaluated
various languages to adopt for their "Safe Autonomous Driving" project. Rust
was considered but didn't win. One of the reasons was literally:

"Does not have a formalized spec"

See [1] page 35.

[1] [https://www.slideshare.net/AdaCore/securing-the-future-of-
sa...](https://www.slideshare.net/AdaCore/securing-the-future-of-safety-and-
security-of-embedded-software)

~~~
lionkor
The nvidia thing is part of why I wrote my comment, too, yeah. Was really eye
opening to the requirements that some big players have

------
notamy
It's not loading for me, so here's an archive:
[https://web.archive.org/web/20200919120933/https://codecs.mu...](https://web.archive.org/web/20200919120933/https://codecs.multimedia.cx/2020/09/why-
rust-is-not-a-mature-programming-language/)

~~~
nneonneo
The first comment is amusingly prescient:

> Aw, dang it. This post is going to get out and cause this server to crash
> again, isn’t it?

------
rudolph9
Anyone interested in formal language specification should check out
k-framework! This space is pretty mind blowing.

[http://www.kframework.org/index.php/Main_Page](http://www.kframework.org/index.php/Main_Page)

------
chrismorgan
Adding a few more things to Steve’s response:

> _Rust does not have a formal language specification […] A proper mature
> language (with 1.0 in its version) should have a formal specification_

Python doesn’t have a formal specification. It doesn’t even have a _semi_
-formal specification. I would consider Python a proper mature language. (…
even if it doesn’t have 1.0 in its version!)

Some recently-published work in the general direction of formally specifying
Rust behaviour: [https://people.mpi-
sws.org/~jung/thesis.html](https://people.mpi-sws.org/~jung/thesis.html)

> _In Rust it’s undefined because there’s no format specification to tell you
> even that much._

That seems to me an very unreasonable definition of “undefined”. By that
token, _nothing_ in Rust is defined, which renders the term “undefined” devoid
of meaning and completely useless. Rather, the implementation defines the
specification, which, yes, is weaker than a formal specification, but not
_that_ much weaker. (Rust’s stability guarantees do allow it to retcon, but
only if safety is on the line, or sometimes if you can convince people that
affected code probably doesn’t exist, or was wrong anyway. Changing argument
order evaluation in this sort of case would break plenty of real-life code,
and so will never happen.)

> _[…] traits […] the problem is not me being stupid but rather the lack of
> formal description on how it’s done and why what I want is so hard._

I disagree that the lack of a formal description of how it’s done is the
problem, though such a description would certainly help. I feel that the real
problem here is that you’re trying to treat traits as something that they’re
not, trying to do things that you’re used to doing in dynamic/GC languages
that just don’t map to Rust because of it being a thin abstraction over what
can be fastest. Upcasting and downcasting trait objects is _really_ rare,
because other constraints of the language make them just not very useful
operations. The main reason you want those operations in other languages is
inheritance, not interfaces, and Rust doesn’t do inheritance, and traits
aren’t inheritance.

> _rustc problems_

The bootstrapping process is not laughably bad, the developers have merely
prioritised their own ergonomics rather than pandering to making proving a
theoretical problem false easier. Still more, they’ve prioritised actually
_using_ new functionality, which helps make sure that it both works properly,
and is the _right_ new functionality. So I find two or three good reasons for
doing it the way they have, and one weak reason not to do it that way.

The LLVM dependency: I feel that this complaint is more about there being only
a single Rust backend, rather than about the LLVM dependency. This point is
then debatable. Yeah, Rust would be _more_ mature if it had more backends (or
better, more full implementations), but does having only a single
implementation make it immature? Eh. Plenty of mature languages functionally
have but a single implementation.

———

I definitely consider Rust not yet mature, I just don’t think that most of the
reasons in this article are legitimate. I _would_ focus in no small part on
documentation, just not requiring _formality_ of specification or
documentation before I’d consider those parts mature. But note that I said
that I’d consider _Rust_ not yet mature, rather than the Rust _programming
language_. Because in most regards I _do_ actually consider the programming
language itself mature, and a lot of its tooling (more than popular languages
thrice its age), though there are definitely still gaps in both. But the
ecosystem _around_ the programming language, that’s the area where it’s not
yet mature. Rust is much more complex than many languages (e.g. Go), so it
takes a lot longer to fill in the spaces in library availability, and there
are many very significant gaps that haven’t been filled yet. GUI, for example,
is very immature space. Audio is… eh, it’s getting somewhere, but I wouldn’t
call it _mature_. Web is approaching maturity for some sorts of tasks, but is
not generally mature.

~~~
steveklabnik
> The bootstrapping process is not laughably bad, the developers have merely
> prioritised their own ergonomics

Ironically, I would disagree here; the language developers have _not_
prioritized their own ergonomics, which is why building rustc is a big pain.

I do agree that making it easier to bootstrap _in that way_ would not
necessarily help them... there is a sense in which you're right, I just found
the framing kind of funny, since I'd argue the same point but for completely
opposite reasons.

~~~
chrismorgan
Building rustc may be a bit of a pain (big pain? It’s more than five years
since I last built rustc from source, but I don’t recall having any particular
difficulty with it), but I was speaking specifically of the bootstrapping
part, which I don’t feel is at all terrible. Specifically targeting version _n
− 1_ means that you can adopt new language features, which you couldn’t if you
were targeting version 1.0 forever, or writing it in another language.
_That’s_ what I was meaning by prioritising their own ergonomics—allowing them
to use new features. With that clarification, I’m interested in whether you
agree or disagree. You’ve been a lot closer to the action than I have.

~~~
steveklabnik
Yes, I do think you're right about this generally, which is what I was getting
at at the end.

This doesn't have to be all-or-nothing, though, if you check out matklad's
post I linked, he points to a version where the standard library still gets to
use unstable features, but the compiler does not, which is an interesting
hybrid that may retain the best of both.

------
ch_123
I find it odd that inline assembly is considered the sign of a mature systems
language when not even all C/C++ compilers have it (for example, the last I
checked, Microsoft's x86-64 C++ compiler lacks it)

------
ufmace
Well the server for this page seems to be dead. I wonder what language it's
written in? ;)

~~~
steveklabnik
Looks like Wordpress to me.

------
jjpe
The problem with this article is that the first example is wrong, as in it
compiles fine. I could even tell without running it that it would compile.

Therefore the article as a whole cannot be taken seriously, and reflecting
that I stopped reading it immediately after.

~~~
steveklabnik
It used to not work, and it does acknowledge that it does work now. You missed
that since you bounced, which is why it's a good idea to fully digest a thing
before deciding if it's terrible or not.

~~~
gilmi
Let's be real, life is too short to read every article on the internet before
deciding if it's worth your time.

~~~
steveklabnik
It depends on your goals, and yes, I do agree that life is too short to read
everything. But if you don't have the time to fully digest what's written, you
also don't have the time to trash talk it, in my humble opinion. That's what I
mean by "deciding if it's terrible or not," that is, I see a personal
distinction between "did not pique my interest enough to bother" and "this is
actively bad." You have to actually read the whole thing to make the latter
determination, IMHO.

~~~
jjpe
Well in all fairness, I might've kept reading had it not been for that blatant
factual error.

