I'm Brett Slatkin and this is where I write about programming and related topics. Check out my favorite posts if you're new to this site. You can also contact me here or view my projects.

04 February 2015

Rust may exceed the pain threshold of some programmers

This post on Lambda the Ultimate about Rust is interesting. One takeaway that resonated with me is:

Rust has to do a lot of things in somewhat painful ways because the underlying memory model is quite simple. This is one of those things which will confuse programmers coming from garbage-collected languages. Rust will catch their errors, and the compiler diagnostics are quite good. Rust may exceed the pain threshold of some programmers, though.

This is where I'm at. I was a die-hard C++ programmer for a long time. Yet Rust seems totally unapproachable to me. I've moved on to Python and Go. It seems the problems I solve these days aren't incompatible with garbage collection.

The problem starts with the new operators in Rust:

ref mut

As a newbie these might as well be on an APL keyboard:

With a history of using C, C++ (before C++11), or Java, none are obvious except for & and maybe mut. I realize some of these have changed in newer versions of the language, but this is my impression of it.

Most of the magical memory management and pointer types I've used in C++ are variations on templates like shared_ptr or unique_ptr or linked_ptr. Instead of special symbols or syntax it's just plain old names. These are readable and discoverable to a new reader of the code.

Python and Go are also pretty simple in the operators they use. The worst Python has is probably * and ** for function arguments. Go's worst is <- for channel operations. I realize that Rust is trying to do something different and needs more ways to express that, so I'm not putting it down here.

If it's worth anything, another data point is I'm not in favor of Python adopting the @ operator for matrix multiplication (PEP 465). I think it's too hard for newbies to quickly understand what it means.

(Originally from my comment here)
© 2009-2016 Brett Slatkin