8 ms·
A taste of pavex, an upcoming Rust web framework
- ptato 4y agoThe answer to help beginners understand highly generic rust code is not more abstraction and magic.
- deleted 4y ago[deleted]
- BoardsOfCanada 4y agoI'll definitely check this out, I have a microservice that I have rewritten in rocket, warp and axum that I'll port for comparison. Rocket was nice but has stalled, I read the author has health problems to focus on, so my go-to framework is axum for now. What I miss the most in the rust ecosystem compared to the kotlin+spring boot stuff I do at work is the dependency injection, I haven't found anything I like much in rust.
- BFLpL0QNek 4y agoHave you read this good series of blogposts on implementing Hexagonal Architecture in Rust? https://alexis-lozano.com/hexagonal-architecture-in-rust-1/ https://alexis-lozano.com/hexagonal-architecture-in-rust-1/ I’m the opposite, I don’t find much need for “dependency injection” frameworks. It’s trivial to do DI without frameworks.
- BoardsOfCanada 4y agoThanks, will check it out
- eklavya 4y agoThis hexagon architecture looks a lot like a free monad interpreter.
- chromatin 4y agoFYI Rocket has revived, and I heard recently he (Sergio) has made plans for a Rocket foundation so that the development team can be expanded and there is no longer SPOF
- nindalf 4y agoI respect Sergio but I’ve heard that like too many times in the last 3 years. Every few months it’s the same excitement whenever some activity is spotted on the repo. It always ends the same way - stalled yet again. The goodwill earned has been squandered. I’ll believe in rocket when I see releases being cut. Until then I strongly recommend no one touch rocket.
- capitainenemo 4y agoSo, the last time I asked on #rocket they told me the release was basically done, but they were not going to move past RC until the documentation was completed, which seems stalled. Is there anything else missing that you heard of?
- nindalf 4y agoI’ve heard that story many times. Maybe it’s true this time. I’m not going to stick around to find out because I got burned before.
- capitainenemo 4y agoCan you give a bit more detail on the burning bit? Just want to know if there's anything missing in particular from the 1.5 release besides the docs.
- db48x 4y agoWhy do other people need to be working on a library for it to be useful to you? Can’t you pitch in?
- 4y ago
- deleted 4y ago[deleted]
- dmitriid 4y agoI skimmed the post. Looks like asp.net approach of registering all dependencies up front (with various lifetimes/scopes). Still looks very verbose. But then asp.net has had a decade, and this project is new.
- smt88 4y agoI loathe this approach. Declarative architecture is incredibly hard to debug and understand.
- dmitriid 4y agoThere's nothing declarative in asp.net. You specifically define services and dependencies in one place in code. It goes something like this: public void ConfigureServices(IServiceCollection services) { // Add framework services. // Add application services. services.AddTransient<Type, ClassThatImplementsType>(); services.AddScoped<Type, ClassThatImplementsType>(); // etc. } So when dependency injection happens, you know exactly which class is used, and where it was added.
- smt88 4y agoThat's declarative. You're injecting code using the type system. You aren't directly calling any constructors with those classes -- they're added in code that you can't easily put a breakpoint in. The result is that you're looking at a class with a dependency of "ISomething" and you can't click through to the class. You have to go back and find where the services were configured (which sometimes isn't intuitive, depending on how the original person wrote the code). The worst is when there are entire behaviors added this way, and you just have to search your code base for keywords to figure out what's happening. It's awful. .NET is a great ecosystem, but the ".NET way" of doing the architecture is insane and not ergonomic.
- dmitriid 4y ago> The result is that you're looking at a class with a dependency of "ISomething" and you can't click through to the class. You can. Jetbrains' Rider will happily show you the implementation (Cmd + Option + Click IIRC) > The worst is when there are entire behaviors added this way, and you just have to search your code base for keywords to figure out what's happening. Not in ASP.net in mu experience. But true for Spring in Java. In ASP only the classes you declare in the constructor get injected. Only the classes registered in ConfigureServices get injected etc. All in all ASP.net has surprisingly little magic compared to many other frameworks. That's not to say it's without warts. There are definitely WTF cases and places where you can't properly stop a debugger.
- wokwokwok 4y agoI was with you all the way until the api example. That doesn’t look ergonomic, it’s verbose AF, and the ugly use of f! is (like most crates that lean heavily into macros) going break tooling like the intellij rust plugin. Does rust really need another web framework? Does it need a compiles-to-rust meta language that means you cant easily see the actual rust code you’re using? Does this feel ergonomic enough to make it worthwhile the downsides of the first two? Hm.
- rhodysurf 4y agoYeah I don’t get it. The Axum example is pretty easy and the actix counterpart would be easier. The pavex api looks way messier, but maybe it’s cuz I came to rust as an express and flask user
- pryelluw 4y agoIt’s Java written in Rust. :shrugs:
- deleted 4y ago[deleted]
- colejohnson66 4y agoMetaprogramming/macros are my biggest gripe with Rust. Sure, they're cool, but they're annoying when they're thrown all over the place. Especially proc-macros. You have no idea what it's actually doing unless you hunt it down.
- nbittich 4y agoIt has the worst ideas of the frontend world (transpiler) and the worst ideas of the backend world (verbosity of c#). I'll stick with Axum, thanks.
- deleted 4y ago[deleted]
- vbezhenar 4y agoIs there popular Rust web server which uses just threads with no async stuff?
- mfashby 4y agoRocket.rs I believe
- DoubleFree 4y agoRocket is moving towards async as well
- 0x457 4y agoRocket is not moving anywhere right now. 0.5 supposed to be async, but it's delayed more than a year because maintainer doesn't have time.
- Grimburger 4y agoYou don't have to use async in Rocket v0.5.
- stevedonovan 4y agoI suppose async web servers is the poster child of async, and drove a lot of the development. However, then _everything_ went async, adding the cognitive overhead of dealing with Rust async throughout the ecosystem, whether needed or not. In short, it still feels like a leaky abstraction: marvelous to look at working code, but errors (both compile and run-time) expose the underlying machinery underneath the syntactical sugar. This is probably heresy, but as a former Rust dev I'm enjoying web-services in Go more these days.
- afavour 4y agoI love Rust but I kind of agree. It’s really, really rare for a web service to need the low-level stuff Rust provides. A garbage collected is going to be just fine.
- i_dursun 4y agoLooks interesting and I am totally behind this for exploring new design decisions.
- KingOfCoders 4y agoLove your book and everything you do !
- didip 4y agoUgh, Dependency Injection Framework. This will not be popular. The blogpost itself is already shown what’s wrong with pavex. Adding so much concept and extra code just to be able to instantiate something. $1 abstraction cost for $0.05 problem.
- aliqot 4y agorust ecosystem is very JS-like in this regard, having spent the last few years working with it.
- deleted 4y ago[deleted]
- 0x457 4y agoYeah, so many more leaky abstractions that will be hard to debug. Not even sure why? You're not saving anytime by doing it this way. Axum already has good DI that is somewhat ergonomic in rust (well, I hate how extensions aren't checked at compile time like in warp...) I think the solution to "rust doesn't have DI like C# and Java" isn't trying to make DI like C# and Java (you won't be able without very heavy runtime cost), but make a DI that works well in rust and re-adjust yourself.
- 29athrowaway 4y agoYou identify a problem then create a leaky abstraction that is hard to understand to solve it and then call it ergonomic.
- deleted 4y ago[deleted]
- i_am_toaster 4y agoNot sure if author is the same as OP (I’m leaning towards not?), but if they are… I’m curious what caused you to go down the route of transpiling? Do you think that this methodology will be a core facet of the architecture, and will it be able to be changed when rust gives you the tools you seemingly want? Do you think that the transpiling will be annoying to debug and update as rust continues to mature?
- jokethrowaway 4y agoVery interesting to see movement but personally I found the debug_handler route picked by axum to be easier to understand and work with. Transpiling means you end up with two codebases and having to think about more abstractions. I sincerely hate transpiling from all the work I've done in node.js / babel and other similar devilish spawns
- deleted 4y ago[deleted]
- sanderjd 4y agoI like the idea! I disagree with other commenters here that dependency injection is not useful. I think it doesn't come across well in toy examples, but in my experience it is very useful for large services, which otherwise tend to accrue a big rats nest of instantiation in the startup code, which is difficult to modularize. I haven't built a service like that in Rust yet, so maybe other patterns work well, but I have noted these big instantiation entry points in rust code that I've read, so I'm skeptical that it is a solved problem. I do agree that it introduces a significant legibility and debugging burden, but I think that can be significantly better with compile time DI. However, I think it does require good tools that would take quite awhile to be built for an immature framework like this. But the thing I'm most skeptical of here is the implementation. Is there not enough information available in a normal procedural macro to figure out the dependencies, without using this trick with the rustdoc data? That approach seems very cheesy and likely fragile to me.
- pxeger1 4y agoI'm always wary of tools that as an extra compilation step, because of the added complexity. (Look at the common C workflow: cc was too hard to use on its own, so make was created; make was too hard to use on its own, so autoconf was created; m4; ...) I hope the user experience makes it worth the complexity.
- ploppyploppy 4y agoNo thank you
- tunnuz 4y agoIf you haven't also check out Zero to Production in Rust, it's an excellent book by the author of this framework.
- satvikpendem 4y agoYes, it's a great book, going through it now. https://zero2prod.com https://zero2prod.com
- jiggawatts 4y agoFYI: This framework uses rust doc-comments for essential functionality. It’s basically using the documentation tool’s JSON output programmatically during compile time. Generally this kind of “too clever” programming tends to fail in creative ways, especially over longer periods of time.
- 9dev 4y agoIt’s not using doc-comments, but compile-time reflection — it’s just that Rust‘s only reflection output is JSON. That doesn’t render the preposition of using a reflection API for transpiration invalid however. As long as the output code can be verified by tests, I don’t see how this would fail in „creative ways“.