Hacker News Reader

Comment by Goosey | Hacker News Reader

I enjoyed the article as I haven't been exposed to much Rust yet, but I was disappointed that the intro didn't match the content

The second sentence:

> I want a language where I can be much more productive than in C: one in which I do not fear the correctness of my memory management, and don’t have to go through major gyrations to write concurrent code.

And we see no explicit demonstrations of the memory management and no demonstrations at all of the concurrency model. It feels like the author had a more fleshed out post in mind, but either decided it was running too long or got bored before reaching the conclusion. :\

View on HN

It feels like the author had a more fleshed out post in mind, but either decided it was running too long or got bored...

Or it could be that this post is just the beginning of his journey of learning & blogging about Rust. He did post another one 4 days later, albeit not yet touching on the topics you mention:

http://relistan.com/a-pattern-for-wrapping-c-function-calls-...

I agree, the actual content doesn't match the introduction so well.

I've been looking into Rust during the past few days and I must say I got stuck on the memory model - all the different pointers and their interaction with ownership and mutability, closures capturing their environment (variables outside the closure in the scope where the closure is defined), reference binding, and then things like std::Cell which on the one hand seems to be an alternative to std::Option but on the other hand it's using some unsafe operations in its implementation to change mutability or something... It's quite confusing and it stopped me from writing a simple example application I wanted to write because I wanted to understand what's going on a bit better first.

> all the different pointers

@ is going to sink into the library and will be deemphasized in the language to help with this. That leaves only ~ (pointers) and & (references).

> closures capturing their environment (variables outside the closure in the scope where the closure is defined)

Right, this is one of the difficult pieces. This is going away as well in favor of Java-like Runnables to make the variable capture easier to understand (with macro sugar to make them just as convenient as closures). The closures that remain will work just like the closures you know from other languages regarding variable capture, and the Rust-specific stuff regarding variable capture will be gone.

> std::Cell

Yeah, this needs to be better documented. Part of the problem is that we haven't totally nailed down what Cell will be used for yet.

A fair critique. I should write more on the subject.

For the same quoted sentence (@relistan):

1. avoid dynamic allocations (limit yourself to stack-only objects) and you'll get rid of those fears for memory management

2. limit yourself to functional programming and you'll get a pretty good concurrent-ready code

For this "I need a new language" stance you'll need some better reasons.

Or... I could use a language/toolset that makes all that easier. Why does that need further justification?

You don't need reasons to chose a different language/toolset. You need better reasons for dismissing something like C/C++ for not being appropriate.

I read the intro as "I like Rust, I'm going to twist my requirements to match", but that may be a bad read of the author.

That wasn't my intention. I didn't decide to like Rust before trying it, I tried it to see if I liked it. I wrote up what I've learned so far. Probably some day this post will seem naive to me, but for now it's the best I could manage.

Fair - if I were to write up what I'd want from a new systems language it would be: statically typed with some sort of generics capability, natively compiled, not GC'd (I like the idea of ObjC's ARC, though I can't say I've used it), and with first-class support for concurrent or parallel programming - this also sounds an awful lot like Rust, and I don't think I was particularly aiming for it, it's just got a good set of features and design goals for a modern systems language.

Reply on news.ycombinator.com