29 ms·

Personally I dislike go because of its type system. But I can see why people like it.

bayindirh 3y ago
It's a simple, minimal language which does a lot of things right. I see it as a better C when you don't need to touch hardware or OS kernel. It's great for writing small utils, or doing multithreaded things in general. I don't understand qualms against programming languages. It's a tool. Best one is chosen for the task at the hand and applied to the problem. That's all.
- kelnos 3y ago
  Sure, and some tools are better and worse than others. That's of course a subjective matter of opinion. I personally like things with stronger type systems than golang (and C) has to offer. If I'm going to write a small util and don't care so much about types (or performance), I'll reach for python. If I do, I'll reach for rust. Golang just never seems like the right tool for any of my jobs.
  - bayindirh 3y ago
    Understandable. For what I do, Python is slow, and deployment is a problem (mandatory virtualenvs, etc.). I used to love Python, but Go replaced it immediately, I may say. If I need speed, I use C++. If I need something more complicated than a bash script, I use Python.
- neonsunset 3y ago
  This comment is an easy tell. It's so prevalent. Because no one looked at how Go works, what Go does and what its overhead is. Not even mentioning, rightfully pointed out, a complete joke of a type system that completely disregards any improvements made since 80s.
  - bayindirh 3y ago
    > Because no one looked at how Go works, what Go does and what its overhead is. I develop using Go, thanks. > Not even mentioning, rightfully pointed out, a complete joke of a type system that completely disregards any improvements made since 80s. One of the designers of Go is Rob Pike, who's worked on C, UNIX and Plan 9. I think the language embodies the core principles put out by these "things" pretty well. If we're talking about "development time overhead" of Go, initial momentum building is a bit slow, but after it starts rolling it's deviously fast. If we're talking about "runtime overhead", I can say it's "fast enough" for what it's designed for. If we're talking about "storage overhead", you can always dynamically link it.
    - neonsunset 3y ago
      Using the language is not the same as understanding its design and being familiar with its implementation details.
      - bayindirh 3y ago
        True, yet I tend to read the specs, (bundled) libraries and compiler design docs of the languages I use, because I don't like to fly blind, if you pardon the term. I didn't advance into stdlib and compiler yet (I'm a beginner in Go, I may say), but its behavior didn't disappoint me yet, and the specs make sense. I have a couple of multithreaded tools on the roadmap, which will help me understand the gopher better.
        neonsunset 3y ago
        It's a bad language with obtuse and verbose design, a caricature of Elixir, a mockery of Modula-2 and a cautionary tale of C.
        bayindirh 3y ago
        Which I enjoy. These things are subjective, and I agree to disagree. Have a nice day :)
- kaba0 3y ago
  What does it do right? It has a bad type system, has bad scoping rules (defer does it at the end of the function, really?!), bad conventions (capitalization as visibility, really? Also, unused variable disallows compilation is just absolutely idiotic, there is no sane reason for doing that. Introduce a debug mode and a prod mode, and do so in the latter only if you really want to)
  - bayindirh 3y ago
    It reduces cognitive load, dead code, forces handling errors and forces you to be mindful of what you initialize and use. Don't we use -WError to force warnings as errors in C++? How is this different? You don't have to use defer(), yet it allows for neat tricks for tying ends in fatal situations easily. Its implementation of interfaces feels a bit backwards, but it allows for neat implementations of inheritance and polymorphism. Python uses underscore as visibility convention, how capitalization is different from that? Plus, it has a very responsive and well working defragmenting GC, which is great for keeping tabs on memory use. I'm not a big fan of static compilation by default, but it allows compile once run anywhere (in the same arch) and is an acceptable trade-off for most cases. On top of that it has at least two competent compiler implementations. Go's shallowness is its power, because it forces you to write boring, yet understandable code backed by a GC which reduces possibility of errors and problems a ton. I can throw stones to any programming language. Java for its factories of factories, Rust for limiting for what I can do with my pointers and memory, C++ for its footguns, Lisp for its parentheses, etc. Nobody is forcing you to use Go, Rust or anything. Select the tools you like, and works for problems you have. If we have to have an open mind to accept Rust, and oh we're bullied into that open mindedness to accept Rust as our savior, we can be open minded about Go and look from its perspective, too. Same is true for every programming language actually. From D, to Hare, to Rust, to Go, to C++, to Brainfuck and Malbolge. I can say there's no sane reason for doing that in myriad of programming languages, but these are implemented and in use, so there are sane reasons these things for at least some people. Be flexible. There's no need to be that rigid.
    - kaba0 3y ago
      Fair, I do think that languages are tools and we should select the ones that are appropriate for a task. But that doesn’t make every tool useful, especially that languages do depend on network effects quite a lot, unlike a hammer. There was no need to introduce a language just like many others, and Go - in my opinion - fails to carve out a novel niche of the PL scene, that would have some legitimacy of existing. Rust with all its flaws is novel, there is no other memory safe low-level language (disregarding exotic/research languages). That’s a hugely important niche, so its “hype” is warranted (even though I’m not a rust fan). For Go, even if we limit ourselves to AOT compiled managed languages, there is C#, Java (with Graal), D, Haskell, OCaml, etc. As for your mentioned advantages: > reduces cognitive load In what way? Please don’t come with the usual marketing that “every line is easy to understand blablah”, because otherwise we would be programming in assembly. Too little abstraction is just as bad as too much. > dead code Most AOT languages do that > forces error handling It’s literally C’s errno forced on you by the compiler. I hope we can agree that C’s solution is very far from what one would mean by good error handling. It hides the actual business logic, while not even forcing you to handle it (a random if block is not error handling in itself), and accustoms people to just skip over these. > mindful what you initialize and use That’s only a problem in C and C++. Also, I don’t even agree it does a good job at it, it basically has multiple nulls for example for no sane reason.

It's a simple, minimal language which does a lot of things right. I see it as a better C when you don't need to touch hardware or OS kernel. It's great for writing small utils, or doing multithreaded things in general. I don't understand qualms against programming languages. It's a tool. Best one is chosen for the task at the hand and applied to the problem. That's all.

kelnos 3y ago
Sure, and some tools are better and worse than others. That's of course a subjective matter of opinion. I personally like things with stronger type systems than golang (and C) has to offer. If I'm going to write a small util and don't care so much about types (or performance), I'll reach for python. If I do, I'll reach for rust. Golang just never seems like the right tool for any of my jobs.
- bayindirh 3y ago
  Understandable. For what I do, Python is slow, and deployment is a problem (mandatory virtualenvs, etc.). I used to love Python, but Go replaced it immediately, I may say. If I need speed, I use C++. If I need something more complicated than a bash script, I use Python.
neonsunset 3y ago
This comment is an easy tell. It's so prevalent. Because no one looked at how Go works, what Go does and what its overhead is. Not even mentioning, rightfully pointed out, a complete joke of a type system that completely disregards any improvements made since 80s.
- bayindirh 3y ago
  > Because no one looked at how Go works, what Go does and what its overhead is. I develop using Go, thanks. > Not even mentioning, rightfully pointed out, a complete joke of a type system that completely disregards any improvements made since 80s. One of the designers of Go is Rob Pike, who's worked on C, UNIX and Plan 9. I think the language embodies the core principles put out by these "things" pretty well. If we're talking about "development time overhead" of Go, initial momentum building is a bit slow, but after it starts rolling it's deviously fast. If we're talking about "runtime overhead", I can say it's "fast enough" for what it's designed for. If we're talking about "storage overhead", you can always dynamically link it.
  - neonsunset 3y ago
    Using the language is not the same as understanding its design and being familiar with its implementation details.
    - bayindirh 3y ago
      True, yet I tend to read the specs, (bundled) libraries and compiler design docs of the languages I use, because I don't like to fly blind, if you pardon the term. I didn't advance into stdlib and compiler yet (I'm a beginner in Go, I may say), but its behavior didn't disappoint me yet, and the specs make sense. I have a couple of multithreaded tools on the roadmap, which will help me understand the gopher better.
      - neonsunset 3y ago
        It's a bad language with obtuse and verbose design, a caricature of Elixir, a mockery of Modula-2 and a cautionary tale of C.
        bayindirh 3y ago
        Which I enjoy. These things are subjective, and I agree to disagree. Have a nice day :)
kaba0 3y ago
What does it do right? It has a bad type system, has bad scoping rules (defer does it at the end of the function, really?!), bad conventions (capitalization as visibility, really? Also, unused variable disallows compilation is just absolutely idiotic, there is no sane reason for doing that. Introduce a debug mode and a prod mode, and do so in the latter only if you really want to)
- bayindirh 3y ago
  It reduces cognitive load, dead code, forces handling errors and forces you to be mindful of what you initialize and use. Don't we use -WError to force warnings as errors in C++? How is this different? You don't have to use defer(), yet it allows for neat tricks for tying ends in fatal situations easily. Its implementation of interfaces feels a bit backwards, but it allows for neat implementations of inheritance and polymorphism. Python uses underscore as visibility convention, how capitalization is different from that? Plus, it has a very responsive and well working defragmenting GC, which is great for keeping tabs on memory use. I'm not a big fan of static compilation by default, but it allows compile once run anywhere (in the same arch) and is an acceptable trade-off for most cases. On top of that it has at least two competent compiler implementations. Go's shallowness is its power, because it forces you to write boring, yet understandable code backed by a GC which reduces possibility of errors and problems a ton. I can throw stones to any programming language. Java for its factories of factories, Rust for limiting for what I can do with my pointers and memory, C++ for its footguns, Lisp for its parentheses, etc. Nobody is forcing you to use Go, Rust or anything. Select the tools you like, and works for problems you have. If we have to have an open mind to accept Rust, and oh we're bullied into that open mindedness to accept Rust as our savior, we can be open minded about Go and look from its perspective, too. Same is true for every programming language actually. From D, to Hare, to Rust, to Go, to C++, to Brainfuck and Malbolge. I can say there's no sane reason for doing that in myriad of programming languages, but these are implemented and in use, so there are sane reasons these things for at least some people. Be flexible. There's no need to be that rigid.
  - kaba0 3y ago
    Fair, I do think that languages are tools and we should select the ones that are appropriate for a task. But that doesn’t make every tool useful, especially that languages do depend on network effects quite a lot, unlike a hammer. There was no need to introduce a language just like many others, and Go - in my opinion - fails to carve out a novel niche of the PL scene, that would have some legitimacy of existing. Rust with all its flaws is novel, there is no other memory safe low-level language (disregarding exotic/research languages). That’s a hugely important niche, so its “hype” is warranted (even though I’m not a rust fan). For Go, even if we limit ourselves to AOT compiled managed languages, there is C#, Java (with Graal), D, Haskell, OCaml, etc. As for your mentioned advantages: > reduces cognitive load In what way? Please don’t come with the usual marketing that “every line is easy to understand blablah”, because otherwise we would be programming in assembly. Too little abstraction is just as bad as too much. > dead code Most AOT languages do that > forces error handling It’s literally C’s errno forced on you by the compiler. I hope we can agree that C’s solution is very far from what one would mean by good error handling. It hides the actual business logic, while not even forcing you to handle it (a random if block is not error handling in itself), and accustoms people to just skip over these. > mindful what you initialize and use That’s only a problem in C and C++. Also, I don’t even agree it does a good job at it, it basically has multiple nulls for example for no sane reason.