> It means there is special protection for strings that is not available to anything else
Lots of languages have no C/C++-style const objects yet immutable strings. It's weird to pick on Go specifically for this. (Since it's the JVM model, at this point it may even be a majority of mainstream languages.)
If you mean specifically the panic when modifying a static string, is this not just the default `mprotect` on rodata? You can do that to any memory page you want. It's a feature of the kernel's memory management, not the type system or even the language runtime.
> library-authors get panic reports about immutable byte slices.
I'm really skeptical this happens in any meaningful amount. Go offers the feature to transform a byte slice you know you won't want anymore into a string without a memory allocation; or to pass a string to a function which wants a []byte and will not mutate it, usually to wrap an optimized implementation working on both strings and []byte. Modifying a string's contents is always undefined behavior, even if it doesn't panic immediately - the compiler will assume strings are immutable and make "as if" judgements accordingly.
I'm pretty sure it's the JVM model. Kotlin collections are "immutable" in that they have no mutating accessors, which is not the same thing as a memory region defined to be immutable by the specification which can be relied on to e.g. trivialize certain compiler optimizations. (I plead ignorance about Kotlin Native, maybe it does such things.)
You can also look at what kinds of things are allowed in class constant pools; you will not find any collections.
If you specifically mean RO memory pages, then yes, thats not the same thing. The language and the runtime will enforce collection immutability though, throwing an exception if you attempt to mutate. Poking at the underlying byte code will defeat this, of course.
Lots of languages have no C/C++-style const objects yet immutable strings. It's weird to pick on Go specifically for this. (Since it's the JVM model, at this point it may even be a majority of mainstream languages.)
If you mean specifically the panic when modifying a static string, is this not just the default `mprotect` on rodata? You can do that to any memory page you want. It's a feature of the kernel's memory management, not the type system or even the language runtime.
> library-authors get panic reports about immutable byte slices.
I'm really skeptical this happens in any meaningful amount. Go offers the feature to transform a byte slice you know you won't want anymore into a string without a memory allocation; or to pass a string to a function which wants a []byte and will not mutate it, usually to wrap an optimized implementation working on both strings and []byte. Modifying a string's contents is always undefined behavior, even if it doesn't panic immediately - the compiler will assume strings are immutable and make "as if" judgements accordingly.