Rust vs Go: Which is best? THE Definitive Answer 

That’s it I’m writing a language combined with the good from both Go and Rust. I shall call it Gusto.

23:41 "Rust Runtime crashed when I introduced ridiculous levels of parallelism" This is because std::thread is not the same as tokio::task or Go's go. std::thread actually creates an operating system thread through the OS's native interfaces, and the operating system can impose a limit to the number of threads that your program can spin up. It has that overhead of the OS needing to initialize structures and put it in the scheduler. tokio::task and go, meanwhile, are greenthreads. These are fake threads that are scheduled by the tokio or go runtime, and executed in a pool of working native OS threads. OS threads are better for getting the most that you can out of your computational and memory resources. Greenthreads are better for I/O heavy tasks where, most of the time, the threads are sleeping while they wait on networking or filesystem operations.

14:40 this is not how to iterate over a string (or the characters of a string) in rust, and it's not a naive solution either IMO .chars().nth() cannot be compared to indexing as it does significantly more work. strings in rust are utf8 encoded. they are a wrapper over an array of u8s, where a character may be multiple bytes wide (i.e. 🦀 becomes [240, 159, 166, 128]). because of that, you can't index into the string and expect to get a char out of it. at least not in O(1) time. if you do want to index into the raw bytes and get a single byte (not a character) at a specific index (which is what the code does), one can use str.as_bytes()[i]. this is what Go does when you index into a string. "🦀"[0] returns "ð", not the real emoji. "🦀".chars().next() returns the emoji. when you do .chars(), an iterator over the characters is created, and every time you call `.next()` on the character iterator (which `nth()` does), it walks the array of u8s as many bytes as it has to to decode a full character. `nth()` continuously calls `next()` on the iterator as many times as it has to yield the character at a given position. this means that creating an iterator and calling nth *on every iteration* means walking the string from the start of the string, up to the character index every time. you effectively have to decode the utf8 string on every iteration up to character index `i`. the solution is to create one iterator outside of the loop and just iterating over it, so you don't start decoding the utf8 string at the very beginning of the string on every iteration, but where you left off in the previous iteration. if you were to compare this to equivalent Go code, you would have to add a for loop that does nothing but iterate from 0 to i before getting the character inside of the loop. also, iterators often eliminate boundary checks, so thats another reason to prefer iterators over manual for loops again 21:05 and 27:48 mentions how strings in Rust are inferior, which isn't true. the code that was shown was not a naive solution that someone knowing utf8 would implement. other languages either encode strings differently, such as javascript where strings are UTF16, in which case string indexing just works, or it's a hidden implementation detail and indexing is O(n), *or* indexing just returns the raw byte at a given index (like go). 27:18 rust is data-race free, but not race condition free. race conditions aren't memory errors, and they are safe.

Nice comparison, but I still think that I would strongly consider Go. If I were starting a company today (I did in 2000, but that was before Go or Rust; we used Java), I would also have to consider how difficult it would be to hire good developers. If my project was written in Rust, I would need to find developers who were already competent in the language. If I chose Go, I could probably hire people who were already expert programmers in any language, even if they did not know Go. I could give them a copy of a good Go book (The Go Programming Language, by Donovan and Kernighan, maybe, or one of the newer excellent books) and know that the new developer could learn the language in few days.

Initially I thought "Nice clickbait", but it turned out not to be clickbait, good stuff man!

It feels like the point of Rust's compiler was missed here... yeah, it's phenomenally slow, because a point that's regularly emphasised with it, is that it's running slews of compile-time checks for things like memory errors you'd encounter in other languages, to the extent you'd might be able to call it something like "Compiler Oriented Programming"...

6.5/5 would watch again. 😁 I like that you actually show some code examples side by side.

1. To start project in go just say "go mod init ". 2. There's good way for project structure not wrong way except files in one folder is package have to same pkg name and all your packages in module. 3. Testing is more then unit testing in go you can make benchmarks, code m coverage, race detection, profiling and much more with only command line flags. 4. Unused variable and packages also non implemented functions increases compilation time. 5. Note: Concurrency is different the parallelism and go implemented both the examples you've used in this presentation is more like parallel version. To use goroutine in jus type go in front of the function if it's returning values or talking to other goroutine use channels not wait groups.

Having someone with such an intense background in development do a deep-dive like this is INVALUABLE. Thank you for taking the time to put this presentation together - I hope you give this talk at a few conferences to help spread the info. It was great to listen to.

Really appreciate the comprehensive breakdown of the strengths of each language. I'm currently a comp sci student taking C++ courses and both the syntax as well as ease of use of GO has me jealous. Look forward to more videos!

Almost 9 years of C straight.. sounds like a prison term! A minimal security prison though...

After using other languages for a while, and now experimenting with Rust and Go, what are your thoughts on C now? Would you still choose it for any use cases besides the obvious compiler availability ones?

Thanks for great video! I never be able to compile golang into a static library. Upon checking with ldd or readelf command, it still depends on standard library dynamically. Compile with -static flag won't help me either. Any suggestion on this? (I use go1.17.3)

I like writing code using TDD and the amazing speed go compiles makes red-green-refactor really nice.

Thanks. Especially from the point of view of a programmer with previous c/c++/java experience.

While Rusts Strings can be a bit harder to work with, they are at least 100% correct. It forces you to handle the Utf-8 correctly, which can be a bit annoying for simple scripts, but is better for bigger projects.

I love Go and Rust as language to develop projects. Both are powerful ver well. Thank for reviewing both.

Great video, but I would suggest you look into ways around the "must be used" variable issue for go. It is a pain in the butt at first but there are ways around it. I would also argue channels in go are a little easier to work with compared to rust. For rust, cargo check is your friend, it lets you ensure code will compile much faster than cargo build, that way you arent waiting for code to compile since rust is slow just to have it fail 80% of the way.

Hey Michael, if I was to use rust or go as the language on my server, which language would require me to write more lines of code?

Silly to have an 'overall' winner. Go has generics now, so is this invalid now?

It was really nice comparison, very deep analysis of both languages, but it would have been great if you have shown some real time statistics, like when you say rust is at least twice faster. Thanks

Thank you sir. I watched all the way through. I appreciated you showing side by side code. I had already chosen Rust as my next systems level and performance/security oriented language, but I wanted to understand where and when Go might be implicated. Very clear. Even after just two days using Rust and an hour or two on Go your information was clear and relevant. One hopefully constructive comment: on the comparison slides where the bullet points for the each language's score for the given slide topic, the bullet items are often just the inverse of the other language. That's fine and appropriate for the slides themselves, but when presenting you could be more succinct and possibly add additional color or show more code by condensing the spoken delivery to just saying the statements once, as in something like: "Go has a clear and intuitive way of providing an abstraction of treating a string as an array of characters, whereas Rust uses an arcane syntax." You could now use the extra time to expand on that statement rather than repeating it more or less for each language. This is something I was taught 30 years ago by a mentor when I worked in Silicon Valley at Symantec. These days I'm a CTO and mentor people myself. Great video.

love you man, helped a lot even though some codes were not the conventional rust way, it really showed your point regardless. Thanks again

This was very helpful. Thank you!

Just so you know your validate string examples are not an exact comparison. Rust strings are always valid UTF-8. This is not true for go. Go can have valid utf8 but its not enforced by the default string. For your GO code what you do is grab the byte out of the string. Depending on what you wanted the byte could be invalid(if its the second byte of a utf8 character). You then turn it into a rune. I'm pretty sure that does "nothing" as its not going to change it to UTF8. But you can then use it as a "char". In the original rust code you get a UTF8 character out of the string. This requires parsing up to the first 4 bytes. You then do this over and over again. To get the Nth character in utf8 you must parse the previous ones. Basically you were doing more work then you needed to. You could have done something like. If pass.is_ascii(){ Let bytes = pass.as_bytes() Prev = bytes[0] //you know its ascii and can treat it like the go string or more correctly a non null c string. ... Else{// its utf8, you must grab chars not bytes Let prev = pass.chars().nth(0) //could even be replaced with the first next() iterator call. For char in pass.chars().skip(1).take(5){ ... I typed this on my phone so there may be a few errors. Basically the restriction you talk about is less of a rust restriction and more of a utf8 one. A pure GO(c or c++) utf8 string would have the same issue. Hope that all makes sense.

That’s a good talk! I guess Rust compilation times are slow(er) because it does a lot of checks behind the scene (I’m pretty sure you’ve seen Rust compilation errors telling you about dangling references etc, that gives me a feeling of running a static check analyzer and they’re kinda slow), whereas Go just compiles the program as long as it’s syntax errors free, but it leaves you with all the dangers of null pointers, dangling references and so on.

Michael, thank you for the fantastic videos! I'm trying to pick a language for my project - I'm deploying ML models on a server and running them on my backend/deploying docker containers. Which language do you think would fit better under the following constraints: 1) A lot of networking programming: preferably with pre-existing tools to deploy my models/apps 2) Good Python integration: most of our code still runs on PyTorch, and I'm not sure we're going to do inference in other language in the near time Thanks!

Oops someone else already said this Could your validate extra function just use the chars iterator directly? You would still take the first character as you did before, but then you'd do for test in password.chars().skip(1).take(5) { // rest is identical } there could be something wrong with this that I'm missing though.

I'm a little confused about the single binary bullet point in the first comparison... Doesn't rust do this already, albeit with large binary sizes because everything gets popped into the single binary (static linking) by default and you have to turn on dynamic linking as an option?

Go's module system initialization is just "go mod init", I don't think its that weird, and also has pprof for flamegraphs, but overall, great video!

Nice analysis. At 24:08 you compare the go vs rust concurrent dowork function. I wish you would've use the more compact func signature using the keyword int only once instead of repeating it 4 times. (a, b, c, d int)

I got hangup over how go imports a package that you created in your project

Great Job! Would love a Scala vs Julia

Robust comparison!!! Thank you

That's a nice comparison. One thing that's different between is the ease of learning go. But in like rust alot due to memory safety performance.

You said that go is better when it comes to strings but rust is 2x+ faster when converting chars to u8’s. Could you expand on that?

A performance difference between `fn` and `impl Fn` sounds suspicious to me. Could you link to any code sample that's able to repro this? Note that `impl Fn` is actually *static* dispatch, not dynamic. My guess is that if we put together benchmarks that actually did dynamic dispatch in both cases, they would perform the same.

For your slow string implemenation, I think that your Go version should have given you the insight that you're traversing a UTF-8 string. I think that your initial version that was slow converted each UTF-8 character in the string to a UTF-32 (rune) array on every iteration of the loop. Since Go would have given you a copy in a new allocation each iteration, I'd bet a Go version of that same procedure would be slower. Also, Go and Rust syntax are both pretty good. Syntax isn't as much of a human concern as it is a machine concern speed wise, but human understanding is manditory. I believe that they both do a better job than C++ and maybe C. Zig almost looks like Rust because it was already very good.

For the problem at 16:10 you probably should have iterated over the string with the password.chars() ie for test in password.chars { /* do stuff */ }

you can create static binaries in Rust using musl and apline images docker images, so I don't really think that Go is that much of an advantage here. Although if an application is string heavy Go may be a little easier.

Great video, excellent information

I have a theory why rust refused to launch your million threads: when using standard rust threads you’re relying on actual Os-threads and when using Tokio I think you’re using green threads

Very straightforward, thank you

Amazing work

Hey, I left a few comments that were slightly critical about the languages, but please don't take them as criticism of your video. It's a great video, and I enjoy the subjects of Go, Rust, and programming languages in general. Please make more videos on this subject. It's great fuel to forge ideas about what's best to use, and why.

Amazing, someone that actually did the research. Still, I'd argue that Go and Rust both have their niches and will probably stay strong in them, assigning an overall winner is maybe fitting for you but for most others an oversimplification. The one thing where I'd have wished you'd have taken a broader approach is stuff like embedded programming and compatibility with other languages. I assume at some point rust is gonna take over most of embedded programming from C and C++, even if just for its memory security. Also Rust has some Foreign function interface capabilities for C and C++, I'd love to know how well Go handles that. One thing where I personally don't agree with the praise of Rust is its type system. Yeah its a vast type system and you can do a lot of stuff with it, but I think they did a few things that make it quite unpredictable (or "arcane") that could've been done better. Maybe I'm just spoiled by Typescript. But in a lot of cases I understand why Rusts type system is limited, but in others I wonder if it shouldn't have been limited some more, while providing some freedoms elsewhere. One specific thing I'm not a fan of is how in Rust type information can "flow up" the lines of code, I. E. For a std::Vector, you can declare it without elements or a type which gets inferred from the assignments. This makes the type system sometimes quite flaky. If Rust wouldnt do that it would make a feature easier that I personally would really love, that is inferred return type. Especially with a Result with many error options as return type, the return type can be quite annoying to handle and break your compilation all the time.

What do you think? Is RUST going to be next big thing in terms of opportunities? I know 4 languages, should I pick Rust as next one? BTW I am currently working on Golang.

The editor's font is beautiful, which font do you use？

Thank you for the video :)

Nice comparison💯❤‍🔥

3:20 - “abouut” CANADIAN SPOTTED

Also, as far as compilation speed, Rust is slower, the slowest among "compiled" languages, but Go is not faster than D (unless you write really heavy template meta programming stuff).

You can mute variables or comment them to compile correctly

With the new version of Go supporting Generics, you can argue that Go would be the winner in this debate, because you counted 1 point off because it didn't have generics. Also, you can check for race conditions with the: "go run -race main.go" command It will not compile if you have race conditions, just like rust. So when everything is added up, Go wins by a .5 point margin.

You don't have to use the glibc crates though. You can write them yourselves.

I'm confused now, does rust gonna replace c++ sooner?

Another excellent video! Great concise analysis. Please keep these videos coming. Would also appreciate videos on rust and go projects.

Personally, I am very happy with go's insisting on using declared variables and imported modules. Letting that slide makes for problems later. In C, it's #include , in Go, it becomes gratuitous dependencies that really don't exist.

Generics are now part of Go as of version 1.18.

Go is more developer friendly and easy to learn n understand.⚡

I think the community and package manager really make a language. Most devs (outside creative hubs in US) need a language that’s supported on AWS and Azure. While I keep an eye on both rust and go, neither will help me or my clients go more than what I use python and c# for. 90% of jobs in my area need these skills

Nice video

great, cheers

I'm very new to Go, & programming in general, but it seems like at 24:15 you are comparing the concurrency(goroutines) of Go to the same in Rust(tokio) but you did not use the "go" keyword in front of the func definition while you did use the "async" keyword in front of the same definition in Rust. To my knowledge, you aren't using concurrency in go without calling "go" on the function definition, which would explain the lackluster experience you had... Go also seems to emphasize that concurrency & parallelism aren't the same, I'm no CompSci student so I'm not versed on the difference. Please let me know if I'm misunderstanding... Thanks for the very informative content!

Thorough and impressive.

Great comparison. Like some others I thought this was a bit click bait, but scoring made it pretty empirical. Not used Go in years but love Rust because of its features and ecosystem.

I would use go and rust in different circumstances

One thing I like about both languages is cross-compilation, which is necessary while developing an embedded system. Way better than C/C++!

Project setup in go has nothing to envy to cargo. Go module and Cobra and viper are fantastic for command line. Go modules are fantastic for dependency. You don't need generic to write complex application thank to go interface. However since 1.18 generic is supported. Regarding syntax, go is much simple to learn and faster to write for average developer. Go routine is so easy to implement. The overhead is ridiculously low....

Please, create night versuion :DDD staring this wight sheet is a pain!

What about garbage collection?

In rust you can get chars of strings using the standard indexing syntax, which is way more performance. When using your weird chars method, it creates an iterator, counting up until the expected element is reached, which is horrible for performance. EDIT: I think the indexing thing is even more naive

In project setup: - Running 'go tool' in http mode will not only give you flamegraph but other nice visuals. In Syntax: - Their is no need to convert to rune. - for debugging purposes there is no need to use fmt.Println, you can use built-in function 'println()'.

Go also depend on LibC

too close each other - less than the statistics error of the evaluation method

If(want to get shit done quickly == true) { use Go} else if(Want to do closer to low level shit that is very performant such as a game engine == true) { use Rust}

At 18:45 you mentioned getting frustrated having to use variables, just use ‘_ = varName’ and that will get Go to ignore it.

You forgot the amazing message compiler error in Rust, it's so amazing that I feel pity for the C++ one. Also, the syntax in go is so easy that you can read go code just fine, even if you have never seen go code before (except concurrency)

Go has discards, so dont need unused variables.

Best for what should be the question

Strings are not arcane in rust, they are pretty well handled, it's just that what you did is completely wrong. You need to understand that in utf8, you never know wether a character will be 1, 2, 3 or 4 bytes, so getting the nth character means that you will have to go through all the preceding characters as you can't just say that you take the nth element of the bytes array. For example, é takes two bytes, so if you want chars of "héllo", 1st char is h and takes just 1 byte, but 2nd char é takes two, so third char is not the 3rd element of the array but the 4th, that's why the complexity of .chars.nth(i) is O(i), so instead, you should just have iterated through .chars() with a for loop. Then you would have gone through the string without any issue in speed. So you didn't need runes or anything, you just needed plain for c in my_str.chars() { // do something with `c` } which is waaaay simpler than what you did I had a good blogpost about character encoding in the past but lost it. I just googled the thing and that post seems legit, so it might be a good read on the concept medium.com/jspoint/introduction-to-character-encoding-3b9735f265a6#:~:text=A%20character%20encoding%20is%20a,characters%20based%20on%20their%20values. There is also that for string handling in rust stackoverflow.com/questions/22118221/how-do-you-iterate-over-a-string-by-character

in go you will be stuck with standard library. frameworks is kinda frowned upon

I find Go more practical and easier for web servers, which is all I do. I agree on the huge appreciation of Rust by the community, but I believe one should use right tool for the job. For web, Rust is an overkill.

Hmmm.. many points for each language seem to have been missed.

I would use the "chars()" function of a string to return an iterator, which I believe should be very performant (and is also pretty idiomatic).

absolutely. you can see that it's rust from a mile away. and I say that as a dude about to do a job full time in go :D

Now, I'm confused 🤔

One aspect is completely missing where Go blows Rust out of the water big times: Ecosystem maturity. IMHO this is THE most important aspect of a language because a language with a young ecosystem will not get you anywhere. Now, Rust's ecosystem is not entirely bad but it's young and especially everything network-related is a mess thanks to async vs non-async vs tokio vs async-std, you name it. So in regards to networking, the ecosystem is actually split which is much worse than simply be unmatured. That's really a problem in the Rust world and currently there is no cure.

The string thing about rust was because Rust uses unicode strings by default. They can't be indexed, because chars are not fixed size. The "string.chars().nth(i).unwrap()" actually loops through the entire string up until the character index you requested. This is a significant difference from C, where strings are just arrays of bytes, with ascii encoding assumed. Rust is weirdly pedantic like that in many cases. For example, sorting by float can be pain, because they lack total order property due to NaNs.

Rust is really annoying to setup crates in, because you _HAVE_ to specify a version string for every crate, and the format is really weird. Sometimes you just want to use the most recent version.

Since Go doesn't support generics and all variables must have type declaration, the compilation speed is HIGH. But Go will add generics and inferred types, so compilation speeds will go down

I'm simple Python user and Rust scares me... I prefer Go ;-)

Rust has built-in benchmark tests that are as descriptive as benchmarks in Go - the only thing you need to add to use built-in benchmarks is #![feature(test)] 🙂 more on benchmarking: nnethercote.github.io/perf-book/benchmarking.html

But there is more jobs for Golang ...

Although still unstable rust, I find `cargo bench` via libtest provides comparable clarity for the benchmark report.

Go has generics now.

26:30 glibc vs musl issues sometimes apply to Go too. For example we weren't able to find full replacement for libvips in pure Go. Vips has Go binding, but it requires glibc. So I needed to rewrite some parts of libvips in pure Go to make our service work on Alpine.

Are you Canadian?

Prediction: "It depends"

Uses Arch BTW