3 ms·

I am not interested in what people CAN make in a language. Anything that can be made can be hypothetically made in any (Turing-complete) language. That is an, I

I am not interested in what people CAN make in a language. Anything that can be made can be hypothetically made in any (Turing-complete) language. That is an, IMO, silly criteria. People made awesome things (for the time) flipping switches and entering opcodes directly at one point. I am interested in a language that makes things easy, clear and elegant. I agree with the original article in that I do not find Go to be any of these for many things I would use it for. Hence, I do not use it. I think the author’s comment that Go ignored a lot of modern programming language theory especially hits it on the head for me.

laumars 9y ago
> I am interested in a language that makes things easy, clear and elegant. Isn't the easiest way to establish that by writing code yourself rather than reading an opinion piece written by someone else who likely has a different coding style to yourself?
- SomeHacker44 9y ago
  Been there, done that. We built a heavily asynchronous back-end communications service in Go a year or two ago. It was a great learning experience. I learned that I don't like Go and its limitations and design choices first hand, wrote a bunch of notes about what I did and didn't like (mostly didn't like), and moved on. We had chosen Go to use for the reasons others here have commented about (especially the part about enabling relatively inexperienced software engineers to be productive quickly), but in the end I felt it sacrificed too much on that altar and I would rather spend more time mentoring and training our software engineers to use tools I felt were better. It's mostly a matter of opinion, like I said - with sufficient dedication you can pretty much do anything with any language. But I'm not investing any more time into Go when I have other tools out there (like Clojure, Rust, Haskell, Common Lisp, C#, various BEAM languages, Ruby/Python, etc.) that I find to be uniformly more pleasant to use.
  - lilbobbytables 9y ago
    Curious what you preferred over Go for the task mentioned.
    - ska80 9y ago
      Haskell has a great runtime and green threads.
    - sridca 9y ago
      I switched from Go to Elixir, and eventually over to Haskell. Never looking back.
    - SomeHacker44 9y ago
      We didn't re-implement it. If we do reimplement it, however, we are likely to lean toward Clojure, as it deals with a lot of routing of unstructured data. Clojure deals nicely with data, transformations of data, and asynchronous processes very well, including having an analog of Go's goroutines and channels, so there would not necessarily need much redesign. A BEAM language would also be a reasonable choice, whether it is Erlang, Elixir, LFE or whatever.
- twic 9y ago
  I don't have time to do that for every plausible new language that comes out. Good analysis of new languages are therefore useful.

laumars 9y ago

> I am interested in a language that makes things easy, clear and elegant. Isn't the easiest way to establish that by writing code yourself rather than reading an opinion piece written by someone else who likely has a different coding style to yourself?

SomeHacker44 9y ago
Been there, done that. We built a heavily asynchronous back-end communications service in Go a year or two ago. It was a great learning experience. I learned that I don't like Go and its limitations and design choices first hand, wrote a bunch of notes about what I did and didn't like (mostly didn't like), and moved on. We had chosen Go to use for the reasons others here have commented about (especially the part about enabling relatively inexperienced software engineers to be productive quickly), but in the end I felt it sacrificed too much on that altar and I would rather spend more time mentoring and training our software engineers to use tools I felt were better. It's mostly a matter of opinion, like I said - with sufficient dedication you can pretty much do anything with any language. But I'm not investing any more time into Go when I have other tools out there (like Clojure, Rust, Haskell, Common Lisp, C#, various BEAM languages, Ruby/Python, etc.) that I find to be uniformly more pleasant to use.
- lilbobbytables 9y ago
  Curious what you preferred over Go for the task mentioned.
  - ska80 9y ago
    Haskell has a great runtime and green threads.
  - sridca 9y ago
    I switched from Go to Elixir, and eventually over to Haskell. Never looking back.
  - SomeHacker44 9y ago
    We didn't re-implement it. If we do reimplement it, however, we are likely to lean toward Clojure, as it deals with a lot of routing of unstructured data. Clojure deals nicely with data, transformations of data, and asynchronous processes very well, including having an analog of Go's goroutines and channels, so there would not necessarily need much redesign. A BEAM language would also be a reasonable choice, whether it is Erlang, Elixir, LFE or whatever.
twic 9y ago
I don't have time to do that for every plausible new language that comes out. Good analysis of new languages are therefore useful.