3 ms·

> It could get most of the same practical upside of symbols from interned strings I don't think so - unless you mean always interning all strings. The point of

• masklinn 5y ago
  > I don't think so - unless you mean always interning all strings. The point of symbols is you can do a single address comparison. How can you do that if you could have two strings that are the same but have different addresses? You intern all the literals (which includes lexical symbols) and are 99% if the way there.
  • chrisseaton 5y ago
    > and are 99% if the way there I don't understand - if you're not 100% of the way there then you can't rely on address comparison. 1% of your string comparisons would fail!
• samatman 5y ago
  Always interning all strings is what Lua does, and the concept of a symbol in Lua is merely a particular string pattern which the parser will recognize. They aren't syntactically identical, you can replace any .field with ["field"] but you can't say `local ["field"] = value`, but there is no distinction in the types. I get a lot of use out of both of those decisions (immutable strings and string/symbol identity), they work well together, and I'd (much) rather have the problem of string-builders than the problem of tracking references to strings and copying them if I need both the original and revision.
  • chrisseaton 5y ago
    > Always interning all strings is what Lua does That'd be catastrophic for performance in Ruby - every string allocation would always have to be reified, and would always need to access a shared data structure.
    • samatman 5y ago
      I'll take your word for that. It's the opposite in Lua, which is several times faster than stock Ruby. If your runtime takes it as a given that every string will be interned, there are all sorts of assumptions this enables which mutation invalidates.
      • chrisseaton 5y ago
        > If your runtime takes it as a given that every string will be interned, there are all sorts of assumptions this enables which mutation invalidates. Yes but if you're regularly creating strings, which is what Ruby web servers do all the time, then your intern table is going to become a white-hot hotspot, contended by all threads all the time.
        • samatman 5y ago
          That's one way of stating the problem, sure. It's more accurate to say that Ruby has mutable strings as part of its semantics, and that can't be changed, and would interact disastrously with immutability. Languages with immutable strings simply architect a web server around that semantic, the problem you're describing doesn't happen. A mutable string is replaced with (in Lua) a mutable array containing immutable string fragments, which are made into a string using the builtin table.concat.
          • chrisseaton 5y ago
            > A mutable string is replaced with (in Lua) a mutable array containing immutable string fragments, which are made into a string using the builtin table.concat. That's what TruffleRuby does internally! We give you 'mutable' Ruby strings, but really they're made up of fragments of immutable strings.
            • samatman 5y ago
              So it.. isn't catastrophic for performance? Edit: I'm guessing you're saying they're immutable but not necessarily interned. Ok.