Comment by Zababa | Hacker News Reader

Comment by Zababa | Hacker News Reader

Parent Full thread

It's surprising to me that as a engineer you seem to be taking pride in not knowing things. I personally have a biais for functional programming in general. I think there is a lot to learn by studying the languages and pattern used. And I think the last 5-10 years have proved that I'm right, as more and more languages are adopting features that were used only by functional languages before. Records, ADTs, pattern matching. I think Go would have benefited from studying these languages.

But I also appreciate Go as a language. I love the wide standard library, I love how asynchronous IO is handled, I love the tooling and the fast compilation, I love the cross-compilation. And more than that, I recognize them as good solutions to problems. I wish other languages would adopt that. I wish making a web server/API in OCaml was as easy as in Go. I wish Rust had some M:N threading model when doing stuff that's a bit less performance-sensitive. I wish Stack/Cabal/Nix were as easy as go build. When I had to make a small program to cut text files for a friend, I did it in Go, and it was a great experience.

We're engineers, let's try to be a bit less tribalist and a bit more pragmatic, and we will all end up with better tools.

>It's surprising to me that as a engineer you seem to be taking pride in not knowing things.

I'm not the GP, but I think this is off the mark. There's a big difference in purposefully choosing boring technology and purposefully taking pride in not knowing things.

I think the message that I initially replied to hints more at the "taking pride in not knowing things", or at least can be interpreted that way easily. A different message, that, according to me, doesn't have this issue would be:

"This is why I enjoy Go, it shepherds you to write clear and uniform code that cannot be mistaken. Go makes well-known tradeoffs that have already been discussed to death, and I find that I agree with these tradeoffs. In my experience, collaborating on Go code is easier as the absence of some means of abstractions prevents people from creating their "language inside the language", and thus allow for a team to share more easily their mental model about how the code works."

You could even add a caveat in the form of "Go isn't perfect, no language is, and has made what could be considered objective flaws. But on the other hand, the handling of things like generics shows that the maintainers are not closed to idea. They tend to err on the side of taking more time to make things rights, even if that time isn't always needed, and that's a tradeoff I agree with.".

My sentiment is moreso that an engineer should be trying to create robust, maintainable software and my experience has guided me towards believing that simplicity is the easiest route to this, which Go solves in my opinion.

I agree with you about robust, maintanable software and simplicity. I also think that Go solves those problems pretty well. My point is that there is no need to put down other things, since simplicity may vary from person to person, teams to teams and problems to problems.

Reply on news.ycombinator.com