Hacker News Reader

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.)

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.

>(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.)

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.

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.

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.

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.

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.

Doesn't it also use functionality not available to userland code? Generics come to mind, but they will finally be available to everyone.

Most of it doesn't. Take a look at net/http. I'm not aware of anything it does that your package could not. Certainly nothing that would move the needle on succinctness.

net/http is a great example.

The std lib is disciplined about using safe Go ideas except in the exceptional cases. I feel like it’s nothing that is enforced by the formal spec of the language, just that the std lib has an exceptional emphasis on making it really hard to walk away with misconceptions.

It really depends on what you're comparing Go to and on what kind of projects. Some languages will fair better for simplicity for some tasks. Other languages will fair better for simplicity for other tasks. Programming is a hugely vast topic with an infinite number of problems to be solved in an infinite number of ways.

It's not noise if you can understand every line written though. That's maintainable code that will last the decades, instead of being replaced with the next hip language 5-10 years down the line.

If you don't have to think too much about what code does, you can get a better overview of what's going on.

Plus, there's more developers available if your code is simple. That is one unspoken (yet written down!) reason why Go was devised - to be able to have mediocre developers still be productive.

Clever code is illegible by most people, unless they wrote it, are very smart themselves, and are actually interested in the code in front of them.

Go code is readable and comprehensible by everyone.

I’m simply not convinced about that talking point. It’s an extraordinarily strong claim that it’s comprehensible to everyone.

Sure if you have a 100 lines of pure Go, that should be readable. But take a look for instance at the source for go tool cover. How much time do you need to spend to understand it? Then imagine Rob didn’t write it, but a junior. How much more convoluted would it be?

You’re conflating ease of understanding/reading Go code with complexity of a hard problem. I can personally read the standard library, or basically any library, and I regularly do to understand how stuff works under the hood. But certain problems are hard and are going to take time to understand the problem and solution versus a basic idea of some things the code is doing. Eg: reading how a RabbitMQ library is using a parameter versus understanding the entire protocol it’s handling. Go is very nice in being able to read other people’s code where other languages it’s extremely hard. (Eg: I’ve tried to read the code for SQL Alchemy in Python and it’s… very hard)

I'm as torn as some of the other commenters here as Go can feel stifling to me frequently, but I have to say I find Go's readability comes with a culture of reading the source, which can be powerful. Often if I'm using a Go tool and I have questions about exactly what it's doing under the hood, unlike other languages where I have to learn the localized style/conventions/patterns (are you using annotations? Dependency Injection? Thread pools or async?), I can just pop open the source and read it. That doesn't necessarily mean I'll _understand_ what I'm reading easily but it does let me pick up subtleties under the hood.

Hashicorp's tools are great examples; before you could find endless posts online about using their tools I'd often dive into portions of Consul or Nomad with questions. Both of these are complicated pieces of software and being able to read the source helped a lot. On the other hand, trying to debug Werkzeug and Flask in Python is a nightmare of objects inheriting weird properties and all sorts of control flow weirdness, despite Flask ostensibly being a lightweight web framework.

"It's not noise if you can understand every line written though. " It can still just be noise. Have you never seen getters and setters in Java? Error handling in Go is mostly just noise a well. I mean manually wrapping errors so that you can get a stack trace? Our codebase is littered with span calls that in Java could have been relegated to an AOP library.

> It's not noise if you can understand every line written though.

If I can understand every line of a 10,000 line program, is it not still noise compared to a 100 line program that accomplishes the same goal?

> If you don't have to think too much about what code does, you can get a better overview of what's going on.

That's the problem with Go. I do have to think about what the code does, because the ability to abstract things to a higher level is virtually nonexistent.

Take the following:

    items
      .select  { |item| whitelist.include?(item) }
      .sort_by { |item| item.price }
      .map     { |item| item.name }

I don't have to think about what this code does at all. It's obvious. And I am extremely confident that there are no bugs. The Golang equivalent?

    var tmp []item
    var res []item

    for _, item := range items {
        for _, entry := range whitelist {
            if item == entry {
                tmp = append(tmp, item)
                break
            }
        }
    }

    sort.Slice(res, func(i, j item) bool {
        return tmp[i].Price < tmp[j].Price
    })

    for _, item := range items {
        res = append(res, item.Name)
    }

Sure I can understand every line of the latter. It's still noise. And it's only comprehensible by sitting down and carefully reading every single line. Are there bugs? I think not, but I'd have to think through it to be sure. Go took what should have been a simple problem and somehow turned it into something that would feel at home if I was writing a device driver.

Case in point, I just reread this and realized there are two bugs.

This was my experience as well. I inherited a codebase of very simple, well-written Go. Anytime I needed to go to the source to find out how the business logic was implemented, I ended up scrolling... and scrolling... and scrolling... collecting the information bit by bit like a scavenger hunt.

Go seems like it would be great for motivating someone to figure out the simplest possible way of solving a computing problem. Unfortunately for software development (but fortunately for humanity) not all problems allow engineers the freedom to brutally simplify the solution. Many domains come with hundreds of rules and exceptions that were all added for nontechnical, human-driven reasons, and your company probably does not have the power to throw out all existing business practices, human expectations, and regulatory requirements in your domain and replace them with something simple to implement. You just have to suck it up and implement the requirements in the most programmer-friendly way you can, and Go doesn't offer very good tools for that.

Admittedly, Go sets a higher floor than more expressive languages. A smart programmer with poor judgment can do a lot worse in Java or Scala than they could in Go. But Go's ceiling isn't much higher than its floor.

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.

> 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?

> 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.

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.

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.

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.

> 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.