zlacker

[return to "“Go’s design is a disservice to intelligent programmers”"]
1. barson+Z3[view] [source] 2015-03-25 22:25:44
>>apta+(OP)
His Go is a little disingenuous. This (https://gist.github.com/EricLagerg/105431503d32f18d239b) is almost as short as his D code, and functions the same.
◧◩
2. jff+o4[view] [source] 2015-03-25 22:31:11
>>barson+Z3
It's almost as if, like most people who write articles complaining about Go's lack of "expressiveness" and generics, he took a cursory look at the language, wrote some naive examples that supported his point, and squeezed out a blog post.
◧◩◪
3. waps+le[view] [source] 2015-03-26 00:42:37
>>jff+o4
If the code was equivalent you might have a point. Unfortunately it is not (tokenizing/line scanning vs. copying). One has a shortcut in Go, the other does not.

Would you say that Go is not excessively verbose in non-trivial use cases ? I recently had to sort a struct list in a program. Added lines of code for sorting a single list once : 30. What the ...

◧◩◪◨
4. falcol+3i[view] [source] 2015-03-26 01:38:54
>>waps+le
There's an equivalent method which can be called to read individual lines: ReadLine. There's also join and split methods to more naturally model what the D code is actually doing.

    fileBytes, _ := ioutil.ReadAll(<file>)
    text := string(bytes.Join(bytes.Split(fileBytes, '\n')))
    fmt.Println(text)
> Added lines of code for sorting a single list once : 30. What the ...

Sorting requires implementing three methods, at least one of which is usually given to you for free (Len). A simple case will usually cost about 9 lines of neatly formatted code, 3 if you're not so neat (which the Go sort library does itself).

    func (sl structSlice) Len() int { return len(sl) }
    func (sl structSlice) Less(i, j int) bool { return sl[i].MyKey < sl[j].MyKey }
    func (sl structSlice) Swap(i, j int) { return sl[i], sl[j] = sl[j], sl[i] }
Ultimately, even this isn't a case of verbosity so much as it is not abstracting away the basic sorting functions.
[go to top]