6 ms·

I keep hearing that, but Go is one of the languages I'm least productive in, and I know I'm not alone in that. You can pick it up in a week, sure. That's not t

I keep hearing that, but Go is one of the languages I'm least productive in, and I know I'm not alone in that. You can pick it up in a week, sure. That's not the same as productivity.

mhh__ 6y ago
Apart from the, I feel, quite pretentious and lazy Rob Pike quote. The productivity in this case is probably referring to the initial period rather than the steady state afterwards (so to speak). Go is a fairly horrible language by today's standards, but it does what it's supposed to. I like generating code automatically at compile time based on, but I can appreciate the appeal of something that forces you to actually do work rather than being clever.
- throwaway894345 6y ago
  There’s also a lot outside of the language—tooling, ecosystem, etc that Go absolutely nails; however, these things are tremendously undervalued. You have people in this thread talking about how awful Go is for using “//go:” instead of #pragma as though this sort of concern dominated the software development process.
FPGAhacker 6y ago
Just curious, but what are your productive languages? Mine is probably clojure.
- Filligree 6y ago
  Depends on the situation. Python 3 for anything simple, but the way I go about coding is, I first define the data structures and types for a given module - its inputs and outputs, first of all - and only fill in the code afterwards. Not unexpectedly, this means Rust is one of my favorite languages. Anything with a poor type system makes this approach unbearable, and even Python has better static typing than go.
  - Thaxll 6y ago
    "Python has better static typing than go." What? In Python you don't know what you receive and someone could have modified something in an object somewhere in the code that will break down the line in unexpected ways. Python does not have any type checking those are just annotation it does not enforce anything. https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html "Note The Python runtime does not enforce function and variable type annotations. They can be used by third party tools such as type checkers, IDEs, linters, etc."
    - Filligree 6y ago
      Type checking is achievable. It doesn't matter if I need to use external tools; those tools are available.
Chiron1991 6y ago
Amen to this. I don't remember the source, but I read somewhere that Google's internal 'killer feature' is indeed the low barrier of entry. You can get a new intern working with it in literally a week. It's also good enough for all employees up to the very senior people, so you get a good coverage of people with the same tool, which is a tremendous benefit in team cooperation.
- aspenmayer 6y ago
  Do you have a good intro to coding in Go for absolute beginners? It’s so hard to Google for Go related things, ironically.
  - jpxw 6y ago
    Google “Golang” rather than “Go”
    - aspenmayer 6y ago
      Ah, thanks. I was actually worried that it was a different, similarly named language in the same space, and the existential dread of trying to untie that Gordian knot via Google itself left me content to just make a mental note, and ask those who do know when it came up next.
  - mjlee 6y ago
    Absolute beginniners to go or to programming in general? If it's the former, I'd recommend https://tour.golang.org https://tour.golang.org and The Go Programming Language. If it's the latter... I can't personally recommend any beginner's textbooks which are written to use go, but it might be worth looking at Head First Go, the rest of the books in the series are quite approachable.
    - aspenmayer 6y ago
      That’s great, two for two! Thank you. What would you say is the best starter language these days? Java? Python? Something else like C++ or Rust? I am not a coder at all. I mangle configurations and implement functionality upon request, but I always run up against scripts and CLI and I am no expert in bash or powershell and I don’t have to quit vim. But I get by okay. Not a dig, I just admit I only know as much as I do primarily from self-learning and doing. That’s why I care to learn what I’m not seeing because I’m not able to do it yet: the code. There’s just so much to not know, especially about setups and small things that impart outsize benefits or functionality, like dotfiles for instance. All these things are so hard to learn in isolation. It’s hard to have scope and find the rails under you to know how to turn and move yourself around in the dev space, in a basic computing, nuts and bolts sense, if that makes any sense. So if you have any tips about things like that, let me know. For example: https://missing.csail.mit.edu https://missing.csail.mit.edu They even link back, how nice!
change442200 6y ago
I'm a dev for more than 10 years. Much Python, C#, Java, JS/TS, Kotlin, a bit of Rust and was recently forced to use Go. Writing out source code by hand: Nothing beats TS or Kotlin. Not even Python. But what surprised me with Go after a couple of month (and please, nobody should judge a language until having done a serious project): Taking everything into account, from installing to looking for libs, writing code, testing, compiling, revisiting code after a couple of month ... Go is an absolute dream in terms of overall efficiency. Writing out error-checking or for-loops is a one shortcut in GoLand. Getting a table-test template for a function as well. People complaining about having to type this stuff out should learn a proper editor.
- Cthulhu_ 6y ago
  Whilst I agree with your comment, I would like to point out / express my personal opinion that having to rely on your editor to churn out boilerplate like error checking is a smell; it reminds me of ye olde Java where Eclipse could generate hashCode and equals. Later on I always used Lombok, and if I were to work in Java again I'd push hard for Kotlin, which has stuff like that built in. I know Scala does as well but it's a can of worms, it has too many options and no two developers will write the same code.
  - api 6y ago
    I've never needed to have an editor churn out Go error handling, and I don't find it that hard. It could be better, but not much better. Exceptions are not less complex. They just move the complexity around. Exceptions as typically implemented also don't play well with event driven or concurrent models. The thing I actually like about Go errors is that it makes you think about them right when they happen, while an exception encourages dealing with errors "later" which often means "never" or "as an afterthought." Go kind of has exceptions, but panics are intended only for very extreme cases like out of memory errors that crash most applications and are often not recoverable. Using panics for non-fatal errors is bad Go code. One reason I think people don't get Go is that it occupies a language niche that formerly was not occupied by any language. It's like Python meets C, a "low level scripting language." It's designed to be productive and pragmatic but fast and compiled and capable of dealing with pointers or even embedded ASM.
Cthulhu_ 6y ago
You're looking at it from your personal, one-person point of view, but it was made by and for Google, who struggle with tens, hundreds of millions of LOC and thousands of developers whose time is often spent on waiting. There was a post yesterday (I believe) about just that, how a developer in a FAANG managed to do a few tasks at best per week. How fast you can churn out code in a language becomes completely irrelevant at those scales. How fast you can get to grips with a codebase, make the change, compile it, test it, and have it reviewed is much more important. And that's where Go comes in; it doesn't have much cleverness so most code is instantly readable. Take a random file from https://github.com/golang/go/tree/master/src https://github.com/golang/go/tree/master/src and any developer will understand it and be able to make changes. They optimized the language for compile speed (https://stackoverflow.com/a/8673468/204840); https://stackoverflow.com/a/8673468/204840); the joke goes that they came up with Go while waiting for a compile. And because the code is so simple and standardized, reviewing also takes less time. I'm mostly thinking of Scala as the direct opposite of Scala which has as many different coding styles as it has developers, and Go's language design process as rebelling against most other languages that seem to want to put other language features in them for the sake of it (I'm still bitter about classes in Javascript and streams in Java). TL;DR: If you're a solo developer or work in a small team, then Go may not be for you if you're measuring personal productivity. Its value starts to show if you scale up, and you go from churning out code to maintenance mode.
- pansa2 6y ago
  > Go's language design process as rebelling against most other languages that seem to want to put other language features in them for the sake of it Rob Pike in 2015, about what Go was trying to avoid: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." [0] [0] https://www.dotconferences.com/2015/11/rob-pike-simplicity-is-complicated https://www.dotconferences.com/2015/11/rob-pike-simplicity-i...
api 6y ago
I've coded in C, C++, Ruby, JavaScript, Java, C#, PHP, and messed with Rust and Haskell a little. Go is by far the most productive compiled language I've used, though I've certainly had moments with JS and Ruby that felt more productive. For me the reason is that the language imposes little cognitive load, leaving my brain free to spend almost 100% of its energy thinking about the problem I am attempting to solve. With complex languages like C++ I find that I'm spending too much time thinking about language internals and syntax, and with C I am spending too much time doing super low level things. Both these languages also require constant attention to make sure their many built-in footguns do not go off. Scripting languages like JS and Ruby can be more productive up front, but as a code base matures it becomes harder and harder to feel confident about the code not having hidden runtime bugs. Dynamic runtime typing is technical debt. These languages also run slower, though I have to say JS VMs are impressive. I have not used Rust enough to comment. Feels like a better C++. Haskell feels like it would be great for certain areas where the provability it offers shines but isn't quite general purpose. But YMMV. Ultimately I care more about what is written than the language. 'Tis a poor craftsman who blames his tools.
throwaway894345 6y ago
This is strange to me. I’ve always found Go to just click, and I can write code very quickly. I used to work at a Python shop, and I would prototype in Go to make sure things were reasonably correct before porting to Python (and then to watch the performance, type safety, and a good chunk of the maintainability evaporate, to my great dismay). I wonder if this comes down to differences in how programmers think about programming?
sangnoir 6y ago
That depends on how you define "productivity" - is it how quickly an individual can solve a defined use-case on a timescale of a few days or how well a team, division or company can solve the overall problem. As a former Perl wrangler, I was super-productive in the short term with terse, elegant, and often clever Perl code: I could really express myself. Maintaining the codebase on the long-term was a nightmare though, so team productivity wasn't great. Go is the opposite, "harder" to write, but much easier to read and understand - which pushes up team productivity significantly.

I keep hearing that, but Go is one of the languages I'm least productive in, and I know I'm not alone in that. You can pick it up in a week, sure. That's not the same as productivity.

mhh__ 6y ago

Apart from the, I feel, quite pretentious and lazy Rob Pike quote. The productivity in this case is probably referring to the initial period rather than the steady state afterwards (so to speak). Go is a fairly horrible language by today's standards, but it does what it's supposed to. I like generating code automatically at compile time based on, but I can appreciate the appeal of something that forces you to actually do work rather than being clever.

throwaway894345 6y ago
There’s also a lot outside of the language—tooling, ecosystem, etc that Go absolutely nails; however, these things are tremendously undervalued. You have people in this thread talking about how awful Go is for using “//go:” instead of #pragma as though this sort of concern dominated the software development process.

FPGAhacker 6y ago

Just curious, but what are your productive languages? Mine is probably clojure.

Filligree 6y ago
Depends on the situation. Python 3 for anything simple, but the way I go about coding is, I first define the data structures and types for a given module - its inputs and outputs, first of all - and only fill in the code afterwards. Not unexpectedly, this means Rust is one of my favorite languages. Anything with a poor type system makes this approach unbearable, and even Python has better static typing than go.
- Thaxll 6y ago
  "Python has better static typing than go." What? In Python you don't know what you receive and someone could have modified something in an object somewhere in the code that will break down the line in unexpected ways. Python does not have any type checking those are just annotation it does not enforce anything. https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html "Note The Python runtime does not enforce function and variable type annotations. They can be used by third party tools such as type checkers, IDEs, linters, etc."
  - Filligree 6y ago
    Type checking is achievable. It doesn't matter if I need to use external tools; those tools are available.

Chiron1991 6y ago

Amen to this. I don't remember the source, but I read somewhere that Google's internal 'killer feature' is indeed the low barrier of entry. You can get a new intern working with it in literally a week. It's also good enough for all employees up to the very senior people, so you get a good coverage of people with the same tool, which is a tremendous benefit in team cooperation.

aspenmayer 6y ago
Do you have a good intro to coding in Go for absolute beginners? It’s so hard to Google for Go related things, ironically.
- jpxw 6y ago
  Google “Golang” rather than “Go”
  - aspenmayer 6y ago
    Ah, thanks. I was actually worried that it was a different, similarly named language in the same space, and the existential dread of trying to untie that Gordian knot via Google itself left me content to just make a mental note, and ask those who do know when it came up next.
- mjlee 6y ago
  Absolute beginniners to go or to programming in general? If it's the former, I'd recommend https://tour.golang.org https://tour.golang.org and The Go Programming Language. If it's the latter... I can't personally recommend any beginner's textbooks which are written to use go, but it might be worth looking at Head First Go, the rest of the books in the series are quite approachable.
  - aspenmayer 6y ago
    That’s great, two for two! Thank you. What would you say is the best starter language these days? Java? Python? Something else like C++ or Rust? I am not a coder at all. I mangle configurations and implement functionality upon request, but I always run up against scripts and CLI and I am no expert in bash or powershell and I don’t have to quit vim. But I get by okay. Not a dig, I just admit I only know as much as I do primarily from self-learning and doing. That’s why I care to learn what I’m not seeing because I’m not able to do it yet: the code. There’s just so much to not know, especially about setups and small things that impart outsize benefits or functionality, like dotfiles for instance. All these things are so hard to learn in isolation. It’s hard to have scope and find the rails under you to know how to turn and move yourself around in the dev space, in a basic computing, nuts and bolts sense, if that makes any sense. So if you have any tips about things like that, let me know. For example: https://missing.csail.mit.edu https://missing.csail.mit.edu They even link back, how nice!

change442200 6y ago

I'm a dev for more than 10 years. Much Python, C#, Java, JS/TS, Kotlin, a bit of Rust and was recently forced to use Go. Writing out source code by hand: Nothing beats TS or Kotlin. Not even Python. But what surprised me with Go after a couple of month (and please, nobody should judge a language until having done a serious project): Taking everything into account, from installing to looking for libs, writing code, testing, compiling, revisiting code after a couple of month ... Go is an absolute dream in terms of overall efficiency. Writing out error-checking or for-loops is a one shortcut in GoLand. Getting a table-test template for a function as well. People complaining about having to type this stuff out should learn a proper editor.

Cthulhu_ 6y ago
Whilst I agree with your comment, I would like to point out / express my personal opinion that having to rely on your editor to churn out boilerplate like error checking is a smell; it reminds me of ye olde Java where Eclipse could generate hashCode and equals. Later on I always used Lombok, and if I were to work in Java again I'd push hard for Kotlin, which has stuff like that built in. I know Scala does as well but it's a can of worms, it has too many options and no two developers will write the same code.
- api 6y ago
  I've never needed to have an editor churn out Go error handling, and I don't find it that hard. It could be better, but not much better. Exceptions are not less complex. They just move the complexity around. Exceptions as typically implemented also don't play well with event driven or concurrent models. The thing I actually like about Go errors is that it makes you think about them right when they happen, while an exception encourages dealing with errors "later" which often means "never" or "as an afterthought." Go kind of has exceptions, but panics are intended only for very extreme cases like out of memory errors that crash most applications and are often not recoverable. Using panics for non-fatal errors is bad Go code. One reason I think people don't get Go is that it occupies a language niche that formerly was not occupied by any language. It's like Python meets C, a "low level scripting language." It's designed to be productive and pragmatic but fast and compiled and capable of dealing with pointers or even embedded ASM.

Cthulhu_ 6y ago

You're looking at it from your personal, one-person point of view, but it was made by and for Google, who struggle with tens, hundreds of millions of LOC and thousands of developers whose time is often spent on waiting. There was a post yesterday (I believe) about just that, how a developer in a FAANG managed to do a few tasks at best per week. How fast you can churn out code in a language becomes completely irrelevant at those scales. How fast you can get to grips with a codebase, make the change, compile it, test it, and have it reviewed is much more important. And that's where Go comes in; it doesn't have much cleverness so most code is instantly readable. Take a random file from https://github.com/golang/go/tree/master/src https://github.com/golang/go/tree/master/src and any developer will understand it and be able to make changes. They optimized the language for compile speed (https://stackoverflow.com/a/8673468/204840); https://stackoverflow.com/a/8673468/204840); the joke goes that they came up with Go while waiting for a compile. And because the code is so simple and standardized, reviewing also takes less time. I'm mostly thinking of Scala as the direct opposite of Scala which has as many different coding styles as it has developers, and Go's language design process as rebelling against most other languages that seem to want to put other language features in them for the sake of it (I'm still bitter about classes in Javascript and streams in Java). TL;DR: If you're a solo developer or work in a small team, then Go may not be for you if you're measuring personal productivity. Its value starts to show if you scale up, and you go from churning out code to maintenance mode.

pansa2 6y ago
> Go's language design process as rebelling against most other languages that seem to want to put other language features in them for the sake of it Rob Pike in 2015, about what Go was trying to avoid: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." [0] [0] https://www.dotconferences.com/2015/11/rob-pike-simplicity-is-complicated https://www.dotconferences.com/2015/11/rob-pike-simplicity-i...

api 6y ago

I've coded in C, C++, Ruby, JavaScript, Java, C#, PHP, and messed with Rust and Haskell a little. Go is by far the most productive compiled language I've used, though I've certainly had moments with JS and Ruby that felt more productive. For me the reason is that the language imposes little cognitive load, leaving my brain free to spend almost 100% of its energy thinking about the problem I am attempting to solve. With complex languages like C++ I find that I'm spending too much time thinking about language internals and syntax, and with C I am spending too much time doing super low level things. Both these languages also require constant attention to make sure their many built-in footguns do not go off. Scripting languages like JS and Ruby can be more productive up front, but as a code base matures it becomes harder and harder to feel confident about the code not having hidden runtime bugs. Dynamic runtime typing is technical debt. These languages also run slower, though I have to say JS VMs are impressive. I have not used Rust enough to comment. Feels like a better C++. Haskell feels like it would be great for certain areas where the provability it offers shines but isn't quite general purpose. But YMMV. Ultimately I care more about what is written than the language. 'Tis a poor craftsman who blames his tools.

throwaway894345 6y ago

This is strange to me. I’ve always found Go to just click, and I can write code very quickly. I used to work at a Python shop, and I would prototype in Go to make sure things were reasonably correct before porting to Python (and then to watch the performance, type safety, and a good chunk of the maintainability evaporate, to my great dismay). I wonder if this comes down to differences in how programmers think about programming?

sangnoir 6y ago

That depends on how you define "productivity" - is it how quickly an individual can solve a defined use-case on a timescale of a few days or how well a team, division or company can solve the overall problem. As a former Perl wrangler, I was super-productive in the short term with terse, elegant, and often clever Perl code: I could really express myself. Maintaining the codebase on the long-term was a nightmare though, so team productivity wasn't great. Go is the opposite, "harder" to write, but much easier to read and understand - which pushes up team productivity significantly.