I enjoyed the article very much. Please continue with your journey of explaining Rust to programmers that are looking for new alternatives to C.
I really appreciate that feedback. Thanks!
A Week with Mozilla's Rust
91–100 of 104 posts
Re: A Week with Mozilla's Rust
#92Earlier quoted context omitted.
I hope Rust can eventually reach compile speeds of most module based languages. Every time I update my netbook with a new Rust release it takes a few hours, it almost feels like I am compiling KDE or something.
The compiler is pretty slow (although there's a big drive starting a few days ago to get certain aspects down (mostly compiling small files); because running the testsuite is so slow that work on the compiler is getting dragged down), but compiling the compiler itself is particularly bad: - it has to build LLVM: Rust currently has to use a custom version; the goal is for this to be unnecessary so that the system LLVM…
What does it use for the first-stage bootstrap, out of interest?
Re: A Week with Mozilla's Rust
#93I 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 a…
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.
Re: A Week with Mozilla's Rust
#94Earlier quoted context omitted.
The compiler is pretty slow (although there's a big drive starting a few days ago to get certain aspects down (mostly compiling small files); because running the testsuite is so slow that work on the compiler is getting dragged down), but compiling the compiler itself is particularly bad: - it has to build LLVM: Rust currently has to use a custom version; the goal is for this to be unnecessary so that the system LLVM…
What does it use for the first-stage bootstrap, out of interest?
There are periodic (made when someone feels like it, normally every one or two weeks) snapshots, i.e. a normal bootstrap saved as a binary, of the current master branch, which are uploaded to rust-lang.org, and downloaded (once, they are cached) when building a revision that requires that snap.
Re: A Week with Mozilla's Rust
#95Earlier quoted context omitted.
Exactly! This is what makes Rust exciting - as opposed to yawnfests like Go that merely provide a compiled, somewhat faster Python.
Go does have one interesting feature: CSP concurrency built in. Even this was predated by Erlang, though.
I was really a little bit disappointed to learn that go (touted for it's goroutines) doesn't have actors, i would love to have the erlang style, network aware actor model in a language i belief i could learn easily ;)
Without that, i don't see so much noveltly :(
All in all i don't see how goroutines can compare to the Erlang model at all (
Re: A Week with Mozilla's Rust
#96Why do people keep reinventing syntax? Quick tell me what the following mean: struct Digest { digest: ~[u8] } // what's ~ here? for self.digest.iter().advance |&byte| { acc = acc.append(fmt!("%02x", byte as uint)); } acc What does the above mean? acc as a separate line and nothing else I hate it when people reinvent the same construct that can be found in other languages but differently. I guess they want to do somet…
Rust does have some new syntax, but I think most of it is justified for making programming in it nicer. The `~[u8]` would be written `std::unique_ptr ` in C++. They're used everywhere in Rust, and having to write out unique_ptr would get awfully tiresome. The `acc` on its own line is a result of "the last statement gets returned" like many functional languages do. If you were writing C++, you'd write `return acc;` in…
> The `~[u8]` would be written `std::unique_ptr` in C++.
Wouldn't it be `std::unique_ptr>`?
Re: A Week with Mozilla's Rust
#97Earlier quoted context omitted.
You haven't mentioned defer/panic/recover, which seems like the strangest aspect of the language to me. It's similar to exceptions, but the mechanism of action is much more complicated semantically.
As I understand it (and I'm not a Go expert), but panic/recover is not idiomatic Go, and they much prefer the style of using a second return parameter for errors. defer is just a useful syntactic construct that becomes complicated when you add in exceptions (but no more so than calling the destructors in C++ stack unwinding).
> defer is just a useful syntactic construct that becomes complicated when you add in exceptions (but no more so than calling the destructors in C++ stack unwinding).
defer is quite a bit more complex than C++ stack unwinding, because it's dependent on implicit mutation of per-function state and can't really be implemented any other way in the general case. This shows up when you call defer repeatedly in a loop, for example.
Re: A Week with Mozilla's Rust
#98I 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 a…
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?
Re: A Week with Mozilla's Rust
#99Earlier quoted context omitted.
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.
Re: A Week with Mozilla's Rust
#100Why do people keep reinventing syntax? Quick tell me what the following mean: struct Digest { digest: ~[u8] } // what's ~ here? for self.digest.iter().advance |&byte| { acc = acc.append(fmt!("%02x", byte as uint)); } acc What does the above mean? acc as a separate line and nothing else I hate it when people reinvent the same construct that can be found in other languages but differently. I guess they want to do somet…
Rust does have some new syntax, but I think most of it is justified for making programming in it nicer. The `~[u8]` would be written `std::unique_ptr ` in C++. They're used everywhere in Rust, and having to write out unique_ptr would get awfully tiresome. The `acc` on its own line is a result of "the last statement gets returned" like many functional languages do. If you were writing C++, you'd write `return acc;` in…
I agree that C++ broke the syntax terseness of C and become verbose for the sake of being explicit enough. This gets inconvenient sometimes, but the good thing is that it is a technical solvable problem - just redefine the long keywords or configure your editing tools to help you out typing.