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

Show HN: Rocket – Web Framework for Rust

rocket.rs

Post reply on HN
Print view View original

101–110 of 123 posts

Re: Show HN: Rocket – Web Framework for Rust

#101

Post by iopq »

eutectic wrote: post #23
Manishearth wrote: post #17

Earlier quoted context omitted.

> I've also heard it's for systems programming, which makes me think of C and has kept me away from it. One of its major goals is making systems programming more accessible. So you shouldn't dismiss it because "systems programming = C", it's trying to change that! :) That's not to say it won't involve learning some systemsy concepts. But it won't be as scary as C. You can't necessarily bang out scripts quickly. A typ…

There's nothing that makes typed languages inherently more verbose; a Haskell script will tend to be substantially shorter than the equivalent Python. Rust gives you much more control over how your program runs, but this necessarily means paying a price in expressiveness.

>a Haskell script will tend to be substantially shorter than the equivalent Python.

someone offered a counter-example where a JSON parser had more lines of type definitions in Haskell than total lines of code in Python

Re: Show HN: Rocket – Web Framework for Rust

#102

Post by SkyMarshal »

eveith wrote: post #86

I am not a web development guy, so this question might seem ridiculous: To me, it always seems that there are a lot of hazards in any web development project, security-wise: A number of attacks, be it injections, XSS, etc. When seeing a new web development framework, I always ask myself: Are the basic security concerns known today addressed? How can I make sure that choosing cool web framework in language X doesn't l…

This is actually the million dollar question, not remotely ridiculous. A lot of web frameworks are built with ease of use, productivity, and "fun" for developers in mind, but neglect security at the framework level, instead leaving security to be reimplemented by the devs on every new project.

But the whole point of a framework is to encapsulate all the things that you have to implement for every new web project, so you don't have to keep redoing that every time, and can instead focus dev time on new features and unique elements of each individual site. Securing against common vulnerabilities should be part of that.

There are a few frameworks that get this right, Lift (https://liftweb.net/) being the best I know of, designed to eliminate most of the OWASP Top 10 Vulns (https://www.ibm.com/developerworks/library/se-owasptop10/ind...) using Scala's strong type system and a virtual diff architecture similar to now-in-vogue Javascript frameworks like React. Haskell's Yesod framework is, as mentioned above, another good one in this respect.

Re: Show HN: Rocket – Web Framework for Rust

#103

Post by strictfp »

l1ambda wrote: post #71
strictfp wrote: post #59

Earlier quoted context omitted.

I've worked on everything you mention and more, and I find the simplicity of say node.js or SparkJava very refreshing when coming from metaprogramming frameworks. Once you go metaprogramming everything is suddenly metaprogramming. Data serialization is metaprogramming. Middleware is metaprogramming. Adding your own plugins to the framework becomes metaprogramming. Also, because the framework wants to create your clas…

Your post totally resonated with me, particularly how once you go metaprogramming everything is suddenly metaprogramming. I work at a Spring shop and we joke about how we should just be called Senior Java Annotators. I find it ironic that Spring does all this machinery in order to instantiate your application, yet often you end up needed to use the Order http://docs.spring.io/spring/docs/current/javadoc-api/org/sp...…

Hey! A colleague who also sees the light! I've been pushing for more programmatic control in our apps due to the same problems you mention. I would actually consider myself one of the most versed in Spring at our shop. But while I see so many problems, many devs only see "the beauty of the minimal code". I wish I could understand what is blindsiding them from all the problems we have.

The latest incarnation of this problem is Spring Boot. It does some really far out stuff to your app, like making m separate metrics for each unique url of your webapp. That goes south pretty quickly. Not to mention how much longer the app takes to start, how much slower it is compared to coding the same functionality manually (x4), how much trouble people have getting the right mental model of how the app works (with instrumented transaction boundaries and stuff that you mention), how hard it is to debug (why did this endpoint return 404?) etc.

We did some POCs with vert.x and spark, and all of a sudden you see what type of overcomplicated mess we have been creating for ourselves.

Re: Show HN: Rocket – Web Framework for Rust

#104

Post by chrismorgan »

sbenitez wrote: post #24
halestock wrote: post #21

Are dynamic params enforced at compile time? I.e. will the compiler ensure that the route "/ " has a matching id parameter?

Yes! Here's what happens when you don't do the right thing: error: 'id' is declared as an argument... --> src/main.rs:8:9 | 8 | #[get("/ ")] | ^^^^ error: ...but isn't in the function signature. --> src/main.rs:9:1 | 9 | fn hello() -> &'static str { | _^ starting here... 10 | | "Hello, world!" 11 | | } | |_^ ...ending here

The span for the “...but isn't in the function signature” should be just the `()` rather than the whole function.

Re: Show HN: Rocket – Web Framework for Rust

#105

Post by chrismorgan »

ekidd wrote: post #79
rubyfan wrote: post #68

I suppose this an advance for those already using Rust but the core message on the front page doesn't speak to me as a non-Rust person. FTA: Rocket is a web framework for Rust that makes it simple to write fast web applications without sacrificing flexibility or type safety . All with minimal code. I'm at a total loss for why I really care about this major part of their message (type safety). If I have already switch…

> I'm at a total loss for why I really care about this major part of their message (type safety). Honestly, you might not care about type safety. It depends a lot on the kinds of programs you write. In general, a language with a good type system[1] brings several major advantages to the table: 1. If your program compiles, there's typically a 90% chance it will work correctly on the first try, even if you just changed…

The state of completion in the JavaScript world is fairly impressive these days, considering what it is.

Re: Show HN: Rocket – Web Framework for Rust

#107

Post by chrismorgan »

amelius wrote: post #106

I'd like to use it, but I need a solution which allows to use the same language on client and server.

Wait for a few months and that will start to become viable, though it probably won’t be reasonable for two or three years.

Rust 1.14, released a couple of days ago, introduced experimental support for WASM/asm.js backends. There are experiments like https://github.com/tcr/rust-todomvc which show off the possibilities. At the moment it produces a rather massive blob (over 1MB as JavaScript, not sure as WASM), but that will improve, and for some situations that doesn’t matter so much anyway.

Re: Show HN: Rocket – Web Framework for Rust

#108

Post by chias »

eveith wrote: post #86

I am not a web development guy, so this question might seem ridiculous: To me, it always seems that there are a lot of hazards in any web development project, security-wise: A number of attacks, be it injections, XSS, etc. When seeing a new web development framework, I always ask myself: Are the basic security concerns known today addressed? How can I make sure that choosing cool web framework in language X doesn't l…

In this vein, one thing I'm not seeing (although I haven't finished reading the "book" yet) is built-in CSRF protection.

While not difficult to implement correctly yourself, I've found that applications written on frameworks that don't include this in the box tend to be applications vulnerable to CSRF.

Re: Show HN: Rocket – Web Framework for Rust

#110

Post by steveklabnik »

chias wrote: post #108
eveith wrote: post #86

I am not a web development guy, so this question might seem ridiculous: To me, it always seems that there are a lot of hazards in any web development project, security-wise: A number of attacks, be it injections, XSS, etc. When seeing a new web development framework, I always ask myself: Are the basic security concerns known today addressed? How can I make sure that choosing cool web framework in language X doesn't l…

In this vein, one thing I'm not seeing (although I haven't finished reading the "book" yet) is built-in CSRF protection. While not difficult to implement correctly yourself, I've found that applications written on frameworks that don't include this in the box tend to be applications vulnerable to CSRF.

https://github.com/SergioBenitez/Rocket/issues/14
Post reply on HN