zemo

because their project goal is to iterate on the ownership model, not to iterate on the web design.

I use a self-hosted forgejo instance now (as of like, a week ago, let's see if I stick with it haha). I like GitHub the piece of software just fine, but I don't like the idea of my code training copilot. I think the design of GitHub is fine and people already know it, so I like that. If the reason you would want to not use GitHub is the design, gitea or forgejo will probably not be to your liking.

and fwiw, a lot of the assumptions in here are akin to saying at the dawn of photography that nobody would ever paint any more. Photography of course replaced certain entire categories of painting, but didn’t erase painting from the face of the earth altogether. Of course there are far more photographs than there are paintings, but volume alone is not the totality of meaning.

Generated content is strictly culturally regressive anyway. After a hundred years of ChatGPT will people still be writing prompts with “in the style of [person who produced all of their work before the year 2000]”? That would be a sad and boring future.

by 2017 Shark Tank was eight years old and Gwyneth Paltrow was a judge on apple’s short lived startup show that flopped. I really don’t know how much more obvious it could be that the trend had already jumped the shark in 2017.

how do you guarantee that the state that you set as the initial state is reachable in your system?

My argument is not that it’s impossible, it’s that the whole value proposition of these frameworks is that they make you jump through fewer hoops than building on top of Hyper yourself, but it looks like a lot of the problems that I’ve encountered with Rocket are being replicated with Axum. There’s a very good chance we -will- move our services to Axum, I’m just not confident that this is really stable ground.

As for the specific example, I think you’re missing the forest through the trees. I used that specific example because it’s in the article and it’s in Axum’s readme, so it’s safe to assume that people discussing the article would be familiar with that case.

Here's some pseudo-code of an endpoint that can accept json or form data as an alternative to the Json<T> abstraction that Rocket and Axum both currently utilize:

    async fn handler(thing: Thing) {
        // the Thing is read from the request by a request decoder.
        // The request decoder is chosen from a set of available
        // request decoders based on the Content-Type header.
    }

    let mut app = App::new();
    app.register_decoder(jsonDecoder);
    app.register_decoder(formDecoder);
    app.post("/thing", handler);
    app.run()

That's not really accurate. net/http provides an abstraction that has survived for a decade that has been leveraged by a lot of tools to make middleware interchangeable. For example, gorilla/mux uses the net/http standard, that has worked great for me for like 8 years running (unfortunately, that project lost its maintainer). The argument I'm making is that not all abstractions are equally good; Json<T> is an example of an abstraction that is used in Rocket that I have found to be cumbersome and Axum is repeating that abstraction. It's one of the very first examples in their docs. Why couple handler logic to request encoding? I think that abstraction is wrong, I don't think it will withstand the test of time, and in another year or two, will be back at it, updating our Axum services to use [some new thing].

So instead of the core abstraction being "every endpoint accepts whatever type it wants", the core abstraction could be "every endpoint accepts one value of the same type":

    async fn handler(req: Request<Body>) {
        // req.decoder looks at the content-type header and
        // picks from a list of registered decoders. If
        // the client picks an unsupported decoder it fails.
        let dec = req.decoder()?;
        let thing = dec.parse::<Thing>()?;
    }

    let mut app = App::new();
    app.register_decoder(jsonDecoder);
    app.register_decoder(formDecoder);
    app.post("/thing", handler);
    app.run()

I honestly would rather have that for HTTP requests than making an assumption about the content encoding in the handler's signature.

> (Well, you didn't really respond to the content of my comment at all, but nevermind.)

I mean my argument is "a thing that is trivially expressible and easy to do in other stacks has poor ergonomics in this framework" and your response is basically "ok so take the product of all of your endpoints and all of your encodings, ez pz", which ... is also not ergonomic? Literally the opening prompt was me saying I think that coupling the encoding to the endpoint's logic means you'd have to write another endpoint and that feels wrong to me, so ... you're just telling me to do the thing that I specifically said is the thing that makes me think this abstraction is weak.

Any server that has clients that aren't fully under your control that you can't force-update, where the clients today and the clients yesterday encode their requests differently.

I mean, it's the entire purpose of the `Content-Type` header. The whole concept is that the server has a set of encodings that it can understand, and the client can pick between them.

This isn't a new idea. Here it is in RFC 2068, from 1997: https://www.rfc-editor.org/rfc/rfc2068#page-116

These concepts have existed for decades.

In your comment, you make an implicit assumption: the assumption is that the person that writes the server is in control of the client. When we make tools that make it easier to construct software that assumes the server operator is in control of the client but do nothing to make it easier to build software in which the server operator is not in control of the client, we are making a political choice to place power in the hands of server operators at the expense of end users. That's not a political choice that I'm comfortable with.

Honestly it a lot of the Rust http frameworks strike me as eerily similar to either Falcore or Revel. Falcore was a very early Go http application framework built by ngmoco, a now-defunct game company. Falcore didn't really gain a lot of traction, partially because it provided abstractions that weren't very ergonomic. It's whole thing was that the core abstraction was a modular pipeline. https://github.com/ngmoco/falcore

I think most people know Revel, it's a little less obscure. It's philosophically the precursor to Gin.

Axum and Rocket have the same general thrust, the abstraction being that you define types to see a thing that’s not an HTTP request. That’s the abstraction that I think is incorrect. That design strategy is actively making things complicated for me on a daily basis at my dayjob writing services in Rust.

I want something higher level than Hyper but with a different theory of abstraction than Rocket or Hyper want to provide. The theory of Rocket’s abstraction is that the framework handles the http request and response for you, what you see is something else. That’s not the toolkit I’m looking for. The toolkit I’m looking for makes it easy to interact with http request and response streams instead of making it easy to hide their existence.

same line of reasoning as here

Honestly I don't think that Axum is right either. So for example, this:

    async fn create_user(
        Json(payload): Json<CreateUser>,
    ) -> impl IntoResponse {
         let user = User {
            id: 1337,
            username: payload.username,
        };
        (StatusCode::CREATED, Json(user))
    }

Rocket has a similar thing with its request guards, it has a similar json type that you put into the signature of a handler function and it automatically plucks the value from the body and parses it as json.

What's weird to me is that it's coupling the request and response format to the logic. What if a client wants to post this as a form body? Write a separate endpoint? What if some old clients put the arguments in the query string? When I see this snippet as one of the intro examples for Axum, it feels like a red flag to me.

> It's also interesting to note how the tone changes after receiving funding.

seems on-topic to me.

Honestly the JBL Charge speaker has the best and simplest solution to this: it just lets two devices pair to it simultaneously.

It has a full game loop but is very small. It takes 10-30 minutes to play through depending on how quickly you see through the puzzles. Right now I only have a Windows build :\

I worked on that for a few months full time, but have to get back to earning an income so I'm not working on it at the moment, interviewing instead. I did the game design MFA program at DePaul to find a group of people to learn to make games with, it was a lot of fun. I think without doing a program like that I would have wound up yak shaving in circles and making a bunch of tools instead of ever making any games.

I'm currently interviewing and this has come up in the first-round phone screen stage with everyone I've talked to.