1. 43

  2. 11

    I am so, so excited about this! It had me at

    fn hello(name: &str, age: u8) -> String {...

    Seriously, it’s hard to find safe routing patterns among any other request-oriented rust library. Most of the time, you have to .get().unwrap() parameters from a Map or something. If you don’t like the .unwrap(), you need to handle the None case, which is a huge anti-pattern IMO, since you defined the route such that it’s impossible to enter the handler if it’s None. Gah!

    I wrote my own horribly hacky macro library for my own routing purposes. The code it generates isn’t pretty, but it’s at least validating the routes at compile time, no .unwrap() necessary.

    But this look leaps and bounds better. Can’t wait to build more stuff with rust now!

    1. 3

      Sadly, this is a no-go for me (even as a Rust fan and contributor):


      It means that you are also pulling in an unspecified amount of issues and problems that is constantly changing along with the library.

      I know they need compiler plugins for a lot of their things, but I’m also opposed to them :).

      Additionally, the core lib is full of unstable features which will not be stable for a long while, so you can’t even bypass codegen and code the busywork by hand.

      1. 3

        I’m not a rust person, figured I’d give it a try.

        Can’t get the hello-world example to build because cargo can’t fetch the crates index because of some git issue talking to https://github.com/...

        Every time I try projects like this, and the tooling is wonky, it makes me appreciate golang that much more.

        Fascinating that someone voted this down as (incorrect). I can show you my terminal if you want, this did actually happen, and is actually a defect.

        1. 5

          Too bad this happened. Given the limited info you gave it could be different things: 1. a transient error connecting to github 2. a proxy in use that somehow breaks the connection 3. using a broken version of cargo (yes, we had that recently…)

          From my own experience I find the Rust tooling far more reliable than what Go offers.

          1. 2

            Do you think that’s because golang has concretely better tooling in some way or because you’ve grow accustomed to its quirks? I’ve experienced the promising new library without a working example a lot, regardless of language. I’d be curious to hear what approach go takes that can address it.

            1. 5

              Quirks that hang up new golang devs:
              * $GOPATH
              * the import system
              * (new) vendoring

              Things that golang gets right:
              * When things fail, they fail in very transparent ways. An example would be, if I had the above issue, I would 100% be able to reproduce it if I tried a git clone myself, vs. rust where it’s not shelling out and it’s some other configuration or library issue.
              * golang has no configuration files, everything you need can be inferred by what’s on disk.

              Basically it comes down to, an initial hurdle of slight magic with golang, and then extreme transparency and logic with everything after that initial acclimation period.

            2. 2

              On other end of spectrum, I had to try to code something in a hurry on a new computer without knowing tooling or programming due to memory loss. FreeBASIC did a simple install, I/O worked as in tutorials, typed stuff into text editor, and ran compiler with terminal command.

              Effortless just like QBasic I started with ages ago. Another good one from my early time was LISP box or something like that. Integrated everything from editor to compiler in one executable. Stuff like this is how I judge how easy tooling is to install and get running with.