DEV Community: Niclas

Luxon Timezones and JS-Date interop

Niclas — Wed, 23 Nov 2022 16:00:20 +0000

If you ever wondered how luxon and native JS-Dates (with TimeZones) behave when converting them between each other and ISO-Date-Strings here are my tests:

import {DateTime} from 'luxon'

const date = new Date();
const offset = date.getTimezoneOffset();
console.log('TimeZoneOffset(min): ', offset * -1);
console.log('TimeZoneOffset( h ): ', offset / 60 * -1);

/*
TimeZoneOffset(min):  60
TimeZoneOffset( h ):  1
 */

const strLocal = '2023-07-21T09:35:31.825+01:00'
const strUtc = '2023-07-21T08:35:31.825Z'

const jsDateLocal = new Date(strLocal)
const jsDateUTC = new Date(strUtc)

const dateTimeLocal = DateTime.fromISO(strLocal)
const dateTimeUTC = DateTime.fromISO(strUtc)

console.log(`ToLocal`)
console.table({
  jsDateLocal: jsDateLocal.toLocaleString(),
  jsDateUTC: jsDateUTC.toLocaleString(),
  dateTimeLocal: dateTimeLocal.toLocaleString(),
  dateTimeUTC: dateTimeUTC.toLocaleString(),
  dateTimeLocalFull: dateTimeLocal.toLocaleString(DateTime.DATETIME_FULL),
  dateTimeUTCFull: dateTimeUTC.toLocaleString(DateTime.DATETIME_FULL),
})

/*
┌───────────────────┬───────────────────────────────────┐
│      (index)      │              Values               │
├───────────────────┼───────────────────────────────────┤
│    jsDateLocal    │     '7/21/2023, 10:35:31 AM'      │
│     jsDateUTC     │     '7/21/2023, 10:35:31 AM'      │
│   dateTimeLocal   │            '7/21/2023'            │
│    dateTimeUTC    │            '7/21/2023'            │
│ dateTimeLocalFull │ 'July 21, 2023 at 10:35 AM GMT+2' │
│  dateTimeUTCFull  │ 'July 21, 2023 at 10:35 AM GMT+2' │
└───────────────────┴───────────────────────────────────┘
 */

console.log(`ToIsoTimestamp`)
console.table({
  jsDateLocalToIso: jsDateLocal.toISOString(),
  jsDateUTCToIso: jsDateUTC.toISOString(),

  dateTimeLocalToIso: dateTimeLocal.toISO(),
  dateTimeUtcToIso: dateTimeUTC.toISO(),

  dateTimeLocalToUtcToIso: dateTimeLocal.toUTC().toISO(),
  dateTimeUtcToUtcToIso: dateTimeUTC.toUTC().toISO(),
})
/*
┌─────────────────────────┬─────────────────────────────────┐
│         (index)         │             Values              │
├─────────────────────────┼─────────────────────────────────┤
│    jsDateLocalToIso     │   '2023-07-21T08:35:31.825Z'    │
│     jsDateUTCToIso      │   '2023-07-21T08:35:31.825Z'    │
│   dateTimeLocalToIso    │ '2023-07-21T10:35:31.825+02:00' │
│    dateTimeUtcToIso     │ '2023-07-21T10:35:31.825+02:00' │
│ dateTimeLocalToUtcToIso │   '2023-07-21T08:35:31.825Z'    │
│  dateTimeUtcToUtcToIso  │   '2023-07-21T08:35:31.825Z'    │
└─────────────────────────┴─────────────────────────────────┘
 */


console.log(`jsDate to DateTime to Iso`)
console.table({
  fromJsLocal: DateTime.fromJSDate(jsDateLocal, ).toISO(),
  fromJsUTC: DateTime.fromJSDate(jsDateUTC).toISO(),

  fromJsLocalWithUtc: DateTime.fromJSDate(jsDateLocal, {zone: 'utc'}).toISO(),
  fromJsUTCWithUtc: DateTime.fromJSDate(jsDateUTC, {zone: 'utc'}).toISO(),

  fromJsLocalToUtc: DateTime.fromJSDate(jsDateLocal).toUTC().toISO(),
  fromJsUTCToUtc: DateTime.fromJSDate(jsDateUTC).toUTC().toISO(),

  fromJsLocalWithEuropeBerlin: DateTime.fromJSDate(jsDateLocal, {zone: 'Europe/Berlin'}).toISO(),
  fromJsUTCWithEuropeBerlin: DateTime.fromJSDate(jsDateUTC, {zone: 'Europe/Berlin'}).toISO(),

  fromJsLocalWithEuropeBerlinToUtc: DateTime.fromJSDate(jsDateLocal, {zone: 'Europe/Berlin'}).toUTC().toISO(),
  fromJsUTCWithEuropeBerlinToUtc: DateTime.fromJSDate(jsDateUTC, {zone: 'Europe/Berlin'}).toUTC().toISO(),
})

/*
┌──────────────────────────────────┬─────────────────────────────────┐
│             (index)              │             Values              │
├──────────────────────────────────┼─────────────────────────────────┤
│           fromJsLocal            │ '2023-07-21T10:35:31.825+02:00' │
│            fromJsUTC             │ '2023-07-21T10:35:31.825+02:00' │
│        fromJsLocalWithUtc        │   '2023-07-21T08:35:31.825Z'    │
│         fromJsUTCWithUtc         │   '2023-07-21T08:35:31.825Z'    │
│         fromJsLocalToUtc         │   '2023-07-21T08:35:31.825Z'    │
│          fromJsUTCToUtc          │   '2023-07-21T08:35:31.825Z'    │
│   fromJsLocalWithEuropeBerlin    │ '2023-07-21T10:35:31.825+02:00' │
│    fromJsUTCWithEuropeBerlin     │ '2023-07-21T10:35:31.825+02:00' │
│ fromJsLocalWithEuropeBerlinToUtc │   '2023-07-21T08:35:31.825Z'    │
│  fromJsUTCWithEuropeBerlinToUtc  │   '2023-07-21T08:35:31.825Z'    │
└──────────────────────────────────┴─────────────────────────────────┘
 */

Using ts-node in nx-monorepos

Niclas — Tue, 22 Nov 2022 19:10:10 +0000

At my current work we use monorepos a lot. We use nx as tool to manage the different projects in the repo.
Naturally you also need some scripts to automate some tasks in the repository. Sometimes you also want to use libraries of your monorepo inside these scripts.

To be able to do that you just need to install tsconfig-paths (npm install -D tsconfig-paths) and alter the ts-config file you use for ts-node:

{
  "extends": "./tsconfig.json",

  ...

  "ts-node": {
    // It is faster to skip typechecking.
    // Remove if you want ts-node to do typechecking.
    "transpileOnly": true,

    "files": true,

    "require": ["tsconfig-paths/register"],

    "compilerOptions": {
      // compilerOptions specified here will override those declared below,
      // but *only* in ts-node.  Useful if you want ts-node and tsc to use
      // different options with a single tsconfig.json.
    }
  }
}

The key part is the "require": ["tsconfig-paths/register"] as it enables ts-node to resolve the path of your libraries.

Using Ory Keto to secure NestJS backends

Niclas — Sun, 13 Nov 2022 13:10:27 +0000

Ory Keto is a Permissions & Access Control System based on Zanzibar: Google’s Consistent, Global Authorization System.
It uses a graph to evaluate permissions and is therefore very flexible in its structure.
Allowed access is nothing more than an existing path in the graph.

For checking permissions it uses a structure called Relation Tuple.
The string-representation has the following syntax (BNF):

<relation-tuple> ::= <object>'#'relation'@'<subject>
<object> ::= namespace':'object_id
<subject> ::= subject_id | <subject_set>
<subject_set> ::= <object>'#'relation

A valid example would be namespace:object#relation@subjectId or namespace:object#relation@subjectNamespace:subjectObject#subjectRelation.
The latter can be difficult to read, therefore you'll often see the following variant: namespace:object#relation@(subjectNamespace:subjectObject#subjectRelation)

Relation Tuples can be verbalized.
The Relation Tuple sharedFiles:a.txt#access@dirs:b#access can be verbalized as "Anyone with access to dirs:b has access to sharedFiles:a.txt".

The SDKs of Ory Keto (REST and gRPC) use an object/class representation of the Relation Tuple. This is fine for most cases but not as convenient to use and understand as a simple string.

Because of this I wrote a small Typescript library to parse the string-representation of a Relation Tuple into the needed object-representation.

The general variant, not tied to Keto, is called @nidomiro/relation-tuple-parser (npm, github).
It supports converting static strings and strings with placeholders.
The latter is especially useful if you want to substitute e.g. the id of the currently logged-in user in the Relation Tuple.

The variant for Keto @nidomiro/relation-tuple-parser-ory-keto (npm, GitHub) just contains converters. They convert the given Relation Tuple (with, or without replacements) into a form you can use with the Keto SDK.

Let's look into a usage-example.

Example with NestJS

I assume you already know NestJS and are in a freshly created project. Additionally, I assume that Keto is already accessible.

The full source-code of this example can be found here

What we want to accomplish

We want an easy way to secure a backend route with Keto.
The person developing a new route shouldn't be responsible for communication with Keto.

The routes permissions should therefore be configurable via a Decorator. The choice fell to the following syntax:

@GuardedBy(({ currentUserId }) => `groups:users#member@${currentUserId}`)

It is concise and flexible at the same time.
We can use it, to secure our getData route:

@Controller()
export class AppController {
    @GuardedBy(({ currentUserId }) => `groups:users#member@${currentUserId}`)
    @Get()
    getData() {
        return 'Access grated!'
    }
}

Implementing the Decorator

How is the decorator shown above implemented?

In fact, it is relatively simple. It accepts a string or a generator function as parameter. Then it parses the given Relation Tuples and stores them inside the Handlers' metadata.
This way, the parsing happens at app-startup and not with every request.

The decorator (full source):

export const GuardedBy = (relationTuple: string | RelationTupleStringGenerator<PossibleReplacements>) => {
    let valueToSet: GuardedByMetadataType
    if (typeof relationTuple === 'string') {
        valueToSet = parseRelationTupleWithReplacements(() => relationTuple).unwrapOrThrow()
    } else {
        valueToSet = parseRelationTupleWithReplacements(relationTuple).unwrapOrThrow()
    }

    return SetMetadata(GUARDED_BY_METADATA_KEY, valueToSet)
}

Note that both variants are stored as a RelationTupleWithReplacements. This way we only have to think about one variant during the evaluation.

To statically type the possible replacements we create a type:

export type PossibleReplacements = {
    currentUserId: string | 'Unauthorized'
}

Implementing the (App-) Guard

The actual check of the Relation Tuple against Keto happens inside the Guard - KetoGuard (full source) in our case.

First we need to add the Keto SDK: npm i @ory/keto-grpc-client and if you need the REST-client npm i @ory/keto-client.

We use the gRPC variant for checking, because it is a bit faster than the HTTP variant - at least in theory.

What we need to do in the Guard:

get the value set by the Guard (the RelationTupleWithReplacements)
get the needed replacement values. In our case just currentUserId.
replace the values in the RelationTuple and evaluate the tuple against Keto
Allow / Deny access according to the result of the check.

For step 1 create another method inside guarded-by.decorator.ts (full source) with the following definition:

export const getGuardingRelationTuple = (
    reflector: Reflector,
    handler: Parameters<Reflector['get']>[1],
): RelationTupleWithReplacements<PossibleReplacements> | null => {
    return (
        reflector.get<GuardedByMetadataType, typeof GUARDED_BY_METADATA_KEY>(GUARDED_BY_METADATA_KEY, handler) ?? null
    )
}

Now we can retrieve the RelationTupleWithReplacements if any is set. Otherwise, we get null instead.

For step 2 I chose the "simple demo approach" and just extract a userId from the URL parameters. Only use this approach for demos, never for production! (source code)

Step 3 is implemented in keto-read-client.service.ts (full source).
With RelationTupleWithReplacementsConverter.toKetoGrpcCheckRequest we replace the values inside the RelationTuple and store the result directly in an CheckRequest, needed by Keto's gRPC client.
The next step is to call the Keto client with our CheckRequest and return the result. Note that the error-status NOT_FOUND is handled as "not allowed" (see here).

The last and final step is to use the Result and allow or deny the Request.

Now we need to load some rules into keto and check the result.
For this demo the necessary rules are set in keto during app-startup (full-source):

async function initKeto(ketoWriteService: KetoWriteClientService) {
    await ketoWriteService.addRelationTuple(parseRelationTuple('groups:users#member@user1').unwrapOrThrow())
    await ketoWriteService.addRelationTuple(parseRelationTuple('groups:users#member@user2').unwrapOrThrow())
}

With these Relation Tuples set, you can now check the result yourself:

Allowed access: http://localhost:3333/api?userId=user1
Allowed access: http://localhost:3333/api?userId=user2
Forbidden access: http://localhost:3333/api?userId=user3
Forbidden access: http://localhost:3333/api

Allowed Access returns:

Access grated!

Denied Access returns:

{"statusCode":403,"message":"Forbidden resource","error":"Forbidden"}

And that's it. Now you can add more Controller and/or Handler and just use the @GuardedBy decorator to secure them.

In a real world-example you would also validate the session and fetch the data of the currentUserId inside the guard. The fetched data can then be attached to the request and therefore be used by the Handler without the need to fetch the data again.

If you have any questions or improvements feel free to comment below.

Using OSS to secure your web-app / app / ...

Niclas — Fri, 11 Nov 2022 08:22:48 +0000

"Security is hard. You shouldn't implement it yourself.".

That's a phrase I heard a lot by now, and it's true for the most part.
Aside from that why bother with implementing the same functionality for different projects all over again.

To solve this issue often providers like Firebase, Auth0, ... step in an provide user-management and permission-management.
These solutions work fine but get costly very quickly.
But the main 'not-selling point' for me is that they are not opensource and cannot be hosted by myself.
I like being able to have control over things I invest my time in.

There are some opensource solutions that are trying to solve this issue; one of them is Keycloak.
Keycloak solves this problem well but introduces some other problems: It is very complex and custom styling is everything but easy if you want to use something like Next.js to fully integrate the Login/Registration into your webapp.

But Keycloak isn't the only player in the field.

After some searching I found Ory.
They provide several isolated applications for different auth concerns:

Ory Kratos for Identity Management
Ory Keto for Permissions & Access Control based on Zanzibar: Google’s Consistent, Global Authorization System
Ory Hydra for providing OAuth2 and OpenID Connect functionality

You can use everything together in their cloud variant 'Ory Network' or host it yourself. It is even possible to use only some applications, as any can be used without the others.

The functionality needed for 90% of all applications can be covered by Kratos and Keto; yes even Social sign-in, Multi-factor Authentication and Passwordless via WebAuthn.

What sets Ory's products apart from other opensource solutions is that their mantra is 'Bring your own UI'.
The (self-hosted) applications itself only provide an API (REST and partially gRPC).
You can use one of the (example-) UI's developed by Ory, but the normal way is to use your own UI.
More areas where Ory is different can be found in the docs or Ory.

The project I'm currently working on uses Next.js; and it's directly supported by Ory. It works flawless so far.

If you decide to use Kratos it can seem odd at first, but the design-decisions make sense if you think about them.
Kratos will provide an abstract representation of what elements are needed e.g. on the login-page / registration / user-settings.
With this abstract representation it is possible to render HTML-Elements or an App-UI dynamically.
The benefit of this technique: Adding e.g. a new Social-login is as easy as adding it in the Kratos config. Your UI will update automatically - without any code change or deployment.

You can use Kratos to store much more than just email and password.
With custom Identity Schemas you can define which fields are needed or possible for an Identity (= User).
There can even be different types of Identities, therefore requiring different information, at the same time.

For handling permissions and access-control Ory Keto can be used.
It is based on Zanzibar: Google’s Consistent, Global Authorization System and uses a graph to evaluate permissions.
Through this method it is very flexible in the permissions are organized.
Allowed access is represented as an existing path between two nodes in the graph.

Hierarchical structures can easily be realized and changed at any time.
With the right concept it is even possible to redo your entire permission-structure without the need to deploy your application again.

Maybe it's worth trying out Ory for your next project, you probably will like it ;)

Rust-04: More operators and loops

Niclas — Wed, 09 Nov 2022 11:00:00 +0000

In the last post we improved the simple program to be extendable with other operators.
In this post we will implement more operators and a loop.

Let's start with the simple task: adding more operators.
To support more operators we have to change two parts of the calculator, the parsing and the evaluation.
First let's look into changing the parser.
For this we simply add the new operators (-*/) to the regex inside Operation::from_string.
The resulting regex will look like this: ^\s*(\d+)\s*([+\-*/])\s*(\d+)\s*$.
Now the parser accepts the new operators; first part done.

The second part to change is the evaluation of the parsed operation.
Adding the new operators is as simple as adding more arms to match:

let result = match operation {
    Operation { left, operator: '+', right } => Ok(left + right),
    Operation { left, operator: '-', right } => Ok(left - right),
    Operation { left, operator: '*', right } => Ok(left * right),
    Operation { left, operator: '/', right } => Ok(left / right),
    x => Err(format!("{} is not a valid operator", x.operator)),
};

With the current state, the app can now accept +, -, *, / as operators and calculate the result.

Since we expanded the capabilities, we can also look for some possible refactorings.
You might see, that the execution of the Operation still happens inside the main function.
It would be cleaner to move the evaluation closer to Operation itself.
So let's add another function to impl Operation called execute and move the mentioned code to that function.

impl Operation {
    // <snip>

    fn execute(&self) -> Result<i32, String> {
        match self {
            Operation { left, operator: '+', right } => Ok(left + right),
            Operation { left, operator: '-', right } => Ok(left - right),
            Operation { left, operator: '*', right } => Ok(left * right),
            Operation { left, operator: '/', right } => Ok(left / right),
            x => Err(format!("{} is not a valid operator", x.operator)),
        }
    }
}

Right now execute only returns a String in case of an error.
To be more specific, what error occurred we add another struct to represent this error.

struct InvalidOperatorError { operator: char }

// <snip>

impl Operation {
    // <snip>

    fn execute(&self) -> Result<i32, InvalidOperatorError> {
        match self {
            Operation { left, operator: '+', right } => Ok(left + right),
            Operation { left, operator: '-', right } => Ok(left - right),
            Operation { left, operator: '*', right } => Ok(left * right),
            Operation { left, operator: '/', right } => Ok(left / right),
            x => Err(InvalidOperatorError {operator: x.operator}),
        }
    }
}

After these changes, we are at state: 2d6c605a.

Until now, we have completed task one: implementing more possible operators.
The second task is to change the calculator to accept multiple calculations one after the other.
A loop is a prime example to achieve this behaviour.

Just wrapping everything in a loop does enable multiple calculations, but the user of our calculator has no way of exiting the program.
We want to be able to type 'quit' to exit the program.
The code below will achieve just that.

fn main() {
    loop {
        println!("Please enter a calculation (or quit to exit)");

        let mut input = String::new();
        std::io::stdin()
            .read_line(&mut input)
            .expect("Could not read line");

        if input.trim().eq("quit") {
            println!("exiting...");
            break
        }

        let operation = Operation::from_string(&input).expect("Your input is invalid");

        let result = operation.execute();


        println!("The result is: {}", result.unwrap());
    }
}

But we have another problem to fix.

Since we allow multiple calculations we don't want the calculator to crash on an invalid input anymore.
Using expect and unwrap as error-handlers, will result in a crash of the app if they encounter an error-state;
so we need to exchange them.
Obviously we use match instead:

fn main() {
    loop {
        println!("Please enter a calculation (or quit to exit)");

        let mut input = String::new();
        std::io::stdin()
            .read_line(&mut input)
            .expect("Could not read line");

        if input.trim().eq("quit") {
            println!("exiting...");
            break
        }

        let operation = match Operation::from_string(&input) {
            None => {
                println!("Your input was invalid");
                continue
            },
            Some(x) => x
        };

        let result = match operation.execute() {
            Err(InvalidOperatorError { operator: op}) => {
                println!("The operator {} is invalid", op);
                continue
            },
            Ok(x) => x
        };


        println!("The result is: {}", result);
    }
}

Now we get an info, if the input is invalid and can try again on the next iteration.

After all changes of this post, we are at state: 8322be09.

In the next post we will change the structure radically to be able to support multiple operators in one input - at least on the execution side.

Rust-03: Improving the simple program

Niclas — Tue, 08 Nov 2022 11:00:00 +0000

In the last post we created a simple program that would accept an input like 5+5 and calculates the result.
In this post we will improve this program.

To prepare for adding more operators we need to improve the input-parsing.
Currently, we just split the input-string at the plus-sign.
If we want to know the operator, we have to choose another approach.

In this case I chose regex:

#[derive(Debug)]
struct Operation {
    left: i32,
    operator: char,
    right: i32,
}

impl Operation {
    fn from_string(input: &String) -> Option<Operation> {
        let regex = Regex::new(r"^\s*(\d+)\s*([+])\s*(\d+)\s*$").unwrap();

        regex.captures(&input).map(|capture| Operation {
            left: (&capture[1]).parse().unwrap(),
            operator: (&capture[2]).parse().unwrap(),
            right: (&capture[3]).parse().unwrap(),
        })
    }
}

As you can see we have a new thing called struct in the code.
If you are coming from a language like Java or Typescript, a struct can be seen as a class without any methods.
This struct is called Operation and as the name suggests it holds an operation.
The fields left and right are both typed as an i32 or in other words a "signed 32-bit integer".
The field operator is a char since we only use one character for an operator.
In rust strings and chars are utf-8, therefore a char can contain one unicode codepoint, not just a byte.

The other new thing is a impl called Operation.
An impl is the method-part equivalent of a class.
Here you can define methods, that are available to call on the struct with the same name.
In this case we have one method called from_string.
This method is our new parser.
It takes a string as an input and returns an Operation wrapped by an Option.
Rust does not have null, so every time when there is the possibility that a value could be non-existent an Option is used.

If you read the code carefully, you may have noticed that the last statement of the function does not have a semicolon.
That is on purpose.
If the last statement of a function has a semicolon, it returns () (equivalent to void), if it isn't preceded by the keyword return.
You can omit the keyword return by omitting the semicolon on the last statement of a function.
Then, the value of the last statement is used as the return value.

Now we have a new method of parsing, so lets look at the new evaluator:

let operation = Operation::from_string(&input).expect("Your input is invalid");

let result = match operation {
    Operation { left, operator: '+', right } => Ok(left + right),
    x => Err(format!("{} is not a valid operator", x.operator)),
};


println!("The result is: {:?}", result.unwrap());

Here we can see another example of a powerful feature of Rust: Pattern matching.
With pattern matching, we can save a lot of else-if-statements.
In this simple case it wouldn't make a big difference, but we want to expand the code.

So what happens inside the match operation {... statement?
Each line contains a Pattern, followed by => and a statement or block.
The pattern Operation { left, operator: '+', right } matches every Operation with + as its operator.
left and right have no value assigned in the pattern, so all values match.
You can use left and right as variables in your following statement, as seen in the code.
x => ... matches all cases, it's therefore the default case.

After these changes, we are at state: 24affc71

In the next post we will add more operators to the calculator and more.

Rust-02: The beginning

Niclas — Mon, 07 Nov 2022 11:00:00 +0000

At first, I didn't like Rust.
Managing memory myself is something I don't want to do.
After a first look at Rust and setting it aside for a few weeks, it appeared back on my radar.
I thought: "This time I'm looking deeper into it".
So I started by reading the Rust Book; and I'm still reading it and find new concepts that are really clever.

One of the first things I discovered is that I do not need to manage memory myself.
The majority of the management will be done by the Rust compiler; I just have to follow some Rules.
These Rules, called "Ownership", are a bit confusing to start with, but make more sense, the more you think about them, and the more you use them.
In combination with the strict differentiation between mutable and immutable structures, you can write code that is easy to read, easy to think about and resource efficient - a combination, I thought never possible.

It was about chapter 5 when I started my example project - a calculator.
I will use the project in this series to explain some things and concepts.
Keep in mind that this project is just a learning project.
It makes no claim to be perfect, nor very Rust-idiomatic; but it will improve over time and with understanding more concepts.

You can find the repository here: https://github.com/nidomiro/learning-rust-calculator

I skip the setup process of cargo as it is super simple and well described in the Rust-Book.

My first action was to implement a simple addition.
You can enter 5+5 and the program outputs 10 - hopefully ;).

fn main() {
    println!("Please enter a calculation");

    let mut input = String::new();

    std::io::stdin()
        .read_line(&mut input)
        .expect("Could not read line");

    let parts: Vec<i32> = input.split(['+'])
        .map(|x| x.trim().parse().expect("Only numbers are allowed"))
        .collect();

    if parts.len() != 2 {
        panic!("Currently only + is a supported operator")
    }


    println!("Parts: {:?}", &parts);

    println!("{} + {} = {}", parts[0], parts[1], parts.iter().sum::<i32>())
}

Source: https://github.com/nidomiro/learning-rust-calculator/blob/e96ce3c449972be7854545bf0c5d9c386eccbd42/src/main.rs

Let's examine what happens here.
First we print a text to the console to let the user know what we want from him.
Then we declare a mutable String instance.
We use this mutable String and pass a mutable reference to the read_line method.
When the user enters text and presses Return, the entered text will now be stored in the variable input.

So far so good, but hat does this line .expect("Could not read line") do?
To understand why this line is there, we have to dive a bit deeper into Rust's error-management.
In general there are two types of errors: recoverable errors and unrecoverable errors.
If you encounter an unrecoverable error, it is not safe to continue executing the program and therefore the program will just exit.
This is called panic.

The other type of errors are recoverable errors.
A recoverable error is represented by the Result enum.
This enum has two possible values, Ok if there is no error and Err if a recoverable error occurred.
This is one of the concepts I learned over the years, and I really like it.
You can see at the method signature what errors can occur and don't need an ugly try-catch block to handle errors (performance is also better).
But what does the line .expect("Could not read line") now do?
read_line returns a Result, and therefore the compiler forces us to handle the error-cases.
.expect("Could not read line") is a shortcut for "I don't care if errors occur. Just crash the program (panic) with the given message.".
It is obvious that you need to be careful when to use this.
In this case it is ok, because the program is just for learning purposes and not a production program.

You can read more about error handling in Chapter 09 "Error Handling" of the Rust-Book.

With that out of the way we can continue with the input-processing.
First we split the String at the character '+' and then trim the resulting parts (remove excess whitespace characters) followed by an integer-conversion (.parse()).
The collect() is needed, because map is evaluated lazily and therefore doesn't return a vector itself.

After checking if we got two numbers in the vector and panicking if not, we print the calculation and its result.

And there it is, we have our first functioning Rust program :)

Over the next posts, we will improve the code and add functionality.

Rust-01: Why am I learning Rust?

Niclas — Sun, 06 Nov 2022 19:36:29 +0000

This is a good question, a very good question.
Why am I learning Rust?

To begin with, I programmed in a lot of languages so far: C++, Python, Swift, Java, Kotlin and TypeScript to name a few.
All languages have some features I missed when programming in other languages.

Currently, my favorite languages are Kotlin and TypeScript; with Kotlin having the lead.
These languages are expressive, and really nice to write.
I can express my thoughts in code without having to convert them too much in order to make the compiler happy.

Swift also has some super neat aspects.
For example that you are able to add a potocol (≃ Interface) to a class after the fact.
This opened my mind to a whole new set of "Metaprogramming"-Methods.
Swift also introduced me to Pattern Matching, a very powerful tool, if used correctly.
Guards are another thing I'm missing from Swift.
Yes you can achieve a similar behaviour in other languages, but having a special keyword for this type of operation helps in code readability.

Most of my professional programming years I spend programming Java with a short trip to Swift, because a customer wanted to have an iOS app.
During this time Kotlin arrived at my horizon.
It was amazing compared to Java; so concise, so expressive and more secure because the compiler forced you to handle null values.
Unfortunately the company, I was working for at this time, wasn't as exited as me.
So I used Kotlin for private projects only.

In 2020, I switched my job and started to use TypeScript as my primary language.
TypeScript added some features which I really liked but also lacked some.
Duck-Typing is very nice, because you don't have to convert your Data-Objects all the time.
This alone is a huge time saver, but at the cost of some strange behaviours.
For example, if you have a class with two attributes you can assign a plain object to a variable with the type of the class, if it has the same attributes (and methods with the same signatures).
This can introduce strange behaviour if you, for example, rely on the type of the class to execute some code, or you rely on code that is executed in the constructor.
I prepared a code example at typescriptlang.org to make this point more clear.

But back to the initial question: Why am I evaluating Rust to become my primary programming language?

The simple answer is: Rust combines multiple features of languages that I really like.
It is at the same time a low-level (in therms of C and C++) and a high-level (in therms of Kotlin and Typescript) language.
This means I can use it to write webservices and microcontroller / system code.

Some concepts seem odd at first but absolutely make sense if you think about them more deeply.
In the following articles we'll dive deeper into some of these concepts.