Comment by glandium | Hacker News Reader

Comment by glandium | Hacker News Reader

The take-away for me is this:

"Despite the restrictions of the type system, I am more productive in Rust than I am in either Javascript or Haskell. It manages somehow to hit a sweet spot between safety and ease of use."

When I toyed with Rust last year (so, I'll admit my knowledge is outdated, I need to refresh it), I had a pleasant experience on the productivity side. The big reward for me, coming from C/C++, is that my programs simply worked as expected once I was past fixing all the errors the compiler reported. That usually doesn't happen this way in C/C++, where you spend additional time fixing whatever null deref and whatnot that break your program in subtle ways at runtime.

Doesn't using C++ RAII eliminate some of that? Or you use raw pointers often?

Rust uses RAII too. But borrowing makes it much more powerful.

Yeah, Rust controls much more than C++ RAII does.

Anything in C++ generally comes with its very own footgun.

The one for RAII looks like this:

  {
    mutex_guard(some_mutex);
    foo();
  }

What does this do? It locks some_mutex, then immediately unlocks it, then calls foo().

I don't understand the example. Why would it do that and not unlock after foo()?

The following code would do the right thing; see if you can spot the difference, and think about whether you would catch that in code review (g++/clang++/visualc++ won't warn about it).

  {
    mutex_guard guard(some_mutex);
    foo();
  }

I guess you meant std::lock_guard.

Anyway, the first example creates a temporary object which doesn't lock anything since it will be destroyed right away because it's an rvalue (not sure why would anyone do that for locking, unless not knowingly). The second example creates a proper guard which lives until the end of the scope.

Ah, now I see it and it makes sense.

The answer to the code review question is obvious. I didn't see the error even though I was told what happens.

Reply on news.ycombinator.com