Writing a website in Rust
blog.viraptor.info
Writing a website in Rust
1–10 of 141 posts
Re: Writing a website in Rust
#2Thanks for the detailed write-up. You are a pioneer in the rust webdev space and have created a map (with the dragons labeled) for others :)
Re: Writing a website in Rust
#3Thanks for the detailed write-up. You are a pioneer in the rust webdev space and have created a map (with the dragons labeled) for others :)
Haha, I didn't intend to go for detailed :) I'm pretty sure there's a lot more to tell about the details. I just wanted to at least list all the modules I've been looking for / using in this webapp. Thank you for the feedback.
I intend to write another post with some very basic skeleton / hello-world of a new Iron application using database with connection pooling, templates, logger, parameter parsing. But that's for another day.
Re: Writing a website in Rust
#4Thanks for the detailed write-up. You are a pioneer in the rust webdev space and have created a map (with the dragons labeled) for others :)
Haha, I didn't intend to go for detailed :) I'm pretty sure there's a lot more to tell about the details. I just wanted to at least list all the modules I've been looking for / using in this webapp. Thank you for the feedback. I intend to write another post with some very basic skeleton / hello-world of a new Iron application using database with connection pooling, templates, logger, parameter parsing. But that's for…
Please do so, and tell HN. Many of us are paying attention.
Re: Writing a website in Rust
#5[deleted]
Re: Writing a website in Rust
#6> Actually the compiler checks cover most of the things I’d normally unit-test, so this is probably the only non-trivial project I wrote without checks and I’m OK with that.
This is interesting. First time I read about Rust I had this gut feeling that it's design might reduce the number of unit testing cases. Someone care to comment on that?
Re: Writing a website in Rust
#7> Actually the compiler checks cover most of the things I’d normally unit-test, so this is probably the only non-trivial project I wrote without checks and I’m OK with that. This is interesting. First time I read about Rust I had this gut feeling that it's design might reduce the number of unit testing cases. Someone care to comment on that?
Just to add some context, here are the tests which I didn't write, but would in Python/Flask usually:
- Proper behaviour if I don't pass a parameter. Not needed, because it's an explicit `Option` which I have to handle.
- Is results list constructed properly / what's the None-vs-empty behaviour. Not needed, `Vec` is verified at type level and None is not possible.
- What happens if various database functions don't find a result. Not needed, because type signatures force either a returned `Entity` (if it's not there, it's an implementation bug: panic + 500), or `Option` which again needs to be explicitly handled.
But these are only unit tests. If it was a critical app, I'd still write functional / logic tests to make sure the right data goes all the way to the database and back in known scenarios. Types can't guarantee that.
One kind of tests I'm tempted to write is for templates rendering properly, because handlebars-iron takes parameters as Json - all type guarantees go out of the window there. But it may be the same amount of effort to migrate to some type-safe templating like Maud.
Re: Writing a website in Rust
#8> Actually the compiler checks cover most of the things I’d normally unit-test, so this is probably the only non-trivial project I wrote without checks and I’m OK with that. This is interesting. First time I read about Rust I had this gut feeling that it's design might reduce the number of unit testing cases. Someone care to comment on that?
I've dabbled with rust, but did quite a bit of stuff in haskell.
A lot of unit testing is verifying failure modes. What happens if they pass in null? What happens if they ask for a value i don't know about? stuff like that. Haskell (and rust) give you a lot more control over what a function is willing to accept at compile time.
You could spend your time writing a test to ensure null is handled gracefully. With rust, you have a bit more power, and you can simply ensure the function can't be called with null. It's more general than just null checking, but that's the flavor of what happens.
Re: Writing a website in Rust
#9> Actually the compiler checks cover most of the things I’d normally unit-test, so this is probably the only non-trivial project I wrote without checks and I’m OK with that. This is interesting. First time I read about Rust I had this gut feeling that it's design might reduce the number of unit testing cases. Someone care to comment on that?
I've dabbled with rust, but did quite a bit of stuff in haskell. A lot of unit testing is verifying failure modes. What happens if they pass in null? What happens if they ask for a value i don't know about? stuff like that. Haskell (and rust) give you a lot more control over what a function is willing to accept at compile time. You could spend your time writing a test to ensure null is handled gracefully. With rust,…
That's my general feeling as well. Coming from Scala transition into "dabbling" with Rust was actually quite smooth. I try to stick to functional style where possible, exhaustive pattern matching, everything wrapped in Result/Option, etc - eliminates the need of unit testing in many cases.
Re: Writing a website in Rust
#10Here's something that most of you will probably learn the hard way: popularity and merit are not the same thing.
Rust is very popular now. That doesn't mean it has a great design. One of the very first design decision/belief they made was "no code can perform with garbage collection". Well, garbage collection does cause quite a few performance problems, but that doesn't mean it can't work if you engineer it right.
Personally I think Go and Nim are better languages as a general statement, both for applications and systems programming.
I know I am going out on a limb making a negative statement like that, and previously Nim developers have tried to discourage me from saying negative things about Rust. Those guys are smart and have social skills and they realize they should be careful to be nice to Rust developers because sophisticated developers looking for things like performance, type safety, etc. with a C or C++ background are really going to benefit from Nim if they give it a chance and Rust developers are prime candidates for Nim conversion.
So let me just say clearly that I don't associate with the main Nim community, the core developers, or anyone really. Nothing I say here reflects on them I hope.
I literally have no friends in fact.
I don't understand people, or pay much attention to them, or interact with them very much. When I do interact I say what I really think, not what people want to hear.
What I DO understand is technology. From a very early age I have been programming in everything from different types of assembly language to C to C++ to Ruby, Javascript/CoffeeScript/ES7, different variants of SQL, Rust, Forth, OCaml, etc.
Mozilla is a leading technology organization with many contributors. Rust is a new technology with quite a few people innovating on it.
Unfortunately, Rust starts with a bad design decision and never really recovers from that design decision. The values and perspective are lacking a modern, contemporary perspective.
The Rust worldview is trapped in the C++ era.
I have been primarily a JavaScript developer both on the front and back end for many years now. Why? Because I like to make useful applications and I am sane and paying attention.
But in a world where people were better informed and had better judgement and the best things won out rather than the most popular, Rust would be an obscure language being toyed with by a few academics for (perhaps?) implementing certain parts of kernels, the new browser from Mozilla would be fully peer-to-peer capable (using IPFS/gittorrent/swarm/ndn etc), written in Nim of course, use JIT/VM/something Nim for scripting, and have thrown out JavaScript/ES6/ES7 AND CSS for good. Of course, in this ideal world there would be no google monopolizing all advertizing and capturing most good engineering talent, since semantic markup and p2p query would also be be built in to this browser, making google irrelevant. The default mode for the browser would be virtual reality, with the ability to render 2d operating systems or markdown/images on arbitrary 3d surfaces.
But instead we have the world we have. All advertising must follow the dictates of a giant all-powerful global corporation. Mozilla is trapped in a pseudo-C++ mindset and spending most of its efforts trying to reproduce the intractable mess of decades of CSS hacks, in the time the engineers have left after going through in excruciating detail all of the possible ways to 'borrow' memory. CSS, a brilliant system that is a pain the in the ass not only for programmers but also designers, so complex that only two computer programs in the world are known to do a reasonable job of rendering it accurately.
Its time to stop dragging the old tools, mindsets, and technical debt forward. Stop judging things on the basis of momentum or authority (Google/Mozilla/Microsoft) and start using your brain to select things rationally.
Mozilla as an organization is not going to be capable of admitting they made a mistake with Servo/Rust and recoding it in Nim. Just like the world is not going to accept that we should throw out CSS and use any other simple system that can reproduce graphic designs. And we are not getting rid of JavaScript with its horrible threading model and garbage collection anytime. But we should. In a sane world we would learn from our mistakes and throw all of that out.