> I'm positive linguists aren't happy with English becoming the global language either

Nit: Linguists do not hold prescriptive opinions about the "quality" of languages. They analyze languages to form descriptive theories about the structures and features of certain languages. I only nitpick this because, while having a lingua franca is certainly valuable and there is nothing "bad" about English any more than literally any other language, the closest thing to this in programming "languages"/notations is actually C, not Go. It's hard to overstate the invisible influence on C on basically every mainstream language and how we think of programming and computers in general.

An interesting analogue to your example of English is the varying efforts to transliterate most languages into using the Latin alphabet, much like how many programming languages today need/greatly benefit from a compatibility layer with a C compiler/the C standard library.

> There's no perfect language, yet people are always trying to find one. It's OK if you don't like Go and prefer another language, the real devil / tradeoff is in the fact that conformance to a single language (or set of languages) is such a strong social phenomena. I think that's why people end up so angry with viewed-as-subpar languages like Go gaining so much traction

I hope my post didn't come across this way. To be clear, I think Rust and Swift (as two examples that I mention multiple times) have a lot of problems (slow compilation being a very big one), and are by no means perfect. I'm not angry at Go's popularity as much as wanting improvements to the developer experience.

An F# program can be about as mundane as a similar Go program, only concise.

This is like the C++ argument that you should just use C++ because it has almost every feature so you can just use the ones you want and ignore the others. Of course, in practice you still have to deal with colleagues and upstream packages that use features you don’t like. Same deal with F#—you could write F# in a Go-like style, but you’ll be swimming against the current. And the only advantage is a little less verbosity, which really isn’t anyone’s bottleneck—people over-index on minimizing localized boilerplate and ignore the costs of gratuitous abstraction.

Type-inference is a zero-cost 'abstraction' and any place you choose can make explicit narrowing of them. The libraries I needed to make a web application didn't have any mind-bending patterns, but rather did the most obvious things with the basic language features.

Scala and Haskell are pretty much "dead" language, I worked with Scala in the past, it was impossible to find poeple willing to work with it so everything was re-written in Java.

Im not sure its fair to call Scala dead. Its still pretty widely used, at least in companies in London. Hiring is a bit more competitive but we still get some great Scala devs interviewing for the more senior roles.

Disclaimer - I work with Scala every day, so am definitely highly biased.

I worked at a Scala shop about 10 years ago. Everyone had their own preferred "dialect", kind of like C++, resulting in too much whining and complaining during code reviews. IMHO, the language is too complex. Also, the compiler was slow, and the IDE support was plain awful (Eclipse was especially bad, IntelliJ was better.) Keep in mind this was over a decade now, so I'm sure things have improved.

This was my experience as well. I worked at a place that used Scala primarily in the "better Java" style and enjoyed the language a lot. I moved to a different company and the lead programmer there was a functional purist who insisted on putting scalaz/cats into everything and using Scala as Haskell lite, despite it really not being appropriate for the use case. It really soured me on the language.

There’s no bigger productivity killer than scalac and sbt.

I work in a Scala shop with 500k lines of Scala. We're moving to a Bazel-based development workflow because SBT is a slog and doesn't handle incremental compilation well at all.

Is it still that way? I've thought about taking another look at it for personal projects.

By the time the sbt shell starts I swear to god maven would have my project fully packaged.

Not parent but yes it is.

Scala is definitely not dead. Sounds like a recruiting failure than anything about the language itself.

I learned Scala a while ago on the job, and I’m grateful for that opportunity. Nobody on your team volunteered?

Lol. Why would people be unwilling to work in Scala. I moved from Java to Scala and it was a breath of fresh air. We’ve had no trouble hiring people who didn’t know Scala but learned it on the job. It’s not rocket science.

Scala just got a new version, which fixes plenty of shortcomings. It also has an option to exclude the null value from the language, so I wouldn’t call it dead by any mean of the word.

It is also running splendidly at plenty of companies.

I bet plenty of universities will keep using them beyond our lifetimes.

From that point of view they are doing quite well.

you can also take a Latin course in college. how "well" is Latin doing?

Good, it is still the official language in Vatican documents, has an updated dictionary, and some European countries see it as a CV requirement by most HR departments when hiring for top management positions.

> some European countries see it as a CV requirement by most HR departments when hiring for top management positions.

This sounds utterly bizarre, I have a very hard time believing this. Which countries would that be?

I can't confirm the specific example, but this sounds like a smoke cover for nepotism and/or classism. If you're not allowed to recruit solely from your personal friend group, requiring that applicants be able to speak a dead language let's you select that same group of people while giving a flimsy justification.

So, just like strong idiosyncratic preferences for particular programming languages.

In France for example, it used to be that all good family kids studied Latin, so high league universities and was seen as plus on the CV, at least for 20 years when I used to live there.

France would be a typical example, except that this is an urban legend.

Context: I graduated from the 3rd best high school in France, then from one of the Grandes Ecoles (~ Ivy League). I was born in the early 70's in Versailles.

German and Latin were seen as languages where the best students meet. This was a vision of the parents without getting in the reality. The best high-school students were everywhere.

I had Latin and Greek in mid-school and high school like anybody else. Complete loss of time when you are not interested.

At university it did not matter at all.

Today, when recruiting even for the "really French" companies nobody would think about Latin as a discriminant. It literally wouldn't cross anyone's mind.

There are urban legends everywhere, this is one about French education (which is sometimes great, and sometimes completely backwards to the point where I doubt the decisions makers have ever seen kids in real life)

As for today (and not 40 years ago), in the class of my son in that same elitist high school, one student does Latin and Greek. Because he is interested in the languages.

That’s pretty good for a dead language, but not so much for a living one to the OP’s point.

> so.. Haskell and Scala? Those would be the top two that come to mind for me when someone says "highly 'logical' and 'compose well'", "having sum types", 'more expressive', etc.

I don't think Haskell composes that well; monads don't combine well (not that I could do better) since you can only stick them together in an ordered way, the lazy evaluation makes it complicated to see how your program will run by reading the code, and so on.

Btw, "sum types" means enums; it's not actually a super-complicated Haskell only feature.

Do you write imperative programs that execute statements — out of order? Ordering is precisely the point of monads, since they are monoids as well.

And sum types are most definitely not enums, though Rust’s enums do use a bit strange terminology here.

> Do you write imperative programs that execute statements — out of order? Ordering is precisely the point of monads, since they are monoids as well.

Sure do. After all, your superscalar CPU executes things out of order, and C is a pure functional language in the memory monad.

http://conal.net/blog/posts/the-c-language-is-purely-functio...

> And sum types are most definitely not enums, though Rust’s enums do use a bit strange terminology here.

Swift's enums too. But sure, in C it's an enum with a union at the end.

Well, being pedantic, sure almost every modern CPU uses OOE. But they must do so with the huge caveat that from the outside it should be equivalent to executing it in serial (notwithstanding CPU vulnerabilities). But this is an implementation detail only, we could just as well use an older CPU design.

Having written a lot of Scala, I generally agree until you can form a team that knows what they're doing or has a background in Scala. After that, Scala shines as the codebase(s) scale.

Substitute Scala for any other programming language and the statement still holds.

Experienced developers and those with specific language expertise excel when implementing in that language.

Who would have expected that? /s

The point is the barrier to entry for Scala is higher but once you have a skilled team working in Scala, you probably get more velocity than others due to the language ergonomics.

I don't think there are any (many?) studies on this subject. Much less that confirm this particular bias you've shown.

> mundane, repetitive, boring language

These apply just as well to assembly, yet they are the reasons almost nobody tries to use it.

> so.. Haskell and Scala? Those would be the top two that come to mind for me when someone says "highly 'logical' and 'compose well'", "having sum types", 'more expressive', etc.

I wrote Scala for years - it might be a bit too complicated but overall pretty decent, but I hear good things about Scala 3. I think the ML's, of which it takes inspiration from, are probably a better match. OCaml (EDIT: or F# as another comment mentioned) for instance is a pretty nice balance.

Haskell is very nice and I think qualifies except that it is pretty hard core purely functional with no punches pulled (unlike ML), so is foreign enough for most people not to be deemed a candidate.

I like Rust probably best atm as it is "imperative but with a functional flair", but doesn't qualify as easy I don't think, but is definitely highly logical and composes very well (even if obviously not finished yet).

> I've heard they're great languages (haven't used them much myself), but I probably wouldn't choose them for say an early-stage startup. Go's value is in being a mundane, repetitive, boring language. It makes it easy for any random kid to dive into an existing code base and become productive, that can be super valuable.

I would probably agree on the novice programmer and picking up Go quickly which is arguably the prime feature of Go. I just question the quality of that code, and honestly, don't feel Go is nearly as easy as touted. It is simple for sure, but not always easy. I always had to look up simple things like those magic comment compiler directives and is that interface{} param a pointer or a pointer to a pointer? I just remember the lack of expressiveness actually causing real world confusion (for me at least).

> There's a gradient of programming languages where one side is "has a single expression for exactly your problem, a single unique expression you've never heard of exists to solve every possible problem" and the other is "requires thousands of expressions to express your problem, but only a thousand are available" - or something like that.

While true, I would argue we have found a small amount of constructs that fit well 80% of the time, and is demonstrability better than half the constructs that fit well 40% of the time. Trying to solve every problem with a new construct is not worth it, but nor is the opposite extreme IMO.

> My point? There's no perfect language, yet people are always trying to find one. It's OK if you don't like Go and prefer another language. A real devil / tradeoff is the prohibition of using languages that do not conform with past (company) choices.

Honestly not sure we've found the ideal language yet, and agree there is subjectivity and trade offs at about every turn. In fact, the only thing I'm certain of is that Go missed what I would look for in just about every category except a few (but I agree it is easy to learn, but does it matter if you can't write good code with it?). That said, very intelligent and respected people disagree with me, so to each their own.

> I like Rust probably... (even if obviously not finished yet).

what? what languages fit your definition of finished?

My disappointment with Rust, that in no way diminishes how much I enjoy using it in my own time, is that I have a hard time recommending it for microservices, which are arguably an average project at an average company. The ecosystem just doesn't feel as fleshed out or complete as in Go. It's a shame because there's libraries in Rust that I adore like clap, serde, and diesel but when I last wanted to write something that integrates with AWS, I found a deprecated unofficial crate and a non-production-ready official crate from AWS.

I don't know whether to attribute this disappointment to the breadth of what Rust can be used for and the difficulty in doing all of them well, or a lack of wider/corporate buy-in for these use cases. It's a pity, because after getting past the initial learning curve I struggle to find anything wrong with the language itself.

FWIW, AWS now have an official SDK for Rust in beta:

https://aws.amazon.com/sdk-for-rust/

There are people at Microsoft working on a Rust SDK for Azure, but it's explicitly a volunteer effort with no support guarantees at the moment:

https://github.com/Azure/azure-sdk-for-rust

These days I probably would not look at any language that did not have SDKs for AWS and Azure, for similar reasons.

What tools or libraries is Rust missing for building microservices?

They already mentioned AWS support was poor, which I can't confirm. I can say that GCP support is subpar. Comparing Python's GCP library with Rust's is a world of difference.

> It makes it easy for any random kid to dive into an existing code base and become productive, that can be super valuable

professional developers are rarely “kids”