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

51–60 of 68 posts

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

#51

Post by sehugg »

mercurial wrote: post #4

Having been the victim of a fun Javascript bug recently (something like ("1" + 10)*2), I must say that I agree that type coercion is the wrong thing to do 99% of the time (probably with the exception of attempting to divide integers).

I think that one safe exception is upcasting of integer types (e.g. i8 to i32) and I think it's a little awkward to program in Rust without it.

It seems also that using the "as" syntax for both upward and downward casts makes code a little harder to read. Either allowing implicit upcasting or having separate syntaxes for safe vs. unsafe numeric casts would make more sense to me.

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

#52

Post by lucian1900 »

AlisdairO wrote: post #49
alkonaut wrote: post #30

Earlier quoted context omitted.

Java raises an exception. If you handle it in code, the app does not crash. The crash is a consequence of failure to handle and recover from the exception. Granted, it is very rare that you can/should recover from nullpointer or OOB exceptions anyway. What you can do though is try to clean up things, show a polite message and shut down the application in a semi-controlled way. "Preventing crashes" isn't the best desc…

It's not that uncommon to want to recover from NPEs in a webapp environment. You want your thread of execution to error out, return a 500, and rollback whatever db changes it's made, but you want the webapp as a whole to keep running.

And this is precisely what task failure in Rust lets you do. Requests run in tasks, if the task fails, show an error message and make a new task for the next request.

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

#53

Post by unwind »

masklinn wrote: post #43
mercurial wrote: post #40

Earlier quoted context omitted.

Yes (though it treats 1 as True and 0 as False, which it really ought to avoid).

Historical imperative though, for backwards compatibility with if some_bool == 1 or if isinstance(some_bool, int) written before the bool type was added (which only happened 2.3)

I dream of a language where booleans cannot be compared explicitly against literals, that would be awesome.

I have powerful dislike for code like the future version of the above, i.e.

    if some_bool == True
since that, in my mind's machine, just generates a bool result, which then (in the logic of the code) must be compared to True. If the result of == doesn't have to be compared, then why does some_bool? It's brutally inconsistent and fantastically annoying.

Unfortunately, to many programmers it's also second nature to write such comparisons. Gaah. :(

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

#54

Post by simias »

Ygg2 wrote: post #50
xioxox wrote: post #48

I understand that there is probably a performance motivation for having int/uint having machine-dependent sizes. However, it seems to me that having different sizes on different platforms is a potential security hazard if the programmer doesn't think of this. It also gives rise to porting bugs. Isn't the idea of rust to make a securer language than C++? I would have thought mandating 32 or 64 bit for int/uint would m…

I do remember a discussion on mailing list that all uint/int would be just fancy typing for u64/i64.

Wouldn't that mean that the code would have a huge performance penalty when running on 32bit hardware?

I think C99's way of handling that is fine, if you want to use whatever native width happens to be on your hardware you just use int/unsigned, otherwise you have stdint.h.

Like C, rust could mandate a minimal range for each type in the standard, but setting the type width in stone seems dangerous to me, both for backwards and forwards compatibility.

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

#55

Post by masklinn »

unwind wrote: post #53
masklinn wrote: post #43

Earlier quoted context omitted.

Historical imperative though, for backwards compatibility with if some_bool == 1 or if isinstance(some_bool, int) written before the bool type was added (which only happened 2.3)

I dream of a language where booleans cannot be compared explicitly against literals, that would be awesome. I have powerful dislike for code like the future version of the above, i.e. if some_bool == True since that, in my mind's machine, just generates a bool result, which then (in the logic of the code) must be compared to True. If the result of == doesn't have to be compared, then why does some_bool? It's brutally…

Equality might be used for other things, e.g. a map with boolean keys, stuff like that. So I don't think it would be workable.

You could try removing Eq, Ord and TotalOrd from Rust's bool and see what breaks.

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

#56

Post by Dylan16807 »

unwind wrote: post #53
masklinn wrote: post #43

Earlier quoted context omitted.

Historical imperative though, for backwards compatibility with if some_bool == 1 or if isinstance(some_bool, int) written before the bool type was added (which only happened 2.3)

I dream of a language where booleans cannot be compared explicitly against literals, that would be awesome. I have powerful dislike for code like the future version of the above, i.e. if some_bool == True since that, in my mind's machine, just generates a bool result, which then (in the logic of the code) must be compared to True. If the result of == doesn't have to be compared, then why does some_bool? It's brutally…

>where booleans cannot be compared

Sounds like a way to make XOR be a big pain.

Or do you only want to ban comparing to literals? It can make things clearer to write something like "if bool==false" rather than "if not bool", especially when double negatives get involved.

Only ban comparing to literal true? Sure, go for it. But then the language is more complex for no real benefit.

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

#57

Post by coldtea »

simias wrote: post #54
Ygg2 wrote: post #50

Earlier quoted context omitted.

I do remember a discussion on mailing list that all uint/int would be just fancy typing for u64/i64.

Wouldn't that mean that the code would have a huge performance penalty when running on 32bit hardware? I think C99's way of handling that is fine, if you want to use whatever native width happens to be on your hardware you just use int/unsigned, otherwise you have stdint.h. Like C, rust could mandate a minimal range for each type in the standard, but setting the type width in stone seems dangerous to me, both for bac…

>Wouldn't that mean that the code would have a huge performance penalty when running on 32bit hardware?

Or it could just forget 32bit hardware altogether. Even mobile phones are going 64bit already -- and the language will be ready for production in 1-2 years, where even more platforms will be 64bit.

It's not like they have to compromise just to be able to run on some embedded stuff.

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

#58

Post by coldtea »

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.

No. Something recoverable, like an exception.

But it seems you have your mind set, and wont accept any other answer.

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

#59

Post by coldtea »

alkonaut wrote: post #30
sisalcat wrote: post #20

Earlier quoted context omitted.

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.

Java raises an exception. If you handle it in code, the app does not crash. The crash is a consequence of failure to handle and recover from the exception. Granted, it is very rare that you can/should recover from nullpointer or OOB exceptions anyway. What you can do though is try to clean up things, show a polite message and shut down the application in a semi-controlled way. "Preventing crashes" isn't the best desc…

>Granted, it is very rare that you can/should recover from nullpointer or OOB exceptions anyway.

Actually it can be quite common, especially in complex web / network programs with many components. In Java such errors do not corrupt memory like in C, and since they are isolated, no reason not to continue the operation of the overall program. The error could just be due to a resource not being found, or faulty input coming from outside -- that is, nothing that prevents you from continuing to work on other requests.

That's somewhat like Erlang handles the case, if I am not mistaken.

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

#60

Post by alkonaut »

AlisdairO wrote: post #49
alkonaut wrote: post #30

Earlier quoted context omitted.

Java raises an exception. If you handle it in code, the app does not crash. The crash is a consequence of failure to handle and recover from the exception. Granted, it is very rare that you can/should recover from nullpointer or OOB exceptions anyway. What you can do though is try to clean up things, show a polite message and shut down the application in a semi-controlled way. "Preventing crashes" isn't the best desc…

It's not that uncommon to want to recover from NPEs in a webapp environment. You want your thread of execution to error out, return a 500, and rollback whatever db changes it's made, but you want the webapp as a whole to keep running.

Of course when you have a web application running requests using some thread pool or even more lightweight worker, then what we call the "application" is likely the request and you most likely don't want to kill the app server because you have good reason to believe the other requests are unaffected by the failing requests.
Post reply on HN