6 ms·

Noisy, unreadable code, obsessed with ownership, may give rise to whole new classes of errors that otherwise won't be there. Good that someone experimented with

Noisy, unreadable code, obsessed with ownership, may give rise to whole new classes of errors that otherwise won't be there. Good that someone experimented with building a language around ownership, but for me it all demonstrates that the idea is not viable. I tried to read 10 tutorials already, each leaving me more confused than ever before.

adamnemecek 12y ago
> obsessed with ownership, may give rise to whole new classes of errors that otherwise won't be there How does baking the ability to statically determine resource ownership into a language lead to a class of errors? What sort of errors are these?
- lohankin 12y ago
  By taking away the ability of programmer to read and understand the code written by somebody else, or by himself 1 week ago
  - adamnemecek 12y ago
    I have no clue what you are talking about and I don't think that you have either so I'll just leave this discussion now.
  - wycats 12y ago
    As someone who has written many thousands of lines of production Rust code, this doesn't ring true to me at all. Ownership semantics have dramatically improved my ability to reason about my code, not the opposite.
Retra 12y ago
Have you written any code?
Animats 12y ago
I tried to read 10 tutorials already, each leaving me more confused than ever before. I can understand that. The language has been changing so fast that most of the stuff on the Web is outdated or wrong. I just found a place in the official reference manual that's out of sync with the compiler, and sent in a note. (The lambda/closure syntax is still in a state of flux.) Rust roughly follows C/C++/Java syntax, except that, like Go, it's a "name: type" language. Talking about ownership in code is new, as is the syntax for that. The ownership syntax is a bolt-on, and it shows. The lambda syntax is kind of weird; the designers went for conciseness over clarity. Some of this will take getting used to. The syntax is no worse than C++, and in some areas, better. The syntax isn't the hard part, anyway. It's living within the ownership restrictions that's hard. It's hard because that's a design issue. There's a Rust port of Doom, and it has far too much unsafe code, because Doom's data structures were not designed with Rust in mind. It's not yet clear how big an issue this will be. The remark that 10% of Servo, the web page renderer, is unsafe code is a bad sign. I don't have a personal opinion on this yet. I haven't written enough Rust code. I'm writing an RSS feed parser to get a sense of what it's like to deal with a complex tree in Rust. So far, it's going well, with no need for unsafe code. If Rust can eliminate buffer overflows, dangling pointers, and memory leaks, that's enough to justify using it in place of C/C++.
- wycats 12y ago
  For what it's worth, I've written two fairly large pieces of code in Rust: Skylight and much of Cargo. In both cases, the amount of unsafe code was very small (tiny) and restricted to FFI boundaries, which are "unsafe" even in high level languages like Ruby. Servo has been under active development for far longer, and sometimes used unsafe code to work around historical issues that no longer require unsafe code. I find the idea of an idiomatic codebase (written today), that is 10% unsafe code (outside of FFI boundaries) to be difficult to imagine.
- eddyb 12y ago
  Mentioning Go for `name: type` may not be inaccurate, but it is an odd choice (we're seeing more comparisons of Rust and Go than Rust and any language it is closely related to). I believe the origin for Rust's choice is actually the ML family. EDIT: I just checked more carefully and Go doesn't even have the colon ([this blog post](http://blog.golang.org/gos-declaration-syntax http://blog.golang.org/gos-declaration-syntax) used it in pseudocode).

adamnemecek 12y ago

> obsessed with ownership, may give rise to whole new classes of errors that otherwise won't be there How does baking the ability to statically determine resource ownership into a language lead to a class of errors? What sort of errors are these?

lohankin 12y ago
By taking away the ability of programmer to read and understand the code written by somebody else, or by himself 1 week ago
- adamnemecek 12y ago
  I have no clue what you are talking about and I don't think that you have either so I'll just leave this discussion now.
- wycats 12y ago
  As someone who has written many thousands of lines of production Rust code, this doesn't ring true to me at all. Ownership semantics have dramatically improved my ability to reason about my code, not the opposite.

Retra 12y ago

Have you written any code?

Animats 12y ago

I tried to read 10 tutorials already, each leaving me more confused than ever before. I can understand that. The language has been changing so fast that most of the stuff on the Web is outdated or wrong. I just found a place in the official reference manual that's out of sync with the compiler, and sent in a note. (The lambda/closure syntax is still in a state of flux.) Rust roughly follows C/C++/Java syntax, except that, like Go, it's a "name: type" language. Talking about ownership in code is new, as is the syntax for that. The ownership syntax is a bolt-on, and it shows. The lambda syntax is kind of weird; the designers went for conciseness over clarity. Some of this will take getting used to. The syntax is no worse than C++, and in some areas, better. The syntax isn't the hard part, anyway. It's living within the ownership restrictions that's hard. It's hard because that's a design issue. There's a Rust port of Doom, and it has far too much unsafe code, because Doom's data structures were not designed with Rust in mind. It's not yet clear how big an issue this will be. The remark that 10% of Servo, the web page renderer, is unsafe code is a bad sign. I don't have a personal opinion on this yet. I haven't written enough Rust code. I'm writing an RSS feed parser to get a sense of what it's like to deal with a complex tree in Rust. So far, it's going well, with no need for unsafe code. If Rust can eliminate buffer overflows, dangling pointers, and memory leaks, that's enough to justify using it in place of C/C++.

wycats 12y ago
For what it's worth, I've written two fairly large pieces of code in Rust: Skylight and much of Cargo. In both cases, the amount of unsafe code was very small (tiny) and restricted to FFI boundaries, which are "unsafe" even in high level languages like Ruby. Servo has been under active development for far longer, and sometimes used unsafe code to work around historical issues that no longer require unsafe code. I find the idea of an idiomatic codebase (written today), that is 10% unsafe code (outside of FFI boundaries) to be difficult to imagine.
eddyb 12y ago
Mentioning Go for `name: type` may not be inaccurate, but it is an odd choice (we're seeing more comparisons of Rust and Go than Rust and any language it is closely related to). I believe the origin for Rust's choice is actually the ML family. EDIT: I just checked more carefully and Go doesn't even have the colon ([this blog post](http://blog.golang.org/gos-declaration-syntax http://blog.golang.org/gos-declaration-syntax) used it in pseudocode).