Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A 30-minute Introduction to Rust

doc.rust-lang.org

Post reply on HN
Print view View original

31–40 of 94 posts

Re: A 30-minute Introduction to Rust

#31

Post by klibertp »

Pacabel wrote: post #20
pcwalton wrote: post #18

Earlier quoted context omitted.

C++ is not safe in the same sense that Rust is. Without the use of "unsafe", Rust is designed to never segfault or have undefined behavior, ever. Even a modern subset of C++ cannot make the same guarantees (consider iterator invalidation, etc.)

I'll gladly use modern C++ techniques and a bit of care, even if that means only getting say 90% or 95% of the safety that Rust potentially offers offers, if it also means that I can get my code written today, and I can trust that it'll still compile unchanged tomorrow, next week, and probably a decade from now. I think it's great what Rust could potentially offer software developers. But it's still pretty theoretica…

Long-term stability is not exactly needed for Project Euler solutions, don't you think?

I think you're overreacting here - somebody barely mentions a language and you immediately start praising said language for features not even needed in this particular person use cases.

Re: A 30-minute Introduction to Rust

#33

Post by steveklabnik »

njharman wrote: post #32

Who is "behind" Rust? A company, consortium, academics, BDFL? http://www.rust-lang.org/ doesn't have an about page. Didn't see answer listed in the FAQ.

Mozilla is behind most of it. The original creator has already left the project, so we don't have a BDFL. There is a core team, mostly of Mozilla employees. Tilde has been contracted to do the package manager, I have been contracted to do documentation. There's a pretty significant community for a language so young, our IRC channel has ~600 people in it.

Re: A 30-minute Introduction to Rust

#34

Post by blub »

Out of curiosity I implemented the two examples in C++11.

For the number add I used a unique_ptr (although returning by value would be better in every way).

For the shared state I used async with a lamba that calls transform and returns the modified vector through a future. This doesn't execute in parallel for each for loop though. I think something like Arc can be coded in C++ too - template wrapper that returns a RAII lock whick unlocks on scope end.

I think the only big difference is that some errors in Rust are happening at compile time. In the first case the original buggy code was triggering only a warning in C++.

Right now the extra compile-safety of Rust is IMO not worth giving up the other benefits of C++, especially now that C++11 with some extra static checking and good guidelines can go a long way.

Re: A 30-minute Introduction to Rust

#35

Post by Pacabel »

klibertp wrote: post #31
Pacabel wrote: post #20

Earlier quoted context omitted.

I'll gladly use modern C++ techniques and a bit of care, even if that means only getting say 90% or 95% of the safety that Rust potentially offers offers, if it also means that I can get my code written today, and I can trust that it'll still compile unchanged tomorrow, next week, and probably a decade from now. I think it's great what Rust could potentially offer software developers. But it's still pretty theoretica…

Long-term stability is not exactly needed for Project Euler solutions, don't you think? I think you're overreacting here - somebody barely mentions a language and you immediately start praising said language for features not even needed in this particular person use cases.

I doubt that working on small casual programming puzzles is his only use for programming languages. I read his comment as saying that that's merely all he's used Rust for, so far.

Short-term and long-term stability are needed for just about any serious software application or system. They're useful to have even for short scripts that might be reused later on.

And he said he was "terrified" by C++. I explained why he shouldn't be. I'm not sure why you're getting worked up over that.

Re: A 30-minute Introduction to Rust

#36

Post by steveklabnik »

blub wrote: post #34

Out of curiosity I implemented the two examples in C++11. For the number add I used a unique_ptr (although returning by value would be better in every way). For the shared state I used async with a lamba that calls transform and returns the modified vector through a future. This doesn't execute in parallel for each for loop though. I think something like Arc can be coded in C++ too - template wrapper that returns a R…

Box is roughly equivalent to unique_ptr, and you're correct, returning by value would be better. Rust idiom is to use stack allocation and borrowing wherever possible.

> I think the only big difference is that some errors in Rust are happening at compile time.

This is true in these examples, except maybe the enforcement of not using a pointer after you've sent it to a task.

That said, there are other examples, like iterator invalidation, where Rust is completely memory safe, unlike C++. Furthermore, Rust has significantly less undefined behavior and odd edge cases. These are in C++ for good reason, but they're still there.

> with some extra static checking and good guidelines can go a long way.

They can go a long way, and that may be enough for you. Big applications continue to have security issues due to problems that Rust would prevent, though: in the last Pwn2Own, all of Firefox's bugs would not have been possible in Rust, for example.

Re: A 30-minute Introduction to Rust

#37

Post by klibertp »

Pacabel wrote: post #35
klibertp wrote: post #31

Earlier quoted context omitted.

Long-term stability is not exactly needed for Project Euler solutions, don't you think? I think you're overreacting here - somebody barely mentions a language and you immediately start praising said language for features not even needed in this particular person use cases.

I doubt that working on small casual programming puzzles is his only use for programming languages. I read his comment as saying that that's merely all he's used Rust for, so far. Short-term and long-term stability are needed for just about any serious software application or system. They're useful to have even for short scripts that might be reused later on. And he said he was "terrified" by C++. I explained why he…

> I'm not sure why you're getting worked up over that.

I'm not! And I agree with all your points here. It's just that this is not a thread about C++, but about Rust, and about solving small puzzles with it for that matter. Which makes both original mention of being "terrified by C++" and your explanation a bit off-topic. I won't downvote you or anything, I just wanted to point this out.

Re: A 30-minute Introduction to Rust

#38

Post by blub »

steveklabnik wrote: post #36
blub wrote: post #34

Out of curiosity I implemented the two examples in C++11. For the number add I used a unique_ptr (although returning by value would be better in every way). For the shared state I used async with a lamba that calls transform and returns the modified vector through a future. This doesn't execute in parallel for each for loop though. I think something like Arc can be coded in C++ too - template wrapper that returns a R…

Box is roughly equivalent to unique_ptr, and you're correct, returning by value would be better. Rust idiom is to use stack allocation and borrowing wherever possible. > I think the only big difference is that some errors in Rust are happening at compile time. This is true in these examples, except maybe the enforcement of not using a pointer after you've sent it to a task. That said, there are other examples, like i…

Thanks for the details. In all honesty I am probably not a target for Rust anyway, I almost never use C++ for systems programming, but rather for (cross-platform) application development. It would seem that neither Rust nor Go serve this area and probably do not intend to do it either.

Re: A 30-minute Introduction to Rust

#39

Post by steveklabnik »

blub wrote: post #38
steveklabnik wrote: post #36

Earlier quoted context omitted.

Box is roughly equivalent to unique_ptr, and you're correct, returning by value would be better. Rust idiom is to use stack allocation and borrowing wherever possible. > I think the only big difference is that some errors in Rust are happening at compile time. This is true in these examples, except maybe the enforcement of not using a pointer after you've sent it to a task. That said, there are other examples, like i…

Thanks for the details. In all honesty I am probably not a target for Rust anyway, I almost never use C++ for systems programming, but rather for (cross-platform) application development. It would seem that neither Rust nor Go serve this area and probably do not intend to do it either.

Could you expand on why?

I ask because the largest test case for Rust, Servo, is a cross-platform application, and I'm always looking to improve our marketing.

Re: A 30-minute Introduction to Rust

#40

Post by pcwalton »

blub wrote: post #34

Out of curiosity I implemented the two examples in C++11. For the number add I used a unique_ptr (although returning by value would be better in every way). For the shared state I used async with a lamba that calls transform and returns the modified vector through a future. This doesn't execute in parallel for each for loop though. I think something like Arc can be coded in C++ too - template wrapper that returns a R…

> Right now the extra compile-safety of Rust is IMO not worth giving up the other benefits of C++

I can't speak to everyone's use case, but for ours memory safety is extremely important. C++ is not safe, and we still see tons of memory safety issues, many security-sensitive, in practice, despite using modern C++ for all new code.

Even if safety isn't as important to you, there are other reasons you might be interested in Rust: a module system, pattern matching, a standard library which offers better performance than STL for many tasks, ADTs, concepts, a package manager, etc.

Post reply on HN