Rust vs Go : Hands On Comparison
ฝัง
- เผยแพร่เมื่อ 2 ต.ค. 2023
- Recorded live on twitch, GET IN
/ theprimeagen
Reviewed blog article: www.shuttle.rs/blog/2023/09/2...
Author: Matthias Endler | x.com/matthiasendler?s=20
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts - วิทยาศาสตร์และเทคโนโลยี
![[UPDATE] Mojo Is Faster Than Rust - Mojo Explains More](http://i.ytimg.com/vi/MDblUyz0PtQ/mqdefault.jpg)
![[TH] 2024 PMSL SEA GF D1 | Summer | แข่งที่ไทย ต้องใส่ให้สุด](http://i.ytimg.com/vi/Jkuf7nCS7jI/mqdefault.jpg)
"everybody loves tokio except that for that one person that writes those articles like 'don't use async rust' and tokio is inveitably mentioned in it" literally the same author as this article 🤣🤣🤣
Guy who wrote both articles here. I kinda like Tokio. There's just more alternatives people should explore. But maybe I should write one titled "how far can you get with sync Rust" 🤓
@@HelloRustThat's unironically a banger article. Defo gonna read it if you do it.
@@HelloRusttokio feels so heavy, somehow heavier than python asyncio.
I feel the need to at least kinda understand portions of most of the libraries I use, and I know that I could just hitch together an event loop using generators and async http primitives in python.
Tokio is black box magic to me, and I only write silly little scripts and tools in rust so far. Tokio seems like overkill
@@dnullify100 Or as Prime says, just use parallel. I don't know of a good usecase for a CLI tool to include its own worker pool, especially when the IO is independent from each other.
@@dnullify100 Idk, I think it feels heavier to you because you're aware of a lot more of what it's doing (because unfortunately you need to), while in Python it kinda just works without you knowing how it did, so it feels like there isn't much "machinery" there.
Go devs: “You must manually check every error every time always. No the language will not help you with with that”. Elixir devs: “just let it crash lol”
Other language devs: just try if it's crash
if go had the ? operator to automatically propagate errors up the call stack like rusts shortcut for match, everybody would stop making weird complaints about the error handling
PHP devs: Error? Let's continue anyway lol.
@@Dhalucario What the user pasted a shell script into the username dialogue box. Better execute it for them :p
Just don't allow Elixir devs write Go code
It's also worth mentioning that any external dependency is a liability to a project. Go standard library is very stable, so from my experience it's much easier to maintain in the long run, as the project matures.
How it benchmarks against the frameworks?
@@beneditomaurooFrankly not that much difference, since the frameworks tend to use the standard library under the hood.. Yeah except for fiber which uses fasthttp...
except go is build around external dependencies and external code.. so something isn't right in your comment.
Standard libraries get updated just like external ones
I'm proud to say that I've converted my company to use both
Go for more "general" microservices and rust for the microservices that are a bit cpu/ram heavy
Least insane dev
hire me, now.
It's understandable for faster iteration, but Rust is all-around the safer language. No null and forced error handling. It's not just a language focused on performance
What did you switch from?
This is the only correct answer
The beauty of Rust is that I feel so confident when it is compiled. I remember when I was using C++ and I had to keep thinking about the program with full of fear. It is not just for performance. It is for mental health.
Segmentation fault. Core dumped.
Rust has a negative effect on the brain.
@@bebobauomy1265 all programming language has.
confident when it's compiled? Rust code still contains bugs when improperly used. Memory leaks, infinite loops and blowing up a stack can all still happen. Sure, it catches some issues that a C++ compiler doesn't catch. But in return you have to wrestle with the borrow checker, which has its own impact on mental health ;)
@@martijn3151 there is no bug free language. Rust prevents a lot of common human errors and that's all I need.
There has been the argument, that error handling distracts from the business logic. One of the main reasons for me to prefer Go right now is, that the way of error handling it enforces, encourages me to see errors which can occur as part of the business logic, when writing.
Ideally, there should be ways to force the developer to *think* about errors whilst still allowing them to ignore them should they actively choose to. This is why .unwrap is so powerful.
? Is awesome as well.
@@AdroSlice My personal opinion is, that an error should never be ignored. If it was ignorable, there would not be error potential.
@@timdithmer9184 Handling an error case you know to be impossible, but that cannot be detected as such by static analysis tools, has a performance downside.
@@AdroSliceCouldn't you just use _ to ignore the error?
Concurrency in rust is fearless, but not painless
@@johnyepthomi892just don't write concurrency, painless 🧠
25:03 These two code block are alternative implementations. Both are mapping the error: the first is mapping the error in the pattern matching case; the second is using the `.map_err` method.
Good reason to use Go is there actually being jobs looking for it
"but it also distracts from business logic"
Error handling SHOULD be part of the business logic.
I disagree. You should think about error handling. Error handling should be explicit (i.e visible in your code), a part of your regular code, but I don't think it takes away from this philosophy to have it handled a bit more succintly. Ultimately, 70% of the time you do actually want to look at the happy path only, and conceptualise the general flow of a request through your codebase. Regardless, I'm fine with either and it's not a dealbreaker for me (for reading, not for writing).
dun dun DUUUUUUUUUUUU
@@VivekYadav-ds8oz You're talking sh!t and making your own sentence false. How can someone "not think about error handling" and at the same time make it visible in the code? You're a proper dumbazz that I deal with in day-to-day life.
If error is from the same level of abstraction as the business logic (ie. Getting a 404 when calling external api) - sure, that should be in business logic.
But handling errors from lower layers (getting tcp/ip error when doing the same api call) that's just noise and distraction, as it has nothing to do with your business logic, nor should it have
He meant happy path
lol I was java programmer and I had good experience with go recently and I was wonder what if I learn rust for my new project. so I searched and found Primes former video about rust and go and to see other video , I searched and reached this vid that has uploaded in 2 hours ago. love you and I'll watch it after this comment ends
My favorite try catch pattern is the one that doesn't throw or log the error. Really love that.
6:43 I'm not offended by having to handle errors but I'm offended by the result type being (nil + result) * (nil + error) rather than result + error. :-P
33:50 template-in-code is a big issue at my current job. I’m trying to maintain/update an old PL/SQL web server but all of the HTML templates are distributed in bits and pieces throughout the tightly coupled source code. The first thing I did was write static templates to replace the ones created by the PL/SQL code
Yeah I hate that. I prefer a hard frontend/backend seperation, connected by an API, for most of my projects. I guess I'm in the smallest minority - Wanting SPAs for webapps, but not wanting JS on the backend.
The fact the article spends the majority of the time explaining how you would or could do it in Rust should tell you everything you need to know.
This go example illustrates why you'd prefer try/catch - you really don't care about "failed to parse JSON" case - it getting caught by global exception handler and converted to a 500/logged with a stack trace perfectly fine, and if it's not it's trivial to wrap the external call in a block that's as granular as you'd like. There are a bunch of error cases I can do nothing about except some logging and return the same error response + rollback - try/catch/finally works just fine. I get that this isn't true for systems programming where you want to be rigorous about error handling - but in this example (web app talking to external services), or stuff like GUI, it's superior IMO.
You only need to define "json" tags on struct fields in Go if you want to e.g. `,omitempty`, or if you want an exported field skipped (`-`), or if you want to use an explicit name for the field (e.g. a lowercase key). If you marshal a struct with exported fields with no defined json tags, it'll just use the (capitalized/exported) field name. :)
(Which personally is still preferred; explicit naming and behaviour is better than implicit IMHO and I hate seeing capitalized JSON key names, but if you're just doing quick and dirty it isn't required. FYI!)
Lets FF 5, 10 years and see how many of this super duper frameworks, command line utilities, webservices in RUST are still maintained and how many developers are there and still understand the codebase. THAN we can make a comparison. I bet RUST will rise to its top when micro webservices in tiny wasm / wisp container will be THE THING. Time will tell.
Just working on my new web page base skeleton, using axum, minijinja as templating, htmx/hyperscript and currently I chose UIKit3 as css (unsure yet), and my first customization was to add a markdown macro into minijinja to enable markdown syntax rendering in my templates, styled with markdown.css, and i was amazed how fast it started to come together.
I plan to slap on media management, an admin etc. later on, but for now my next step is integrating diesel and providing a basic database auth middleware.
Honestly if there was a rust syntax based language with garbage collection, or some way to fast compile while developing without full safety, even some kind of development interpreter, I would use rust for everything.
Take a look at rust-lang/miri. It's a Rust's mid-level IR (MIR) interpreter availiable on Rust nightly
Gleam seems to have a lot of common DNA with Rust-style ML features, it’s not quite like Ocaml and it’s not quite like Rust but in between somehow. They don’t do macros though (intentionally) but they have a JSON lib at least, but you’ll need to get used to writing encoders and decoders…
ReScript is also pretty close, and also doesn’t use macros (well you can use ppx’s but you shouldn’t it seems) but you’ll need to roll a lot of your own libs and figure out best practices by scouring the forums.
the code at 6:55 is so clean, I can't believe someone could make an argument against it
missing indent from return and lots of if err != nil
that's not clean at all
yes! that's also one of the goals of go, to make most of the things explicit so that it is easy to reason about the code flow.
@@yt-1337 what do you mean missing indent? You would rather have return ( ... ) or something like that?
Also, don't all languages handle errors in their own way? I like go because it is dead simple: if error is not nil, handle it. I prefer it over the "try .. catch" pattern
not trying to argue, just want to hear other perspectives
@@yt-1337From your previous replies in this channel and this, You have no idea about what you talking about.
I remember watching the end of this video on live. What’s a really good article you have read. Also you make me discover in this live the existence of this amazing golden library that is templ. Some may said it’s just TSX in go but it’s truly make me remember that good old days with Laravel and Blade.
(Btw I don’t have a Lamborghini yet and I don’t know if it make sense for me cause I’m living in the middle of the sea -_-)
Man, the Rust part of that article was like 3x the length of the Go part.
didnt watch the video, but here to tell you that
finally used htmx in a project, and it went really well
htmx is my go now if the project requires a centralized back-end
lets go!
it works well for non centralized backends too!
For choosing Go Web Framework and ORM: Don't, try to use the standard libraries (it's much better since 1.21) and Sqlc first instead. Most of the external libraries and frameworks have some shenanigans that are not (trying to) conform to the HTTP/WebSockets, etc. specs.
Even Echo and SQLx?
You have a good read / src on this? New to GO
maybe avoid sqlc bc it doesn't work well with dynamic queries
@@nataoliveira2247echo uses fasthttp which isn't actually to spec and likely never will be. Turns out you can be fast when you ignore the rules
@@superderpyderpsecho dropped support for fasthttp from v3
44:44 I'm already somewhat fluent in C++ standard library. At this point any other language looks as if it was designed so even toddlers would understand it the first time they see it.
6 months later --- Prime: "So i've decided to do a year of Golang"
39 min to discover this is actually a tutorial on how to wrap a Shuttle infomercial inside a go vs rust tortilla.
30:49 - Are those HTML templates basically Jinja templates ? or are they something else ?
I'm thinking of going Rusty again, so much new quality stuff since it's release, now I need to get in there.
As for Golang, it's nice but they don't use semi-colons which bothers me when I read more lower-level code and reminds me of JS so I'll skip that for myself.
20:40 I wonder how Prime feels about Option::ok() handling instead of matching.
every time i put on a youtube video and space out for a bit, i come to and hear ThePrimeTime talking about javascript
> The behaviour of a unit of code should be as obvious as possible by looking only at that unit of code.
I like rust -- but magical/hidden side effects are a liability, not a feature.
Zig got this right.
I love the idea of returning errors as values in Go. The annoying part is the amount of if statements. Being used to Scala with ZIO, Kotlin with Ktor and such, where you can chain/map the errors, if statements are annoying
Forgot to add. Templating in Java can be : @JStache(path = "feeds/main#table") public record TableModel(List feeds) {}
#table is the fragment within the template. Just fill in the model and return it, e.g:
@Get(value = "/table") TableModel renderRowsTable(@Nullable @QueryValue String q) { ....
This is with HTMX as well :)
Thanks for this, was a great article, and great job reading it! I appreciate you not playing music, cause I watch all content in 2-3x.
Hi Prime, just came across your youtube channel a couple of days ago and accidentally put it on 1.75 speed. It change my life...
Imagine how much less code it would be if they were to use Elixir, Phoenix, and ETS instead.
27:12 So, I suppose one have to know which functions you need to do await on then, as it's not obvious? Such as normally a function would return when it's done, but here it could be a magic separate asynchronous function.....
"Rust allows you to put all the sh*tty code in the basket". That's exactly why I love this language. The From trait, the macros.
I feel so unproductive writing generic functions in JS/TS with if/else/switch, whereas in Rust I simply do x.into() or do_x!() and I call it a day
haskell does the same with even nicer looking syntax
haskell mentioned
damn that Rust templating looks really slick!
46:40 what people usually mean with "don't roll your own auth" is about bearer tokens, jwt and oauth2.0 flow. If you write your own security algorithms or schemes, you can be sure they are broken beyond repair on some level. Same with session handling/cookies on MVC.
I’d love to see you do the comparison on cli tools in both languages
Using an oauth library is a gotdam sight from rolling your own auth. Using a library is definitely not rolling your own.
Never roll your own auth*.
*If you think this doesn't apply to you, there is a 100% chance it applies to you. There are people who can roll their own auth, but they're not in the youtube comments.
12:43 Some People are just plain ignorant. GDPR relates to personal data of EU Citizen. Weather Data is not Data of EU Citizen - unless you track the Weather in your underwear. Bloody hell.
15:10 this is available in Java for decades. It goes even further by injecting authenticated session details or any request scoped object.
Always fun to see Java haters discover stuff Spring has done for over a decade by now.
@@spell105 Try and explain AOP to a GO or Rust developer.
@@KangoV Can't, they hate useful features.
Java is shit
I was hyped about rust, I even installed mold to compile rust 4x faster. Yet, when I tried Axum, the hello world example just won't compile. a lot of people complained why the maintainer won't update his examples, yet the maintainer doesn't listen. I fail to see why it's the top library for http when you can't even compile the examples.
I like the error handeling in go, cuase while reading I know what can cause the error and what will be handeling it. Unlike try catch languages where if someone decides to have to function that throw errors and one catch exception and handeling the error now I need to figure out which one is throwing with LSP or in case of javascript by calling the foribidden gods and sacrificing my souls to guide them me to the function throwing the error. Or I could just use the debugger
"Quietly guiding" he said 😂. Rust quietly guides you, hands lightly rubbing your shoulders while whispering into you ears "YOU'RE F@#KING DOING IT ALL WRONG, GO BACK TO JAVASCRIPT". The sound of Kenny G's saxophone wistfully dancing in the air.
🤣🤣🤣🤣🤣🤣
What website is he using?
How dare you... That gopher is the cutest language mascot there is!
imho some people underestimate what rust will allow you to do longterm. Embedded, machine learning, gaming,... I honestly think it's the surface of rust that is the true USP.
The best thing about building web services with go is that you can easily replace developers. With rust everyone has their own way of doing things and this lower maintainability.
On second thought, maybe Go isn't such a good idea... (for my job security)
@@MagicMrBlue you are correct, that is why I write the most gibberish code seen by man
lol
This is exactly why tom's a genius.
23:30 cos you can consume a burrito wrapped up or unwrap to get to the juicy goodness inside
Chicken burrito or steak burrito look the same in the outside when wrapped up
I recommend you try Tinda Masala if you ever get the chance.
0:04 was so unexpected It made my heart hurt out of laughter 😂
does `nil` work in go like it does in lua?
nil is basically null but with a different name in Go
16:11 - this is why I tune in
33:43 the oracle crate doesn’t have derive-from-row 😓😓😓
"Error handling takes a good part of the code."
Antipattern 101... it handles virtually nothing.
So, what "error" does occur? Internet down? Wrong url? Proxy auth? Server down? Wrong certificate? Malformed parameter?
It's not the domain of the API itself to manage potentially disastrous - read: exceptional - errors.
23:26 the monad as a burrito analogy is just a joke satirizing people who try to use silly analogies to explain monads. it's meant to be confusing and unhelpful. it's basically the same joke as "a monad is just a monoid in the category of endofunctors, what's the problem?", except from the opposite direction: just as unhelpful, but technically correct and very abstract instead of wrong and very down-to-earth
bro gave us a flashbang warning for some fancy Highlighting 😂😂😂
Man, the thing about passing args from the request to the route function as parameters exist in just about every framework, not just in Rust 😂
so... you can pass parsed data of any type in any order and create your own parsers and it works swimingly?
i don't think i have seen this in typescript because typescript isn't real
Monads are just containerization for your state (or vice versa).
matching option is easily done without a match with just functions and mapping errors with `?` operator, so no need to match everything, rust is functional language after all...
So Go code is more verbose and Rust is more type safe and shorter yet we use unwrap all over the place which can crash the whole program.
That did not look like fair comparison to me. Panic in Go is just as short as unwrap
I'm waiting for Rust vs Mojo🔥
I started using nvim because of this man.
Leptos is cool tech, and I'm not a JS/TS fanboy, but I would definitely not choose Leptos for professional work on the front end.
No performance benchmark?
go has the potential to be a perfect language. however in my opinion, it lacks safety. sqlx can't check sql validity at compile time. struct fields are not mandatory (that's by design) and most of the time errors are just strings and not typed, so if a user can't access a s3 file, i would have to check of the err string contains "not found", "no access" or even better, there is an update and the messages have changed without you knowing💀
An alternate viewpoint: you might be trying to solve problems that you don't have. For example, have you ever had a runtime error in your sql? And if so, is it effort it took to fix greater than the combined effort that would be involved in typing all of your sql queries? And have you had an actual need to differentiate between not found and 404 where it was not sufficient to just throw the error up on the screen?
Not trying to be argumentative or advocate for one solution or the other, but I do think it's important to understand that choices are usually about trade-offs, and not about 'a better technology'.
No, most of the time errors are typed and can be properly type switched. You mentioned S3. For that I would use minio client library, which has typed errors and I can properly determine exact error code (404 in your "not found" case) without resorting to string matching. I don't remember the last time I manipulated strings in error handling. From my experience, that just doesn't happen.
@@travisSimon365fair points.
have you looked into the go jet package? it seems to give type safety for sql at compile time.
@@thesaintseiya yes i have. Found it a few weeks ago and i love it. Convincing my company to use it is a different story though.
when you are coming from a C# or JavaScript background then both are amazing
Rolled a auths before and worked fine. But I've seen people screw up with auths real bad though
been using Axum for quite a while now...
The team that wrote that Axum extraction thing got really inspired on how Symfony do things (Symfony has the best DX, change my mind ♥️)
you not destroying performance with arcmutex, where you got that idea?
“I could find myself getting pretty f-rust-rated..”
akshually monad is like Schrödinger's Box
i like to live dangerously and code c,javascript,rust,go in a single project
What: no assembly language?
@@ScienceAfterDark
> no haskell
cringe smh
afaict the original developer of Actix left the project and created Ntex, which is just a fork of Actix
Which language should I use to construct a low-latency backend: rust or Ocaml, zig, or go
js
@@Kanra951😂
Build your backend as electrical circuits using transistors. Near zero latency 👌
HTML v1
It's one of those "If you have to ask..." questions. If you want the lowest possible latency - zig is your guy. If you want to actually build something - go is your guy. Rust is in the middle
11:54 That does not belongs to golang. But that DB example is definiive a sql injection olace dude.
6:52 a "backend dev" at my previous company
0:05 This seemed too personal 🤣🤣
If let Ok(res) = result{}
Honestly, Go is so much easier to understand and look much more clean too, the error handling is a little verbose but rust is so much worse for beginners
This article just missed a benchmark of these 2 solutions. This is "the way" I build APIs with Rust... and my benchmarks of are really bad (node even wins)
Fearless cost abstrurrency.
Rust isn't a cult.
It's a Foundation™
Marketing content
springboot with kotlin is pretty close to rust magic as shown here, but not quite
more a comparison of web frameworks than of programming languages
It’s pretty funny when Rusters gasm over little things like having the framework automatically populate query parameters into their handler function but conveniently miss the mass of await.clone.unwrap() ‘static derive-everything-everywhere in front of them
It's a matter of preference. I really like the tools that Rust has, while Golang missing quite a few things frustrates me. OTOH, the opposite is true for someone like you that prefers less tools to work to simplify things, and doesn't like extra tooling that complicates things.
@@azufendusgarendum6583 I don’t think you’re wrong, it’s largely personal preference. There isn’t anything out there that’s a perfect language.
As I’ve become more experienced, I’ve grown in my appreciation for languages with fewer features. I don’t say Rust is a terrible language, but there is a segment of their community that is blind to the fact that it has significant rough edges like any language.
Also keep in mind Rust and Go are not the only two alternatives.
who would ever say that Go "offers a batteries-included development environment"
Anyone? because it literally is? It comes with http server, db, templating. this baby project literally needs 0 dependencies if they would choose not to use any.
The language syntax is minimal, but the standard library is comprehensive.
Assembly language is the king
... of insane-o-developer-land, yes. as a former resident, I know this.
the JS developer hate :D why should I handle errors, when I dont need to or my only need to is log it. Well i can have a centralized try catch and send stuff to sentry. SOLVED!
Matching Enums is cumbersome? That's what making Rust much superior (apart from other features).
Only *5 months* and so many *Rust Foundation shitshows* for Prime to be a Go Andy
"JS guys don't do error handling" - Well yeah. But the guys writing getLatLong also didn't. The code we see here is exactly as "valuable" as JavaScript code that doesn't contain code for error handling. This "handling" code we see does one thing: It simulates the call stack you get from a JS runtime (badly). Nothing more. It has to do that, because otherwise the caller wouldn't know there was an error. The argument "Yeah but this paradigm forces developers to handle errors" is shown to be weak at best.
Error handing means to either fix the problem, if that's possible, or to delegate the error handling to the caller while preserving enough information to make that possible (and preferably easy).
In this case, there are three error conditions: Networking issues, a contract violation by the service (invalid data format) and a not really error. None is handled locally, which is fine. What does the caller have to do to handle the error? They had to parse the error message to find out what kind of error occurred. To do that, they have to obtain and read the source code. Once that's done for the first two cases, they might need to inspect inner error which might or might not be available after using Errorf (don't know Go). The immediate caller, here a web service/server can assume that the network is working, considering that it's processing a web request, thus it's safe to not do anything about network errors other than to log them and create a "please try again later" error. If it's receiving "the other error", it's probably time to ring the alarm bell, because if that's not one of the rare undetected transmission errors it hints at a bug in the used meteo service. Well and the third error is a shit-in-shit-out thing. Nobody knows if there are no results because somebody wiped the city database or the caller provided something that the server doesn't recognize as city. And empty result is just as meaningful as an error. Why create an error if the service who could know better didn't? When opinions prevail over understanding...
Let's compare that to what JS devs do, nothing. They will do noting up until the point where the service has to respond to the web-site with something like "shit hit the fan". What's the difference for the user? Little to nothing. Neither approach supports localized error messages, neither supports identifying the nature and source of the error easily. The exception might have a stack trace, if it was more than a string in JS world.
If you call for real error handling, you're calling for spending half of the initial development time on that task (it gets much less over repeated dev cycles and in maintenance). Error handling is hard. Whether you're using exceptions or error return values does not have any significant impact on how hard it is. If you are not handling errors, what most JS devs do and apparently most Go devs are no better - if this is an example for error handling, then exceptions make it easier. Error returns might be more performant. How relevant is that really? I spend years tuning the performance of code and db queries. I never once had to tune the performance of error handling.
The only situation where I mix program and error handling logic, is when I have to roll-back effects of actions that are part of a failed complex operation. Whenever that is not an exceptional occurrence in a program, I create a kind of transaction mechanism that does just that, roll-backs with proper error handling, because that's much too hard to get right ad hoc (errors in roll-back/retry/etc.).
Error handling happens either very close to the source of an error, where it can sometimes and then better be locally fixed - or it happens where the audiences to which the handling is eventually being dispatched are know, high up the call stack. Only very rarely do you see this transaction kind of handling, that actually handles the consequences of an error and not the error itself. That happens most in the middle of the call stack.
Exceptions are the more natural mechanism to support error handling. Especially if exceptions are part of method signatures and if they are not aggregated into "Error" as is common in Java-world. It's more natural, because it supports people who actually handle errors better (static typing of errors, delocalization of handling in try/catch) and it also supports people who don't handle errors better. It also documents whether errors are handled or not. You see it in code(absence of try/catch) and often in documentation (method signatures with "throws Error") on first sight. To know whether somebody pretended to or actually handled errors requires you to loose time reading and understanding the code. Annoying.
I like the swift approach to error handling, which uses error enums (typing), error returns (performance) and try-catchy handling options with some syntax sugar.
i like axum more because i can use tokio main
Axum is awesome!
Actix can too!
This is the worst way of comparing the two languages. The example application's main overheads are network calls. So all programming languages will do the same in terms of latency. Some may perform better when it comes to scaling, resource utilization and cost. However, the main reason why one would pick one language over the others is the team that's going to work on them. You need to pick the language based on your team's skills and what the support for that language in the company looks like. Just because XYZ can perform better for a specific tool, it doesn't mean you should do it in that language.
You realize you can turn off dark-reader by website right?
have you chanting chroot noooo XD XD