Ben - I'm sorry, this turns into a rant. Please forgive me and extract the useful bits 😄
This is a hard problem. I don't think there's "an answer". How do you approach these sorts of situations in the ecosystem of your choice?
Damn straight it's hard. One of the reasons I left Rust behind (about two years ago) was the focus on Nightly by Rocket - it seemed insane that what was (at the time anyway) the most popular web framework in the language relied on the version of Rust with a shifting API (and I see it still does - madness). A language that ostensibly prides itself on stability and correctness shouldn't really have a Nightly channel with big projects depending on it. It shouldn't have a Nightly channel at all.
I was unaware of actix-web but I can't say I'm surprised - the maintainer has obviously decided that correctness is not as important as raw speed - as the examples from the WebFramework Benchmarks show - or his ego.
Regarding raw speed - I saw the same nonsense kick off in the Go community a few years ago as every framework maintainer built and boasted of the 'fastest' HTTP framework like they were racing muscle cars down the L.A. River. I see nothing's changed. It's such a ... ridiculously empty metric. Frameworks can be as quick as you like, but if your code isn't maintainable, and the framework isn't stable, then it's really not worth it. The latency from a slow web server is - to my mind - usually negligible unless it's really slow.
Anyway, to answer your point: how do I approach this in the ecosystem of my choice?
My ecosystem of choice is Go, and I choose - usually with an irritatingly iron will - to only use the standard library if I can bloody well help it.
An horrific experience with NodeJS (ah, left pad) left me highly suspicious of dependencies which were themselves towers of dependencies (another criticism of actix-web - and almost all modern frontend development). What I like about Go is the way that the language is very, very stable - almost pathologically so. And the standard library is good enough. No, it's not the fastest HTTP library - not even the fastest one in Go. But it's fast enough, well documented, and very nice to read if you have a mind to of an afternoon, or if you're wondering just how it is that the HTTP headers get parsed. You feel as safe and comfortable using it as you do using the strings library, or adding two numbers together.
Now how would I approach this 'wonder framework' or actix-web? I'd try and ignore it until it goes away - which it will. The developer will get bored of it, or get a job, or move on to yet another language in which to build Greased Lightning and - poof - all of a sudden there are no maintainers and a mess of unmaintainable code and a thousand developers screaming in the wilderness about how it isn't fair.
Well, bully. If you favour hype and speed over maintainability and community then you deserve everything you get in the end.
Yes, Rocket was what drew me to Rust, and Nightly is what drew me away from Rocket. It felt crazy to me at the time, quality of the framework aside. That's why I hopped to actix-web the moment I heard about it - similar functionality but stable rust, and this whole cool Actor idea to boot, which isn't really relevant anymore.
ecosystem of choice is Go,
That's the thing about Go I liked. The standard library gets you way further than you expect. I should give it another shot someday.
... favour hype and speed over maintainability and community
This is rough, because actix-web was specifically a situation which I had hoped was avoiding all this, and headed towards the latter two. I guess it remains to be see how it all shakes out - meanwhile I'll do my servers in something else with an eye on tide once async/await stabilizes. I think that's as close to the Go-style stable standard way of doing things as we'll get for a while, and it looks pretty good...but relying on a language feature that hasn't even landed yet means we're a ways away from anything robust.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Ben - I'm sorry, this turns into a rant. Please forgive me and extract the useful bits 😄
Damn straight it's hard. One of the reasons I left Rust behind (about two years ago) was the focus on Nightly by Rocket - it seemed insane that what was (at the time anyway) the most popular web framework in the language relied on the version of Rust with a shifting API (and I see it still does - madness). A language that ostensibly prides itself on stability and correctness shouldn't really have a Nightly channel with big projects depending on it. It shouldn't have a Nightly channel at all.
I was unaware of
actix-webbut I can't say I'm surprised - the maintainer has obviously decided that correctness is not as important as raw speed - as the examples from the WebFramework Benchmarks show - or his ego.Regarding raw speed - I saw the same nonsense kick off in the Go community a few years ago as every framework maintainer built and boasted of the 'fastest' HTTP framework like they were racing muscle cars down the L.A. River. I see nothing's changed. It's such a ... ridiculously empty metric. Frameworks can be as quick as you like, but if your code isn't maintainable, and the framework isn't stable, then it's really not worth it. The latency from a slow web server is - to my mind - usually negligible unless it's really slow.
Anyway, to answer your point: how do I approach this in the ecosystem of my choice?
My ecosystem of choice is Go, and I choose - usually with an irritatingly iron will - to only use the standard library if I can bloody well help it.
An horrific experience with NodeJS (ah, left pad) left me highly suspicious of dependencies which were themselves towers of dependencies (another criticism of
actix-web- and almost all modern frontend development). What I like about Go is the way that the language is very, very stable - almost pathologically so. And the standard library is good enough. No, it's not the fastest HTTP library - not even the fastest one in Go. But it's fast enough, well documented, and very nice to read if you have a mind to of an afternoon, or if you're wondering just how it is that the HTTP headers get parsed. You feel as safe and comfortable using it as you do using thestringslibrary, or adding two numbers together.Now how would I approach this 'wonder framework' or
actix-web? I'd try and ignore it until it goes away - which it will. The developer will get bored of it, or get a job, or move on to yet another language in which to build Greased Lightning and - poof - all of a sudden there are no maintainers and a mess of unmaintainable code and a thousand developers screaming in the wilderness about how it isn't fair.Well, bully. If you favour hype and speed over maintainability and community then you deserve everything you get in the end.
Yes, Rocket was what drew me to Rust, and Nightly is what drew me away from Rocket. It felt crazy to me at the time, quality of the framework aside. That's why I hopped to
actix-webthe moment I heard about it - similar functionality but stable rust, and this whole coolActoridea to boot, which isn't really relevant anymore.That's the thing about Go I liked. The standard library gets you way further than you expect. I should give it another shot someday.
This is rough, because
actix-webwas specifically a situation which I had hoped was avoiding all this, and headed towards the latter two. I guess it remains to be see how it all shakes out - meanwhile I'll do my servers in something else with an eye on tide once async/await stabilizes. I think that's as close to the Go-style stable standard way of doing things as we'll get for a while, and it looks pretty good...but relying on a language feature that hasn't even landed yet means we're a ways away from anything robust.