3 ms·

In real world robotic applications you would make a very strong point, but there is always an educational angle. I have been interested in learning Go for awhil

by ssully 13y ago

In real world robotic applications you would make a very strong point, but there is always an educational angle. I have been interested in learning Go for awhile and recently have been tinkering with robotics. With Gobot I might actually take the plunge and give Go a shot.

wyager 13y ago
I'm a fan of Go, but it's really not at all suited to robotics. The only area I would say Go is "good" for is web services. It's really a pretty mediocre language for anything else. The type system is kind of horrendous, there's no clean way of generic programming, etc. It's really not good for many things, least of all robotics. If you want to get into Go, I recommend writing a web server. It shows you the good parts of Go, and where it's useful.
- dragonwriter 13y ago
  Instead of just repeating the claim that Go is good for nothing, except maybe web services, multiple times in a 7 sentence post, maybe just say it once and provide and dedicate more than one sentence with two points (one of which is subsumed by the other) and no depth to explaining why you think that.
  - wyager 13y ago
    I didn't want to go over my reasoning unless someone asked, since it's kind of a long explanation. The lack of generic support is really terrible. What you have to do instead (cast things to {}interface) is like casting things to Object and then hoping they have the right methods in Java, or passing things around as void* in C++ and then casting them. It's basically the same type safety as a 100% dynamically typed language (i.e. almost none), but with a much uglier syntax. Many features are built-in, non-extensible language directives. Take the `range` operator. `range` only supports built-in types like maps, slices, and chans. You want to range over a tree? Too bad. Want to range over a graph? Too bad. Want to range over a queue or a linked list? Hmm, well too bad, or maybe wrap the queue or LL with a chan, write a helper function, range over that, and watch your performance go to shit. And for embedded programming tasks, like robotics, Go simply doesn't have the right primitives. There isn't a way to perform unsafe operations or pointer arithmetic (necessary for embedded programming), so you have to use cgo. You also lose a lot of language features if you don't have a heap. No chans, no maps, etc. Considering that Go's claim to fame is its suite of useful language features (like goroutines and easy-to-use chans) and standard library (with good web tools), neither of which are usable in most embedded contexts, and certainly not in real-time contexts, any advantages go might have kind of fly out the window.
    - dpritchett 13y ago
      Thanks for elaborating. I didn't really know what to think after your first two posts.

by ssully 13y ago

wyager 13y ago

I'm a fan of Go, but it's really not at all suited to robotics. The only area I would say Go is "good" for is web services. It's really a pretty mediocre language for anything else. The type system is kind of horrendous, there's no clean way of generic programming, etc. It's really not good for many things, least of all robotics. If you want to get into Go, I recommend writing a web server. It shows you the good parts of Go, and where it's useful.

dragonwriter 13y ago
Instead of just repeating the claim that Go is good for nothing, except maybe web services, multiple times in a 7 sentence post, maybe just say it once and provide and dedicate more than one sentence with two points (one of which is subsumed by the other) and no depth to explaining why you think that.
- wyager 13y ago
  I didn't want to go over my reasoning unless someone asked, since it's kind of a long explanation. The lack of generic support is really terrible. What you have to do instead (cast things to {}interface) is like casting things to Object and then hoping they have the right methods in Java, or passing things around as void* in C++ and then casting them. It's basically the same type safety as a 100% dynamically typed language (i.e. almost none), but with a much uglier syntax. Many features are built-in, non-extensible language directives. Take the `range` operator. `range` only supports built-in types like maps, slices, and chans. You want to range over a tree? Too bad. Want to range over a graph? Too bad. Want to range over a queue or a linked list? Hmm, well too bad, or maybe wrap the queue or LL with a chan, write a helper function, range over that, and watch your performance go to shit. And for embedded programming tasks, like robotics, Go simply doesn't have the right primitives. There isn't a way to perform unsafe operations or pointer arithmetic (necessary for embedded programming), so you have to use cgo. You also lose a lot of language features if you don't have a heap. No chans, no maps, etc. Considering that Go's claim to fame is its suite of useful language features (like goroutines and easy-to-use chans) and standard library (with good web tools), neither of which are usable in most embedded contexts, and certainly not in real-time contexts, any advantages go might have kind of fly out the window.
  - dpritchett 13y ago
    Thanks for elaborating. I didn't really know what to think after your first two posts.