Live data from Hacker News

Rust 0.5 released

mail.mozilla.org

31–40 of 54 posts

Re: Rust 0.5 released

#31
post #28

I'm a little rusty but I did read the 0.4 docs before and gave the language a try, I'll dive into 0.5 again this weekend, I am a little confused by something however. What's going on with strings? When I last looked, a lot of the string operations worked with a specific pointer sigil[1]. If I'm using managed boxes, and the methods take and return unique boxes, is it because I'm using the wrong sigil for the job or sh…

It's not your misunderstanding, there is just very little library suport for managed vectors (and strings). For quite a while managed vectors did not exist, so owned vectors are everywhere.

The semantics of managed vectors and owned vectors are quite different and unifying the library code so that managed vectors are more accessible will be a challenge. It is a widely-felt problem though and some folks have ideas for solutions.

For now, it is best to use owned vectors, but there are two modules, `core::at_vec` and `core::at_str` that can help you if you need them.

Re: Rust 0.5 released

#32
post #31
post #28

I'm a little rusty but I did read the 0.4 docs before and gave the language a try, I'll dive into 0.5 again this weekend, I am a little confused by something however. What's going on with strings? When I last looked, a lot of the string operations worked with a specific pointer sigil[1]. If I'm using managed boxes, and the methods take and return unique boxes, is it because I'm using the wrong sigil for the job or sh…

It's not your misunderstanding, there is just very little library suport for managed vectors (and strings). For quite a while managed vectors did not exist, so owned vectors are everywhere. The semantics of managed vectors and owned vectors are quite different and unifying the library code so that managed vectors are more accessible will be a challenge. It is a widely-felt problem though and some folks have ideas for…

Ah ok, brilliant. This was my main reason for not trying to play with Rust a little more. I thought it was something I just didn't understand. Just out of interest, is there anywhere I can have a look to see what kind of solutions have been suggested?

Re: Rust 0.5 released

#33
post #20

How is rust compared to Go?

I love both. If you are writing a production app today, I would strongly recommend Go. However, if you want to write an app that you want to take over the world with in a year or so, I would strongly recommend coding it in Rust. Go is a beautifully minimal language and very easy to learn. Rust isn't quite as productive, but it won't be too foreign for most coders either — unlike the Erlangs and Haskells of this world…

Thanks, that's very helpful, and good comments about the standard library. Tons of library support is what accounts for the "stickiness" of Java in the enterprise domain.

Re: Rust 0.5 released

#34
post #27
post #13

Earlier quoted context omitted.

Rust and Go may be superficially similar, but they are night and day semantically. They're also aimed at different niches and have wildly different goals. So though it may be tempting to compare the two, it's not an especially productive exercise. :) This town is more than big enough for the two of them.

It seems to me that any answer that stated specifically what those different niches and wildly different goals actually were would be a more productive exercise. If there's room for more than one of them in this town, in which part of town would each reside?

[Disclaimer: I've written only a tiny amount of Rust code, and no real Go code. I work for Mozilla but not on the Rust team.]

From what I've seen Go is designed with emphasis on ease of programming, performance, and concurrency; Rust is designed with emphasis on safety, performance, and concurrency. (Of course these are broad generalizations, and neither language is limited to only these concerns.)

Go is a simpler language in various ways. Rust provides more control over things like memory management but at the cost of some added complexity (e.g. multiple pointer types). Rust provides some abstraction/expressivity features that Go lacks (like parametric/generic types, macros, and algebraic datatypes), again at the cost of some added complexity. Rust makes more static safety guarantees (for example, no null or "nil" pointers). While the compiler provides many of these guarantees without creating extra work for the programmer, sometimes you do have to structure or annotate your code in a particular way so the compiler can prove its safety.

Of course the two languages are also similar in many ways. For example their syntaxes are in the C family; they compile to native code; they provide CSP-style concurrency; they have some amount of local type inference; and they do not use inheritance as the main style of composition.

Rust's safety features should make it ideal for writing security- or stability-critical code. Go's simplicity probably makes it faster to learn and better for rapid development, especially for programmers used to dynamic languages like Python or JavaScript. Rust's expressive power might provide more options for abstracting common patterns out of large codebases, or to provide libraries that extend the language in different ways (e.g. using macros). Go is more mature than Rust at the moment and has more libraries and a larger community. Rust has first-class support for code that does not use garbage collection, which can make it more suitable for certain types of systems programming.

Re: Rust 0.5 released

#35
post #5

I've really become quite a Rust fanboy, although I haven't written tons of code in it. IMO, it's considerably more accessible than Haskell or a ML-family. I'm not precisely sure why, but it seems to "make sense" in a very straightforward way. Some of it I think is lessons-learned from older languages, some of it might be the syntax, some of it just might be mental fit. Certainly - and this is a huge deal - I could re…

> I've really become quite a Rust fanboy, although I haven't written tons of code in it. As someone who's been meaning to try it out for a while, I have a couple of questions for you. First, how did you get started? I found the tutorial decent, but after reading through it, I didn't feel like I could quite jump in and start writing code. By contrast, I never actually read the Go spec/tutorials; I did a brief run thro…

- I don't have a good answer for you about how I started, I just got the compiler running and started writing code. A BST, as it so happened.

- I don't claim to understand the memory model entirely, but I think I have a grasp on it. This is due to my knowing C++ and having a grasp of the lambda calculus.

WRT libraries, it's not a mature language. It's not going to have the tens of thousands of libraries like Perl. I would recommend writing applications that fall into a functional programming/low level area, but that's just me. There's Servo, a research web browser.

Finally, I don't recommend comparing Rust with Go. Two languages and two different design goals. A better compare would be with D or OCaml.

Re: Rust 0.5 released

#36
post #35

Earlier quoted context omitted.

> I've really become quite a Rust fanboy, although I haven't written tons of code in it. As someone who's been meaning to try it out for a while, I have a couple of questions for you. First, how did you get started? I found the tutorial decent, but after reading through it, I didn't feel like I could quite jump in and start writing code. By contrast, I never actually read the Go spec/tutorials; I did a brief run thro…

- I don't have a good answer for you about how I started, I just got the compiler running and started writing code. A BST, as it so happened. - I don't claim to understand the memory model entirely, but I think I have a grasp on it. This is due to my knowing C++ and having a grasp of the lambda calculus. WRT libraries, it's not a mature language. It's not going to have the tens of thousands of libraries like Perl. I…

How is D or OCaml more Rust-like than Go? Can you explain?

Re: Rust 0.5 released

#37
post #27
post #13

Earlier quoted context omitted.

Rust and Go may be superficially similar, but they are night and day semantically. They're also aimed at different niches and have wildly different goals. So though it may be tempting to compare the two, it's not an especially productive exercise. :) This town is more than big enough for the two of them.

It seems to me that any answer that stated specifically what those different niches and wildly different goals actually were would be a more productive exercise. If there's room for more than one of them in this town, in which part of town would each reside?

Disclaimer: I'm not a Rust developer.

One way to think about this is that if you want to implement GitHub, use Go; if you want to implement git, use Rust.

Re: Rust 0.5 released

#38
post #36
post #35

Earlier quoted context omitted.

- I don't have a good answer for you about how I started, I just got the compiler running and started writing code. A BST, as it so happened. - I don't claim to understand the memory model entirely, but I think I have a grasp on it. This is due to my knowing C++ and having a grasp of the lambda calculus. WRT libraries, it's not a mature language. It's not going to have the tens of thousands of libraries like Perl. I…

How is D or OCaml more Rust-like than Go? Can you explain?

Rust is basically ML + C's lovechild. Sophisticated type inference, mostly pure variables, pattern matching lambda functions, a few other FP goodies. But it's also a fairly clean imperative language if you care to use it like that. Generics, mutable variables, {}; syntax, pointers, etc. Also, more fundamentally, I see D, OCaml, and Rust as occupying a "let's be clean" kind of space.

I see Go as occupying a "let's be scruffy" space; not really pushing the language state of the art, focused on industrial work; it's like a type-safer & compiled python, afaict. It doesn't really strive to push the state of the art, it seeks to solidify certain well-known taken ground in programming language design, and to be really focused on that.

I'm not going to apply a "better" metric, I don't think that's appropriate because they are occupying different areas in the design space with different goals. If they were posed as straight-up competitors, then it'd be appropriate to measure them against each other.

Re: Rust 0.5 released

#39
post #5

I've really become quite a Rust fanboy, although I haven't written tons of code in it. IMO, it's considerably more accessible than Haskell or a ML-family. I'm not precisely sure why, but it seems to "make sense" in a very straightforward way. Some of it I think is lessons-learned from older languages, some of it might be the syntax, some of it just might be mental fit. Certainly - and this is a huge deal - I could re…

> I've really become quite a Rust fanboy, although I haven't written tons of code in it. As someone who's been meaning to try it out for a while, I have a couple of questions for you. First, how did you get started? I found the tutorial decent, but after reading through it, I didn't feel like I could quite jump in and start writing code. By contrast, I never actually read the Go spec/tutorials; I did a brief run thro…

"Second, how did you come to understand the memory model? I consider myself more familiar in both functional programming and memory management than average, but I found the memory model to be a bit of a conceptual hurdle (even though I'm attracted to the approach on a philosophical level). Having such a unique memory model makes it a little tough to simply get started writing code right away."

I think that if you understand the smart pointers in C++ (especially C++11) you basically understand the Rust memory model. In C++ terms, Rust has stack-allocated data, std::unique_ptr, and (non-thread-safe) std::shared_ptr built into the language. (There's a thread-safe std::shared_ptr in the library.) We also have a bunch of safety checks to make sure you use the smart pointers correctly, so you can't use non-thread-safe pointers in threaded code, you don't have iterator or reference invalidation, etc.

The tricky part is making it accessible to folks not coming from C++, which is an important goal. Any ideas would be much appreciated :)

Re: Rust 0.5 released

#40
I'd hoped that rust would have a lot of powerful tools for typing and exposing invariants and contracts— tools to help create provably reliable software. As sexy as new programming tools are, the big problem in software today is that we simply can't manage the complexity of it and as a result _everything_ is full of bugs and unintended behavior. Addon layers like ACSL are hard to use and messy because they work at odds with the language, instead, e.g. of being integrated with the typesystem.

I was hopeful that rust could really advance the art here in the context of practically usable systems (vs academic toys) and I suppose it does, but it also lost features for formal analysis between versions and as its now becoming stable I suppose they won't return.

Post reply on HN