Golang makes easy things difficult
Jan. 8th, 2016 05:46 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Go claims to have strings. That would be a nice feature except that most of the core library functions operate on byte arrays and you need to make an explicit cast every time you move from strings to byte arrays and back.
Do you want to interpret a boolean as an int? Fuck you.
It is difficult to define complex types such as sets of function references. The syntax that works in a parameter definition produces a syntax error when I try to cast an array. By the way, you need to cast your arrays when you define them because the compiler cannot determine that information from the array's contents.
Error handling is... different. For example, if you wanted to write to a file in any other language you would do something like this:
status = fopen("foo.txt", "w")
or:
try { fopen("foo.txt", "w") } catch e { ... }
In Golang you need to do something like this:
var writer *bufio.Writer f1, err1 := os.Open("foo.txt") if(err1 != nil){ return writer, err1 } tmp2, err2 := io.Writer(f1) if(err2 ! nil){ return writer, err2 } return bufio.Writer(tmp2)
... so you end up with long repeating branches in a function that would be a few lines in any other language.
Do you want to close the file, allow other subprocesses to work on it, and reopen it later for reading? Fuck you.
Have I mentioned that I don't like golang's error handling pattern? I don't like golang's error handling pattern.
Go gets one thing right and that is its goroutines. Parallelization of a function should be as easy as putting the word "go" in front of the function. Other languages should pick up on this.