1. 49
  1.  

  2. 24

    Ha, so I guess this is going around the link aggregators now. As I posted elsewhere, just a reminder that this is a personal list and you are free to disagree with my thoughts. My intention was to give some honest thoughts, in the hope that it might spark ideas and thoughts, either for people working on Rust, or on newer languages.

    1. 11

      Pretty sure it started here first: I saw you liked my gist, looked at your gists, and posted here. Now I see you’ve linked to hn and that too was posted 3 hours ago, just after I posted :p

      1. 3

        Hah, so that’s how it happened. Glad you found it interesting enough to post!

    2. 6

      These are some nice reasons I haven’t really seen others mention :o

      1. 6

        I mean, it’s more well thought out than most complaints about Rust!

        1. 11

          brendanzab did a lot of work on formative crates in the Rust gamedev/graphics ecosystem (gfx, cgmath) as well as lang-dev tools (the delightful codespan and codespan-reporting). He knows what he’s talking about. <3

          1. 15

            Heh, thanks. Yeah I’ve been using Rust for…. ack, just on 10 years at this point. If you want some amusement this is one of my first public commits using rust. It’s also pretty amazing that while I’ve been goofing around with Rust for this long, there’s so many newer people who are far more knowledgeable and skilled at Rust than me. I was more just lucky to be there pretty early on and silly enough to give it a try at the time. And even then I’m finding a bunch of fascinating history from before my time as well looking through some of the older commits to the Rust repository and discussions from pre-0.4.

            1. 1

              oh heck I’d forgotten you were here

            2. 9

              Oh, btw, re. the graphics stuff, kvark did almost all of the work in getting gfx-rs up to something usable and building a community around it. I just made the initial repo and had some half baked ideas for a graphics API abstraction layer. Many of the bad design decisions I made early on had to be undone over years by kvark and the gfx community to get the Rust graphics ecosystem to where it is today. So yeah, I did some early work on wrapping libraries and stuff, but others have done far more hard work over the years to build a viable ecosystem around Rust for games and graphics programming. Just think it’s important to point out!

        2. 6

          I believe “allowing semicolons to be omitted after some expressions, like match, if/else, and if.” is more a consequence of blocks being values, and if you don’t place a semicolon then the last value is the final value of the block, whereas if you do place a semicolon, the block value becomes ().

          This is a thing you can run into all the time with smaller functions where you are just relying on “return the final value”, but you put a semicolon at the end of the line (like every line before it) and it decides you didn’t want to return the last value. I really like blocks being values, but the semicolon behavior feels like a real anti-feature to me (though there’s maybe some deep reason why this is done that

          1. 1

            I think what the author is complaining about is that you don’t need to put a semicolon after an if block even if you want to ignore its value, which is inconsistent.

            if true {
                x = 1;
            } else {
                x = 2;
            }; // this semicolon is not needed
            x = 3;
            
          2. 4

            One of the problems will go away soon: type ascription will be removed. https://github.com/rust-lang/rfcs/blob/master/text/3307-de-rfc-type-ascription.md (It’s a nightly feature that hasn’t seen work for years, so no one uses it, but it trips error diagnostics)

            I actually agree with a lot of those grievances - it’s an indiscriminate, unweighted list and while there’s a lot in it that I would not see as serious, I specifically agree with all the places that point to lack of polish.

            1. 2

              Except that type ascriptions would allow for easier steering of the type inference logic in long chains of iterators. Currently, we’re forced to put type declarations in few very specific places where the language allows us to insert a them. What would be a better UX is to allow for putting them where it makes it easiest to read the code later.

            2. 4

              Re: async/await splits the ecosystem. Keyword Generics Initiative is trying to address it. I agree it is a big problem.

              1. 4

                NLL has access to tricks that are not expressible in type system, making it impossible to factor out code in some cases.

                Yeah, that would be great to fix. There’s a proposal for view types.

                1. 4

                  Blog post says “This is not a proposal”

                  1. 6

                    I’m proposing this and you can’t stop me!

                  2. 1

                    Oh wow cool! That looks really useful!

                  3. 3

                    You can’t run broken Rust programs (translating compile time errors to runtime errors).

                    Feels like there needs to be a swing back toward dynamic or gradual typing. I have gotten good mileage out of gradual typing with MyPy, although performance is still a big problem.

                    One of the Rust core devs is experimenting with a language with dynamic semantics first: https://dada-lang.org/docs/about (i.e. to solve precisely this problem – you can run broken programs)


                    A bunch of these criticisms fall under “biformity” (which as far as I can tell is a new word, but seems like a good one for the problem)

                    https://hirrolot.github.io/posts/why-static-languages-suffer-from-complexity#

                    e.g. metalanguage vs. language, and async vs. sync. Also “shadow language”: https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.html

                    1. 3

                      In what situations would one benefit from running a program that contains type errors?

                      1. 3

                        For me the interest is in experimentation and exploration during development. Instead of getting everything to line up exactly, before you can run the program, you can still give it a whirl just to see what happens, even if it crashes. I find myself doing this anyway by commenting out broken stuff and putting a todo!() in its place - would be great if the compiler could handle this for me.

                        1. 1

                          Anything where you don’t yet understand the data or the problem. This arises in basically every programming domain, but to give a few examples, I’d say “data science”, experimental science, and reverse engineering. Or just “business”, which in its best forms are like science.

                          Often the easiest way to understand the DATA is to write CODE. But that does not imply having types.

                          I wrote a lot about that here:

                          https://www.oilshell.org/blog/2022/03/backlog-arch.html#tradeoffs-between-dynamic-and-static-types-faq

                          It’s in very condensed FAQ and link-rich form. I would emphasize the comments by Don Syme, designer of F#, a typed functional language inspired by OCaml. F# is about programming with DATA and functions, not with types, or at least not putting types first.


                          For a very concrete example, try writing down an AST (type definition) for the language of $# ${#} ${##} ${###} ${####} in bash without writing any code. From experience I’d say that it’s hard to get this right “all at once”, and experimenting with the data dynamically, over time, is the best way to get it right.

                          The Five Meanings of #. And What Does ${####} Mean?

                          There are dozens of other examples like this from bash/Oil, including some that came up this year and last.

                          Another concrete example is from some of the “Rust vs. Zig” links – i.e. dealing with the reality of hardware pins, which are not modeled by a type system. They are “reality”.

                          Types are a map or model for reality, not reality itself :) Insisting that everything must be typed before you can run it is very limiting

                        2. 2

                          Feels like there needs to be a swing back toward dynamic or gradual typing.

                          Yep! There’s been lots of good, practical progress made in static type systems the last decade or so, and for a while it looked like we’d maybe be able to say “why do we need dynamic typing at all, we can do whatever we want with static typing”. Now we’re hitting the limits of that spurt of progress, in the form of type systems that can express most things we’d want but are complex enough to be either be super inconvenient or outright undecidable. It’s probably time for the pendulum to start swinging the other way for a while, as it did when V8 was first released and it looked like we could make JIT’s so fast we could say “why do we need static typing at all, we can do whatever we want with dynamic typing”.

                          1. 2

                            True, I have seen a disheartening amount of “why do we need dynamic typing at all?” lately… Our field has a short memory.

                            The shortest answer I give now is to imagine if the entire Internet was a typed system. If you can’t see the problems with that, then you don’t understand type systems or software very well :)

                            Basically at a certain scale, you always need dynamic typing. And all type systems are domain-specific. I framed it in this post as fine-grained types vs. coarse-grained “waists”.

                            https://www.oilshell.org/blog/2022/03/backlog-arch.html#tradeoffs-between-dynamic-and-static-types-faq


                            But I also do remember some people saying that “JITs make dynamic languages fast enough”! They can recover the types! Which turned out not to really be true.

                            So yeah unfortunately it’s a bit like politics – the extreme positions tend to get magnified, whereas the truth or most effective paradigm is somewhere in between, and depends on the situation. And people can learn a lot from each other, and from history ! :-)

                        3. 3

                          How not to throw the baby out with the bathwater?

                          Not too long ago, PHP, Ruby, Perl, and Python were fighting over scripting language dominance. The strategy employed was, er, aggressive research. When a language learned tuple unpacking, and it was good, everyone grafted into their languages. Even today, one reaches for an itertools clone in any language.

                          I can certainly see taking some parts of RustDoc and perhaps much of Cargo. Heavy items could be rethought, such as the borrow checker, premature metadata removal, and unfortunate mini-languages. What would be survive from Rust into a new language?