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.
@beneditomauroo Жыл бұрын
How it benchmarks against the frameworks?
@legends_assemble4938 Жыл бұрын
@@beneditomaurooFrankly not that much difference, since the frameworks tend to use the standard library under the hood.. Yeah except for fiber which uses fasthttp...
@RaZziaN1 Жыл бұрын
except go is build around external dependencies and external code.. so something isn't right in your comment.
@igortolstov48711 ай бұрын
Standard libraries get updated just like external ones
@madlep Жыл бұрын
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”
@afterschool2594 Жыл бұрын
Other language devs: just try if it's crash
@justin_ooo Жыл бұрын
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
@Dhalucario Жыл бұрын
PHP devs: Error? Let's continue anyway lol.
@wilfridtaylor Жыл бұрын
@@Dhalucario What the user pasted a shell script into the username dialogue box. Better execute it for them :p
@bionic_batman Жыл бұрын
Just don't allow Elixir devs write Go code
@Jamguin Жыл бұрын
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.
@juniorsundar11 ай бұрын
Segmentation fault. Core dumped.
@bebobauomy126511 ай бұрын
Rust has a negative effect on the brain.
@Jamguin11 ай бұрын
@@bebobauomy1265 all programming language has.
@martijn315111 ай бұрын
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 ;)
@Jamguin11 ай бұрын
@@martijn3151 there is no bug free language. Rust prevents a lot of common human errors and that's all I need.
@M3t0r Жыл бұрын
"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 🤣🤣🤣
@HelloRust Жыл бұрын
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" 🤓
@comradepeter87 Жыл бұрын
@@HelloRustThat's unironically a banger article. Defo gonna read it if you do it.
@dnullify100 Жыл бұрын
@@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
@phoenix-tt Жыл бұрын
@@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.
@comradepeter87 Жыл бұрын
@@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.
@crimsonbit Жыл бұрын
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
@danielchettiar5670 Жыл бұрын
Least insane dev
@annusingh4694 Жыл бұрын
hire me, now.
@brandongregori995 Жыл бұрын
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
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.
@AdroSlice Жыл бұрын
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.
@georgerogers116611 ай бұрын
? Is awesome as well.
@timdithmer918411 ай бұрын
@@AdroSlice My personal opinion is, that an error should never be ignored. If it was ignorable, there would not be error potential.
@AdroSlice11 ай бұрын
@@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.
@haniffaris89179 ай бұрын
@@AdroSliceCouldn't you just use _ to ignore the error?
@codeman99-dev Жыл бұрын
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.
@victorchoi1318 Жыл бұрын
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
@funkdefied1 Жыл бұрын
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
@AdroSlice Жыл бұрын
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.
@theairaccumulator71445 ай бұрын
A little bit late but I absolutely hate that too
@xevious4142 Жыл бұрын
Good reason to use Go is there actually being jobs looking for it
@shellderp3 ай бұрын
na, I would rather be unemployed than suffer through that
@bendon46048 ай бұрын
6 months later --- Prime: "So i've decided to do a year of Golang"
@sunrae3971 Жыл бұрын
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.
@-ion Жыл бұрын
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
@neunmalelf Жыл бұрын
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.
@brentsaner Жыл бұрын
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!)
@chepossofare Жыл бұрын
"but it also distracts from business logic" Error handling SHOULD be part of the business logic.
@comradepeter87 Жыл бұрын
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).
@voidwalker7774 Жыл бұрын
dun dun DUUUUUUUUUUUU
@well.8395 Жыл бұрын
@@comradepeter87 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.
@xeamek99 Жыл бұрын
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
@viktorshinkevich3169 Жыл бұрын
He meant happy path
@SvetlinTotev Жыл бұрын
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.
@Aimsport-video Жыл бұрын
39 min to discover this is actually a tutorial on how to wrap a Shuttle infomercial inside a go vs rust tortilla.
@getattrs Жыл бұрын
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.
@doctorgears9358 Жыл бұрын
My favorite try catch pattern is the one that doesn't throw or log the error. Really love that.
@bandr-dev Жыл бұрын
the code at 6:55 is so clean, I can't believe someone could make an argument against it
@yt-1337 Жыл бұрын
missing indent from return and lots of if err != nil that's not clean at all
@gombike95 Жыл бұрын
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.
@bandr-dev Жыл бұрын
@@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
@poms3559 Жыл бұрын
@@yt-1337From your previous replies in this channel and this, You have no idea about what you talking about.
@voskresenie-3 ай бұрын
@@yt-1337 'err != nil' ohhhh nooo the horror!!!! I much prefer wrapping my entire main function in a try/catch, so much more elegant
@suede__ Жыл бұрын
Man, the Rust part of that article was like 3x the length of the Go part.
@lucascamelo30795 ай бұрын
To be fair, Go e 3x simpler
@cariyaputta Жыл бұрын
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.
@nataoliveira2247 Жыл бұрын
Even Echo and SQLx?
@SorryStamin Жыл бұрын
You have a good read / src on this? New to GO
@Patrickdaawsome Жыл бұрын
maybe avoid sqlc bc it doesn't work well with dynamic queries
@superderpyderps Жыл бұрын
@@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
@RaghavendraBhuvan Жыл бұрын
@@superderpyderpsecho dropped support for fasthttp from v3
@asdfghyter Жыл бұрын
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
@Ollinho12 Жыл бұрын
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.
@Gennys11 ай бұрын
How dare you... That gopher is the cutest language mascot there is!
@architect-ki7el9 ай бұрын
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.
@RogerValor Жыл бұрын
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.
@oleksii_ihnatenko Жыл бұрын
Take a look at rust-lang/miri. It's a Rust's mid-level IR (MIR) interpreter availiable on Rust nightly
@ceigey-au Жыл бұрын
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.
@Mohamedrasvi Жыл бұрын
15:10 this is available in Java for decades. It goes even further by injecting authenticated session details or any request scoped object.
@spell105 Жыл бұрын
Always fun to see Java haters discover stuff Spring has done for over a decade by now.
@KangoV Жыл бұрын
@@spell105 Try and explain AOP to a GO or Rust developer.
@spell105 Жыл бұрын
@@KangoV Can't, they hate useful features.
@cca9837 Жыл бұрын
Java is shit
@kenny-kvibe Жыл бұрын
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.
@lazyh0rse Жыл бұрын
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.
@nomadshiba Жыл бұрын
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
@ThePrimeTimeagen Жыл бұрын
lets go! it works well for non centralized backends too!
@jly_dev11 ай бұрын
> 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.
@phoenix-tt Жыл бұрын
"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
@AdroSlice Жыл бұрын
haskell mentioned
@funkdefied1 Жыл бұрын
20:40 I wonder how Prime feels about Option::ok() handling instead of matching.
@codeman99-dev Жыл бұрын
19:55 NO! You do NOT "lift" by exiting the elevated world. A "lift" take a value and wraps it with the idiomatic next level up. `Ok(value)` is a lift. Unwrapping it is the opposite.
@909crime Жыл бұрын
every time i put on a youtube video and space out for a bit, i come to and hear ThePrimeTime talking about javascript
@stevenhe3462 Жыл бұрын
Imagine how much less code it would be if they were to use Elixir, Phoenix, and ETS instead.
@makesnosense6304 Жыл бұрын
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.....
@eddierandom6074 Жыл бұрын
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.
@MagicMrBlue Жыл бұрын
On second thought, maybe Go isn't such a good idea... (for my job security)
@eddierandom6074 Жыл бұрын
@@MagicMrBlue you are correct, that is why I write the most gibberish code seen by man
@azufendusgarendum6583 Жыл бұрын
lol
@AdroSlice Жыл бұрын
This is exactly why tom's a genius.
@DoubtfulTrain Жыл бұрын
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.
@orterves10 ай бұрын
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
@KangoV9 ай бұрын
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 :)
@suikast420 Жыл бұрын
11:54 That does not belongs to golang. But that DB example is definiive a sql injection olace dude.
@fritskayadoe2726 Жыл бұрын
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...
@timcates42614 ай бұрын
You've taught me a ton I appreciate your work
@fb-gu2er8 ай бұрын
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
@newsofthenerd Жыл бұрын
"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.
@elephant_888 Жыл бұрын
🤣🤣🤣🤣🤣🤣
@kubre10 ай бұрын
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
@cheebadigga409210 ай бұрын
damn that Rust templating looks really slick!
@b1chler Жыл бұрын
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.
@jeetchheda8916 Жыл бұрын
bro gave us a flashbang warning for some fancy Highlighting 😂😂😂
@davidlee588 Жыл бұрын
Key Takeaways: Comparing Rust and Go for web development reveals different approaches and trade-offs. Go is known for its simplicity, ease of use, and batteries-included approach, making it great for quick development. Rust, on the other hand, offers more robustness, safety, and extensibility, thanks to its rich type system, error handling, and compile-time checks. Overall, while Go might be the preferred choice for getting started quickly, Rust provides long-term benefits with its robustness and extensibility.
@billeterk Жыл бұрын
“I could find myself getting pretty f-rust-rated..”
@gungun974 Жыл бұрын
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 -_-)
@funkdefied1 Жыл бұрын
33:43 the oracle crate doesn’t have derive-from-row 😓😓😓
@danielyrovas Жыл бұрын
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.
@k98killer Жыл бұрын
Fearless cost abstrurrency. Rust isn't a cult. It's a Foundation™
@CIBI Жыл бұрын
Which language should I use to construct a low-latency backend: rust or Ocaml, zig, or go
@Kanra951 Жыл бұрын
js
@shrin210 Жыл бұрын
@@Kanra951😂
@PavitraGolchha Жыл бұрын
Build your backend as electrical circuits using transistors. Near zero latency 👌
@NotMarkKnopfler Жыл бұрын
HTML v1
@cotneit Жыл бұрын
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
@McZsh8 ай бұрын
"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.
@Hi-kue Жыл бұрын
0:04 was so unexpected It made my heart hurt out of laughter 😂
@khhnator Жыл бұрын
you not destroying performance with arcmutex, where you got that idea?
@at0mly Жыл бұрын
Monads are just containerization for your state (or vice versa).
@user-qr4jf4tv2x Жыл бұрын
i like to live dangerously and code c,javascript,rust,go in a single project
@ScienceAfterDark Жыл бұрын
What: no assembly language?
@raffimolero64 Жыл бұрын
@@ScienceAfterDark > no haskell cringe smh
@realbutters Жыл бұрын
16:11 - this is why I tune in
@nomadtrails11 ай бұрын
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.
@FarryEntertainment Жыл бұрын
What website is he using?
@patocarrasco6266 Жыл бұрын
does `nil` work in go like it does in lua?
@jamlie977 Жыл бұрын
nil is basically null but with a different name in Go
@mastermachetier5594 Жыл бұрын
I’d love to see you do the comparison on cli tools in both languages
@ZoltanTemesvari_temy Жыл бұрын
Matching Enums is cumbersome? That's what making Rust much superior (apart from other features).
@michaelutech47869 ай бұрын
"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.
@boonytoons796811 ай бұрын
when you are coming from a C# or JavaScript background then both are amazing
@multinaute Жыл бұрын
Assembly language is the king
@tsalVlog Жыл бұрын
... of insane-o-developer-land, yes. as a former resident, I know this.
@0xiamsanj Жыл бұрын
0:05 This seemed too personal 🤣🤣
@JD2jr.5 ай бұрын
I have no idea what 90% of these words mean.
@iagobontempocosta Жыл бұрын
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)
@phb17 Жыл бұрын
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 😂
@ThePrimeTimeagen Жыл бұрын
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
@ahmedaghadi8281 Жыл бұрын
No performance benchmark?
@zahash1045 Жыл бұрын
Before I start the video, I'm betting the whole video to be "look, I made some stupid backend in rust and go, oh and look, memory spikes in go! Who would've guessed! Oh look low and predictable memory consumption in rust! OMG what a surprise! Oh and look go us not that far behind rust in performance!" And primeagen at some point makes a comment "use rust if you hate your life" or "rust is very hard, go is very simple" or something like that Why do people even compare those two?? Go vs C# would be far better
@comradepeter87 Жыл бұрын
If you would've chosen any other video, you would've been partially correct, but you chose to write this comment on the worst possible video XD
@livioribeiro Жыл бұрын
afaict the original developer of Actix left the project and created Ntex, which is just a fork of Actix
@jazzochannel Жыл бұрын
I recommend you try Tinda Masala if you ever get the chance.
@Patrickdaawsome Жыл бұрын
who would ever say that Go "offers a batteries-included development environment"
@kattankarl Жыл бұрын
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.
@ForeverZer010 ай бұрын
The language syntax is minimal, but the standard library is comprehensive.
@fghjconner Жыл бұрын
You realize you can turn off dark-reader by website right?
@EhteshamShahzad Жыл бұрын
6:52 a "backend dev" at my previous company
@victordvickie Жыл бұрын
akshually monad is like Schrödinger's Box
@LetszGoo Жыл бұрын
I started using nvim because of this man.
@baxiry. Жыл бұрын
Marketing content
@soulsweapon Жыл бұрын
Rolled a auths before and worked fine. But I've seen people screw up with auths real bad though
@TheSulross Жыл бұрын
more a comparison of web frameworks than of programming languages
@not_yet_implemented Жыл бұрын
If let Ok(res) = result{}
@Hence_Proved_95 ай бұрын
Rust is more performant because it doesn't need to deal with garbage collector. Read the article why Didcord switched to Rust over GO.
@flogginga_dead_horse4022 Жыл бұрын
been using Axum for quite a while now...
@Skylooo8 ай бұрын
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!
@zeroows9 ай бұрын
Only *5 months* and so many *Rust Foundation shitshows* for Prime to be a Go Andy
@joaopauloalbq Жыл бұрын
I'm waiting for Rust vs Mojo🔥
@rodilife Жыл бұрын
Why do people even bother with these? The whole discussion about which frameworks to use… C# and .NET Core are solid. You can build anything. It’s multi-platform and fast.
@KuroKazeZX10 ай бұрын
springboot with kotlin is pretty close to rust magic as shown here, but not quite
@DenDenn110 ай бұрын
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
@solomon.hamburg Жыл бұрын
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💀
@travisSimon365 Жыл бұрын
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'.
@creker1 Жыл бұрын
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.
@solomon.hamburg Жыл бұрын
@@travisSimon365fair points.
@thesaintseiya Жыл бұрын
have you looked into the go jet package? it seems to give type safety for sql at compile time.
@solomon.hamburg Жыл бұрын
@@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.