Rust for C++ programmers – part 3: primitive types and operators
featherweightmusings.blogspot.com
Rust for C++ programmers – part 3: primitive types and operators
1–10 of 68 posts
Re: Rust for C++ programmers – part 3: primitive types and operators
#2what about rust for webapps? are there any frameworks out there?
Re: Rust for C++ programmers – part 3: primitive types and operators
#3what about rust for webapps? are there any frameworks out there?
Not really. A lot of the infrastructure has kept changing for a while (eg, the IO facilities were recently rewritten), so code for older versions of Rust (like [1]) fall behind and do not get updated anymore.
With Chris Morgan's rust-http library (which I think is also used by Servo), you should have the base on which to build a web framework. Somebody apparently wrote (and still maintains) a pure Rust Postgresql driver ([2]), so you could in theory write a simple CRUD webapp, if you're willing to write the routing yourself.
Re: Rust for C++ programmers – part 3: primitive types and operators
#4Having 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).
Re: Rust for C++ programmers – part 3: primitive types and operators
#5From 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.
Re: Rust for C++ programmers – part 3: primitive types and operators
#6From 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?
Re: Rust for C++ programmers – part 3: primitive types and operators
#7what 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.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.
Re: Rust for C++ programmers – part 3: primitive types and operators
#8From 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?
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...
Re: Rust for C++ programmers – part 3: primitive types and operators
#9From 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
Re: Rust for C++ programmers – part 3: primitive types and operators
#10From 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 of the array at compile time, it will not let this code compile. In the case of an unknown length at compile time, the compiler cannot really help you here, but it will cause a task failure when you try to access out of bounds (since it does know the length at runtime, it checks to make sure that it is in bounds). This is similar to what happens when you are trying to access an element that doesn't exist on growable vector as well. I hope this information clears up somethings for you and even more so I hope my information is correct! I'm still learning rust, so I still have misunderstandings quite often.