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.
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.
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.
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.
> 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.
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.
True. But writing short critical posts on HN isn't the same as understanding the language, either. Why should we believe your opinion on the language to be more correct than bayindirh's?
Frankly, you sound like a zealot, and I distrust zealots in the area of computer language design. (I distrust them in a lot of other areas, too.) I trust pragmatists a lot more.
You've shown off a decent vocabulary, but there's far more rant than substance. Got any substance to show us why we should listen to your opinion?
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)
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.
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.
> Go - in my opinion - fails to carve out a novel niche of the PL scene, that would have some legitimacy of existing.
People love to bash C++ and try to replace it day and night. Go is not trying to be "the next step" in programming. Its promise is simple. C, reimagined, for relatively simple tasks. Plus it adds some batteries: green threads, a GC, modern utilities like JSON, HTTP, flag support, better portability out of the box, integrated testing, etc.
In short, it's a better C, written in the spirit of UNIX/Plan9. I didn't expect a cutting edge, exciting, "knocks my pants off" language when I started using Go. It's a mundane tool to be honest, and I prefer boring technology for myriad of reasons.
It's designed to be boring, to get the job done. Not to excite people with cutting edge stuff, and this is the novelty of Go. A collection of mundane ideas combined with care, resulting in a superior experience with no surprises (for the most part).
> In what way? Please don’t come with the usual marketing that “every line is easy to understand...
No, not in a line by line basis, but in project scope. See, Go is a simplistic language. You can't do "interesting" things with it much (e.g.: I love auto-tokenization tricks in C++ iostreams, but it needs an innate understanding how "<<" works in C++ universe). This means there's no hidden "magick" under the code to unpack. As a result, the written code is shallow, transparent and boring. When you open a Go project you don't know, reading it is easy. Because there are no tricks. As a consequence, when you don't think of tricks, but of simple utilities and function calls, the state you keep in your mind becomes smaller.
This results in two things. 1) You can see the whole picture with less energy, resulting in better architectural awareness, 2) You can resume a project much faster, because there's less context to load from memory and code structure. I resume my paused Go projects under 10 minutes. Which is fast.
> Most AOT languages do that
Compilers eliminate dead code, correct, but it lives in your codebase nonetheless. "No unused variables and no unused imports" make you remove the dead code from the codebase too, resulting in a leaner codebase with less head scratches. Less complex codebases means less bugs, more understanding, and faster work. See my previous point.
> 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.
Personally I have no qualms with errno based error handling (and no qualms with exception handling (try/catch and friends)), plus Go's errors provide more context, because error is an object carrying much more information w.r.t. an integer. Also, it makes error handling a must, and skipping over error handling voluntary. If you use "_" instead of error and do not handle it, it's on you now. You had the chance and you skipped it. I think it's a pretty neat mechanism: "You knowingly opt out handling a possible error, and it's your responsibility now. Roll with it". Everybody says that "safety must be on by default". It's Go's safety, and it's on by default. Accepting risks is programmer's own choice.
> That’s only a problem in C and C++.
No. I can leave dead assignments in every language I know, and while it might be eliminated by the compiler itself, it's again cognitive load on the codebase maintainer. See my previous points.
> Also, I don’t even agree it does a good job at it, it basically has multiple nulls for example for no sane reason.
Every language has its peculiarities for "no sane reason" for some people. OTOH, some other people think the reasons for these peculiarities are sane and well justified.
But I can see why people like it.