Why Rust is not a mature programming language

40 pointsby DarkCrusader2over 4 years ago

11 comments

cormacrelfover 4 years ago

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.<pre><code> 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 </code></pre> 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.

评论 #24528446 未加载

Gysover 4 years ago

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

评论 #24527956 未加载

staticassertionover 4 years ago

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.

评论 #24528348 未加载

jedisct1over 4 years ago

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.

评论 #24532197 未加载

评论 #24529662 未加载

评论 #24529603 未加载

steveklabnikover 4 years ago

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 standsThe 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 <a href="http://smallcultfollowing.com/babysteps/blog/2017/03/01/nested-method-calls-via-two-phase-borrowing/" rel="nofollow">http://smallcultfollowing.com/babysteps/blog/2017/03/01/nest...</a>I believe this will get even better with polonius <a href="https://nikomatsakis.github.io/rust-belt-rust-2019/" rel="nofollow">https://nikomatsakis.github.io/rust-belt-rust-2019/</a>Regarding argument evaluation order, technically it is not yet documented <a href="https://github.com/rust-lang/reference/issues/248" rel="nofollow">https://github.com/rust-lang/reference/issues/248</a> but has been left-to-right for basically forever <a href="https://internals.rust-lang.org/t/rust-expression-order-of-evaluation/2605/34" rel="nofollow">https://internals.rust-lang.org/t/rust-expression-order-of-e...</a> 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. <a href="https://matklad.github.io/2020/09/12/rust-in-2021.html" rel="nofollow">https://matklad.github.io/2020/09/12/rust-in-2021.html</a> 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 crateThis may in fact be a good idea! I'm not sure how much use it would actually get.

评论 #24528453 未加载

评论 #24527970 未加载

评论 #24527997 未加载

评论 #24527917 未加载

notamyover 4 years ago

It's not loading for me, so here's an archive: <a href="https://web.archive.org/web/20200919120933/https://codecs.multimedia.cx/2020/09/why-rust-is-not-a-mature-programming-language/" rel="nofollow">https://web.archive.org/web/20200919120933/https://codecs.mu...</a>

评论 #24528369 未加载

rudolph9over 4 years ago

Anyone interested in formal language specification should check out k-framework! This space is pretty mind blowing.<a href="http://www.kframework.org/index.php/Main_Page" rel="nofollow">http://www.kframework.org/index.php/Main_Page</a>

chrismorganover 4 years ago

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 specificationPython 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: <a href="https://people.mpi-sws.org/~jung/thesis.html" rel="nofollow">https://people.mpi-sws.org/~jung/thesis.html</a>> 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 problemsThe 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.

评论 #24528243 未加载

ch_123over 4 years ago

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)

ufmaceover 4 years ago

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

评论 #24528032 未加载

jjpeover 4 years ago

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.

评论 #24527991 未加载