4 ms·

I really like Go and respect the authors and maintainers of the language. It is well designed and achieves its goals exceptionally well. The author of this arti

by dgb23 5y ago

I really like Go and respect the authors and maintainers of the language. It is well designed and achieves its goals exceptionally well. The author of this article is right: Give it a Go! You'll learn it quickly and will appreciate having learned it, there are many, very considerate design decisions to discover, ranging from language implementation, tooling and the standard library. I'm sometimes jealous of Go's users, the language is very readable, light and refreshingly straight forward. That said, I cannot bring myself to use it (anymore). The language doesn't scale with my ability and in some sense seems almost patronizing. I'm not a particularly good programmer, but I'm experienced enough that I feel held back by languages like Go. When you are used to more power, expressiveness and clarity, then you just miss it at every step of the way. On one hand the language doesn't let me encode higher level thinking directly (relational, functional, domain specific...) but I have to act as a compiler. And vice versa it doesn't expose the low level control that one would want to squeeze out performance and minimize resource usage either. Again, Go still feels attractive in some sense, and I wish I had a reason to use it more, but I can't find it.

t8sr 5y ago
I think not letting you encode relational, functional and domain-specific higher level thinking is by design. I review a lot of code, and have been programming for 20 years. I think most programmers go through a phase, after 2-5 years of experience, where they get really into higher-level thinking. Everything is written according to a mantra like TTD, functional design, or everything-is-an-object, and they spend most of their complexity budget on abstractions. The code people write in that stage of their careers looks to them like an improvement over the simpler concepts they started with, it ends up being so much technical debt 12 months later, because almost nobody is good at predicting which higher-level concepts you are going to need, and by the time you realize you were wrong, it’s too expensive to remove them. It’s hard for a language to encourage this kind of you-ain’t-gonna-need-it thinking without seeming patronizing, but I promise you that the next 10 years of your career will change your mind. (I realize I also sound patronizing and I’m sorry: I typed this on a phone, so left out some caveats, such as I don’t know you and your background.)
- dgb23 5y ago
  I agree with your points generally, but I already went through that phase and "recovered". I get a bit of an allergic reaction from unnecessary abstractions, design patterns and purism since quite a while. But I think that "phase" is important, because it pushes/pushed us to dive more deeply into topics around abstraction and to make mistakes to learn from. And to keep to good parts so we can apply them accordingly. I'm convinced that some of those things are almost timeless and just 'correct' for their given use-case. Avoiding side-effects and composing functions isn't a fad, nor does it add complexity but reduces it. The issue emerges when we act as if we can do that completely and absolutely. Relational data modelling and APIs are not things you can even avoid, many seem to try to do this only to come back full circle and re-implement them ad-hoc. Similarly there are a ton of other data-structures and patterns like this that have more limited applicability, but work really well if so and reduce the mental overhead to understand and extend a program, make them simpler and more robust. Another good example would be data-driven/oriented: Pulling concrete stuff out of procedures and putting it into plain, boring data, possibly into structured text (JSON, XML, YAML...). It's boring(!) to program like this once you have settled on the right structure/schema, but in a very good way as in it is relaxing and productive. I would even go as far to say that this is one of the most productivity enhancing force multipliers in programming, but it requires a bit of up-front thinking or at least rewriting/refactoring as opposed to going full-on-procedural. Again, I hear you, I've been there too. Abstraction is hard and requires experience and constant learning. Doing mistakes in that regard is very expensive (time and mental taxation). But lets not pretend like abstraction is inherently evil or misguided, especially not if we choose patterns and data-structures that have stood the test of time like the above. So I think abstraction should be treated as a kind of investment, it has a cost (including opportunity costs) and a possible long term payoff. So we need to be considerate and careful.
- cannabis_sam 5y ago
  >(I realize I also sound patronizing and I’m sorry: I typed this on a phone, so left out some caveats, such as I don’t know you and your background.) Yet your comment is extremely dismissive of young people’s experiences. I personally had to fight for what I considered to be trivial design decisions, because a senior dev was pushing programming techniques based on his experience with Lisp in the literal 80s. Now I love lisp (although I prefer to work in Haskell), but I had to rewrite this old fart’s shitty and slow java application in a vaguely object-oriented way, so that we would have a hope in hell to attract new devs. And when we actually employed new devs, I had to simplify my code even further to help onboarding, thankfully I had exercised most of the idiotic code at that point, so we built a simplified codebase that was accessible to anyone who had a vague understanding of an MVC-style web app. (Today that would probably be some kind of basic React/Vue app.)
kubb 5y ago
Many people love it on HN, but for me coding in Go is a chore that makes me disinterested in my job. After 3 years of working with it, I dispute the claims about readability and simplicity. In Go, you solve problems by outputting inhuman amounts of code. It can feel productive, but most of it is just noise. Of course just because I'm not well suited for it doesn't mean it's not for others. But there's a lot that we've collectively learned about programming, that's not acknowledged in Go's design. You can start coding in it pretty fast, that much is true.
- papaf 5y ago
  In Go, you solve problems by outputting inhuman amounts of code. The standard library manages to pack a lot of functionality in little code. Its probably not easy to write simple concise code in Go but it is certainly possible.
  - kubb 5y ago
    The standard library is good. If you can solve your problem by mostly using tools from the standard library in a short main package, Go works well. The work that I do unfortunately doesn't have that property.
    - makapuf 5y ago
      The point you are responding to is not about using th stdlib, but implementing it. If you look at the stdlib itself, it adds lots of functionality without too much code, from scratch.
      - kubb 5y ago
        It would strengthen your point if you specified which parts of the standard library you're talking about. Crypto stuff - yes. Reflection, AST processing, concurrent hash map - I'm not convinced. Some parts will be terser than others. The standard library doesn't implement typical business logic. So it's not the best benchmark. Not to mention the lack of reusable data structures.
Cthulhu_ 5y ago
But the language is just a tool; it means you can turn your brain off churning out code (or telling others to churn out code) and focus your mind on the REAL problems, for which the code should just be a tool. I've worked with too many developers and projects that made the problem needlessly more difficult, by using a difficult language (Scala), by adding complexity to the whole stack (microservices + cloud based runtime). But they were just CRUD apps. Glue code between services. An API between a front-end and an existing mainframe service, which was abstracted away behind a java service. They all focused their energy on their craft, on flexing their skills, but not on solving the actual problem - that was boring. And they focused on THEIR skills and abilities, while, if they are as good as they think they are, they should use that to make sure others get up to a level as well. There's some quotes out there, paraphrasing one of them, if you write code to the best of your abilities, you are, by definition, not smart enough to debug it. And others are not smart enough to comprehend and maintain it. It creates noise and churn that will eventually lead to stagnation and full replacement. Choose boring technology. Write boring code. Focus on the real problems to be solved, and make sure it's not code you wrote yourself.
- masklinn 5y ago
  > But the language is just a tool; it means you can turn your brain off churning out code (or telling others to churn out code) and focus your mind on the REAL problems, for which the code should just be a tool. By its limitations the tool in question requires churning more code and adds more steps between the “REAL problems” you solved in your minds and the actual implementation of those solutions in-code. If languages are just irrelevant tools and you have but to focus on the “REAL problems” to solve it all, there’s no reason not to use a turing tarpit. Why are you not doing that?
eplanit 5y ago
That's quite an odd humblebrag, I must say. You feel good for the simpletons for whom Go's expressiveness is adequate, but it's just not up to your own lofty ideas. Perhaps the language isn't a fit for your skills or preferences, which is fine. You want something that scales with your abilities, but then say that you're not a strong programmer. A bit confusing.
- dgb23 5y ago
  I feel misunderstood! I wanted to convey that I'm torn. I like Go and I feel like it was made for people like me: Working programmers who want to get stuff done. And in a sense I am, I'm attracted to Go, but there are just enough things that are stumble blocks for me to keep using it or even consider using it in a professional manner over other options. Not because it is a bad language or because I consider its users bad, quite the contrary. In a sense it doesn't scale with my abilities, but that doesn't mean at all that they are special or golden. It's just a set of things that I absorbed and tried with experience or learned from books and filtered and adopted (dumbed down) for my needs. I think you might be right with: > "the language isn't a fit for your skills or preferences" Maybe should have worded it that way. For me Go is really good 80% of the time and then super awkward to use for the 20% where I cannot write the code in the way I think. It blocks me from exploring those thoughts if that makes sense. And that makes me unhappy.
  - deleted 5y ago
    [deleted]
- masklinn 5y ago
  > That's quite an odd humblebrag, I must say. You feel good for the simpletons for whom Go's expressiveness is adequate, but it's just not up to your own lofty ideas. TBF that's how rob pike presents the langage.
sangnoir 5y ago
> I'm not a particularly good programmer, but I'm experienced enough that I feel held back by languages like Go. When you are used to more power, expressiveness and clarity, then you just miss it at every step of the way. I fully agree with this sentiment, but I feel that is a pro when programming in the large. Power and expressiveness are not always a good thing in team environments where each persons view of "expressiveness" is different. I say this as someone who worked on a large Perl code base - Perl is powerful, expressive, and if the stars align, may even have clarity. However, when it comes to maintenance, I'll take a 10-line Go function (or 2) over a clever Perl one-liner, any day.
marcus_holmes 5y ago
Give it some time. You'll come to appreciate its simplicity (and how hard being simple is) once you've made more mistakes. I don't mean that to sound patronising. It's been my journey over 40ish years of coding, 30ish years of professional software development.

by dgb23 5y ago

t8sr 5y ago

I think not letting you encode relational, functional and domain-specific higher level thinking is by design. I review a lot of code, and have been programming for 20 years. I think most programmers go through a phase, after 2-5 years of experience, where they get really into higher-level thinking. Everything is written according to a mantra like TTD, functional design, or everything-is-an-object, and they spend most of their complexity budget on abstractions. The code people write in that stage of their careers looks to them like an improvement over the simpler concepts they started with, it ends up being so much technical debt 12 months later, because almost nobody is good at predicting which higher-level concepts you are going to need, and by the time you realize you were wrong, it’s too expensive to remove them. It’s hard for a language to encourage this kind of you-ain’t-gonna-need-it thinking without seeming patronizing, but I promise you that the next 10 years of your career will change your mind. (I realize I also sound patronizing and I’m sorry: I typed this on a phone, so left out some caveats, such as I don’t know you and your background.)

dgb23 5y ago
I agree with your points generally, but I already went through that phase and "recovered". I get a bit of an allergic reaction from unnecessary abstractions, design patterns and purism since quite a while. But I think that "phase" is important, because it pushes/pushed us to dive more deeply into topics around abstraction and to make mistakes to learn from. And to keep to good parts so we can apply them accordingly. I'm convinced that some of those things are almost timeless and just 'correct' for their given use-case. Avoiding side-effects and composing functions isn't a fad, nor does it add complexity but reduces it. The issue emerges when we act as if we can do that completely and absolutely. Relational data modelling and APIs are not things you can even avoid, many seem to try to do this only to come back full circle and re-implement them ad-hoc. Similarly there are a ton of other data-structures and patterns like this that have more limited applicability, but work really well if so and reduce the mental overhead to understand and extend a program, make them simpler and more robust. Another good example would be data-driven/oriented: Pulling concrete stuff out of procedures and putting it into plain, boring data, possibly into structured text (JSON, XML, YAML...). It's boring(!) to program like this once you have settled on the right structure/schema, but in a very good way as in it is relaxing and productive. I would even go as far to say that this is one of the most productivity enhancing force multipliers in programming, but it requires a bit of up-front thinking or at least rewriting/refactoring as opposed to going full-on-procedural. Again, I hear you, I've been there too. Abstraction is hard and requires experience and constant learning. Doing mistakes in that regard is very expensive (time and mental taxation). But lets not pretend like abstraction is inherently evil or misguided, especially not if we choose patterns and data-structures that have stood the test of time like the above. So I think abstraction should be treated as a kind of investment, it has a cost (including opportunity costs) and a possible long term payoff. So we need to be considerate and careful.
cannabis_sam 5y ago
>(I realize I also sound patronizing and I’m sorry: I typed this on a phone, so left out some caveats, such as I don’t know you and your background.) Yet your comment is extremely dismissive of young people’s experiences. I personally had to fight for what I considered to be trivial design decisions, because a senior dev was pushing programming techniques based on his experience with Lisp in the literal 80s. Now I love lisp (although I prefer to work in Haskell), but I had to rewrite this old fart’s shitty and slow java application in a vaguely object-oriented way, so that we would have a hope in hell to attract new devs. And when we actually employed new devs, I had to simplify my code even further to help onboarding, thankfully I had exercised most of the idiotic code at that point, so we built a simplified codebase that was accessible to anyone who had a vague understanding of an MVC-style web app. (Today that would probably be some kind of basic React/Vue app.)

kubb 5y ago

Many people love it on HN, but for me coding in Go is a chore that makes me disinterested in my job. After 3 years of working with it, I dispute the claims about readability and simplicity. In Go, you solve problems by outputting inhuman amounts of code. It can feel productive, but most of it is just noise. Of course just because I'm not well suited for it doesn't mean it's not for others. But there's a lot that we've collectively learned about programming, that's not acknowledged in Go's design. You can start coding in it pretty fast, that much is true.

papaf 5y ago
In Go, you solve problems by outputting inhuman amounts of code. The standard library manages to pack a lot of functionality in little code. Its probably not easy to write simple concise code in Go but it is certainly possible.
- kubb 5y ago
  The standard library is good. If you can solve your problem by mostly using tools from the standard library in a short main package, Go works well. The work that I do unfortunately doesn't have that property.
  - makapuf 5y ago
    The point you are responding to is not about using th stdlib, but implementing it. If you look at the stdlib itself, it adds lots of functionality without too much code, from scratch.
    - kubb 5y ago
      It would strengthen your point if you specified which parts of the standard library you're talking about. Crypto stuff - yes. Reflection, AST processing, concurrent hash map - I'm not convinced. Some parts will be terser than others. The standard library doesn't implement typical business logic. So it's not the best benchmark. Not to mention the lack of reusable data structures.

Cthulhu_ 5y ago

But the language is just a tool; it means you can turn your brain off churning out code (or telling others to churn out code) and focus your mind on the REAL problems, for which the code should just be a tool. I've worked with too many developers and projects that made the problem needlessly more difficult, by using a difficult language (Scala), by adding complexity to the whole stack (microservices + cloud based runtime). But they were just CRUD apps. Glue code between services. An API between a front-end and an existing mainframe service, which was abstracted away behind a java service. They all focused their energy on their craft, on flexing their skills, but not on solving the actual problem - that was boring. And they focused on THEIR skills and abilities, while, if they are as good as they think they are, they should use that to make sure others get up to a level as well. There's some quotes out there, paraphrasing one of them, if you write code to the best of your abilities, you are, by definition, not smart enough to debug it. And others are not smart enough to comprehend and maintain it. It creates noise and churn that will eventually lead to stagnation and full replacement. Choose boring technology. Write boring code. Focus on the real problems to be solved, and make sure it's not code you wrote yourself.

masklinn 5y ago
> But the language is just a tool; it means you can turn your brain off churning out code (or telling others to churn out code) and focus your mind on the REAL problems, for which the code should just be a tool. By its limitations the tool in question requires churning more code and adds more steps between the “REAL problems” you solved in your minds and the actual implementation of those solutions in-code. If languages are just irrelevant tools and you have but to focus on the “REAL problems” to solve it all, there’s no reason not to use a turing tarpit. Why are you not doing that?

eplanit 5y ago

That's quite an odd humblebrag, I must say. You feel good for the simpletons for whom Go's expressiveness is adequate, but it's just not up to your own lofty ideas. Perhaps the language isn't a fit for your skills or preferences, which is fine. You want something that scales with your abilities, but then say that you're not a strong programmer. A bit confusing.

dgb23 5y ago
I feel misunderstood! I wanted to convey that I'm torn. I like Go and I feel like it was made for people like me: Working programmers who want to get stuff done. And in a sense I am, I'm attracted to Go, but there are just enough things that are stumble blocks for me to keep using it or even consider using it in a professional manner over other options. Not because it is a bad language or because I consider its users bad, quite the contrary. In a sense it doesn't scale with my abilities, but that doesn't mean at all that they are special or golden. It's just a set of things that I absorbed and tried with experience or learned from books and filtered and adopted (dumbed down) for my needs. I think you might be right with: > "the language isn't a fit for your skills or preferences" Maybe should have worded it that way. For me Go is really good 80% of the time and then super awkward to use for the 20% where I cannot write the code in the way I think. It blocks me from exploring those thoughts if that makes sense. And that makes me unhappy.
- deleted 5y ago
  [deleted]
masklinn 5y ago
> That's quite an odd humblebrag, I must say. You feel good for the simpletons for whom Go's expressiveness is adequate, but it's just not up to your own lofty ideas. TBF that's how rob pike presents the langage.

sangnoir 5y ago

> I'm not a particularly good programmer, but I'm experienced enough that I feel held back by languages like Go. When you are used to more power, expressiveness and clarity, then you just miss it at every step of the way. I fully agree with this sentiment, but I feel that is a pro when programming in the large. Power and expressiveness are not always a good thing in team environments where each persons view of "expressiveness" is different. I say this as someone who worked on a large Perl code base - Perl is powerful, expressive, and if the stars align, may even have clarity. However, when it comes to maintenance, I'll take a 10-line Go function (or 2) over a clever Perl one-liner, any day.

marcus_holmes 5y ago

Give it some time. You'll come to appreciate its simplicity (and how hard being simple is) once you've made more mistakes. I don't mean that to sound patronising. It's been my journey over 40ish years of coding, 30ish years of professional software development.