dwyl / dwyl/technology-stack

Rust? 🤓

Open
#103 6 comments 2 reactions 0 assignees View on GitHub
discuss enhancement epic question research technical
Dominant language
JavaScript
Stars
291
Forks
25
PR merge metrics
No merged PRs in 30d

Description

# Context

**`Rust`** has been at the ***TOP*** of the "most loved" programming languages list for the last few years: 🔝
https://survey.stackoverflow.co/2022/#technology-most-loved-dreaded-and-wanted

![stackoverflow-most-loved-programming-languages](https://user-images.githubusercontent.com/194400/188083806-b2d72098-abae-40ff-a6f1-d5fb849089b4.png)

> This year **`Elixir`** was finally [allowed](https://github.com/dwyl/learn-elixir/issues/102#issuecomment-1216314779) on the survey again and no surprise, it's `#2`! 💧 😍
> In previous years it was _excluded_ from the survey so _obviously_ it didn't appear in the results ... 🤦‍♂️

## What?

**`Rust`** is a [multi-paradigm](https://en.wikipedia.org/wiki/Programming_paradigm), [general-purpose programming language](https://en.wikipedia.org/wiki/General-purpose_programming_language). Rust emphasizes [performance](https://en.wikipedia.org/wiki/Computer_performance), [type safety](https://en.wikipedia.org/wiki/Type_safety), and [concurrency](https://en.wikipedia.org/wiki/Concurrency_(computer_science)).

The aspects that appeal to me about **`Rust`** are:
1. **Types** + compile-time type-checking. This is mega helpful in a larger team building more complex software/systems. 👌
2. **Memory safety**; not crashing mid process! (looking at you `JavaScript` - and all compile-to-JS languages!) 🦺
3. **Performance**: execution speed is similar to **`C`** so if we need to perform lots of ops _fast_ ... 🚀
4. "***Recruit-ability***" don't know if that's a word, but you get the idea: finding team members who are passionate about solving problems and writing high-performance code. i.e. the **_best_ engineers**. Ref: [paulgraham.com/pypar](http://paulgraham.com/pypar.html) 💡

These pros are all great, but the **learning curve** for **`Rust`** is **_considerably_ steeper** than for **`Elixir`**. 📈

We have _all_ dabbled with **`Rust`** _informally_, but haven't had a _need_ for it in a project yet. 🧑‍💻
Recently I've enjoyed watching "Code to the Moon" videos on **`Rust`**:

Rust Demystified 🪄 Simplifying The Toughest Parts: https://youtu.be/TJTDTyNdJdY
[![image](https://user-images.githubusercontent.com/194400/188086720-cb46b6be-f554-492a-b998-f10d7a89e231.png)](https://youtu.be/TJTDTyNdJdY)

Rust's Alien Data Types 👽 Box, Rc, Arc:
[![image](https://user-images.githubusercontent.com/194400/188087219-e4d0d6cf-81f9-4c4b-8745-e1a70daddb97.png)](https://youtu.be/CTTiaOo4cbY)

They have been an _acute_ reminder of how much more _complex_ **`Rust`** code is when compared to **`Elixir`**.

I feel that we already have a _superb_ [Tech Stack](https://github.com/dwyl/technology-stack) with [**`PETAL`**](https://github.com/dwyl/technology-stack/issues/87) + [**`Flutter`**](https://github.com/dwyl/technology-stack/pull/80) until we _need_ **`Rust`** for **`performance`** or **`safety`** reasons.
All the [practical reasons why **`Elixir`**](https://github.com/dwyl/learn-elixir/issues/102#issuecomment-445112234) is a great choice for the product/services we are building are still relevant. And the learning curve for new contributors is virtually flat for **`Elixir`** whereas having a **`Rust-wall`** to contribution on our core **`App`** might put a lot of people off ... the counter-argument is obviously that using **`Rust`** would be evidence of our focus on **`performance`** i.e. ["**_Never_ waste anyone's time**"](https://github.com/dwyl/start-here/blob/63468a6bc020f88c762465823da7419478f29687/manifesto.md#your-time-should-never-be-wasted)

## How?

There is a great Free / Open Source Book: https://doc.rust-lang.org/book
and we have a repo _waiting_ to be populated: https://github.com/dwyl/learn-rust

There is evidence that **`Rust`** works on [iOS](https://medium.com/visly/rust-on-ios-39f799b3c1dd) and [Android](https://medium.com/visly/rust-on-android-19f34a2fb43) so we could _explore_ those options but AFAIK it's all very experimental ... 🧑‍🔬
But where **`Rust`** would _shine_ would be in handling a specific aspect of compute for us such as transforming large data structures.
We don't _currently_ have the need for it. Which is why I haven't invested the time to get good at it.
I want to _resist_ the temptation to invent a "_reason_" to use **`Rust`** until we have a legit need.
But if anyone ***`else`*** reading this wants to _proactively_ learn **`Rust`** and populate the [dwyl/**learn-rust**](https://github.com/dwyl/learn-rust) repo ...
It would be awesome if it could match the [dwyl/**learn-elixir**](https://github.com/dwyl/learn-elixir) in terms of getting setup, basic syntax and examples.
I wouldn't be opposed to adopting **`Rust`** for a _specific_ performance/safety-focussed element in the stack.
For that we could either run it as a Erlang NIF function e.g: https://github.com/rusterlium/rustler ***or*** an independent "microservice" e.g. on `AWS Lambda` or `Fly.io` 💭

# Todo

If you want to work on this.

+ [ ] Show your interest in learning **`Rust`** by commenting below.
+ [ ] Start reading the docs/book
+ [ ] Create a **`branch`** and make notes in the [dwyl/**learn-rust**](https://github.com/dwyl/learn-rust) repo.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.