9 ms·

Why Rust is not a mature programming language

40 points by DarkCrusader2 6y ago

steveklabnik 6y 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 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/nested-method-calls-via-two-phase-borrowing/ http://smallcultfollowing.com/babysteps/blog/2017/03/01/nest... 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-evaluation/2605/34 https://internals.rust-lang.org/t/rust-expression-order-of-e... 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.
- rightbyte 6y ago
  Ye, I get it why eg. gcc would want to bootstrap itself, but why would you want that in general? Also writing the compiler in its own language to me would seem to just make debugging the compiler much harder ...
  - Jtsummers 6y ago
    Self-hosting is a kind of right of passage for programming languages. Another reason to aim for self-hosting is that it means it's now viable to only use that language, for instance in targeting a new hardware platform, via cross-compilation initially and then self-hosting after. If you don't have a self-hosting language, you either always cross-compile or you port two languages. That is: CRust (a hypothetical C-based Rust compiler) can be made to target XX99 hardware, but in order to run CRust on that hardware you also have to make the C compiler support it. Achieving self-hosting, especially for a language that's targeting low-level capabilities like Rust is, is rather important.
  - estebank 6y ago
    You want to be able to have the trust chain all the way to a well known "good" version. As rustc uses nightly features, the only (reliable) way to get the current version without breaking the chain is to compile every version with the prior version. This can be thought of as an "academic" problem, but some OS vendors do insist on doing this and it is annoying and time consuming. Writing a compiler on its own language has a bunch of benefits. Early on, it let's both evolve in tandem, even before you know what the language itself might be. Having real world experience in a complex enough codebase for the language will inform some design decisions. Things that are hard to do might get ergonomic work poured into, sharp edges tapered. Things that are too hard to implement or that might cause exponential evaluation might be redesigned to allow for a linear algorithm. Later, having the compiler written in its language is beneficial for contributors: people that use the language can jump in and help with the development of the compiler. This has the caveat if any large codebase, but it certainly was my case. I would go as far as saying that I really learned Rust through my rustc contributions. (BTW, doing that has the nice benefit of fixing your mental models if the language to actually match reality, instead of some approximation based on the documentation and observed behavior.) Finally, setting the debugging scaffolding in place will be made a priority in order to debug the compiler, so even early users of the language will benefit of some tooling in that area, however crude it might be at the start.
Gys 6y ago
Once I regularly see the bashing of a language I know that language is generally accepted and therefore mature.
- srgpqt 6y ago
  Counterpoint : V-lang
  - jjpe 6y ago
    Who even has the time to bash that heap of vaporware?
    - omginternets 6y ago
      What makes you say it’s vaporware? Doesn’t it like...exist?
      - jjpe 6y ago
        Pretty much every touted feature is WIP, definitely all the important ones. So yeah no that's vaporware.
        omginternets 6y ago
        Aha, I took their marketing at face value. I never learn... :(
        kortex 6y ago
        Does the Doom demo actually work? That'd be enough for me to call it "not vaporware" by a longshot.
        edoceo 6y ago
        The magic porting of C-Doom to V-Doom is still WIP
        6y ago
ufmace 6y ago
Well the server for this page seems to be dead. I wonder what language it's written in? ;)
- steveklabnik 6y ago
  Looks like Wordpress to me.
jjpe 6y 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.
- steveklabnik 6y ago
  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.
  - jjpe 6y ago
    Or the author should/could improve their writing style. Just a thought. One concrete improvement would be not to moan about things that aren't even true (anymore).
  - bsagdiyev 6y ago
    Thank you! There seems to be a fair amount of people who, when disproving a single thing in a list, seem to take that as reason to invalidate the rest of the list and reaffirm whatever their belief (bias, desire, ??) is instead.
    - jjpe 6y ago
      Like someone said above, who has time to wade through all the verbal feces before deciding that an article is worth the time? In this day and age, you need to decide quickly, or you'll be wasting a lot of your time. Now I don't know about you, but my time is valuable.
      - bsagdiyev 6y ago
        Someone who isn’t ignorant has time to do it. I don’t pass over reading just because I can disprove a single portion. I value my time, but also my ability to digest and understand all viewpoints regardless of my actual views on them. I suggest you try and do the same.
notamy 6y ago
It's not loading for me, so here's an archive: https://web.archive.org/web/20200919120933/https://codecs.multimedia.cx/2020/09/why-rust-is-not-a-mature-programming-language/ https://web.archive.org/web/20200919120933/https://codecs.mu...
- nneonneo 6y ago
  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?
staticassertion 6y 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.
- singron 6y ago
  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.
chrismorgan 6y 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 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.
cormacrelf 6y 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. 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 6y ago
  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 6y ago
    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&edition=2018&gist=49039ad3198d4162eddc932c98a0f50b https://play.rust-lang.org/?version=stable&mode=debug&editio...
rudolph9 6y ago
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
jedisct1 6y 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.
- AstralStorm 6y ago
  I'd like some crack you're smoking. Rust is very well optimized for developer happiness. Built in decent package manager, minor type system annoyances that do not cause real slow down once you get the hang of it. If you say Java is optimized for developer happiness, or worse, Haskell, I'll pass on this cheap trolling attempt. C family is not optimized for happiness at all, not with the hours spent debugging someone else's bugs that break your code. C# is somewhat better Java. Still not good enough. Python and Ruby are, but you'll curse the day you have to performance optimize code. Object Pascal and Visual Basic, but they're rarely used for systems programming nowadays. Perl has not shaken the write only language moniker, even with Perl 6. What are your other suggestions? Smalltalk or Squeak? Lisp? I think the people have spoken on these... JavaScript with all the silent bugs you can make in it, and the awkwardness of the runtime?
ch_123 6y 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)

40 points by DarkCrusader2 6y 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 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/nested-method-calls-via-two-phase-borrowing/ http://smallcultfollowing.com/babysteps/blog/2017/03/01/nest... 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-evaluation/2605/34 https://internals.rust-lang.org/t/rust-expression-order-of-e... 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.

rightbyte 6y ago
Ye, I get it why eg. gcc would want to bootstrap itself, but why would you want that in general? Also writing the compiler in its own language to me would seem to just make debugging the compiler much harder ...
- Jtsummers 6y ago
  Self-hosting is a kind of right of passage for programming languages. Another reason to aim for self-hosting is that it means it's now viable to only use that language, for instance in targeting a new hardware platform, via cross-compilation initially and then self-hosting after. If you don't have a self-hosting language, you either always cross-compile or you port two languages. That is: CRust (a hypothetical C-based Rust compiler) can be made to target XX99 hardware, but in order to run CRust on that hardware you also have to make the C compiler support it. Achieving self-hosting, especially for a language that's targeting low-level capabilities like Rust is, is rather important.
- estebank 6y ago
  You want to be able to have the trust chain all the way to a well known "good" version. As rustc uses nightly features, the only (reliable) way to get the current version without breaking the chain is to compile every version with the prior version. This can be thought of as an "academic" problem, but some OS vendors do insist on doing this and it is annoying and time consuming. Writing a compiler on its own language has a bunch of benefits. Early on, it let's both evolve in tandem, even before you know what the language itself might be. Having real world experience in a complex enough codebase for the language will inform some design decisions. Things that are hard to do might get ergonomic work poured into, sharp edges tapered. Things that are too hard to implement or that might cause exponential evaluation might be redesigned to allow for a linear algorithm. Later, having the compiler written in its language is beneficial for contributors: people that use the language can jump in and help with the development of the compiler. This has the caveat if any large codebase, but it certainly was my case. I would go as far as saying that I really learned Rust through my rustc contributions. (BTW, doing that has the nice benefit of fixing your mental models if the language to actually match reality, instead of some approximation based on the documentation and observed behavior.) Finally, setting the debugging scaffolding in place will be made a priority in order to debug the compiler, so even early users of the language will benefit of some tooling in that area, however crude it might be at the start.

Gys 6y ago

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

srgpqt 6y ago
Counterpoint : V-lang
- jjpe 6y ago
  Who even has the time to bash that heap of vaporware?
  - omginternets 6y ago
    What makes you say it’s vaporware? Doesn’t it like...exist?
    - jjpe 6y ago
      Pretty much every touted feature is WIP, definitely all the important ones. So yeah no that's vaporware.
      - omginternets 6y ago
        Aha, I took their marketing at face value. I never learn... :(
      - kortex 6y ago
        Does the Doom demo actually work? That'd be enough for me to call it "not vaporware" by a longshot.
        edoceo 6y ago
        The magic porting of C-Doom to V-Doom is still WIP
        6y ago

ufmace 6y ago

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

steveklabnik 6y ago
Looks like Wordpress to me.

jjpe 6y 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.

steveklabnik 6y ago
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.
- jjpe 6y ago
  Or the author should/could improve their writing style. Just a thought. One concrete improvement would be not to moan about things that aren't even true (anymore).
- bsagdiyev 6y ago
  Thank you! There seems to be a fair amount of people who, when disproving a single thing in a list, seem to take that as reason to invalidate the rest of the list and reaffirm whatever their belief (bias, desire, ??) is instead.
  - jjpe 6y ago
    Like someone said above, who has time to wade through all the verbal feces before deciding that an article is worth the time? In this day and age, you need to decide quickly, or you'll be wasting a lot of your time. Now I don't know about you, but my time is valuable.
    - bsagdiyev 6y ago
      Someone who isn’t ignorant has time to do it. I don’t pass over reading just because I can disprove a single portion. I value my time, but also my ability to digest and understand all viewpoints regardless of my actual views on them. I suggest you try and do the same.

notamy 6y ago

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

nneonneo 6y ago
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?

staticassertion 6y 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.

singron 6y ago
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.

chrismorgan 6y 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 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.

cormacrelf 6y 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. 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 6y ago
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 6y ago
  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&edition=2018&gist=49039ad3198d4162eddc932c98a0f50b https://play.rust-lang.org/?version=stable&mode=debug&editio...

rudolph9 6y ago

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

jedisct1 6y 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.

AstralStorm 6y ago
I'd like some crack you're smoking. Rust is very well optimized for developer happiness. Built in decent package manager, minor type system annoyances that do not cause real slow down once you get the hang of it. If you say Java is optimized for developer happiness, or worse, Haskell, I'll pass on this cheap trolling attempt. C family is not optimized for happiness at all, not with the hours spent debugging someone else's bugs that break your code. C# is somewhat better Java. Still not good enough. Python and Ruby are, but you'll curse the day you have to performance optimize code. Object Pascal and Visual Basic, but they're rarely used for systems programming nowadays. Perl has not shaken the write only language moniker, even with Perl 6. What are your other suggestions? Smalltalk or Squeak? Lisp? I think the people have spoken on these... JavaScript with all the silent bugs you can make in it, and the awkwardness of the runtime?

ch_123 6y 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)