What we did to settle the debate was to ask an entry level dev that was just starting if he was interesting in writing two sample applications in each language, having known nothing of either. Nothing complicated but touched enough points (HTTP endpoints, database interaction)

A full day later was still trying to get the Clojure app working correctly.

He finished up the Go one in like an hour.

Since then we've brought new devs on with zero Go experience and they are up writing good code in a day. I can't imagine where we would be if we had gone down the Clojure route.

It's like hiring a new farmhand and saying, "here, dig two 3 foot holes, and we'll see what takes you longer, this shovel or an excavator you have no training or experience with," and then concluding the shovel is superior for all digging tasks from that point on.

Go probably has a leg up on Clojure for reputation in production projects, considering Docker, K8s, Terraform, InfluxDB, and Geth are all written in Go. The biggest ones I can find written in Clojure are Puppet and CircleCI.

pmuch.

I migrated a team off of an aging enterprise application to the product that was rapidly gaining popularity in industry. I had some expertise and believed in it, I won't name products (and it wouldn't mean anything to HN anyway) but this was a painfully obvious change. We were the pilot project at the company, and went though 6 months of most users struggling. It was about 18 months after adoption that my boss told me he felt like the new product was both better and that the slow down had been worth it.

Life isn't long enough for too many of those experiments. Not everything takes that long. And the experiment could have failed. But the experience really put lots of decisions into perspective.

There's a saying that nobody uses technologies that their boss didn't learn in college. Factually inaccurate, quite astute in message.

Kotlin, for example, is a decent bit more complex than java is. It has a lot of new concepts to learn.

Yet, most Java devs can be productive with kotlin in a day or two. Even with the added concepts, it's not that different of a language.

The same is true of C and C++. A C dev could jump into C++ pretty quickly (even if they are just writing C with classes to start).

Your analogy is more like "Dig a hole, here's a shovel and here's a post hole digger". The familiar tool will likely go faster than the unfamiliar tool. And, as it happens, most devs are highly familiar with imperative programming styles, not so much functional programming paradigms.

It accelerates junior devs to production ready at the expense of everyone else.

It really feels like a language designed by people with utter contempt for those who actually write code.

Ultimately this is a disservice to those with any talent as it leads to a work environment where they are relegated forever to the lower ranks (unless they give up coding and move into management).

As you churn employees, anyone new will inevitably be "junior"[1] when it comes to your code base - Go is (mostly)[2] ridiculously easy to read because you can't (easily) do things[3] that make reading - and more importantly, maintaining - it hard.

[1] Sometimes literally a junior too.

[2] There's a few things I think might trip up someone brand new to Go.

[3] Looking at you, Perl and Ruby.

There's a good middle ground that can and has been achieved by other languages.

The "test" itself I agree is a bit shortsighted. I think Go might be a fine choice over time anyway, but the experiment itself doesn't necessarily highlight the things I'd want to highlight for medium- to long-term viability.

Python would beat anything by this measure, but static typing is amazing for stopping bugs.

Also he learned enough Clojure to mess around in, again with 0 knowledge about it. Again impressive. Or is this industry standard competency in some fields?

It would be like deciding to dig the channel tunnel with a spade because TBMs are quite complicated to set up.

It makes sense in retrospect of course, python and ruby are slow, dynamically typed languages, and any improvement in performance and typing is welcome. It doesn't mean that golang is inherently better somehow to other offerings. I still maintain that Java and C# are superior languages and ecosystems.

Performance-wise, C# and Go are head-to-head: https://programming-language-benchmarks.vercel.app/go-vs-csh... I also would say Go has been much more adopted for cross-platform use than C# ever was. Regarding language features, Go's devotion to staying intentionally bare-bones is worth a lot. C# may be more elegant in a lot of ways, however it seems to be in the process of being choked by Microsoft's continuous feature-creep.

There are, of course, other benchmarks that rank c# above go, but benchmarks are flawed. I imagine people are comparing C# to go because it's got a pretty solid type system

On Github[0], Go currently sits at #3 for pull request volume (C# is at 10), #3 for stars (C# is at 8), #6 for pushes/commits (C# is at 10) and #6 for issues opened (C# is at 9). By each of those metrics, Go has a significantly more vibrant ecosystem than C#.

[0]: https://madnight.github.io/githut/#/pull_requests/2023/2

https://survey.stackoverflow.co/2023/#most-popular-technolog...

Now, whether that would move C# over golang, I wouldn’t dare guess.

This is one of the better rankings. But I would add that these will significantly underrepresent enterprise-type projects, where C# is often used. Some say that job listings give a more accurate picture, and while I didn’t look it up, I do believe that C# has more positions.

I'd respectfully disagree with this statement based on my personal experience. Ever since .NET Core was introduced, I've noticed a significant shift in the hosting of ASP.NET apps. Many developers, including myself, now prefer hosting applications in containers on Linux systems rather than relying solely on Windows. This change reflects a broader trend among C# developers.

While I understand that my perspective might not encompass the entire developer community, I strongly believe that the adoption of Linux-based hosting for ASP.NET applications has grown considerably. It demonstrates the expanding reach and influence of .NET Core beyond the Windows ecosystem, proving its establishment in other platforms.

Please note that this is solely my viewpoint based on my experiences and interactions with other developers. Other opinions may vary, but I remain confident in the growing prominence of .NET Core outside of the traditional Windows environment.

Fine. But it's beside your parent comment's point. The article claims that everyone thought Go's type system was an advance on the state of the art. This isn't even close to true.

I'm not sure that this successpoint is really that valuable. It sounds more valuable for those who want butts in seats than it does for long term satisfaction and survivability of your code base.

It's a great language for some problems, horrible for others. The problem is people tend to talk as though everyone works in their domain.

It won't stop you from asking wtf did someone write this and then doing a git blame and seeing your name.

Type annotations for top-level definitions are often encouraged for readability and better error messages, but the compiler can almost always figure everything out itself.

> Type annotations for top-level definitions are often encouraged for readability and better error messages, but the compiler can almost always figure everything out itself.

See? That's not a good thing at all. If the compiler's capability makes the code less understandable, then it's undesirable. Doesn't matter how fancy and cool, or state-of-the-art it may be.

You probably don't want to strap a jet engine to a car, no matter how cool you may think it would be.

As usual C++ choose to something much weirder and more dangerous. Instead of inference C++ can deduce types, in some cases there's no way to write a type's name so you have to deduce types, and they can be deduced at the edges of functions however unlike inference it's not an error to have ambiguity, in some cases deduction may choose one of the possibilities that it liked better even if that's astonishing for you.

Because Rust's functions must tell you their types explicitly, and because some types can't be named specifically, the result is that in Rust you have to write these functions polymorphically, even if in practice there's only one possibility. In C++ you can write the non-polymorphic function, despite not being able to say the name of the type. How do you document that? It's OK, C++ doesn't require you to provide even halfway usable documentation.

I think PureScript has the best compromise here, top-level type signatures are not enforced but if you don't include one you'll get a warning with the inferred signature. On the one hand, this is very helpful because sometimes I have a grasp for what expression I want to use, but am not sure about its type, so I simply comment out the desired signature and let the compiler tell me which direction I'm moving in, i.e. what's the type of what I just wrote. On the other hand, it being a warning also basically ensures nobody writes their top-level functions without the type signatures. Really the best of the two worlds. I think simply disallowing top-level functions without type signatures would hurt my workflow a lot.

Kubernetes is cool, I want to play with Kubernetes.

Maybe I should lean Go to play.

What is that?

Typescript and swift have shown a better type system can appeal to the masses.

Key language designers left after this.

However it seems to have enough management support, that since it found an home in Flutter, I would assert there are having more adoption than Xamarin, React Native or Cordova.

And nothing says that go wouldn't have been more successful had they added those features. In the final analysis, the relationship between the success of a language and any intrinsic qualities is very hard to qualify. But IMO, the success is not a good measure of wether or not the criticism of go were/are valid.

> Go made me truly realize how insufferable the PLT community is

Agree PLT folks can be a passionate bunch, i am not sure they are any worst to any other online community.

> and why they are so absolutely lost when it comes to creating successful languages.

Depends on who you include in the PLT group :

- C# and typescript were design by Anders Hejlsberg , arguably the most successful language designer - Scala is also pretty successful and really tied to the PLT community - Kotlin by JetBrain, Dart started with Gilan Bracha

Not to mentioned the wide range of features seen in most recent language (async-await, reactive programming for msft research) etc... etc...

The fight between pragmatic and simple language vs complex and expressive language is not happening outside the PLT, we have proponent of both ways of thinking inside the community. Not everyone in the PLT is pushing for overly complex theoretical approaches.

But more importantly, let's not forget the 1000's of engineer quietly implementing the compiler, libraries etc... that make go, or any other language possible.

Back to go, my personal gripe with go wasn't the decisions they made, but the rational given for those decisions.

Take the most famous example of not including generics. Designing a good generic type system is a very complicated task, and if the team had come out and say they didn't want generics because they didn't have the bandwidth or the know-how to do so, i wouldn't have care. But the rational given, describing generics as border line useless, or somehow too hard for the average programmer to grasp not only fly against basically 25 years of programming language history, but were just plain rediculous.

Not at all. It's the same as with literally any other product. If it's good, people will use it. Outliers are rare.

Now, you may disagree with what most people consider good, but that's another discussion ;)

"Just get-good at making products, duh"

That's why I didn't mention it, it's boring table-stakes stuff. Obviously if you don't tell anyone about your product, no one will use it. That's not the hard part.

The hard part is of course making a compelling enough product that people actively want to use it. The really good products even advertise themselves to a certain extent.

They aren't lost—they're just more interested in actually good ideas than in popularity. Popular languages must appeal to all kinds of programmers with varying backgrounds, so they are heavily constrained. Your argument is basically that mathematicians don't know what they're doing because their most advanced theories aren't used by mechanical engineers.

Meanwhile, most code is still written in languages like Java, C and PHP.

That's no value judgement or anything, I don't think Java is an amazing language (neither do I think it's a terrible one), but it's not like Go has revolutionised anything. It's just become a new option among many.

Kubernetes adoption seems to be going up but does it really add value for most that adopt it? I would say, no.