What is the difference between strings.Split(s, " ") and strings.Fields(s) when splitting a line into words?

## The two functions ```go func Split(s, sep string) []string func Fields(s string) []string ``` Both return a `[]string`, and both are in the `strings` package (with byte-slice mirrors `bytes.Split` and `bytes.Fields`). They answer different questions, and confusing them is one of the most common early Go parsing bugs. ## strings.Split: cut at every separator `strings.Split(s, sep)` finds every non-overlapping occurrence of `sep` and returns the text between the occurrences. Crucially, **it never collapses anything**. If two separators are adjacent, the text between them is the empty string, and that empty string is a real element of the result. ```go strings.Split("a,b,c", ",") // ["a" "b" "c"] — 2 separators, 3 elements strings.Split("a,,b", ",") // ["a" "" "b"] — 2 separators, 3 elements strings.Split(",a", ",") // ["" "a"] ``` The invariant worth memorising: **len(result) == (number of occurrences of sep) + 1**, always, when `sep` is not empty. Two consequences follow directly. - If `s` does not contain `sep` at all, you get a slice of length 1 whose single element is the whole of `s`. Split never reports "not found"; you have to check `len(result)` yourself. - If `s` is the empty string and `sep` is not, you still get a slice of length 1 containing one empty string — **not** an empty slice. Code that writes `for _, f := range strings.Split(line, ",")` on an empty line therefore runs its body once with an empty field, which is a classic off-by-one in a parser. There is one special case: an **empty separator**. `strings.Split(s, "")` splits after each UTF-8 rune sequence, so `strings.Split("héllo", "")` gives one element per rune. That is a distinct behaviour, not a degenerate one. ## strings.Fields: split on runs of whitespace `strings.Fields(s)` is not parameterised at all. It splits `s` around each run of **one or more** consecutive whitespace characters, where whitespace is whatever `unicode.IsSpace` reports — space, tab, newline, carriage return, vertical tab, form feed, and the Unicode space characters. Because a run counts as one separator and leading and trailing runs are simply skipped, the result never contains an empty element: ```go strings.Fields(" go is fun ") // ["go" "is" "fun"] strings.Fields(" ") // [] — length 0 strings.Fields("") // [] — length 0 ``` So `Fields` is the tokeniser you want for text a human typed or that a tool aligned into columns, where the amount of whitespace is presentational and carries no information. ## Choosing between them Ask what an *empty field* means in your input. - In a delimited record — a comma-separated row, a `PATH`-style list, a colon-separated account line — an empty field is data. `a::b` has a genuine empty middle entry, and dropping it silently shifts every later field by one position. Use `Split`. - In free-form text — a log line, a command a user typed, a whitespace-aligned table — runs of spaces are formatting. Use `Fields`. A parser for a message-broker handshake shows both in one file: the frame is a sequence of header lines, and the *lines* are structural (a blank line terminates the header block, so you must not collapse it), while a value that is a whitespace-separated list of supported versions is naturally tokenised with `Fields`. ## When neither fits: FieldsFunc If you want the collapsing, empty-free behaviour of `Fields` but with your own definition of a separator, use `strings.FieldsFunc(s, f)`, where `f` is a `func(rune) bool` that reports whether a rune separates fields. It splits at each run of separator runes and, like `Fields`, returns an empty slice when there is nothing else. The documentation notes that it makes no guarantees about the order in which it calls `f`, and assumes `f` returns the same answer for the same rune every time — so `f` must be a pure predicate, not something with state. ```go isComma := func(r rune) bool { return r == ',' } strings.FieldsFunc("a,,b", isComma) // ["a" "b"] — runs collapsed strings.Split("a,,b", ",") // ["a" "" "b"] — run preserved ``` That pair is the clearest statement of the whole distinction: same input, same separator, different answer, and only you know which one your format means. ## Cost Both functions allocate one `[]string` to hold the result. The substrings themselves are **not** copies: a Go string is immutable, so each element is a view onto the same underlying bytes as `s`. That makes both cheap in bytes but means retaining one small field keeps the whole original string alive.