Go just sells itself well.
Languages that _actually_ make concurrency easy, such as Haskell, Scala, OCAML or distributed concurreny easy (Erlang/Elixir) are way ahead of Go but are not as hyped and are not marketing themselves as well.
Languages that _actually_ make concurrency easy, such as Haskell, Scala, OCAML or distributed concurreny easy (Erlang/Elixir) are way ahead of Go but are not as hyped and are not marketing themselves as well.
In absolute terms? Yes In terms relative to the userbase? No In terms relative to how powerful or well-designed the language is? Certainly
Go is like a rusty old hammer that will just work and there are not too many ways to hold it. I like Go for this. I think it has a great design. I can do most things from the top of my head. Code reviews are less painful. And I like that the language evolves more slowly and does not pile every crap idea on top of itself. I also know that a language doesn't have to fill every niche..
In the end Go is a productivity language. If you want to get stuff done it is an excellent choice. If you want to muse about the beauty or correctness of your code there probably are better choices.
> In the end Go is a productivity language. If you want to get stuff done it is an excellent choice.
Maybe for mediocre developers. And there are a lot of them and that is totally okay - everyone has been one at some point. But more experienced and developers who do their job with passion and strive to improve, will be limited by the language very quickly which makes them much less productive. Therefore, with good developers, go will reduce productivity in comparison to some other languages.
Another note: most of us are "mediocre" and many of those who think they are somehow great, often turn out to be just "mediocre" themselves when put into a certain situation.
And maybe you are truly a genius, only work alone and Go really limits you. You are free to choose whatever language you want. But don't project your outlier experience onto everybody or even onto teams of people with vastly different skill levels.
Yeah I fully agree - there is nothing bad about that at all. But that does not change what I'm trying to say: once you grow more skills have more experience (which happens to most people), go starts to limit you a lot more than other languages. No "genius" needed. And it's not only me thinking that if you look at the other responses here.
So, hype go as an easy language to learn? Fine by me!
Hype it as a language that is more productive than others? I have to disagree.
You can also get stuff done with other languages. Big surprise.
And there are non-rusty hammers that also "just work" and don't exactly introduce an insurmountable dilemma when it comes to holding them, as well as having pretty basic variations to the hammer head that actually make it easier to "get stuff done" (such as a claw or a peen).
But the people using the rusty hammer like to pretend as though anything other than the most basic form of a hammer (double flat head on a handle) is just "fancy feelings" driven musing about "beauty or correctness".
As its written, your comment reads more like language warfare than discussion
I was extending an analogy that was already presented. The context is, funnily enough, right above my comment if you'd like to read it.
And I don't have strong feelings about Go; its existence is ultimately irrelevant to me as a dev. I do have strong feelings about a certain cadre of Go enthusiasts, however.
> What is this "insurmountable dilemma"
It doesn't exist. That's the point. Said enthusiasts like to pretend as if everybody else is absolutely drowning in a dilemma of which way to achieve X in their language of choice, while Go is for "getting stuff done"™, because obviously no-one ever did anything apart from bikeshedding prior to Go's appearance.
> or the "basic variations to the hammer head"
Any number of programming language features/concepts which some Go enthusiasts like to decry as unbearably fanciful complexity. If it's not in Go then it must be Bad regardless of being objectively superior to whatever Go offers as a replacement. Parametric polymorphism is perhaps the most infamous of these, and even with the Go team moving forward with a specification for generics there are still people that complain about the language losing its "simplicity".
> As its written, your comment reads more like language warfare than discussion
Of course. And relegating people's preferences in their work tools to "musing about beauty and correctness" (presented as caring less about productivity) is "discussion" not language warfare.
Rust for instance is not among greatest when it comes to language features either (the borrow checker is quite a thing though), but it combines lowlevel/performance with FP and language features that enable a high level of abstraction. I'm not really a Rust fun either, but that is a personal opinion and has nothing to do with my impression of if the hype is justified.
I think Go has some pretty good thoughts behind it's design. That is not to say that it is perfect by a long shot. Lack of generics is the main reason I've not actually tried to write any.
But I've looked at some, and even helped debug a tiny bit.
And that was the -nice- thing about it; the patterns are simple enough that you can learn it quickly.
The drawback is that you have to write a LOT of code (or Interface hackery) to make complex things.
And, on one hand, the syntax is still the same. On the other hand it's still more code to write.
I think about C# a lot when I think about Go's simplicity; I'd argue there's a sweet-spot in C# where you COULD write code that is expressive and easy to understand but still more flexible. However, at this point there are 3.5 different ways I can think of off the top of my head to go through an Array/List in the language.
In Go there's usually not too many ways to do the needful. That's an advantage for newcomers, but the proverbial ceiling isn't glass; it's hard iron, and you can't go above it.
Consider checking whether an element `e` is in collection xs
JS: xs.includes(e)
Python: e in xs
Java: xs.indexOf(e) != 1
C++: std::find(xs.begin(), xs.end(), e) != xs.end()
It is already pretty verbose in C++.
Go: contains := false for _,x := range xs { if x == e { contains = true break } }
Some fanboys claim Go is readable. Readability is not about conveying what each line does in micro level, it is about conveying __Intent__.
Go is nothing more than C as far as facilities to convey intent are concerned.
If you want a 1000 households to visit a set of shops in a repeatable Random order until the shops runs out of stock, that’s a List sort with a seed and a sequential loop
Make the 1000 households concurrent and sending messages and it becomes a major exercise in clocking, scaling and scheduling.
Starting 1000 processes is trivial and fast in Erlang. See the first few pages of Joe's presentation from 20 years ago: process creation time ~10us (up to 30k processes); message time ~1us [1]. The code is in his book and the email thread [2]:
[1] https://www.rabbitmq.com/resources/armstrong.pdf
[2] https://erlang.org/pipermail/erlang-questions/2007-July/0280...
https://learnyousomeerlang.com/distribunomicon
> distributed programming is like being left alone in the dark, with monsters everywhere. It's scary, you don't know what to do or what's coming at you. Bad news: distributed Erlang is still leaving you alone in the dark to fight the scary monsters. It won't do any of that kind of hard work for you. Good news: instead of being alone with nothing but pocket change and a poor sense of aim to kill the monsters, Erlang gives you a flashlight, a machete, and a pretty kick-ass mustache to feel more confident
> This is the standard 'tools, not solutions' approach seen before in OTP; you rarely get full-blown software and applications, but you get many components to build systems with. You'll have tools that tell you when parts of the system go up or down, tools to do a bunch of stuff over the network, but hardly any silver bullet that takes care of fixing things for you.
As for the weird syntax, I use Elixir (https://elixir-lang.org/) on the daily and its pretty great. See here for a different write up I did https://news.ycombinator.com/item?id=24173635
But I don't see how such a purely mathematical viewpoint could fit nicely into the real-time world where processes evolve concurrently and can take different times to do things on different executions. In the real world things are mutable, and concurrent programming must take that into account. Therefore it is "complicated".
Same for OS threads. We use green threads in Scala for a long time now, there is a great amount of library support. Here is some example: https://zio.dev/docs/overview/overview_basic_concurrency