Go, Rust, Haskell, come from diffent ways of thinking about how to solve problems using programming languages..
Go aims to be more simple and concise, in the end you write less code to do the same thing, as you would in C++, Haskell or Rust.. because those 3 languages decided to "cover everything" and are worried about other things, creating more burden to the programmer, but with something else to gain
Go is more of a productivity language.. it remind us the we have better things to do in life, and not spend all the time coding, but enjoying that extra time with your family for instance..
Therefore Go is good.. its only MAYBE "not good" for the same thing that Rust, or Haskell are..
Besides.. this is the wrong way to market some technology or idea.. the best way would be "Why Rust or Haskell are Good"
instead of envy the success of others..
Its all about tradeoffs.. and i think this article misses the point.. and care only some things that will obviouslly make some languages more fit.. like, if you care more about memory control,type systems and safety.. its obvious that Rust and Haskell will look good and "correct"
But this is not all about it.. theres team working, productivity.. its a balance.. and always depends of the problem domains.. some language are more fit than others.. theres no need for bashing
You made the claim that "in the end you write less code to do the same thing, as you would in C++, Haskell or Rust". Can you provide any examples where the Haskell equivalent isn't more concise than the Go equivalent?
As a data point, here are links to the Haskell and Go implementations of the TechEmpower benchmarks:
Anyone can encapsulate or "hide" the inner workings so the resulting code will look small.. how much of that code in the frontend is already implemented in the standard library of each language??
To see the reality of it.. a better example would be something without any support library...
Picking something without a library will give an advantage to the other language in most cases because Haskell is very library based.
I didn't cherry-pick btw, I just went to the first benchmark which included community-written snippets of both Go and Haskell I could think of. Cherry-picking would be me intentionally skipping over examples such as the one you provided and instead posting my example.
I´ve provided the links as a example of cherry-pick from my part.. showing that its easy to come with something that looks good..
FP tend to be more expressive, and make you feel more powerful.. but they also tend to be more complex and more verbose.. thats the price of power.. it's the trade of
I think its not enough to show something simple, but with the real complexity hidden in some hidden layers..
Also if line of code is the measure of simplicity the Brainfuck language would win everything.. but it doesnt mean you can read what the code express with less effort..
Nothing against Haskell in particular, only that it doesnt shine when the matter is simplicity..
Expressiveness.. Abstraction power.. shure.... but that was not the original point i was making in the original article
Go aims to be more simple and concise, in the end you write less code to do the same thing, as you would in C++, Haskell or Rust.. because those 3 languages decided to "cover everything" and are worried about other things, creating more burden to the programmer, but with something else to gain
Go is more of a productivity language.. it remind us the we have better things to do in life, and not spend all the time coding, but enjoying that extra time with your family for instance..
Therefore Go is good.. its only MAYBE "not good" for the same thing that Rust, or Haskell are..
Besides.. this is the wrong way to market some technology or idea.. the best way would be "Why Rust or Haskell are Good" instead of envy the success of others..
Its all about tradeoffs.. and i think this article misses the point.. and care only some things that will obviouslly make some languages more fit.. like, if you care more about memory control,type systems and safety.. its obvious that Rust and Haskell will look good and "correct"
But this is not all about it.. theres team working, productivity.. its a balance.. and always depends of the problem domains.. some language are more fit than others.. theres no need for bashing