3 ms·

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 t

by Zababa 5y ago

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.

dmux 5y ago
>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.
- Zababa 5y ago
  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.".
weakfish 5y ago
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.
- Zababa 5y ago
  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.

by Zababa 5y ago

dmux 5y ago

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

Zababa 5y ago
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.".

weakfish 5y ago

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.

Zababa 5y ago
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.