What I found hard about Rust (and how I got the hang of it)

feileacan — Mon, 08 Mar 2021 10:42:52 +0000

Rust is an interesting language. Much-loved, a systems programming language (no garbage collection, etc) but feels like a higher level language with iterators, fancy type systems, nice tooling, and you can write code that works
without needing to carefully juggle memory.

I've done plenty of systems programming (C, C++) and higher level (Python, C#, etc), so figured Rust should be easy enough to pick up, but I'd hit the same struggles everyone else does, where the borrow checker yells at me, and when do I use a String vs &String vs str vs &str?

Eventually I figured out why I was struggling so much though, and now I'll share with you, gentle reader, my revelation.

I was forgetting to think about memory and lifetimes

When coding in C or C++ I'd be constantly aware of every allocation and trying (and sometimes failing) to carefully track the lifetimes of every object I use because if I don't, bad things happen.

In a language like Python I don't because that's all hidden from me. I just code and it's the interpreter's problem.

When writing Rust it felt so easy, so I relaxed and stopped the careful tracking that I would in other systems programming languages. Of course, you can't since it matters in Rust. It has better ergonomics and safety but it's still a systems programming language, that means it assumes you know and care about whether things are heap or stack allocated, or about when exactly something is deallocated.

This then means the solution is sad but easy. I need to go back to thinking about where I want things allocated, how they're getting passed to functions, how long they live for. But at least when I get it wrong I find out from the compiler instead of Project Zero.

What can we learn from Citi's $900 million mistake?

feileacan — Fri, 19 Feb 2021 00:17:03 +0000

Back in 2020 Citigroup accidentally sent almost USD$900 million to Revlon's creditors. About half the money was returned, but 10 creditors held on to the money and a judge has just ruled that they can keep the money.

In short, Revlon sent Citi a few million for them to transfer to creditors as an interest payment. A Citigroup employee didn't fill out a form in a program correctly, so Citi paid off Revlon's loan in full using their own money. Oops.

Here's the form, can you see the problem?
(sourced from the court record)

Thought not. In order to not send lots of money you need to check all of the PRINCIPAL, FUND and FRONT boxes.

What can we learn from this?

The real question is what can the rest of us learn from this mistake? Not that people make mistakes or should be fired (three different people looked at and approved the transfer), but the importance of good UI. To me, there are three main takeaways.

Safe defaults

Usually we should make the common case the default, that's just good UX. But when one of the options is dangerous and the other safe, make the default the safe one.

Think about your ops tools, how many have --dry-run flags instead of --for-realsies? A repeated trend I've seen in outages is someone ran a command, didn't realise they were targeting production and oops.

UI states should match business logic states

Is every combination of checkboxes actually valid? If you have redundant information in the UI you should either consolidate it, or error on mismatch. Either you know what the user wants, in which case you didn't need to ask for it in the first place, or you don't, in which case don't guess. As with all rules you may want to bend this one for convenience but the dangerous an operation the more pedantic you should be.

Adding more reviewers only goes so far.

A common pattern after outages is to add more reviewers for changes: "someone ran the foobar tool and took out a datacentre, now all users of the foobar tool need a second person to check the command and approve before running it". In a pinch it can help, but it's a short-term mitigation. It slows you down, takes more person-time, randomises people, and still doesn't give you as much safety as improving the tool itself.

Obligatory Disclaimers

The above is a very brief summary of what happened, it's more complicated than I made it out to be. Please read the linked article and court record for more details
All opinions are my own and do not represent my employer

DEV Community: feileacan