4 ms·

People like Pike and Kernighan is the reason I've invested so much of my time in learning Go lately. To some this may seem completely irrational, because you sh

People like Pike and Kernighan is the reason I've invested so much of my time in learning Go lately. To some this may seem completely irrational, because you should pick a language based on its merits (e.g. does it support generics, etc), but for me, the books they authored and the software they wrote (e.g. Ken Thompson's contribution to what we now know as unix) says a lot more than a seemingly objective review based on language features. I guess time will show whether I'm right.

bitexploder 10y ago
I am with you. There is a clarity of purpose and thought in their writing and work that causes me to trust them. Also a key reason I started playing with Go.
falcolas 10y ago
As someone who is writing Go (and Python) for a living: I don't regret the choice. The lack of generics is annoying when you come across it, but it's relatively rare to come across. The seemingly foot-shooting flexibility of interface{} and Value are frightening from afar, but seem to "just work" when you use them in practice. Using them introduces just enough natural friction that you don't actually use them unless you need to. GC pauses have yet to cause a problem for me. Error handling is still a bit of a pain, but I do appreciate being forced to think about error handling, instead of just relying on a global try/catch and runtime tracebacks. Yes, I know I should not be relying on a catch of last resort, but it never seems like the right place to handle errors ever naturally appears. Good luck!
- eropple 10y ago
  > The lack of generics is annoying when you come across it, but it's relatively rare to come across. The seemingly foot-shooting flexibility of interface{} and Value are frightening from afar, but seem to "just work" when you use them in practice. ...Unless you write code that treats types as things, and not as inconveniencies that the compiler foists upon you. At which point the problems of generics appear immediately. Like, I'm glad it works for you (well, sort of--the more Go in the world, the more likelihood that I'm going to have to deal with it), but what you're describing really only works from one very particular mindset of software development that isn't super well-shared. > Error handling is still a bit of a pain, but I do appreciate being forced to think about error handling, instead of just relying on a global try/catch and runtime tracebacks. Go's method of "making you think about error handling" is not just "a bit of a pain" but really, really weak, though, and it ties back to the language itself not being particularly expressive. In a language with expressive generics, you just fold() across anything that can return an error because it returns Result<V, E> and you must handle both cases inline.

bitexploder 10y ago

I am with you. There is a clarity of purpose and thought in their writing and work that causes me to trust them. Also a key reason I started playing with Go.

falcolas 10y ago

As someone who is writing Go (and Python) for a living: I don't regret the choice. The lack of generics is annoying when you come across it, but it's relatively rare to come across. The seemingly foot-shooting flexibility of interface{} and Value are frightening from afar, but seem to "just work" when you use them in practice. Using them introduces just enough natural friction that you don't actually use them unless you need to. GC pauses have yet to cause a problem for me. Error handling is still a bit of a pain, but I do appreciate being forced to think about error handling, instead of just relying on a global try/catch and runtime tracebacks. Yes, I know I should not be relying on a catch of last resort, but it never seems like the right place to handle errors ever naturally appears. Good luck!

eropple 10y ago
> The lack of generics is annoying when you come across it, but it's relatively rare to come across. The seemingly foot-shooting flexibility of interface{} and Value are frightening from afar, but seem to "just work" when you use them in practice. ...Unless you write code that treats types as things, and not as inconveniencies that the compiler foists upon you. At which point the problems of generics appear immediately. Like, I'm glad it works for you (well, sort of--the more Go in the world, the more likelihood that I'm going to have to deal with it), but what you're describing really only works from one very particular mindset of software development that isn't super well-shared. > Error handling is still a bit of a pain, but I do appreciate being forced to think about error handling, instead of just relying on a global try/catch and runtime tracebacks. Go's method of "making you think about error handling" is not just "a bit of a pain" but really, really weak, though, and it ties back to the language itself not being particularly expressive. In a language with expressive generics, you just fold() across anything that can return an error because it returns Result<V, E> and you must handle both cases inline.