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.
@@beneditomaurooFrankly not that much difference, since the frameworks tend to use the standard library under the hood.. Yeah except for fiber which uses fasthttp...
"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" 🤓
@@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.
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.
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 ;)
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”
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
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
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.
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.
@@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.
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
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.
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!)
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
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.
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
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).
@@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
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.
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.
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.
@@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
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.
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.
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.
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.
"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
> 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 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 -_-)
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
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
"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.
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.
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.
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.
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.
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.
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
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
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
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 :)
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.
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.
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.....
"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.
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
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.
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!
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
"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.
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.
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.
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)
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
"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.
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.
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
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
Concurrency in rust is fearless, but not painless
@@johnyepthomi892just don't write concurrency, painless 🧠
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?
Good reason to use Go is there actually being jobs looking for it
na, I would rather be unemployed than suffer through that
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
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.
6 months later --- Prime: "So i've decided to do a year of Golang"
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!)
Man, the Rust part of that article was like 3x the length of the Go part.
To be fair, Go e 3x simpler
My favorite try catch pattern is the one that doesn't throw or log the error. Really love that.
How dare you... That gopher is the cutest language mascot there is!
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
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.
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!
"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
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
39 min to discover this is actually a tutorial on how to wrap a Shuttle infomercial inside a go vs rust tortilla.
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.
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.
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.
@@yt-1337 'err != nil' ohhhh nooo the horror!!!! I much prefer wrapping my entire main function in a try/catch, so much more elegant
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 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.
every time i put on a youtube video and space out for a bit, i come to and hear ThePrimeTime talking about javascript
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.
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.
A little bit late but I absolutely hate that too
"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 mentioned
Imagine how much less code it would be if they were to use Elixir, Phoenix, and ETS instead.
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...
> 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 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 -_-)
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
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
"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.
🤣🤣🤣🤣🤣🤣
damn that Rust templating looks really slick!
You've taught me a ton I appreciate your work
Fearless cost abstrurrency.
Rust isn't a cult.
It's a Foundation™
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.
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.
bro gave us a flashbang warning for some fancy Highlighting 😂😂😂
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.
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.
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.
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
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
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.
Monads are just containerization for your state (or vice versa).
20:40 I wonder how Prime feels about Option::ok() handling instead of matching.
when you are coming from a C# or JavaScript background then both are amazing
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
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
“I could find myself getting pretty f-rust-rated..”
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 :)
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.
i like to live dangerously and code c,javascript,rust,go in a single project
What: no assembly language?
@@ScienceAfterDark
> no haskell
cringe smh
16:11 - this is why I tune in
Matching Enums is cumbersome? That's what making Rust much superior (apart from other features).
I’d love to see you do the comparison on cli tools in both languages
0:04 was so unexpected It made my heart hurt out of laughter 😂
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.
I started using nvim because of this man.
Assembly language is the king
... of insane-o-developer-land, yes. as a former resident, I know this.
more a comparison of web frameworks than of programming languages
Rolled a auths before and worked fine. But I've seen people screw up with auths real bad though
akshually monad is like Schrödinger's Box
Marketing content
afaict the original developer of Actix left the project and created Ntex, which is just a fork of Actix
If let Ok(res) = result{}
I have no idea what 90% of these words mean.
0:05 This seemed too personal 🤣🤣
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.
I recommend you try Tinda Masala if you ever get the chance.
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.....
"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.
I'm waiting for Rust vs Mojo🔥
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
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
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.
33:43 the oracle crate doesn’t have derive-from-row 😓😓😓
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!
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
"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.
Only *5 months* and so many *Rust Foundation shitshows* for Prime to be a Go Andy
11:54 That does not belongs to golang. But that DB example is definiive a sql injection olace dude.
springboot with kotlin is pretty close to rust magic as shown here, but not quite
6:52 a "backend dev" at my previous company
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.
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?
been using Axum for quite a while now...
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.
i like axum more because i can use tokio main
Axum is awesome!
Actix can too!
as javascript dev, i can say... yeah, i hate handling errors in javascript. I love how go does it.
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)
Rust is more performant because it doesn't need to deal with garbage collector. Read the article why Didcord switched to Rust over GO.
Leave my gopher alone buddy!!!!
6:42 XDD
"Rust way" likes Java Stream Api