It seems eminently foolish to think Go isn’t a “real language” for lack of generics—why should we concern ourselves about fools’ opinions?

Saying this about one of the fastest growing languages on the scene right now feels… weird?

Niche in your niche perhaps, but there's a lot of code in the wild written in Go. Hell, all the modern devops tools are written in Go (Docker, k8s & co.)

Meanwhile, as a non Java programmer, I've never seen a Scala app. I know about R, but nothing on my PC is written in it.

Agreed that PHP is massive in comparison to all of them.

Sure, devops tools are usually more fundamental, whereas high level languages are used for things closer to the business. Twitter's backend for example is mainly powered by Scala, but you probably don't know about it, because it is not as visible to you.

Enumeration isn’t a compelling way to indicate relative frequency (in this case, frequency of usage of Go and Scala, respectively). An enumeration of size=1 is even less convincing.

That was not my intention. The example was supposed to show that not all software has the same visibility to software-developers.

> Meanwhile, as a non Java programmer, I've never seen a Scala app.

One widely known Scala application is Kafka. Some parts of it are in Java, but actual core is still mainly Scala afaik.

Yep, Kafka is probably the most popular one. I've heard that the team is looking forward to replace the remaining Scala code in the project with Java once pattern matching and co. land. Spark is another beast that was written in Scala. Many are reporting a high cost for compatibility. Nowadays, Scala community is all about Typelevel and ZIO, if you are not a category theory minded person, then you will have a hard time picking it up.

Zio's library is not based on category theory. In fact, its trying to be the opposite.

> I know about R, but nothing on my PC is written in it.

You could say the same thing about excel macros. They are both tools for wrangling data, tools that will typically not be distributed to end users.

Hopefully not and never.

They already have it with panic and recover. They just don't recommend using it for error handling.

Even if this behavior is similar to how Java exceptions work, I love the way go packages are written.

Explicit error handling can be tedious, but I’m never confused about what some code will do.

Compared to Java where an exception may bubble up 10 layers to a catchall try catch statement, I actually know where the error is coming from.

Would be nice to have this abstracted away with tooling though. I would imagine go generate could be used to great effect in this arena.

Go errors are actually less useful in this case since they do not capture backtraces by default (if I remember well), and invite gratuitous re-wrapping. Most times I had to troubleshoot something it was useful to know the lowest level where the error happened, not the arbitrary level the application/library author decided to be appropriate and missed.

Agreed, there are tradeoffs, but at least Go’s approach has more potential—there’s nothing stopping Go from capturing stack traces and returning them on the error object. On the other hand, exceptions always have the confusing control flow problem.

...because panic and recovery is a whole different plane of existence. Recovery feature is a needed evil here, needless for a simple error handling.

Hopefully they will never introduce commonplace exceptions.

Please dont.