6 ms·

I would actually say it’s the opposite in this case: it’s extremely common in scripting languages for strings to be immutable, mutable strings are usually only

• TkTech 1y ago
  All strings in python are immutable, as an example.
  • masklinn 1y ago
    Also JavaScript.
    • fud101 1y ago
      Java too. Rust has only 99 string types, some of those are immutable also.
      • masklinn 1y ago
        It does not really matter in rust anyway: literals are &’static str so naturally immutable and essentially free, and mutable strings require jumping hoops to share, so it’s hard to unwittingly have one mutate from under you.
      • steveklabnik 1y ago
        Rust the language has one string type: &str The standard library also has String, CString, CStr, OsString, and OsStr. The latter four are for niche situations. 99.9% of the time, it's similar to Java: &str is Java's String, String is Java's StringBuffer/StringBuilder.
        • ameliaquining 1y ago
          I would add Path and PathBuf to that list.
          • steveklabnik 1y ago
            Paths are not strings, that's the whole point!
            • simonask 1y ago
              Well... They're also not _not_ strings. In fact, what a perfect candidate for introducing a special type. :-)
        • shikon7 1y ago
          There is also &mut str. The nice thing about Rust is that the same memory area can be used as a "StringBuilder" with &mut str, and then as a "String" with &str. Once you have a &str reference, Rust statically guarantees that no one else cam mutate it.
          • steveklabnik 1y ago
            Yeah the type is really just str but I didn’t want to get into it. &mut str is kinda weird.
          • simonask 1y ago
            You can't really do anything useful with a `&mut str`. For example, you can't change the length of the string or any characters in the string (without unsafe code). The latter is perhaps surprising, but it's because strings in Rust are always UTF-8, so changing a logical character could imply changing the length of the string, and changing a byte could result in invalid UTF-8.
            • whytevuhuni 1y ago
              You're right, but just to add a bit more to this, you can call make_ascii_lowercase and make_ascii_uppercase on &mut str, which can sometimes be useful.
        • fud101 1y ago
          99.9% of the time rust has 1 string type. The other 0.1% of the time it has 99, got it.
          • steveklabnik 1y ago
            It has two, not 99, with owned and borrowed pairs.
      • ameliaquining 1y ago
        All of those languages except JavaScript have mutable strings; they just have different names and API shapes. Python has io.StringIO, Java has StringBuilder, Rust has String. (JavaScript has less need for this because JavaScript strings are ropes in most widely used implementations, reducing the overhead of concatenation, though the language spec doesn't require this.)
        • masklinn 1y ago
          By your incredible criteria of things being mutable strings if they behave nothing like strings but can produce one, JavaScript absolutely does have a mutable string, it’s called Array. It’s also a mutable integer.
          • ameliaquining 1y ago
            I don't consider JavaScript's Array to count because using it as a mutable string incurs a significant amount of additional overhead, because it has to box every character and check at runtime the type of each element. This is not true of the APIs that I listed.
            • masklinn 1y ago
              Ah yes, arbitrary and capricious goalposts moved randomly as you get unhappy with where your decisions lead. Truly a hallmark of solid thinking.
      • echelon 1y ago
        Rust has one core String type. String &str &mut str &'static str etc. These are just the language semantics. The other string types are non-Rust strings. Filesystem, C strings, etc. You only deal with them in dealing with specific OS and binding interfaces. 95% of the time you'll just be using String.
• superjan 1y ago
  It’s true that many languages have immutable strings, but for a web-focused scripting language it makes sense to default to mutable strings. I think the comment is about that you now need to choose mutable vs immutable, and that is framed as a consequence of broader adoption. Which is a development I have also seen before.
  • empthought 1y ago
    > for a web-focused scripting language it makes sense to default to mutable strings Why do you say that? I would say the opposite.
    • superjan 1y ago
      Because there’ll likely be a lot of string concatenation in a language whose job is to output HTML. Adding a single char to a 1k string will require allocating a modified copy, in mutable strings it’s just appending in a preallocated buffer.
      • stouset 1y ago
        If you are using string concatenation to build HTML in your application layer, you are fundamentally doing it wrong. Ruby isn’t making all strings immutable here. Just string literals. You are free to allocate mutable strings that can be appended to, to your heart’s content. It is extremely rare that modifying a literal is intended behavior, since their contents are permanently persisted throughout the lifetime of your program. With your example, this would be like having one shared global buffer for your final document.
  • ttoinou 1y ago
    Exactly thank you. Not sure why you’re downvoted
  • copirate 1y ago
    > for a web-focused scripting language Ruby is not a web focused scripting language.
• wavemode 1y ago
  Even in C, string literals are immutable, and mutating them is undefined behavior.
• ttoinou 1y ago
  But in the syntax of scripting language its very easy to create a new string from the old string, destroy old string, replace variable by new string. Which appears mutable from the point of view of the developer
  • SomeoneOnTheWeb 1y ago
    Can't you do the exact same in compiled languages e.g. C or Rust?
    • shikon7 1y ago
      You can, but allocating and deallocating is more tedious without a GC, and if you care about performance, you might want to have mutable strings.
• fiddlerwoaroof 1y ago
  Common Lisp and Smalltalk have mutable strings, I think. So it’s not too surprising that ruby does too, since it was pretty heavily influenced by these languages.
  • rurban 1y ago
    Amongst the lisps, AutoLISP had the one standout feature that was immutable strings by default. Many other lisps wished they could have that too, esp. for the GC.
  • _zagj 1y ago
    Specifically, it's non-literal strings that are mutable. Implementations of either may allow you to modify the literals, but it's likely to break something due to interning. The Common Lisp standard is clear that destructive literal modification is undefined behavior. I believe it's the same in Smalltalk, and I remember you were admonished to never use the direct modification messages (like at:put: or replaceFrom:to:with:) on strings without copying them first.
    • fiddlerwoaroof 1y ago
      I looked around and it seems like Smalltalk didn't make modifying literals UB, the way Common Lisp does but I'm not an expert. Still, for both languages, most implementations won't stop you if you modify string literals, you just have to deal with the consequences.
      • _zagj 1y ago
        I'm too lazy to review the ANSI spec, but the Smalltalk Bluebook VM served as a reference implementation for Smalltalk VMs for years, and it used a method-scoped literal frame for string (and other) literals: > The selectors in parentheses may be replaced with other selectors by modifying the compiler and recompiling all methods in the system. The other selectors are built into the virtual machine. > Any objects referred to in a CompiledMethod's bytecodes that do not fall into one of the categories above must appear in its literal frame. The objects ordinarily contained in a literal frame are > shared variables (global, class, and pool) > most literal constants (numbers, characters, strings, arrays, and symbols) > most message selectors (those that are not special) > Objects of these three types may be intermixed in the literal frame. If an object in the literal frame is referenced twice in the same method, it need only appear in the literal frame once. The two bytecodes that refer to the object will refer to the same location in the literal frame. > Two types of object that were referred to above, temporary variables and shared variables, have not been used in the example methods. The following example method for Rectangle merge: uses both types. The merge: message is used to find a Rectangle that includes the areas in both the receiver and the argument. http://www.mirandabanda.org/bluebook/bluebook_chapter26.html http://www.mirandabanda.org/bluebook/bluebook_chapter26.html
• riffraff 1y ago
  Mutable strings were part of the perl heritage, which was one of the direct ancestors for ruby.