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

Rust for C++ programmers – part 3: primitive types and operators

featherweightmusings.blogspot.com

Post reply on HN
Print view View original

11–20 of 68 posts

Re: Rust for C++ programmers – part 3: primitive types and operators

#11

Post by sisalcat »

b0b_d0e wrote: post #10
sisalcat wrote: post #5

From the project home page: "prevents almost all crashes (in theory)" How does it prevent index out of bounds errors and division by zero? No, not even in theory. What a ridiculous claim.

index out of bounds errors are handled in separate ways depending on the kind of array you are using. If I understand how it works correctly, you can be working with one of three main kinds of arrays: slices with a known length, slices with an unknown length, or a growable vector. In the case of slices with a known length, ie: let a = [0]; then trying to say a[1] is a compile error since the compiler knows the length…

> it will cause a task failure

i.e. a crash.

Re: Rust for C++ programmers – part 3: primitive types and operators

#12

Post by dbaupp »

adamnemecek wrote: post #6
sisalcat wrote: post #5

From the project home page: "prevents almost all crashes (in theory)" How does it prevent index out of bounds errors and division by zero? No, not even in theory. What a ridiculous claim.

I mean you get an error but not a segfault. Rust crashes on division by zero but honestly, how many crashes have you encountered in the real world due to division by zero?

You get a task failure (similar to an exception) on division by 0 too.

Re: Rust for C++ programmers – part 3: primitive types and operators

#13

Post by sisalcat »

nrc wrote: post #9
sisalcat wrote: post #5

From the project home page: "prevents almost all crashes (in theory)" How does it prevent index out of bounds errors and division by zero? No, not even in theory. What a ridiculous claim.

All array indexing is bounds checked, so those kind of errors are prevented. We're still working on the story around overflow checking

This prevents buffer overflow errors, but not crashes.

Re: Rust for C++ programmers – part 3: primitive types and operators

#14

Post by dbaupp »

b0b_d0e wrote: post #10
sisalcat wrote: post #5

From the project home page: "prevents almost all crashes (in theory)" How does it prevent index out of bounds errors and division by zero? No, not even in theory. What a ridiculous claim.

index out of bounds errors are handled in separate ways depending on the kind of array you are using. If I understand how it works correctly, you can be working with one of three main kinds of arrays: slices with a known length, slices with an unknown length, or a growable vector. In the case of slices with a known length, ie: let a = [0]; then trying to say a[1] is a compile error since the compiler knows the length…

Indexing a fixed-length array (I.e. known at compile time) out of bounds is not prohibited at compile time. All array types trigger a task failure on out-of-bounds access (unless you explicitly opt-in to unchecked indexing).

Re: Rust for C++ programmers – part 3: primitive types and operators

#15

Post by dbaupp »

sisalcat wrote: post #11
b0b_d0e wrote: post #10

Earlier quoted context omitted.

index out of bounds errors are handled in separate ways depending on the kind of array you are using. If I understand how it works correctly, you can be working with one of three main kinds of arrays: slices with a known length, slices with an unknown length, or a growable vector. In the case of slices with a known length, ie: let a = [0]; then trying to say a[1] is a compile error since the compiler knows the length…

> it will cause a task failure i.e. a crash.

It doesn't necessarily take down the whole program, ice. it's recoverable, unlike memory corruption or a segfault.

(Yes I know you can install signal handlers for segv, but that is not isolated at a language level like a task failure is with Rust.)

Re: Rust for C++ programmers – part 3: primitive types and operators

#16

Post by sisalcat »

dbaupp wrote: post #15
sisalcat wrote: post #11

Earlier quoted context omitted.

> it will cause a task failure i.e. a crash.

It doesn't necessarily take down the whole program, ice. it's recoverable, unlike memory corruption or a segfault . ( Yes I know you can install signal handlers for segv, but that is not isolated at a language level like a task failure is with Rust.)

Yes, I can catch SIGSEGV. And I can catch Java NullPointerExceptions and ArrayIndexOutOfBoundsExceptions. So Java prevents all crashes, lol.

Re: Rust for C++ programmers – part 3: primitive types and operators

#17

Post by dbaupp »

sisalcat wrote: post #13
nrc wrote: post #9

Earlier quoted context omitted.

All array indexing is bounds checked, so those kind of errors are prevented. We're still working on the story around overflow checking

This prevents buffer overflow errors, but not crashes.

It prevents the OS killing a misbehaving application (which is what is meant by "crash" in that context). This allows, for example, a multithreaded server application to continue even if one worker task indexes an array incorrectly.

Re: Rust for C++ programmers – part 3: primitive types and operators

#18

Post by dbaupp »

sisalcat wrote: post #16
dbaupp wrote: post #15

Earlier quoted context omitted.

It doesn't necessarily take down the whole program, ice. it's recoverable, unlike memory corruption or a segfault . ( Yes I know you can install signal handlers for segv, but that is not isolated at a language level like a task failure is with Rust.)

Yes, I can catch SIGSEGV. And I can catch Java NullPointerExceptions and ArrayIndexOutOfBoundsExceptions. So Java prevents all crashes, lol.

Yes, Java applications are rarely killed by the OS/memory manager for trying to access memory they don't have control over.

Re: Rust for C++ programmers – part 3: primitive types and operators

#19

Post by mercurial »

b0b_d0e wrote: post #7
camus2 wrote: post #2

what about rust for webapps? are there any frameworks out there?

Kinda, yes, but not really. Currently, the best http framework in Rust is rust-http ( https://github.com/chris-morgan/rust-http ) and it has the things needed for handling requests and sending responses. But as far as actual full featured web frameworks, there is only one that I know of (discounting mre since it hasn't been updated in a long time) and that's because I am the creator of it. oxidize ( https://github.co…

What I like about it is that it's pretty devoid of macros. I'm curious as to how you are planning to handle the environment of the webapp (configuration, connection pool, business objects...), given that you settled for plain functions with a given signature.

Re: Rust for C++ programmers – part 3: primitive types and operators

#20

Post by sisalcat »

dbaupp wrote: post #18
sisalcat wrote: post #16

Earlier quoted context omitted.

Yes, I can catch SIGSEGV. And I can catch Java NullPointerExceptions and ArrayIndexOutOfBoundsExceptions. So Java prevents all crashes, lol.

Yes, Java applications are rarely killed by the OS/memory manager for trying to access memory they don't have control over.

That's a strange definition of "crash" you have there. I should go tell my customers next time that their programs definitely didn't crash.
Post reply on HN