1. 40
  1.  

  2. 5

    I think publishing lists like this is fantastic. :D

    1. 3

      Agreed! These focus largely on memory safety, which is an important concern, but it’s pretty important for anyone designing a language to think in these terms in a whole lot of domains. It’s a lot easier to recognize one’s own ideas as bad when comparing them to someone else’s.

    2. 4

      Next time you’re in a conversation about language design and someone sighs, shakes their head and tells you that sad legacy design choices are just the burden of the past and we’re helpless to avoid repeating them, try to remember that this is not so.

      Just to be That Guy, but this list of anti-features has existed in a fair number of languages for decades. Ocaml has a similar set of anti-features.

      That being said, good work!

      1. 4

        Which makes sense, since Rust has some pretty significant roots in OCaml. (And I note it’s your “language of choice.”)

        But, OCaml doesn’t target the same audience and problem space as Rust. Different set of legacy design choices.

        1. 1

          And I would reckon that a lot of people interested in Rust, who do not write systems software, would be better off with OCaml.

          1. 1

            But, OCaml doesn’t target the same audience and problem space as Rust. Different set of legacy design choices

            Yep, definitely. My comment is pointing out that Rust is not doing anything new in regards to legacy. Hopefully Rust will be able to make such semantics popular.

            1. 5

              I see him pointing out Rust is an example of not repeating legacy design choices. I don’t see anywhere he’s implied that’s an exclusivity or a first. Am I missing something? What are you replying to?

              1. 2

                Some people took it this way on HN as well. It’s really interesting.