[chmln]

Almost every point made here is basically false.

The best performing languages are imperative (C, C++, Rust), with functional languages being at least an order of magnitude slower both in benchmarks and real-life workloads. Whatever properties were supposed to make it faster/parallelizable have clearly not manifested themselves very well after decades.

Imperative and parallel code also does not have to be a nightmare at all, as evidenced by Rust and even Go.

[centimeter]

> functional languages being at least an order of magnitude slower both in benchmarks and real-life workloads

Not even the most contrived benchmark games place functional languages an order of magnitude slower than C. Maybe 2-5 times slower on average. Of course, this doesn’t actually matter, because 95% of apps are performance constrained because of architectural reasons, and functional languages tend to scale better in terms of architectural asymptotics.

> Imperative and parallel code also does not have to be a nightmare at all, as evidenced by Rust and even Go.

Go is, by all accounts, a massive nightmare. I think this claim calls your judgement into question.

[sebmellen]

> Go is, by all accounts, a massive nightmare.

All accounts? That's a pretty strong claim. Go works well at Google.

[tinco]

Both of your comments would have been upvoted if they didn't have offensive judgements in the last sentence.

You speak the truth, functional programming languages have excellent performance characteristics when compared to other GC'd or JIT'ed languages.

I'm not sure about FP leading to better architecture, it might just be the type system there, which Rust has adapted (in a slightly less powerful form) as well.

Maybe if you had used Go to solve the sort of problem that it's meant to solve you wouldn't have judged it such a nightmare.

[ncmncm]

The final remark about Go is the only possibly valid remark.

[cy_hauser]

I've used Go for both "web routing" and business logic apps and found it fairly nice. In what context and in what way do you find it a bad?

[ncmncm]

Go was designed as a language with fairly good performance, but with limited capability so that programmers with limited skills would find it hard to get too far into the weeds. It is well suited to undemanding tasks.

Most programming tasks are undemanding, and most programmers have limited skills, so it is a good match for a great deal of routine work. It fits in the same niche as Java, where Java's OO apparatus imposes complications that are superfluous for simple applications, and an actual obstacle in most. So, a language that abandons all that is better in those applications.

Simple tools are not bad except when you need something more. So, my agreement was with the idea in mind of writing Pandoc in Go, which would be madness.

[cy_hauser]

Thanks for the details. I hear what you've said. I agree that Go was built with limited capability in order to make it easy for junior developer. And I agree it can slow down more senior developers at times. Although not nearly as much as I expected when I first started using it.

I don't know Pandoc so I'll take your word for it. I'll also agree that there are entire of classes that Go isn't sell suited for, but we'll have to disagree as to whether it's limiting for the types of applications it was created for. I must not be building the same class of application as you are.

[ncmncm]

By definition, it is not limiting for the types of applications it was created for. We might disagree on where to put the boundary around those applications. Historically, tools have always found uses beyond their intended purpose, and Go is unlikely to buck that.

It really comes down to whether, while working on a big system, you will discover a necessary task that a language cannot do well. This might be because it lacks a key feature, like bit twiddling operations, first-class functions, or operator overloading. It might be inherently just not fast enough to meet a deadline, or not consistently so. It might not know enough about types to prevent common mistakes, or might lack operations on types needed to direct compilation. It might lack the organizational features needed to make a large system manageable. That doesn't make it a bad language, but would make it an unwise choice for a project that might, as time unfolds, be found to need one or other such quality. Generally, the bigger a project is, the more unexpected requirements surface.

This is where we get to the idea of "dynamic range". A language with a wide dynamic range takes correspondingly long to learn. People skilled in it are harder to find and more expensive to hire, you have fewer of them ready to hand, and those you have are likely to be already busy. Yet, you might need more, and any you have more than earn their keep.