Rust is to Servo what C is to UNIX. Even though they live their own lives now, the ties are strong.

I think programming languages must be developed with their application. For Rust, it is Servo, Go is for Google, LUA is for scripting video games, Swift is for making iOS apps, and of course C is for UNIX.

Lua wasn’t made for scripting video games but as a scripting language for a mining company if I remember correctly from this excellent paper[1]. I can highly recommend all the other ACM hopl papers too for those interested in the history of programming languages. The papers don’t seem to be open access but sci-hub might help with that if you’re so inclined.

[1] https://dl.acm.org/doi/10.1145/3186277

I once met Waldemar Celes, one of the co creators of Lua. It was meant for use within a tool called Geresim for visualizing large 3D models of oil/gas reservoirs - primarily for Petrobras, the Brazilian national oil company.

The hopl paper on lua seems to indicate it came out of a Brazil university. https://www.lua.org/doc/hopl.pdf

Indeed. It was created at PUC-Rio, my alma mater

Lua means moon in Portuguese! (cognate of Luna)

and there is also moonscript which transpiles to Lua!

This one? https://www.lua.org/doc/cacm2018.pdf

I’d love to see your other suggestions!

Products too! Technology projects without an end-user often become vaporware because it’s impossible to make design decisions without constraints. A real end-user adds constraints. Constraints enable good decision-making. It’s much easier to answer a specific question (“is this a good decision for a bowser rendering engine”) than an abstract question (“is this a good decision for software”).

I don’t use Rust, but appreciate how it solves clear problems. I’m really impressed about the way key issues like packaging & distribution, documentation, and coding style/safety are addressed at the language level. I bet those features emerged from the need to address issues with the open source development model. Without servo, maybe those features don’t make it.

Funny. During my time at Google (7 years, left earlier this year), I can count on one hand the number of people who used Go.

The outside world, though, appears to have embraced it.

My understanding is it largely exists in the confines of GCP as it targets infrastructure mainly

As far as Google's open sourced repos go:

C++ 295

Go 252

Java 235

In lines of code, the open source stuff (barring AOSP and Chromium) are a drop in the bucket compared to internal projects.

Also the easiest way for a Googler to open source a hobby project is to open source it under Google's repos - otherwise you need copyright assignments and stuff that's harder to get approved. So it doesn't represent what most Googlers work on.

> Go is for Google,

Google uses many languages beside Go, and I doubt Go is used much outside of cloud infrastructure stuff. E.g. Fuchsia/Android/Chrome add a lot of Rust code recently, but not Go. In Fuchsia, Rust already surpassed C++ in the amount of code. Google was always a heavy user of C++ and Java and it looks like their modern counterparts are Rust and Kotlin.

Ruby is to Rails.

Not sure why you're downvoted. DevOps is definitely a place where I see Go used most often. Go has a fast compiler giving it a scripting-like feel, very low memory and disk footprint overhead, it is also easy to learn and easy to deploy which makes it a great language for devops - all those tiny programs that orchestrate components of a bigger system. And in this case the simplicity of the language is an advantage as you can find people being productive very quickly, but weak expressiveness is not a problem because you're not building anything large.

However, I would not recommend it for anything that's concurrent, needs high performance and resides on the critical path (critical not in terms of performance but in terms of reliability) or is large / to be maintained by many teams. Just too easy to run into problems.