What language best complements Rust for cloud development?

Suppose you are developing the front end + backend of an app running on either AWS or GCP.

Furthermoer, suppse you are only alowed to use Rust + ELisp + JavaScript/TypeScript + SQL + one more language.

What language would you choose and why?

ELisp is for free because Emacs users need ELisp.
JavaScript/TypeScript for free since every front end developer needs some JS knowledge.
SQL for free since every backend dev needs some SQL.
EDIT: You can also have shell of your choice for free.


The question is what other language would you need?

My personal prefernce would be Go:

  • can be used for scripting, interpreter starts up as fast as Python/Ruby
  • decent library support, has backing of Google
  • static types
  • AWS Lambda suport w/o building custom runtime

What language would you pick and why?

I use Bash because it is also "for free" and it is dead easy when I need to massage some data into shape, invoke it from (parallel) pipes, etc. I know all this is over half a century old but it still works well.

Plus the "everything is just a string" universal type has its benefits. Of course, that is totally the opposite pole to Rust but maybe that is what makes it so complementary.

I am also a fan of integer arithmetic :grinning:

1 Like

I don't see much of use for Go when you have Rust.
I'd choose Python because its productivity and libraries.


I'd say it totally depends on what I'm using it for.

  • Server automation: Bash
  • Um... Everything else: Rust

Python might fit in somewhere in there in the places where you need a scripted language that has some more libraries, though.


Python. It's what the Rust team themselves use for infrastructure automation, when they can't use Rust itself. I would use Bash, if I was specifically targeting Linux or macOS, but if you need Windows support also, it's hard to do better than Python for cross-platform scripting languages.


I am not doubting you. This just really surprises me. For example, for aws/boto3 automation, the first line is often

s3 = boto3.client("s3")


ec2 = boto3.client("ec2")

At this point, the IDE is lost and has no idea what auto completions to do on s3/ec2 variables.

Again, I am not doubting you; I just wonder why Python would be pickec by the Rust team.

It's not clear to me how Go helps if one is already using Rust.

For quick and dirty scripted solutions and prototyping ideas I use Javascript under node.js.

Some years ago when looking into languages implementing some server side shunting of XML data streams around in real-time I found node.js outperformed Go as well as being much easier to write. Maybe Go has improved it's random garbage collector stalls now a days but that ship has passed for me.

As it happens the system we are building now uses Rust all the way from the remote embedded sensor systems producing the data through the cloud services derived from it. We have Python doing statistical crunching on top of that infrastructure.

Still JS in the web mind.

In the past, Rust has deliberately tried to remove dependencies, even build-time ones, on language runtimes.

Python seems to be the exception. The Rust team seems implicitly fine having a Python dependency.

  • Homu is written in Python.
  • Highfive is written in Python.
  • DXR is written in Python, but admittedly that’s a Mozilla tool, not one that the Rust project developed
  • I already mentioned the x.py build system...

There’s probably more random Python scripts lying around that I don’t know about, but these are the big ones. It’s mostly just that Python has never been a problematic dependency; it’s easy to find developers that know Python, it’s easy to find Python libraries, Python can run on most infrastructure platforms that you might need to use (particularly Windows), and since everyone else depends on Python, you don’t need to worry about justifying it (LLVM’s build system needs Python, for example).


This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.