5 ms·

Syntax is amazing! Hope (so much) to see it possible on beta soon. Maybe for somebody it's not a new thing, but for me this: struct Message { contents:

Syntax is amazing! Hope (so much) to see it possible on beta soon. Maybe for somebody it's not a new thing, but for me this: struct Message { contents: String, } #[put("/<id>", data = "<message>")] fn update(id: ID, message: JSON<Message>) where message is auto-decoded - it's awesome!

deleted 10y ago
[deleted]
aaron-lebo 10y ago
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?
- k__ 10y ago
  Syntax is why sinatra and express got bit. Just add a callback for your route and off you go.
  - cpeterso 10y ago
    What does "got bit" mean?
    - zackify 10y ago
      he means got big ;)
      - k__ 10y ago
        lol, yes sorry. got bit sounds like I meant the opposite.
        cpeterso 10y ago
        Thanks. That does make more sense. :)
- steveklabnik 10y ago
  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 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!
  - deleted 10y ago
    [deleted]
  - CorvusCrypto 10y ago
    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.
- EugeneOZ 10y ago
  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.
- amelius 10y ago
  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.
  - iopq 10y ago
    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?
    - amelius 10y ago
      Yes, because function calls are much easier to trace down than special syntax.
jonaf 10y ago
Since you mentioned "for somebody it's not a new thing": this looks a lot like Flask, if you're into Python (except for the type safety); I'm sure there's a Ruby equivalent. It looks a lot like Jersey on the JVM (for Scala, Java, etc). This pattern is really nice for web frameworks. I'm super excited to see it for Rust! To me, this signals that we're getting pretty high up there on the early-adoption curve.
- strictfp 10y ago
  Sorry but I cannot agree. I work on the JVM and this pattern is great for "hello world" webapps but breaks down pretty quickly. When large parts of your logic like metrics, security and routing is being done with metaprogramming you're really doing yourself a disservice.
  - EugeneOZ 10y ago
    I disagree. It's great syntax for controllers - place where you should read request data. Services is another story , but you will always have place where you read initial request data.
  - jonaf 10y ago
    I've worked a lot with this pattern in Python (Flask), Java and Scala. I have found it a little inconvenient beyond the simple hello world app when dealing with Flask, but I haven't encountered this problem with Java/Scala. To date, I've worked on probably 4-5 separate applications using this pattern and it's worked quite well. I have also used Spring 4 on the JVM, which ... feels more flexible, but also has a lot of cognitive overhead, and so I'm not crazy about it. I believe Spring Boot follows closely after Jersey, most likely as a result of the pattern's popularity. In my experience, it is pretty straightforward to build your resources (as Jersey calls them) into various classes without any issue, even for applications with many API endpoints. As for metrics, security and routing, most of these are canonically managed using annotations in Java. In Spring, application context XML configurations are used, but they are very big and not close to their actual implementations, which makes them get out of control quickly (and inconvenient when they aren't out of control). It feels like losing either way. I'm a big fan of Coda Hale's work on Dropwizard, which uses metrics, security and routing through annotations, and it works very well for large scale production applications. I use these techniques at scale at Bazaarvoice with great success. To be fair, I won't go so far as to claim the pattern is imperfect. It's just the best pattern I've used for web services to date, even at scale. I would love for you to expound more on your own experiences in more detail! edit: clarification on where I've used the pattern
bwblabs 10y ago
Indeed way cleaner than Iron in terms of parsing query (int) arguments and JSON post data (BodyParser).

deleted 10y ago

[deleted]

aaron-lebo 10y ago

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?

k__ 10y ago
Syntax is why sinatra and express got bit. Just add a callback for your route and off you go.
- cpeterso 10y ago
  What does "got bit" mean?
  - zackify 10y ago
    he means got big ;)
    - k__ 10y ago
      lol, yes sorry. got bit sounds like I meant the opposite.
      - cpeterso 10y ago
        Thanks. That does make more sense. :)
steveklabnik 10y ago
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 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!
- deleted 10y ago
  [deleted]
- CorvusCrypto 10y ago
  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.
EugeneOZ 10y ago
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.
amelius 10y ago
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.
- iopq 10y ago
  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?
  - amelius 10y ago
    Yes, because function calls are much easier to trace down than special syntax.

jonaf 10y ago

Since you mentioned "for somebody it's not a new thing": this looks a lot like Flask, if you're into Python (except for the type safety); I'm sure there's a Ruby equivalent. It looks a lot like Jersey on the JVM (for Scala, Java, etc). This pattern is really nice for web frameworks. I'm super excited to see it for Rust! To me, this signals that we're getting pretty high up there on the early-adoption curve.

strictfp 10y ago
Sorry but I cannot agree. I work on the JVM and this pattern is great for "hello world" webapps but breaks down pretty quickly. When large parts of your logic like metrics, security and routing is being done with metaprogramming you're really doing yourself a disservice.
- EugeneOZ 10y ago
  I disagree. It's great syntax for controllers - place where you should read request data. Services is another story , but you will always have place where you read initial request data.
- jonaf 10y ago
  I've worked a lot with this pattern in Python (Flask), Java and Scala. I have found it a little inconvenient beyond the simple hello world app when dealing with Flask, but I haven't encountered this problem with Java/Scala. To date, I've worked on probably 4-5 separate applications using this pattern and it's worked quite well. I have also used Spring 4 on the JVM, which ... feels more flexible, but also has a lot of cognitive overhead, and so I'm not crazy about it. I believe Spring Boot follows closely after Jersey, most likely as a result of the pattern's popularity. In my experience, it is pretty straightforward to build your resources (as Jersey calls them) into various classes without any issue, even for applications with many API endpoints. As for metrics, security and routing, most of these are canonically managed using annotations in Java. In Spring, application context XML configurations are used, but they are very big and not close to their actual implementations, which makes them get out of control quickly (and inconvenient when they aren't out of control). It feels like losing either way. I'm a big fan of Coda Hale's work on Dropwizard, which uses metrics, security and routing through annotations, and it works very well for large scale production applications. I use these techniques at scale at Bazaarvoice with great success. To be fair, I won't go so far as to claim the pattern is imperfect. It's just the best pattern I've used for web services to date, even at scale. I would love for you to expound more on your own experiences in more detail! edit: clarification on where I've used the pattern

bwblabs 10y ago

Indeed way cleaner than Iron in terms of parsing query (int) arguments and JSON post data (BodyParser).