Também disponível em: Português

My First Month With Rust

8 minutes read · 2017-03-29

Roughly a month has passed since I started using the Rust programming language as my “daily driver”, and I feel like it would be interesting to share my early impressions and thoughts about the language.

Rust's Logo

NB: The title of this post is not entirely accurate, since I had been toying on and off with the language in my free time for a while. Rust has a steep learning curve, so don't feel demotivated if you don't hit the ground running in the first month.


Rust is a systems programming language with a focus on execution speed, memory and data-race safety. It's sponsored primarily by Mozilla, who are using it to develop their next generation browser engine, Servo.

Learning Curve

My first impression of Rust was that it was significantly harder to learn than most languages I had experimented with, perhaps with the exception of Haskell. During the first weeks, it felt like I didn't know how to properly structure anything beyond the simplest programs. That was quite frustrating*.

My advice if you're struggling in this stage is to power through and keep trying to use the language, even if you can't fully understand what's going on yet or get everything to work. Much like learning git and vim, it does pay off later on. After some time, it's finally going to “click”, and you'll start to develop an intuition of how things work.

The following were my major pain points during my first month with rust:

Pain Point #1: Move Semantics

Most other languages provide either copy semantics or reference semantics for dealing with values. What that means is: if you pass a variable x into a function f(), it will receive either a copy of the value in x or a reference to it. (Depending on the language and the type of x)

Rust does away with that, and opts to use move semantics by default for most custom data types. Attempting to compile the following code:

fn f(x: String) {
    // Do something with x

fn main() {
    let x = String::from("Hello");
    println!("{}", x);

Will result in an error, since the value of x is consumed by f(), and cannot be reused by println!():

rustc 1.16.0 (30cf806ef 2017-03-10)
error[E0382]: use of moved value: `x`
 --> <anon>:8:20
7 |     f(x);
  |       - value moved here
8 |     println!("{}", x);
  |                    ^ value used here after move
  = note: move occurs because `x` has type `std::string::String`, which does not implement the `Copy` trait

error: aborting due to previous error

Instead, you need to either explicitly clone the value of x, or take a reference and pass that instead:

fn f(x: String) {
    // Do something with x

fn g(x: &String) {
    // Do something with x

fn main() {
    let x = String::from("Hello");
    println!("{}", x);

This forces you to think about ownership, which is very convenient for providing automatic memory management and compile-time optimizations. However, it does take some time getting used to.

* It doesn't help that most of the “classic” CS 101 assignments that people will commonly implement when learning a new language—e.g. linked lists, binary trees, hash tables—all traditionally involve shared mutable state, which is heavily discouraged by the language in the first place. ↩︎
† Rust was not the first programming language to introduce move semantics for values. C++11 implements it to some extent via move constructors. ↩︎
‡ Primitive data types—and in fact all types that implement the Copy trait—are exempt from this rule, and are instead passed by copy. ↩︎

Building a Beefy VR Workstation

7 minutes read · 2017-02-06


There are plenty of inexpensive ways to experience mobile VR, including the really cheap Google Cardboard that works with any average-sized, reasonably recent smartphone. However, when it comes to the most engaging, immersive experiences, the horsepower available on mobile platforms is, as of early 2017, simply not enough.

Having decided that I'd like to get serious about VR development, I set out to spec out and build a beefy VR workstation.

VR Workstation?

For the purposes of this article, I'll define a “VR workstation” as a high-end gaming PC, that's also well suited for software development.

The requirements for VR and gaming are very similar, though VR benefits more dramatically from higher resolution and lower output latency, whereas games have historically focused more on scene complexity, realistic materials and effects.

Being cost effective was one of the goals of this build. However, the computer is meant to be used professionally, so I targetted a higher price range/quality than I would for a hobby-only rig.

Picking a CPU: i5 or i7?

Most modern games are not CPU bound, so the key component that defines gaming performance is the graphics card, with RAM and CPU being somewhat distant seconds.

If your intent is to simply consume VR content, a 6th generation or newer Core i5 should be more than enough. However, if your intent is to write software, the extra cores on the i7 can dramatically cut compilation times—which is why I decided to get the i7.

I ended up picking the Core i7 6700K Unlocked

Graphics Card

Performance-wise, NVIDIA's new Pascal architecture on the GeForce GTX 10 Series is absolutely insane, particularly for VR. I considered buying a less expensive GeForce GTX 1070 and saving the money to buy a second graphics card later, but ended up opting for a single 1080

As it turns out, the Vulkan API—which I'm interested in the most—doesn't currently support support SLI, and all multi-GPU processing needs to basically be managed manually. By the time I'd be ready to buy the second graphics card—and when/if the standard gets updated to support SLI/Crossfire—the 11 Series will be already out, and it will be time to upgrade my GPU anyway.

As for the maker, I decided to go with EVGA based on a friend's recommendation, but it seems to be a matter of personal preference, mostly.

Due to shipping constraints at the time, my pick was the EVGA GeForce GTX 1080 SuperClocked, though I would probably recommend the FTW edition otherwise.

Starting My .blog

One minute read · 2017-01-29

Welcome to my blog! I've been meaning to write for some time now, and I feel like this will be a great space to do so. 😊

I'd like to thank my great friends and coworkers at Automattic, who kindly provided me this very special .blog address (marco.blog). You can get yours at get.blog: The namespace is way less polluted than, say, .com, so your odds of finding a great domain name are much higher.