The problem with Go it that it is fundamentally non-exciting. It brings very little to the table, when compared to C.
On the top of my head:
- GC (which some people find to be actually a cons)
- Some more modern ammenities for debugging.
- Coroutines (this is really where go shines)
On many other fronts, Go is actually a regression from C, because it favors being "safe" over being expressive. Goodbye macro, pointer arithmetic, etc.
Omitting exceptions is a moronic decision. In a program that does its fair share of I/O, this means that error checking will end up taking a huge % of the code written (easily 30%). It will naturally push people to either eschew error checking, or to write huge methods to dilute the error checking code.
So in the end, I'll use C with a coroutine library. It'll feel (and be) more hackish, but I'll be more productive and my code will be easier to understand.
Now, that's my opinion. Maybe other people have different sensibilities and Go is just fine for them. But I think it's pretty obvious that Go is not right for a lot of people, and nothing's wrong with them. It's unfair to pretend they haven't a point. Go is not for everyone.
They didn't. Go has panic/recover. It isn't idiomatic to expose a panic in a library, but if you know you're going to be doing a lot of error handling, then you can utilize panic/recover to make error handling much terser. I do it frequently when writing parsers[1] or web applications.
Comments
The problem with Go it that it is fundamentally non-exciting. It brings very little to the table, when compared to C.
On the top of my head: - GC (which some people find to be actually a cons) - Some more modern ammenities for debugging. - Coroutines (this is really where go shines)
On many other fronts, Go is actually a regression from C, because it favors being "safe" over being expressive. Goodbye macro, pointer arithmetic, etc.
Omitting exceptions is a moronic decision. In a program that does its fair share of I/O, this means that error checking will end up taking a huge % of the code written (easily 30%). It will naturally push people to either eschew error checking, or to write huge methods to dilute the error checking code.
So in the end, I'll use C with a coroutine library. It'll feel (and be) more hackish, but I'll be more productive and my code will be easier to understand.
Now, that's my opinion. Maybe other people have different sensibilities and Go is just fine for them. But I think it's pretty obvious that Go is not right for a lot of people, and nothing's wrong with them. It's unfair to pretend they haven't a point. Go is not for everyone.
Yes. The OP agrees with you.
They didn't. Go has panic/recover. It isn't idiomatic to expose a panic in a library, but if you know you're going to be doing a lot of error handling, then you can utilize panic/recover to make error handling much terser. I do it frequently when writing parsers[1] or web applications.
[1] - https://github.com/BurntSushi/cif/blob/master/parse.go#L56 (Every panic with a `cifError` will be automatically translated into a regular Go `error` value.)
That's very interesting, thanks!