4 ms·

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

by Goosey 13y ago

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. :\

relistan 13y ago
A fair critique. I should write more on the subject.
pohl 13y ago
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-in-rust/ http://relistan.com/a-pattern-for-wrapping-c-function-calls-...
jkbyc 13y ago
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.
- pcwalton 13y ago
  > 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.
BruceIV 13y ago
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.
- relistan 13y ago
  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.
  - BruceIV 13y ago
    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.
userulluipeste 13y ago
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.
- relistan 13y ago
  Or... I could use a language/toolset that makes all that easier. Why does that need further justification?
  - userulluipeste 13y ago
    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.

by Goosey 13y ago

relistan 13y ago

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

pohl 13y ago

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-in-rust/ http://relistan.com/a-pattern-for-wrapping-c-function-calls-...

jkbyc 13y ago

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.

pcwalton 13y ago
> 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.

BruceIV 13y ago

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.

relistan 13y ago
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.
- BruceIV 13y ago
  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.

userulluipeste 13y ago

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.

relistan 13y ago
Or... I could use a language/toolset that makes all that easier. Why does that need further justification?
- userulluipeste 13y ago
  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.