<p>I have read the official <a href="https://blog.golang.org/strings" rel="nofollow">blog post</a> but I'm not much clearer on the difference? Also when is it better to use one or the other?</p>
<hr/>**评论：**<br/><br/>djherbis: <pre><p>What is it that you're not understanding about the difference? A string is a read-only slice of bytes, but its also a distinct type. </p>
<p>Can you share an example of when you think it wouldn't be clear of which to use? </p>
<p>For the most part choosing which to use is as simple as deciding which section of the stdlib you are working with. If the functions you want to use take strings then use strings, otherwise use []byte. If you need to use both, choose the one which requires the least conversions, and just do string(byteSliceHere) or []byte("string here") to switch between the two.</p></pre>rebelnz: <pre><p>For example when I have to do anything with JSON - however I see what you mean about depending on section of stdlib: json.Unmarshal takes []byte <a href="http://golang.org/pkg/encoding/json/#Unmarshal" rel="nofollow">here</a> </p></pre>Darxide-: <pre><p>I'm pretty new to Go and haven't really thought about how strings work, but I'm guessing strings are a lot like an abstracted way of doing strings like in C. </p>
<p>So example C string:</p>
<pre><code>char s[20] = "Hi this is a string";
</code></pre>
<p>I'm assuming it's similar in Go where </p>
<pre><code>var s [20]byte = "Hi this is a string"
</code></pre>
<p>is the exact same as </p>
<pre><code>var s String = "Hi this is a string"
</code></pre>
<p>the second is just abstracted and contains functions to manipulate the string where as the first does not. - I could be wrong though!</p></pre>karlseguin: <pre><p>biggest difference is that strings are more like slices than arrays and they hold runes rather than bytes.</p>
<p>This might help:</p>
<p><a href="https://golang.org/pkg/reflect/#SliceHeader" rel="nofollow">https://golang.org/pkg/reflect/#SliceHeader</a></p>
<p><a href="https://golang.org/pkg/reflect/#StringHeader" rel="nofollow">https://golang.org/pkg/reflect/#StringHeader</a></p></pre>djherbis: <pre><p>I was under the understanding that the string doesn't actually hold runes, but that runes were decoded from the string which is a read-only slice of bytes. <a href="https://blog.golang.org/strings" rel="nofollow">https://blog.golang.org/strings</a></p></pre>karlseguin: <pre><p>Sure. This might get pedantic, but if you do something like str[2] you'll get the 2nd rune. I'd call the rune-aware nature of strings to be default/normal way strings operate. Is the only time you get the actual bytes (short of unsafe) when casting? </p>
<p>We can at least agree that my wording was poor/bad.</p></pre>djherbis: <pre><p>Yeah, sorry I wasn't trying to get picky about the wording. Was just making sure I had the right idea since the op made mention to the actual memory layout of C strings.</p></pre>djherbis: <pre><p>Missed your question in the middle of this, the only time you get the runes is if you use a for range loop or if using: <a href="http://golang.org/pkg/unicode/utf8/" rel="nofollow">http://golang.org/pkg/unicode/utf8/</a></p>
<p>Doing str[2] will get you the 3rd byte.</p>
<p>For example: <a href="https://play.golang.org/p/1U8LSSSj_e" rel="nofollow">https://play.golang.org/p/1U8LSSSj_e</a></p></pre>djherbis: <pre><p>Go actually makes a distinction between slices and arrays.
<a href="http://blog.golang.org/go-slices-usage-and-internals" rel="nofollow">http://blog.golang.org/go-slices-usage-and-internals</a></p>
<p>In Go it's more like:</p>
<pre><code>var s []byte = []byte("Hi this is a string")
</code></pre>
<p>is <em>almost</em> the same as</p>
<pre><code>var s string = "Hi this is a string"
</code></pre>
<p>They are both essentially a slice of bytes, but Go's typing means that they are not <em>exactly</em> the same, switching between the two requires a type conversion.</p>
<p><a href="https://golang.org/ref/spec#Conversions" rel="nofollow">https://golang.org/ref/spec#Conversions</a></p></pre>
