5 ms·

> Is it as good as we read here? What are its benefits? Just as importantly, what's bad about it? Or if you don't want to say something like (e.g.) syntax can

by philh 14y ago

> Is it as good as we read here? What are its benefits? Just as importantly, what's bad about it? Or if you don't want to say something like (e.g.) syntax can be "bad", what do you dislike? What changes would you make if you were designing it?

FlyingSnake 14y ago
I was intrigued by it and wanted to learn it for a small web project. I was trying to get an objective view to avoid drinking the kool-aid.
jesstaa 14y ago
The bad parts of Go are mostly the tradeoffs you have to make for a systems programming language. They have benefits but also some unfortunate downsides. Some are just implementation details that will get solved over time. * integers overflow * sharing memory between threads isn't safe * mutable state/ shared state * nil pointers * block scoping can lead to multiple different variables with the same names within a function. Sometimes confusing. * value types limit certain conversions. eg. you can't convert an []int to an []interface{} directly because an int and an interface{} are different sizes in memory.(http://golang.org/doc/go_faq.html#convert_slice_of_interface http://golang.org/doc/go_faq.html#convert_slice_of_interface) * Error handling can become quite verbose if you don't design your code to limit the places errors can come from. * gofmt is awesome, but in some rare situations the default format makes code less clear, so you have to change your style of code to fit the formatting. * 'go get' is awesome, but it's lack of centralisation makes it harder to find the good 3rd party libraries amongst the bad/incomplete ones. * The current goroutine scheduler is really simple and moves goroutines between threads and CPUs. This leads to lots of cache misses, so running on many threads can become slower than running on a single thread.
- peterfunny 14y ago
  "nil pointers" is a tradeoff for you? Block scoping, too?
  - jesstaa 14y ago
    It's possible to never have nil pointer dereferences. But the tradeoff is constructors and some complicated scoping. Block scoping is confusing for many people coming from the dynamic languages where scoping is usually function level.
tutufan 14y ago
No exceptions. Like C, it's not failsafe. That is, if you don't check the error status of (say) I/O operations, you lose.
- Ziomislaw 14y ago
  Well it depends, if you want a feature that is _called_ 'exception', than no, there is none. If you want a feature that allows you to signal and catch errors, than: * you can return Error as the second parameter from a function, * you can panic and later defer a recover call (more info: http://blog.golang.org/2010/08/defer-panic-and-recover.html http://blog.golang.org/2010/08/defer-panic-and-recover.html )

by philh 14y ago

FlyingSnake 14y ago

I was intrigued by it and wanted to learn it for a small web project. I was trying to get an objective view to avoid drinking the kool-aid.

jesstaa 14y ago

The bad parts of Go are mostly the tradeoffs you have to make for a systems programming language. They have benefits but also some unfortunate downsides. Some are just implementation details that will get solved over time. * integers overflow * sharing memory between threads isn't safe * mutable state/ shared state * nil pointers * block scoping can lead to multiple different variables with the same names within a function. Sometimes confusing. * value types limit certain conversions. eg. you can't convert an []int to an []interface{} directly because an int and an interface{} are different sizes in memory.(http://golang.org/doc/go_faq.html#convert_slice_of_interface http://golang.org/doc/go_faq.html#convert_slice_of_interface) * Error handling can become quite verbose if you don't design your code to limit the places errors can come from. * gofmt is awesome, but in some rare situations the default format makes code less clear, so you have to change your style of code to fit the formatting. * 'go get' is awesome, but it's lack of centralisation makes it harder to find the good 3rd party libraries amongst the bad/incomplete ones. * The current goroutine scheduler is really simple and moves goroutines between threads and CPUs. This leads to lots of cache misses, so running on many threads can become slower than running on a single thread.

peterfunny 14y ago
"nil pointers" is a tradeoff for you? Block scoping, too?
- jesstaa 14y ago
  It's possible to never have nil pointer dereferences. But the tradeoff is constructors and some complicated scoping. Block scoping is confusing for many people coming from the dynamic languages where scoping is usually function level.

tutufan 14y ago

No exceptions. Like C, it's not failsafe. That is, if you don't check the error status of (say) I/O operations, you lose.

Ziomislaw 14y ago
Well it depends, if you want a feature that is _called_ 'exception', than no, there is none. If you want a feature that allows you to signal and catch errors, than: * you can return Error as the second parameter from a function, * you can panic and later defer a recover call (more info: http://blog.golang.org/2010/08/defer-panic-and-recover.html http://blog.golang.org/2010/08/defer-panic-and-recover.html )