Why Go Or Rust On New Projects 

i fully agree with this take. i've spent 5 years writing go backends and 3 years writing rust backends. i was a huge proponent of rust for everything up til last year. even tho i am up to speed on how it works, it's so slow to write and a way heavier mental model than go. another thing you didn't mention is it takes literal seconds to "compile" and run a golang script on any target. rust projects can take multiple minutes to compile and more often than golang, cross compiling will be an issue

Wow he really soured on Rust. 6 months ago, this wouldn't even be a contest for him.

You are spot on. Rust is great for one offs, something with clear requirements that do not change often, preferrably coded by 1 to 2 developers. Go is in the class of C# and Java, for business logic and rapid development.

You convinced me to get into go and learn a compiled language with your comparison videos a year or few years back i felt like i was on the wrong boat after the hype built around rust. I decided to stick with Go anyway because there are way more jobs in my field and i just felt it fit with me more philosophically in that, it seems to be for people who want to do things the simplest way whereas rust felt like it wants to do everything the 'smartest' way. I'm glad to see you've been moving back and doing more in go as i definitely agree with your points here, I've been enjoying the go htmx videos and hope to see more.

I feel like prime wants a high level language that was built in Rust.

Tbh, there's just something about typing out "if err != nil" that makes me sip my coffee and be like "yeah. I'm a Go developer."

Surprisingly this was by far the best Go vs Rust video I have ever watched and this is just a clip from a steam wow.

Two days ago: "I dont have a favourite language. I am too old for that shit" Two months ago: "My favourite language is rust! Rust is the best language!"

I spent eight months learning rust and trying to write my project with it. My project includes json parsing, filesystem interactions, decoding compressed binary data, and making web requests. It was a battle every step of the way. I finally gave up and tried go, and within two weeks I had the project up to feature parity with the Rust version. The difference in productivity for me is nuts. I like a lot about Rust, but Go is way easier to use. And I agree that Go desparately needs tagged unions.

I was looking into Go and Rust for an API overhaul we're doing at work. Go (with Fiber) seemed like a way better option than Rust (with tokio/actix etc). I've had a pleasant experience so far with Go and learning its quirks. I'm a little disappointed because i wanted to have an excuse to use Rust, but ultimately I think its the best decision... and its way better than our current PHP solution.

Currently working on a framework connecting Go and Flutter. The Dart team (also Google-managed) nailed null safety by 2020. Makes me wonder why Go hasn't followed suit. It would make things even slicker.

Imo GO is better than rust because if I get a new team member, I need to upskill they can figure out GO where as if its rust, it will be my responsibility forever

Wow, prime threw rust under the bus. Modern times folks. Whats next neovim is worse than emacs?

Wow, I generally agree with most of the thing you say, but in this case I don't fully get your points. Any single time I was forced in Rust to think harder than any other language about a concept, it was almost always the compiler saving me from a runtime error. And very much explicitly so, it points you exactly at the problem and how to think about it. Immutability by default (but at the same time the possibility to explicitly opt in to mutability), Option, Result, pattern matching, iterators, error handling, are concept that once ingrained in the everyday work are deeply missed when you return to a language that doesn't support them. About the web server part, I don't get it. I would understand if you had to design it from scratch, but there are phenomenal libraries in cargo that make creating a web server a child's play. At that point is it really that much more complicated than doing so in other languages?

I am staying on Go's side. I enjoy writing it at work, simple and easy and has the performance. I don't break my head while writing it.

"You need to hire that guy that slightly levitates when he walks" LMAO

I think what you’re getting at is that Rust is amazing when the problem scope is well defined and understood. An LSP is a great example as are tools and definitely some systems programming stuff. Where Go shines is where the scope is not defined. When you’re starting up a new company, requirements change substantially. Same with web servers. It’s the language that has almost all of the performance, but the guarantee that you can work out the next batch of requirements without substantially changing your code base. Both languages can do either situation but given my experience I feel the same way.

Built my first project in rust - can confirm really good string support and ability to process data. The syntax however, and the immutability by default are a bit of a pain. Just building a simple cli tool to export data from an API, transform it, and then put it into an excel spreadsheet was way more work than it should have been

I'm not a professional programmer and lots of what he says goes over my head. I've never used rust. But I have dabbled with Excel VBA macros, awk etc for text file manipulation involving dictionaries / maps. When a requirement came up where executable made more sense, better logging and DB access was involved, I tried out go. With zero time spent on language basics or concepts, I could write utility programs that are in regular daily use for couple of years now with no issues. It works. They deal with loading text files dumped in a certain folder to database with some manipulation and error checking etc. Or format conversion with mapping based on maps. I wanted to install rust but realised in windows, it requires much bigger download. I still want to learn it as it seems to be replacing C in Linux. Now that's not easy so it sure has something going for it!

I know it seems like a weird reason, but I don't like Go because of its syntax. The whole lowercase vars are private, uppercase ones are public, the way the projects are structured... just feels so weird. I think Go with Rust syntax and option type and Cargo like tools would be the perfect language for me.

Go would be the goated language if it had the enum system that Rust has

I really thought this was a high effort AI generated meme at first. Times have changed. We're gophers now boys.

I learned that I need two programming languages. One for prototyping in like 10 minutes. The other language is for converting prototypes into mature programs that can be distributed to customers, employees, and contractors. Go is easily a top 5 prototyping language. Anyway, I suggest that all career programmers keep a list of features that you need from each language. One day you'll get skilled enough, where you can make your own compiler. That "features list" will come in handy. You'll also use that list to diagnose and plan which languages to use for certain problem. Good Video. Go is easily top 5 programming compilers and languages.

With Rust, ive come to the point where if i need to summon the dreaded 'a on a type, I just make it a raw pointer instead. Easy to work with, let RAII handle it. (if needed, most the time you use a pointer in place of reference you wouldnt need RAII anyway, just a light wrapper around unsafe {})

Honestly been having a good time with Rust after training myself for about 6 months. That initial struggle was real, though. Whatever language you pick, I never want to use Java again. Been using it professionally for about 5 years now and I need out of this space... I have worked on sooooo many overly complicated Spring Boot projects. Every feature MUST be behind a Controller, a Service interface and implementation, a Dao interface and implementation.... The apps all took 10 seconds to start due to component scanning.... I don't have Go experience, but Rust + axum has already treated me better in every possible way. I'm skilled enough at this point that most borrow checker problems have become a non-issue. Even if the compilation is slower, the startup time is so much better that I'm still iterating faster... Good god... I'm sure I'd love Go if I gave it a shot, but I'm sure we can all agree that basically everything is nicer to use than Java at this point...

Go error management with errors.Is() and errors.Join() feels much better than it used to. Better than old go and Ts/Js

Rust is currently in a weird spot. The ecosystem is and community is shaking around a lot, generating uncertainty. Rust is simultaneously missing some required features, and also introducing feature creep in other places. There's too much boilerplate you gotta write sometimes, and no good ways to avoid it. It would actually be good if a lot of unstable features get stabilised, but don't know if that will ever happen.

As a former go, now rust dev I get the point for learning curve. My biggest complaint with go is the ecosystem, I really don't like the way go modules are handled and they were always a huge pain to debug, cargo / crates in comparison felt like magic even if compile times are bad.

FWIW, in Rust you can pack any chonkier struct into an Rc / Arc if you're *forced* to use a lot of clones. Incrementing the reference counter and *then* moving the Rc / Arc is often faster than cloning a large struct.

3:55 So effing true. Coding Rust is like enjoying the breeze and sun in the beach, until you add lifetimes and boom you have a tsunami coming at you. Your entire codebase needs to change to accommodate that one lifetime 'a that you added in some obscure function, somewhere deep in the hierarchy, to squeeze out that extra few milliseconds. At that point I get frustrated and wish there was some way to not use lifetimes.

Golang also needs proper Enums.

There is something to be said for a language designed so well that it funnels users to making the correct decisions simply by its syntax, and not requiring them to be a guru or understand the inner complexities of the compiler in order to game the system and get the best performance. Obviously Rust has much better potential in the "raw performance" category, but it all came at the cost of a clunky syntax and some very aggravating paradigms. I have been doing some Zig lately, and while it is not without its quarks, its approach feels to have struck a better balance between safety and usability. It has the guide rails, and forces the developer to be explicit when disregarding them, but not so obsessed about it that the language on a whole begins to suffer from it.

I thought this video was really good. I struggle with Go vs. Rust. I like Rust very much, but I agree it's a bit intimidating. I like the simplicity of Go, but miss some of the features of Rust. So I'm torn between the two. I thought this video was a good, truthful, realistic opinion about the choice between these 2 great languages.

Prime, please make distinction between Rust Project and Rust Foundation. They're two different organizations. All drama we saw came from Rust Project, NOT the Rust Foundation. In fact, it seems that Rust Foundation has been a positive force in all of this

You mentioned using Rust for CLI, but what about GUI applications? Not clients, but an old fashioned running on your local box no network needed GUI app? I'd be interested in thoughts there.

Performance is mostly about knowing using the right patterns and using those at the architecture level. The impact of doing that well or poorly dwarfs language differences (within a set of not horrible languages). Using rust to implement a poorly designed architecture is basically doing micro optimizations relative to say using Go but with a good design.

Another 6 months you'll say Go is mid

lmao at guy that said go syntax is bad, like what? the way i got into golang was when i saw one of my clients backend code and i fully understood what was happening. I've had never written a production backend or seen golang code before that.

Thank you Dr DisRespect

Time to rewrite Go in Rust

I love Rust... but they really dropped the ball on learnability/usability.

I think Prime is exaggerating the point about lifetime propagation. Most of the time Rust can infer lifetimes without annotations. When you add an explicit one, there's only a specific set of cases where it's going to propagate everywhere, and that's usually avoidable if you design your APIs more carefully. Granted, it's possible that you work yourself into a corner without realizing it.

I rarely comment on RU-vid videos but this is really really pragmatic take. I mean, I'm too old for that language choice so go is too good, too minimal to avoid over engineering. Rust when inputs and outputs can be chained together. Thanks for the clarity.

Feels like the difficulty level of being very proficient at Rust is so high I think something else like zig may overtake especially if the Rust Foundation keeps being hostile to it's own community.

Go all the way

I was waiting for the day when Rust fanboys would start to say ''hey maybe it's going to be an absolute nightmare to write everything in rust''. If your application is so littered with concurrency that you NEED the constant 'advice' from the BC, I think there's something inherently wrong with the design. If you're doing concurrency correctly, the interface between threads should be minimal to nearly-non-existent - so why build an entire language around the idea EVERYTHING is being borrowed? Building a clean concurrent system requires ACTUAL thought about the design, which would be required irregardless of how much static analysis is provided by the language of choice... Using rust feels like 2-3x the amount of work for something I could write instead in c++ and spend a little time building my own safeguards in for the areas that need it.

If you have the right kind of glue code in Rust - pretty similar to Haskells monads glueing together pure functions - then you can get rid of most of the lifetimes in things that shouldn't have to know about them.

5:15 - This! All day, this! That one simple change would eliminate 90% of stupid mistakes that can crash your program. Even if you’re catching it well before you ever make a commit, it’d still just be a massive win to eliminate that issue(and the needed boiler plate by extension) entirely.

Go is also a good language to learn other parts of programming, like in those books on writing an interpreter or compiler in Go. Imagine doing the same in C++ or Rust! The language would hide the forest for the trees.

After listening to this talk, I began to think that Zig might eventually surpass Rust as a system-level, low-level, real-time language if Rust so complicated to get right. And yeah RF sucks 😅

Rust is different mental model and we should accent it more. Sad to say but many people try to bend Rust and implement old ways in new enviroment. And kind of safety it provides in underrated, i realized this watching videos about Swift and C++ safety and/or succesor languages, presenting many kind of fu..k ups witch are impossible to write or impossible to compile in Rust also explaing how rust mental model enables healthy local reasoning and compiler optimizations Some can be achived in other languages but mostly partialy or more costly.

Elixir Phoenix live Is pure gold

I want to hear his take on C# now with all the language changes

C# adding nullable reference type checking was a big win.

Just when I was thinking of quietly switching to Go, such videos come out and add thousands of competitors to me🍵🗿

I can just agree with go being a great tool. I write code for a small iot platform in go right now, which i do for the first time. Never used Go before, didn't even watch or read a tutorial or syntax intro, just their docs, and it just works right away! That's go for me in a nutshell: simple and does what you intend. The only things i dont like until now are the forced if else formatting and switching up the order of name and type and return types, which feels odd.

I Like GO syntax, it's a nice language to work with

Personally for my new projects I use Kotlin. Lovely syntax, Multiplatform compatibility, null safety, ... I have everything I love from my past experience

I love how they say «prewatched» when you aren't even watching a video, - just you, explaining some thoughts.

imho the solution to the coloring problem is not to remove all color, but to give a type system to the color, and allow the developer to mix and match colors as they see fit

I really disagree on the lifetime point. Lifetimes are a leaky abstraction, but they are inherently necessary if you want to guarantee memory safe programs without a garbage collector. Saying you dont want lifetimes as a part of the type system is saying that you just want garbage collection. Thats fine, dont say that go is better than rust because you want gc. Its a fundamental performance tradeoff. Use the right tool for the job.

I would like to have example of lifetimes breaking your program structure. I am new to rust (although read the book) and don't see when it could cause such issues. Would be really helpful video

Let's Go!!!

Maybe a bit different view from my team experience. We are longtime scala users and when there was internal poll/decision about different language to use for internal tooling or dedicated really safe and performant small services(finances) in parallel to scala backends, there was no one preferring using Go over Rust even when others (ignoring my AI ppl with their Python proposals🤣 ), originally enterprise java teams in my company like Go. Maybe it is a fact that when you come from more complex language ecosystem Rust seems mentally like acceptable effort for good results.

Absurd take, Rust gang for life 🦀🦀🦀

I've been thinking about making a simple database for learning purposes. While I'm currently using go I thought ill try to learn Rust and why not develop the db in Rust as a learning project but after this video I guess Ill just do it with Go. Trying to learn a lot of concepts about databases plus the rust language may take me a year or so to do it.

There is one language that has best parts of both Go and OCaml. That is F#.

In general, it doesn't really matter whether you choose C#, Go, Rust, Java, python, javascript, typescript or whatever for your startup. At that point you're basically re-arranging the deck chairs on the titanic. There are some choices where the choice is obvious. If you're building a messaging backend then why the heck aren't you using a BEAM language, it was literally built for this. If you're writing a Unity game, duh, use C#. If you're building an interactive webapp you don't want to use Java servlets to write javascript to write html. But if you avoid pathologically dumb choices like this, it practically doesn't matter and you should just choose the language you know best rather than waste time bikeshedding.

There's an article on css-tricks "in defense of the ternary statement" that as much as I like ternary expressions I find clinically insane

I'm not really a fan of Go's syntax, I could get used to it after a while, but that goofy little shit stain of a mascot just pisses me off. Why did they make him look like that?

You literally said the problem with rust is that _you_ chose to use something that go doesn't even give you a choice of. You don't _have_ to. You can wrap everything in arcs, use dynamic dispatch, mutexes, etc. Want to avoid lifetimes and things? Copy() that shit. If you could do it _safely_ in go, you can do it in rust the same way. It's not as syntactically easy by any means, but you can do it. My first rust program used globals. I knew I was using a single thread, so I used thread_local. Viola. If you're saying that multiple threads should access that global - then I think you've just hit on one of the most common golang pitfalls. Go doesn't encourage this, they encourage using channels when communicating between threads. Guess what... rust has those same channels! :wow: Now, I'm not saying that this _isn't_ a strength of go. This was a core part of its design, and it is great at not letting the programmer try to be clever. Rust will let you be as clever as you want, often to our detriment.

About web performance: Since Rust can run without a runtime, you can even put it on a scratch docker container. It is a AWS Lambda winner. In fact it is almost like the de-facto language for WASM. And while a newbie can make things bad regarding performance. So what, let them learn better. Either way, a lot of times (if not most of the time), writting something in Rust can be an optimiziation by itself, even with poor developer decisions. Bottom line: You like Go/Know Go? Then Go for it. This has nothing to do with Rust. If you know Rust and how to use it then this is only an advantage P.S. I don't dy my hair.

Meet Swift: Compiled, No garbage collection, async, strict interfaces, fast, Generics, simple syntax, open source... Having built a REST api in Swift, I prefer it to Rust & Go. Hope the market wakes up to this and that Swift server thrives !

Agree completely. I am also a huge fan of Go but I love how you really get into the pros and cons.

var err error var something Something if something, err = function(); err != nil { return err } fmt.Println(something) There, that's how you do it properly in Go

The Rust foundation is actually the reason I started to learn Golang.

I'd love to see Go add `or_else` and `or_return` like Odin has. `or_else` is roughly equivalent (in end result) to `.unwrap_or_else` and `or_return` is basically the `?` operator in Rust.

Let’s Gooooooooo!

I find Go very simple to get productive. The language is small and very intuitive. However, on a large scale system, there are some quirks to learn and deal with which is true for most languages. The first time I saw pooling slices, I was shocked.. haha.. but I now I understand why..

Glad Prime is on the same page as me, I started losing faith in writing Rust as a solo dev for async/complex projects. Honestly if I need concurrency I'm gonna go with Go or Erlang/Elixir maybe even OCaml (I was learning that before Prime and I've used Jane Street's Async for half a year now). If I have a systems level project or CLI too I'll still reach for Rust since Zig is still a bit of a mess.

Can we have a comparison between Dart and Go as a backend? Since i like dart the most but i dont get why nobody use it also for backend since isolate management and sound null safety are so amazing.

@ThePrimeTime I would be super curious what you think about Swift.

you missed embedded baremetal, rust is becoming exquisite there

I think you've just summarized my view of both languages. Great video!

I am not too surprised by this take purely from the goals the language designers of these two language originally set out to do and how they evolved their languages. Go's original goal was to create a SIMPLE and SMALL language which does one thing, creating webservices, well and easy enough for even beginner programmers. This later on changed from "creating webservices" to "creating high-level programs". Rust's original goal was to create a language for browser engines which is capable of replacing C++. This later on changed from "browser engines" over "system programs" to "general purpose software". Go went from a relatively simple problem (webservices) to more complex ones (although not too drastically more complex ones). Furthermore Go tried to actively keep the language small and simple. Rust went from a complex problem (a browser engine) to an even more complex program (system programming) to probably the hardest one you can have when designing a language (general purpose). Furthermore Rust has kind of the kitchen sink approach when it comes to language design (just look at how fast the add stuff to the language). That Go is long term going to beat Rust in a lot of problem domains, is logical, at least imo. If you want to change something while not breaking backwards compatibility, you can't make something drastically less complex, because the old ways will persist and you will keep stumbling upon them, not matter what. Rust kind fell (and still falls) for the same trap C++ fell for, constantly adding a lot new stuff relatively often. Sure, after learning a language adding a few features is that big of a deal for somebody, but do that for an extended period of time regularly. Instead of just needing to learn b like the ones who are there from the beginning, a newcomer needs to learn b + x * t to become effective (After all, you did start to use the new features, didn't you? And most currently actively maintained libraries require knowledge about these things too to even use them, don't they?). Now, if b + x * t is already small, that's not really a problem. But if b already was not all too small but just manageable (like in case of Rust or C++ (if we take C++98 as b)), it depends on how big x * t is. In case of C++, x * t is at this point multiple times bigger than b, making getting into it extremely brutal. And Rust is very much trying to repeat this (at least currently).

He said ‘Rust us okay’ wow That is some great open nature there

My biggest concern about Rust is a slow compilation time, although I am not sure if this is really an issue in practice. Anyways, for most servers I would agree to prefer Go. It just seems easier to get a working Go-server instead of having to setup things like Tokio and whatever else is needed to get a server in Rust.

Modern C# has excellent compiler level type collection. It can be done.

I ended up making my own Optional type in Go to handle optional parameters, but the function signatures got too uncontrollably large, so I then bundled parameters into structs of Optionals. It was a bit tedious and strange, but it worked first try and took just a few minutes to figure out. Go could be improved, but it is pretty damn good already.

But PHP has ===

Both are interesting, but Go seems to be more practical.

just toss on a little 'a .. what happens... ooohhh boy. I feel this in my bones, in my soul.

Why is c# not in the conversation? In Australia from my experience most of the jobs are with c#

I always use the most suitable tool for the problem I'm solving. Yet, I cannot think of a single problem that I may ever face that would have warranted using Go. Of course I'm very biased - I don't have many use cases for languages with a GC, as most of the things I do are real-time. I can think of a couple of cases where I'd use Rust instead of C++ though, so for me Rust beats Go. Another issue I have with Go is that it's a very low level language, much lower level than Rust and C++. Why? Because Rust have proper AST macros. C++ have Turing-complete templates. Go got nothing. Not a single tool for building higher levels of abstraction. And any meta-language (even tiniest of Forths) is infinitely more powerful than any fixed language.

Imo golang with results trumps rust But do I love rust? Yes

I'm a Rust developer and my hair is naturally grey. Why? Because I've seen it all - C, C++, Java, Python, Go and now Rust. Oh, BTW I'm 53 years old.

Ahhhh, so that's why after years of C++ my hair remains in its natural color!

Rust is a language, Go is like shitting in a hat and wearing it (another defunct google graveyard project)

Bro i just wanted say you are my hero

I'm using typescript in the backend and I find sharing code between the client and server valuable. I wish I can do the same in Go.