

Rust for C++ programmers – part 3: primitive types and operators - pohl
http://featherweightmusings.blogspot.com/2014/04/rust-for-c-programmers-part-3-primitive.html

======
xioxox
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 make more sense, and if the
programmer needs more or less they would have to think about that.

~~~
pcwalton
It's not out of concern of performance.

The idea was in fact to reduce correctness gotchas; ints are often used for
indexing into arrays, and you want the size of the integer to reflect the
maximum size of an array on your platform.

What kind of security issues did you have in mind? Integer overflow can be a
problem, but it is usually a memory safety issue, which Rust doesn't have due
to bounds checks and iterators.

~~~
alok-g
Their use as index to arrays sounds reasonable. However in this case it may be
wiser to give them less friendly names than those for the 32-bit and 64-bit
counterparts. To not have portability issues, it is important that the
programmer understands when int and uint should be used (index to arrays, the
sizes of which could be machine dependent) and when specified-size integer
types (when representing application-specific data).

~~~
pcwalton
Yeah, we considered naming them intptr_t and uintptr_t, but the "use an int to
index an array" is so ingrained into programmers' collective consciousnesses
that we decided it was pretty futile to go against the grain here.

~~~
alok-g
I don't really buy that reasoning. :-) If the goal is not to clean up bad
things, we may just stay with C++.

When a new language comes and the programmer is already having an intention to
learn something new, probably is working on a new project, this state is the
best opportunity for the cleanup. Once the language matures, legacy codebases
become rampant, that opportunity is gone forever with _that_ language.

Did you consider naming the type something like 'index' itself, if that is the
predominant good use-case for the type?

------
mercurial
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).

~~~
nnq
99% of such bugs can be avoided in a weakly typed language by simply having
the string concatenation operator different from the "+" operator (PHP has the
"." operator for this, VisualBasic has "&" ...Haskell has "++" ) ...yet
Javascript, Python and Ruby seem to stubbornly avoid this simple way of
achieving some sort of sanity (and yeas on this one PHP is above Python and
Javascript!).

Also, having "<" and ">" also work for strings is another semantic
abomination. You need different operators or just functions for doing this on
strings (and if you treat strings as collections they can also be your
collections operators).

These problems are not cause by "type coercion" itself (even if lots of people
agree that "type coercion" in general is a bad idea...), they are caused by
_mixing scalar operators and vector operators and converting one way or
another when doing this._ The only solution out of this is to either throw and
error for these coercion cases, or, when it actually makes sense, like in
Matlab you have scalars and matrixes, have a new separate set of operators for
these cases (like ".+" and friends family of operators).

~~~
lifthrasiir
No. PHP's `+` operator always tries to convert to the number, and uses 0 (!!!)
when it is not possible. (e.g. what is `"hello" \+ "world"`?) Having different
operators hardly matters; operators should cause a visible and clear error if
they were given unexpected operands. Python is better in that regard since it
does not allow `str + int` and so on.

~~~
nnq
You're right, I forgot about this abomination. I retract any praise for PHP :)
But I still think having one operator "+" for scalars, one like "&" for
strings and another one like "++" for lists makes a lot of sense even in a
dynamic language.

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

~~~
b0b_d0e
Kinda, yes, but not really. Currently, the best http framework in Rust is
rust-http ([https://github.com/chris-morgan/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.com/jroweboy/oxidize](https://github.com/jroweboy/oxidize))
aims to be an inherently safe and fast web framework inspired by several other
frameworks, but I don't consider oxidize to be even in a pre alpha state right
now (pre alpha to me means, don't try to write code with it cause it will
change drastically in the near future). I've rewritten the code for it twice
already and a third time is sitting in a branch that doesn't compile right
now. Progress has been a little slow lately since it became a group project
for a class of mine, and that meant that I needed to manage several people
working on it rather than actually contributing code. Over the summer I hope
to get it in a good state and then make a post about it and fill out
documentation, make tests, submit it to techempower benchmarks, and other
necessities.

Having said that, I'm not confident yet that you want to be coding a web site
in rust. In the name of safety, rust's compiler can be very difficult to
please and in the name of speed it doesn't compile blazingly fast as well.
Some people may have a different opinion from me, but besides writing a web
app to learn the rust language, what advantages for the web does rust give you
that go or haskell doesn't? When you are writing a web app, developer
productivity is priority number one (in my opinion), and having to fight the
borrow/lifetime checker and trying to find out why your struct doesn't fulfil
`Send` are not things I would like to have to do when I'm making a web site.
The tradeoff will be that hopefully a web site written in rust will be both
fast and concurrently safe, but you will be sacrificing developer productivity
for the reasons mentioned above. Irregardless of those issues, I'm still very
determined to make a rust web framework that is both fast and easy to develop
for (probably by providing examples of common web idioms in oxidize so people
can see how to do it), just, I want people that use my framework to be aware
of the tradeoffs that they will make. In short, I consider oxidize an
experiment in trying to make a powerful, expressive, and extensible web
framework in rust, and along the way I've started to question whether this
will have any practical applications, but in spite of that, I still am trying
to achieve the previous listed goals.

~~~
mercurial
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.

~~~
b0b_d0e
Thats the rework that I'm working on! I'm debating between making a context
trait and having the static function signature include a context instead of a
request and the everything request related would be included/appended in the
context, or having the user implement "controller" trait on their struct that
has a method I will call after settling the routes (something like
[https://github.com/jroweboy/oxidize/blob/incoming/tmp/matchb...](https://github.com/jroweboy/oxidize/blob/incoming/tmp/matchblockheroes.rs#L37)
where maybe a macro can generate this method from the urls. Note that this
code doesn't compile though :) While I was initially fond of the latter, it's
been very painful to work with in practice and I don't see it actually
working, so I think that I'll be testing out to see if I can rework the static
functions to have a context. I think the hardest part is that I want to
eliminate any need to have any static variables, but that means I have to
store them all in a struct that requires Send to be fulfilled and thats more
over head for programmers. In the near future, I will be looking into using
the different parts of rust-http directly rather than implementing the server
trait to see if I can gain any benefits from that :)

~~~
mercurial
Personally, I'd be inclined to have the context separate from the request,
since they're really two different things. Also, you could introduce a
FromRequest trait (trivially implemented by Request, returning self) to allow
the user to build structures directly from a request (and its converse
ToResponse), giving your function a signature of:

    
    
        fn (context: Context, req: FromRequest) -> ToResponse
    
        trait FromRequest {
          fn from_request<'a>(req: &'a Request) ->  &'a Self;
        }
    
    
        impl FromRequest for Request {
          fn from_request<'a>(req: &'a Request) ->  &'a Request {
            req
          }
        }
    

This would remove a lot of boilerplate for well-behaved applications. You'll
also need a notion of middleware, which I guess would take a Request and
return either a ToResponse or a request (eg, an authentication handler ought
to return the response immediately in case of authentication failure), and
similarly on the way out, something taking a Response and returning a
Response.

~~~
mercurial
Ah, obviously this wouldn't work, from_request would need to return Self and
not a reference for it work, which means some overhead in the case of Request,
since you'd have to clone it.

------
sisalcat
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.

~~~
adamnemecek
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?

~~~
pbsd
Probably quite a few. There's also more than just division by 0 to be wary of:
[http://blog.cmpxchg8b.com/2013/02/the-other-integer-
overflow...](http://blog.cmpxchg8b.com/2013/02/the-other-integer-
overflow.html)

