Hacker News Reader

Comment by aaron-lebo | Hacker News Reader

Edit: should preface this by saying the framework looks really impressive. I've been looking for a Rust web framework to settle on and this is the most appealing.

It's funny to note how much something small like this matters. It's syntax sugar and presentation, but the difference a comment like this has at the top of an HN post vs an ambiguous but detailed discussion about feature x...massive in effect.

It doesn't seem to be the case, but the entire framework under that could be bad yet it's caught mindshare on the basis of routing syntax (one of the smallest worries in a production web application). Wonder how many frameworks have failed just on the basis of not making a similar decisive first impression?

Syntax matters?

View on HN

We're in the process of addressing discoverability of the crates.io ecosystem, which led to this RFC: https://github.com/rust-lang/rfcs/pull/1824

A quote from it:

> By far, the most common attribute people said they considered in the survey was whether a crate had good documentation. Frequently mentioned when discussing documentation was the desire to quickly find an example of how to use the crate.

Open source projects, in a sense, are like startups: if you want to acquire users, your users have to be able to understand the product! A deeply impressive technical project is, well, impressive, but if nobody can figure out how to use it, it's not going to see nearly as much uptake as a technology that's got a clear and easy way to use it.

There's secondary effects too: a project with a slick website like this makes people take it more seriously. It's less likely that someone who put this much effort in is just going to drop it immediately, though of course, that's not an absolute rule.

TL;DR: developers are users too. Developer marketing matters!

Can I just say, I cannot applaud you enough (nor other contributors to rust) for how much you care about developer opinions and ease of their introduction to the language and subsequent use! I freaking love you guys.

API (and modern web servers are API only) should:

1) handle route (read data, transform, prepare other resources, check access rights)

2) generate response with reading/writing to db.

First step is not so primitive. Reading request data is often boilerplate-rich code, so syntax which can remove tons of boilerplate is very welcomed.

Personally I don't like domain-specific sugared syntax. I prefer clarity above all, especially since I hope to spend the least possible amount of time in the networking domain, and this means I'd otherwise have to relearn the syntax whenever I have to dig into the code again.

When digging into new projects I always find that there's going to be cognitive overhead because of certain abstractions.

    let always_forward = Route::ranked(1, Get, "/", forward);

this is a normal function call, but what does it mean? Is that really better than special syntax that desugars to this code?

Yes, because function calls are much easier to trace down than special syntax.

Syntax is why sinatra and express got bit.

Just add a callback for your route and off you go.

What does "got bit" mean?

he means got big ;)

lol, yes sorry. got bit sounds like I meant the opposite.

Thanks. That does make more sense. :)

Reply on news.ycombinator.com