Great post. I do the same thing for all of my Rust web servers too. I don't use anyhow though, prefer rolling everything myself - which as you call out is a pain after a while.
I used to use Actix for a web project, but the Websocket story was severely lacking. Actix is non-work-stealing multi-threaded (to achieve "performance", I presume) and thus it has to use a non-async Actor model for inter-Websocket interactions. This meant that I could not use an async DB pool or an async HTTP requests library within my Websocket code.
Alternatively, Axum is built by the same people that made tokio, is work-stealing multi-threaded, and the Websocket code is async be default. It is just overall a better library.
I've happy about the recent stabilization of WebGPU in Chrome, and excited for the rest of the browsers to follow suit.
I wanted to start experimenting with it, and attempted to do so with Deno (which is what I've been developing in the past few projects), and I'm sad to find out that they recently removed WebGPU from its interface due to slower start up times and larger binary sizes [0][1] :/ I hope they re-enable it soon so that I don't have to mess around with tsc and webpack again...
I wouldn't say Chromium's WebGPU is stable just yet. It still doesn't run on my Linux system anyway. Mind you that both the Dawn and WGPU c libraries work on this system.
It is kind of ironic that with so many Linux based stuff and two operating systems, the Mountain View gnomes have decided to support Windows and Mac first.
Kind of tells where they see business value to deploy first.
If we don't experiment with getting off of this rock, we're dooming the lives of all known living organisms in the known universe.
An entire universe, void of all life, that doesn't get to experience itself deeply saddens me. Though that might just be the fitness-function within me talking.
"But the spores may not be all bad though. Cortesao's research is looking for ways the space-growing fungi may help us long-term, investigating their capacity to grow in less than ideal conditions. The study's aim is to harness the hardy microbes as biological factories to create materials astronauts may use on longer missions, such as antibiotics and vitamins."
I've created a few projects using the Node/Express ecosystem and have so far loved it. I'm starting to branch out and learn Go now. Can you discuss/compare your experience working in both ecosystems?
We switched from a small Node Hapi monolith to Go at the end of 2017. The main reason to switch was that we wanted to get types to get more explicit code. We considered a number of options (TypeScript, .NET Core, Dart, etc) and ended up picking Go because it's a nice simple language and the performance is great over Node.
We reduced memory usage by 80% over Node. We never had a performance bottleneck with Node either but it feels nice to be running on the smallest Heroku dyno and knowing you won't need much more for at least a couple of years.
As for the developer experience we vastly prefer Go over JavaScript. It's more tedious at times but there is no more ambiguity. We love that we barely need any dependencies. Moving from JS to Go was extremely easy as all devs in our team are polyglots and Go is pretty simple. I don't know how easy it would be for a JS only dev, but I imagine it wouldn't be too hard.
When using NPM/Node/JavaScript it seems there are always hidden dangers, probably more in the front end than when doing backend Node. With Go there are no surprises, everything feels solid and predictable.
After about 2 years with Go we are still happy with the decision.
Thanks for the detailed response! I was definitely going to ask 'why not TypeScript?' if your issue was mainly types, but you beat me to it! I reached similar conclusions regarding the benefits you witnessed switching to GO; it's nice seeing them spelled out.
