• Public

  • Public
  • Network
  • Groups
  • Featured
  • Popular
  • People

The point is to indicate thematic divergence. The priorities I had while working on the language are broadly not the revealed priorities of the community that's developed around the language in the years since, or even that were being-revealed in the years during. I would have traded performance and expressivity away for simplicity -- both end-user cognitive load and implementation simplicity in the compiler -- and by doing so I would have taken the language in a direction broadly opposed to where a lot of people wanted it to go. Performance: A lot of people in the Rust community think "zero cost abstraction" is a core promise of the language. I would never have pitched this and still, personally, don't think it's good. It's a C++ idea and one that I think unnecessarily constrains the design space. ... Expressivity: Similarly I would have traded away so much expressivity that it would probably make most modern Rust programmers start speaking about the language the way its current critics do: it'd feel clunky and bureaucratic, a nanny-state language that doesn't let users write lots of features in library code at all, doesn't even trust programmers with simple constructs like variable shadowing, environment capture or inline functions. Ask people who worked on the early compiler what it was like. It was not easy or fun, and I was stubborn about adding cognitive or implementation complexity just to make it a few percent easier or more fun. I didn't mind making users write...