[theshrike79]

This is exactly why I love Go so much. The whole language is just dumb and simple, you need to REALLY work hard to make complex shit with it.

Doing things the dumb and easy (and maybe a bit verbose) way is the path of least resistance.

Compare that with C++ with its templates and Javascript with its ... everything and even Rust. They invite you to make the most complex monstrosity you can manage with all of the fancy stuff at your disposal.

[apta]

> The whole language is just dumb and simple, you need to REALLY work hard to make complex shit with it.

On the contrary, the resulting code bases are more verbose and harder to understand compared to more expressive languages. And by the latter, I'm not even talking about things like Scala or F#. Java and C# are strictly more expressive and have stronger modeling power compared to golang. Reality is complex, you don't want a dumb language to model it because it will translate to complexity in the code base.

[theshrike79]

Here's some expressive code. If you aren't familiar with Ruby, how long would it take for you to decipher what that does?

  def sum_eq_n?(arr, n)
    return true if arr.empty? && n == 0
    arr.product(arr).reject { |a,b| a == b }.any? { |a,b| a + b == n }
  end

The exact same code in Go would span multiple lines, but would most likely only be constructed of a few basic programming idioms that every programmer with a few months of experience can identify.

Code is read 10x more often than written, it should be easy to read and skim through. "Expressiveness" of code is a quick way to get incomprehensible crap that works, but no-one but the creator can decipher.

[apta]

> If you aren't familiar with Ruby, how long would it take for you to decipher what that does?

Why would I not be familiar with the language of the code base I'm working with? This is a fallacy.

Secondly, I don't use Ruby, and from what I can tell, it's finding if any two non-equal elements in a given array sum up to a given number n.

I worked on several golang projects. It gets tedious and messy very quickly seeing code bases littered with one-use functions with what basically amount to map/filter calls being expanded into multiple line for loops. Not to mention it makes exploratory debugging much more tedious.